Kathleen Moriarty writes: > Thanks for your review of this errata report. As I read your response, this > should be rejected. If a note like you suggest might be added, > > "We could add note saying that format A.4.1 MUST be used when > generating the RSASSA-PSS with default parameters, but A.4.2 can also > be recognized." > > should be added, then I think that should be in a separate editorial errata > and this one should be rejected. > > Does that sound good?
Works for me. > On Tue, Mar 24, 2015 at 11:55 AM, Tero Kivinen <[email protected]> wrote: > > RFC Errata System writes: > > The following errata report has been submitted for RFC7427, > > "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) > ". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=7427&eid=4295 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Annie Yousar <[email protected]> > > > > Section: A.4.2 > > > > Original Text > > ------------- > > Here the parameters are present and contain the default parameters, > > i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, > > saltLength of 20, and trailerField of 1. > > > > 0000 : SEQUENCE > > 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) > > 000d : SEQUENCE > > 000f : CONTEXT 0 > > 0011 : SEQUENCE > > 0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) > > 001a : NULL > > 001c : CONTEXT 1 > > 001e : SEQUENCE > > 0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 > > 002b : SEQUENCE > > 002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) > > 0034 : NULL > > 0036 : CONTEXT 2 > > 0038 : INTEGER 0x14 (5 bits) > > 003b : CONTEXT 3 > > 003d : INTEGER 0x1 (1 bits) > > > > Name = RSASSA-PSS with default parameters, > > oid = 1.2.840.113549.1.1.10 > > Length = 64 > > 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0 > > 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016 > > 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b > > 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101 > > > > > > > > Corrected Text > > -------------- > > If the default parameters are used, i.e., hashAlgorithm of SHA-1, > > maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField > > of 1, the parameters MUST NOT be encoded according to the > > Distiguished Encoding Rules (DER) of ASN.1. Therefore the encoding > > is the same as of A.4.1. > > Not true. In the RFC 4055 the section 3.1 says that even when the > default values are used the implementation MUST understand both > formats, i.e. the case where the default value is omitted and the case > where the default value is explictly given: > > >From RFC4055 section 3.1: > > hashAlgorithm > > The hashAlgorithm field identifies the hash function. It MUST > be one of the algorithm identifiers listed in Section 2.1, and > the default hash function is SHA-1. Implementations MUST > support SHA-1 and MAY support any of the other one-way hash > functions listed in Section 2.1. Implementations that perform > signature generation MUST omit the hashAlgorithm field when > SHA-1 is used, indicating that the default algorithm was used. > Implementations that perform signature validation MUST > recognize both the sha1Identifier algorithm identifier and an > absent hashAlgorithm field as an indication that SHA-1 was > used. > > In this case we are not actually doing either one of those options, we > are not generating signature, and we are not validating them. In this > document we are simply indicating what kind of signature will follows > this binary blob. Yes, when generating those ASN.1 objects for default > values implementations should use the A.4.1 version, but they might > also want to understand the version specified in the A.4.2. > > Note, that in some cases the implementations might simply take the > AlgorithmIdentifier pieces from their own cerificate and not generate > it at all, and this might cause them to take whatever the CA vendor > generated for them. > > Actually when checking for the RFC4055 I notice it says that same > thing (MUST omit in generate, MUST recognize both) for everything else > (hashAlgorithm, maskGenAlgorithm, and trailerField) expect for > saltLength... I do not know if this means that for saltLength we > should actually not encode the default as number or if this is just > sloppy writing of the RFC4055... > > > 0000 : SEQUENCE > > 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) > > 000d : SEQUENCE > > > > Name = RSASSA-PSS with default parameters, > > oid = 1.2.840.113549.1.1.10 > > Length = 15 > > 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 > > > > > > Notes > > ----- > > Section 3 requires the use of DER: > > The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of > PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished > encoding rules (DER) [CCITT.X690.2002]. > > Yes, when generating them they needs to be in DER, when matching the > values sent from the other end, the matching can be looser. > > We could add note saying that format A.4.1 MUST be used when > generating the RSASSA-PSS with default parameters, but A.4.2 can also > be recognized. > > If the implementation has real ASN.1 parser this is exactly what it > will do automatically. > -- > [email protected] > > -- > > Best regards, > Kathleen > -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
