[lamps] Re: [pkix] Re: Re: Re: RFC5280 errata (3 986)

Given this, I’m not sure the rename is worth the effort.
 

Fully agree.

 

From: Corey Bonnell <[email protected]>
Date: Wednesday, June 5, 2024 at 11:55 AM
To: Carl Wallace <[email protected]>, David Benjamin <[email protected]>
Cc: IETF PKIX <[email protected]>, LAMPS WG <[email protected]>
Subject: RE: [pkix] Re: [lamps] Re: Re: RFC5280 errata (3986)

 

Hi Carl,

Replies inline.

 
[CW] I don’t see where there is any ambiguity with signature in the TBSCertificate field since it is a different type and in a different structure. 
 

The ASN.1 grammar is not ambiguous, but referencing these two identically named fields in prose may introduce confusion for the reader. As a concrete example, here’s a snippet from clause 7.2.2 of X.509 2019-10:

 

“A CA generating a public-key certificate with the alternative cryptographic algorithms and alternative digital signature

shall:

– when generating the value in the altSignatureValue extension, exclude the signature component

and the altSignatureValue extension from the public-key certificate, and generate the digital signature

over the remaining DER encoded public-key certificate using the algorithm specified in the

altSignatureAlgorithm extension; and

– when generating the value in the signature component, the subjectAltPublicKeyInfo, the

altSignatureAlgorithm and the altSignatureValue extensions shall be included in the DER

encoding of the public-key certificate”

 

“signature component” refers to two different fields (the first bullet is referring to the “signature” field of the TBSCertificate and the second bullet is referring to the “signature” field of the Certificate), which is a subtlety that was lost on every implementer (3 or 4 different implementations, IIRC) of “alt public keys” certificates at a recent IETF PQC hackathon. If different field names were used, this text would be much easier to understand.

 
The TBSCertificate field is arguably the one that is more poorly named, so if fussing with field names I’d change that to signatureAlgorithm.
 

Agreed. Perhaps “tbsSignatureAlgorithm” to differentiate it from the “signatureAlgorithm” field of the Certificate type?

 
I don’t see where a change to either structure is any more or less of a sailed ship.
 

I’m still relatively new here, so perhaps I’m over-estimating the amount of effort, but renaming these elements would entail changes in RFC 5912 in addition to any changes in 5280. Given this, I’m not sure the rename is worth the effort.

 

Thanks,

Corey

 

From: Carl Wallace <[email protected]> 
Sent: Wednesday, June 5, 2024 10:18 AM
To: David Benjamin <[email protected]>; Corey Bonnell <[email protected]>
Cc: IETF PKIX <[email protected]>; LAMPS WG <[email protected]>
Subject: Re: [pkix] Re: [lamps] Re: Re: RFC5280 errata (3986)

 

Inline replies to David and Corey…

 

From: David Benjamin <[email protected]>
Date: Tuesday, June 4, 2024 at 11:08 AM
To: Corey Bonnell <[email protected]>
Cc: IETF PKIX <[email protected]>, LAMPS WG <[email protected]>
Subject: [pkix] Re: [lamps] Re: Re: RFC5280 errata (3986)

 

I also agree that signatureValue is better here. Ideally the TBSCertificate "signature" field would be named differently, but we're a bit stuck with that. signatureValue also matches section 4.1.1.3. Relative to all that, the name in the appendix seems to just be a mistake.

 

[CW] signatureValue may be better and the appendix may be wrong, but the ASN.1 modules are what people use to generate code. Changing field names in ASN.1 modules will break code that expects the field to be named signature. It may be worth noting that if the field is changed here, it probably also ought change in RFC 5912, where SIGNED{} uses signature as the name of the field. A sad part of that change is SIGNED is used all over the place.

 

On Tue, Jun 4, 2024 at 9:28 AM Corey Bonnell <[email protected]> wrote:

I think erratum 7634 (https://www.rfc-editor.org/errata/eid7634) also needs to be considered here. It appears that the ASN.1 “modules” in A.1 and A.2 refer to the “signatureValue” field as “signature”, whereas section 4.1 (and erratum 3986) refers to it as “signatureValue”.

It would be good if there is alignment between 4.1 and the appendices on the name of this “signature”/”signatureValue” field. My preference would be to name the BIT STRING field that conveys the signature value as “signatureValue” to avoid any ambiguity with the TBSCertificate “signature” field, but that ship has sailed.

[CW] I don’t see where there is any ambiguity with signature in the TBSCertificate field since it is a different type and in a different structure. The TBSCertificate field is arguably the one that is more poorly named, so if fussing with field names I’d change that to signatureAlgorithm. I don’t see where a change to either structure is any more or less of a sailed ship. 

Thanks,

Corey

 

From: Santosh Chokhani <[email protected]> 
Sent: Tuesday, June 4, 2024 9:08 AM
To: 'Deb Cooley' <[email protected]>; 'IETF PKIX' <[email protected]>; 'LAMPS WG' <[email protected]>
Subject: [pkix] Re: RFC5280 errata (3986)

 

Deb,

 

I agree with erratum 3986.  It should be marked “technical”.  As the author or erratum points out “signature” is a field in the certificate identifying issuer signature algorithm used to sign the certificate.

 

From: Deb Cooley [mailto:[email protected]] 
Sent: Tuesday, June 4, 2024 6:04 AM
To: IETF PKIX <[email protected]>; LAMPS WG <[email protected]>; Santosh Chokhani <[email protected]>
Subject: RFC5280 errata

 

Here is the list of errata for RFC 5280.  Are they correct, incorrect, or is there debate about it.  Let me know which it is, and I'll mark them either 'verified', 'rejected', or 'hold for document update'.

 

You can find the details here:  https://www.rfc-editor.org/errata_search.php?rfc=5280 

 

There are 8 that are listed as 'reported'.

3986

5802

5938

6414

6830

7164

7634

7661

_______________________________________________
Spasm mailing list -- [email protected]
To unsubscribe send an email to [email protected]

_______________________________________________ pkix mailing list -- [email protected] To unsubscribe send an email to [email protected]

_______________________________________________
Spasm mailing list -- [email protected]
To unsubscribe send an email to [email protected]