RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

RFC 5915, "Elliptic Curve Private Key Structure", June 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 2698
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2011-01-31
Verifier Name: Stephen Farrell
Date Verified: 2011-11-12

Section 4 says: 

PEM encoding the DER-encoded ECPrivateKey is
common; "Proc-Type:" and "DEK-INFO:" fields [RFC1421] followed by the
DER-encoded ECPrivateKey are sandwiched between:

It should say:

PEM encoding the DER-encoded ECPrivateKey is
common; "Proc-Type:" and "DEK-Info:" fields [RFC1421] (each on a new line),
followed by a blank line, and then followed by the Base64 encoding (see
Section 4 of [RFC4648]) of the DER-encoded ECPrivateKey are sandwiched
between:

Notes:

Needed to indicate that the Proc-Type and DEK-Info are on separate lines and that there is a blank line between the DEK-Info and the ECPrivateKey. Also it's not clear that the ECPrivateKey structure is PEM encoded during this process - it is. And finally, "DEK-INFO" should really have been "DEK-Info". This aligns with current industry practice.

Errata ID: 3962
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2014-04-14
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-24

Section 3 and A says: 

   ECPrivateKey ::= SEQUENCE {
     version        INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
     privateKey     OCTET STRING,
     parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
     publicKey  [1] BIT STRING OPTIONAL
   }

It should say:

   ECPrivateKey ::= SEQUENCE {
     version        INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
     privateKey     OCTET STRING,
     parameters [0] ECParameters  OPTIONAL,
     publicKey  [1] BIT STRING OPTIONAL
   }

Notes:

ECParameters is not a parametrized type. This means that it cannot be used as a parameterized type by passing in the NamedCurve set as a parameter.

Status: Reported (1)

RFC 5915, "Elliptic Curve Private Key Structure", June 2010

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 5008
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Smith
Date Reported: 2017-04-30

Section 3 says: 

Though the ASN.1 indicates that the parameters field is OPTIONAL,
implementations that conform to this document MUST always include
the parameters field.

It should say:

Though the ASN.1 indicates that the parameters field is OPTIONAL,
whether the parameters field is optional, required, or forbidden
depends on the context. When serializing an ECPrivateKey into a PKCS#8
file, the parameters field MUST NOT be included in the serialization.
(This is required to interoperate with PKCS#11.)

When parsing an ECPrivateKey within a PKCS#8 file, when the parser
encounters an ECPrivateKey without a parameters field, the parser MUST
use the parameters from the PKCS#8 privateKeyAlgorithm field, and MUST
NOT reject the key solely due to the missing parameters field.

When parsing an ECPrivateKey within a PKCS#8 file, when the parser 
encounters an ECPrivateKey with a parameters field present, the parser
SHOULD reject the key if the ECPrivateKey parameters do not exactly
match the the PKCS#8 privateKeyAlgorithm parameters.

More generally, these rules should be followed whenever parsing an
ECPrivateKey within a larger structure that contains the parameters.

Notes:

Section 1 notes that we must put "id-ecPublicKey, id-ecDH, or id-ecMQV (from [RFC5480]) with the namedCurve as the parameters in the privateKeyAlgorithm field;"

Thus, in a PKCS#8 file containing an ECC private key, there's no need to include the parameters in the ECPrivateKey field, because they are already in the privateKeyAlgorithm field.

PKCS#11 says "Since the EC domain parameters are placed in the PKCS #8’s privateKeyAlgorithm field, the optional parameters field in an ECPrivateKey must be omitted." - http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf

Further, with OpenSSL 1.0.2h and the OpenSSL trunk, the `openssl genpkey` command only encode the parameters in the PKCS#8 privateKeyAlgorithm, not in the parameters field of the ECPrivateKey:

openssl genpkey -algorithm EC \
-pkeyopt ec_paramgen_curve:P-256 \
-pkeyopt ec_param_enc:named_curve | \
openssl pkcs8 -topk8 -nocrypt -outform der > p256-private-key.pk8

Thus, a parser that wishes to interoperate with OpenSSL cannot enforce the MUST requirement here.

Report New Errata



Advanced Search