Re: [IPsec] [Editorial Errata Reported] RFC7427 (4295)

[Kathleen Moriarty <[e-mail]>]

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?

Thanks.

On Tue, Mar 24, 2015 at 11:55 AM, Tero Kivinen <[e-mail]> 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 <[e-mail]>
> >
> > 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.
> --
> [e-mail]
>



-- 

Best regards,
Kathleen