RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Rejected (2)

RFC 7427, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)", January 2015

Source of RFC: ipsecme (sec)

Errata ID: 4295

Status: Rejected
Type: Editorial

Reported By: Annie Yousar
Date Reported: 2015-03-10
Rejected by: Kathleen Moriarty
Date Rejected: 2015-03-31

Section A.4.2 says:

   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


It should say:

   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.

   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].

KM: Reviewed by expert and response provided.

--VERIFIER NOTES--
From Tero Kivinen

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 explicitly 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 certificate 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.


The 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.

Errata ID: 4296

Status: Rejected
Type: Editorial

Reported By: Annie Yousar
Date Reported: 2015-03-10
Rejected by: Kathleen Moriarty
Date Rejected: 2015-03-24

Section A.4.3 says:

   Here the parameters are present and contain hashAlgorithm of SHA-256,
|  maskGenAlgorithm of SHA-256, saltLength of 32, 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-sha256 (2.16.840.1.101.3.4.2.1)
   001e :         NULL
   0020 :     CONTEXT 1
   0022 :       SEQUENCE
|  0024 :         OBJECT IDENTIFIER  1.2.840.113549.1.1.8
   002f :         SEQUENCE
   0031 :           OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1)
   003c :           NULL
   003e :     CONTEXT 2
   0040 :       INTEGER   0x20 (6 bits)
|  0043 :     CONTEXT 3
|  0045 :       INTEGER   0x1 (1 bits)

   Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10
|  Length = 72
   0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0
   0010: 0f30 0d06 0960 8648 0165 0304 0201 0500
   0020: a11c 301a 0609 2a86 4886 f70d 0101 0830
   0030: 0d06 0960 8648 0165 0304 0201 0500 a203
|  0040: 0201 20a3 0302 0101

It should say:

   Here the parameters are present and contain hashAlgorithm of SHA-256,
|  maskGenAlgorithm of MGF1 with SHA-256, saltLength of 32, and 
|  trailerField of 1.
|  Note that since the trailerField has the default value it MUST NOT be
|  encoded according to the Distiguished Encoding Rules (DER) of ASN.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-sha256 (2.16.840.1.101.3.4.2.1)
   001e :         NULL
   0020 :     CONTEXT 1
   0022 :       SEQUENCE
|  0024 :         OBJECT IDENTIFIER  id-mgf1 (1.2.840.113549.1.1.8)
   002f :         SEQUENCE
   0031 :           OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1)
   003c :           NULL
   003e :     CONTEXT 2
   0040 :       INTEGER   0x20 (6 bits)

   Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10
|  Length = 67
   0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0
   0010: 0f30 0d06 0960 8648 0165 0304 0201 0500
   0020: a11c 301a 0609 2a86 4886 f70d 0101 0830
   0030: 0d06 0960 8648 0165 0304 0201 0500 a203
|  0040: 0201 20

Notes:

1. The maskGenAlgorithm is in fact not SHA-256 (2.16.840.1.101.3.4.2.1), but MGF1 (1.2.840.113549.1.1.8) based on SHA-256 (2.16.840.1.101.3.4.2.1).

2. 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].
--VERIFIER NOTES--
Per Tero Kivinen:

The id-mgf1 oid is there in the example, the tool I used didn't know
the name for it thus it just printed out the oid. As this does not
affect the binary object at all there is no problem in here.

> 2. 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, but RFC4055 says that:

trailerField

The trailerField field is an integer. It provides
compatibility with IEEE Std 1363a-2004 [P1363A]. The value
MUST be 1, which represents the trailer field with hexadecimal
value 0xBC. Other trailer fields, including the trailer field
composed of HashID concatenated with 0xCC that is specified in
IEEE Std 1363a, are not supported. Implementations that
perform signature generation MUST omit the trailerField field,
indicating that the default trailer field value was used.
Implementations that perform signature validation MUST
recognize both a present trailerField field with value 1 and an
absent trailerField field.

I.e. you should recognize both formats. Yes, we could have another
example also showing the object value to used when generating these
and when omitting the default values (like we do have for SHA-1).

Report New Errata