RFC Errata
Found 3 records.
Status: Verified (2)
RFC 5915, "Elliptic Curve Private Key Structure", June 2010
Source of RFC: IETF - NON WORKING GROUPArea 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 GROUPArea 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.