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

[Tero Kivinen <[e-mail]>]

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 <[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
> 

-- 
[e-mail]