Subject: [Curdle] [Technical Errata Reported] RFC8410 (6738)

From: RFC Errata System <[email-masked]>
Date: Tue, 16 Nov 2021 02:53:57 -0800 (PST)

The following errata report has been submitted for RFC8410,
"Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6738

--------------------------------------
Type: Technical
Reported by: Daniel Minder <[email-masked]>

Section: 7 and 10.3

Original Text
-------------
Section 7 says

   OneAsymmetricKey ::= SEQUENCE {
      version Version,
      privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
      privateKey PrivateKey,
      attributes [0] IMPLICIT Attributes OPTIONAL,
      ...,
      [[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]],
      ...
   }

2nd example given in both section 7 and section 10.3:

   -----BEGIN PRIVATE KEY-----
   MHICAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
   oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzgSEAGb9ECWmEzf6FQbrB
   Z9w7lshQhqowtrbLDFw4rXAxZuE=
   -----END PRIVATE KEY------

ASN.1 dump of this private key in section 10.3:

   The same item dumped as ASN.1 yields:

     0 114: SEQUENCE {
     2   1:   INTEGER 1
     5   5:   SEQUENCE {
     7   3:     OBJECT IDENTIFIER '1 3 101 112'
          :     }
    12  34:   OCTET STRING, encapsulates {
          :     04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69
          :     F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75
          :     58 42
          :     }
    48  31:   [0] {
    50  29:     SEQUENCE {
    52  10:       OBJECT IDENTIFIER '1 2 840 113549 1 9 9 20'
    64  15:       SET {
    66  13:         UTF8String 'Curdle Chairs'
          :         }
          :       }
          :     }
   81  33:   [1] 00 19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B
                 96 C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66
                 E1
          :   }

Corrected Text
--------------
Correct definition in section 7:

   OneAsymmetricKey ::= SEQUENCE {
     version                   Version,
     privateKeyAlgorithm       PrivateKeyAlgorithmIdentifier,
     privateKey                PrivateKey,
     attributes            [0] Attributes OPTIONAL,
     ...,
     [[2: publicKey        [1] PublicKey OPTIONAL ]],
     ...
   }

Example key in section 7 and 10.3:

   -----BEGIN PRIVATE KEY-----
   MHQCAQEwBQYDK2VwBCIEINTuctv5E1hK1bbY8fdp+K06/nwoy/HU++CXqI9EdVhC
   oB8wHQYKKoZIhvcNAQkJFDEPDA1DdXJkbGUgQ2hhaXJzoSMDIQAZv0QJaYTN/oVB
   usFn3DuWyFCGqjC2tssMXDitcDFm4Q==
   -----END PRIVATE KEY-----

ASN.1 dump of this private key in section 10.3:

     0 116: SEQUENCE {
     2   1:   INTEGER 1
     5   5:   SEQUENCE {
     7   3:     OBJECT IDENTIFIER '1 3 101 112'
          :     }
    12  34:   OCTET STRING, encapsulates {
          :     04 20 D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69
          :     F8 AD 3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75
          :     58 42
          :     }
    48  31:   [0] {
    50  29:     SEQUENCE {
    52  10:       OBJECT IDENTIFIER '1 2 840 113549 1 9 9 20'
    64  15:       SET {
    66  13:         UTF8String 'Curdle Chairs'
          :         }
          :       }
          :     }
    81  35:   [1] {      
    83  33:     BIT STRING {
                  00 19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B
                  96 C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66
                  E1
                  }
                }
          :   }

Notes
-----
OneAsymmetricKey is defined in RFC 5958. It does NOT define attributes and publicKey as IMPLICIT.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8410 (draft-ietf-curdle-pkix-10)
--------------------------------------
Title               : Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure
Publication Date    : August 2018
Author(s)           : S. Josefsson, J. Schaad
Category            : PROPOSED STANDARD
Source              : CURves, Deprecating and a Little more Encryption
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Nov 2021 09:12:52 -0500

Daniel:

RFC 5958 imports the definition of ATTRIBUTE from the PKIX-CommonTypes-2009 module in RFC 5912.

You will see at the top of the ASN.1 module in RFC 5958 the phrase "DEFINITIONS IMPLICIT TAGS".  This means that the definitions use implicit tagging unless the definition itself includes "EXPLICIT" to override the module default.

However, the PKIX-CommonTypes-2009 module in RFC 5912 has the phrase "DEFINITIONS EXPLICIT TAGS".  Thus, the Attributes SEQUENCE should have explicit tags as shown in the examples

Therefore, the only correction needed is the incorrect quote from RFC 5958 in Section 7 of RFC 8410.

ORIGINAL TEXT:

CORRECTED TEXT:

Hope this helps,
 Russ

> On Nov 16, 2021, at 5:53 AM, RFC Errata System <[email-masked]> wrote:
> 
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Daniel Minder <[email-masked]>
Date: Tue, 16 Nov 2021 15:11:45 +0000

Russ,

you are right. It seems I completely missed that header.
Since in section 7 there is no complete module definition and the "DEFINITIONS IMPLICIT TAGS" is missing here, one could perfectly argue that the "IMPLICIT" statement could be included for clarity.

I thought I came across a PKCS#8 / OneAsymmetricKey example in another RFC or a standard tool, but I cannot find it anymore. I was probably wrong here, too.

Please excuse the disturbance. I'm ok to reject the errata completely.

Thanks,
Daniel

-----Original Message-----
From: Russ Housley <[email-masked]>
Sent: Dienstag, 16. November 2021 15:13
To: Daniel Minder <[email-masked]>
Cc: Simon Josefsson <[email-masked]>; Roman D. Danyliw <[email-masked]>; Ben Kaduk <[email-masked]>; [email-masked]; Rich Salz <[email-masked]>; [email-masked]; RFC Editor <[email-masked]>
Subject: Re: [Curdle] [Technical Errata Reported] RFC8410 (6738)

Daniel:

ORIGINAL TEXT:

CORRECTED TEXT:

Hope this helps,
 Russ

> The following errata report has been submitted for RFC8410, "Algorithm
> Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure".
>
> use "Reply All" to discuss whether it should be verified or rejected.
> When a decision is reached, the verifying party can log in to change
> the status and edit the report, if necessary.
>

________________________________

Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen – Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO

This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Nov 2021 10:55:24 -0500

I do think it is appropriate to make the one change noted below.

Since the ASN.1 module at the end of the document does not reference OneAsymmetricKey in any way, this error in the body of the document did not impact the implementation that I did in any way.

Russ

> On Nov 16, 2021, at 10:11 AM, Daniel Minder <[email-masked]> wrote:
> 
> Russ,
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 25 Nov 2021 13:02:15 -0800

Hi Russ, Daniel,

I updated the errata report in-place but left it in state "reported".
Can you please confirm that the current version is accurate?

I think it would qualify to mark as "verified" (rather than "hold for
document update") since the correction is clear and unambiguous.

Thanks,

Ben