Elliptic Curve Private Key Structure
draft-turner-ecprivatekey-04

[Ballot comment]
The end of Section 1 says:
  >
  > When the public key is included, it is present in the ECPrivateKey
  > publicKey field not in the PKCS#8 publicKey field.
  >
  It would be more clear to say:
  >
  > There are two possible locations to carry a public key.  When one is
  > included, the publicKey field in the ECPrivateKey is used.  The
  > publicKey field in PKCS#8 is not used.

  In section 4, the document says:
  >
  > Local storage of an unencrypted ECPrivateKey object is out of scope
  > of this document.  However, one popular format uses the .pem file
  > extension.
  >
  PEM files support encrypted storage too.

  In section 5, the document says:
  >
  > Protection of the private-key information is vital to public-key
  > cryptography.  Disclosure of the private-key material to another
  > entity can lead to masquerades.  The encryption algorithm used in the
  > encryption process must be as 'strong' as the key it is protecting.
  >
  This is incomplete.  The consequences of disclosure depends on the
  purpose of the private key.  If a private key is used for signature,
  then the disclosure allows unauthorizes signing.  If a private key
  is used for key management, then disclosure allows unauthorized parties
  to acess the managed keying material.

1.a - Carl Wallace is the Shepherd. He's personally reviewed the I-D and
personally knows it's ready for IESG publication.
1.b - The document has been reviewed by IETF attendees. There are no
concerns about depth or breadth of the reviews.
1.c - There is no need for wider review.
1.d - There are no specific concerns that the AD and/or IESG should be
aware of.
1.e - The consensus is solid as a rock.
1.f - There has been no threat of an appeal.
1.g - The Shepherd has personally verified that the document satisfies
all I-D nits.
1.h - The document splits it references.
1.i - The document has an IANA consideration and it is consistent with
the main body (there are no IANA considerations).
1.j - The Shepherd has personally compiled the ASN.1 modules.

Technical Summary

This document specifies the syntax and semantics for Elliptic Curve (EC)
private key information.  This syntax and semantics defined therein are
based on a similar syntax and semantics defined in Standards for
Efficient Cryptography Group (SECG).  It is profiled for the IETF as the
ECPublicKey structure from SECG is profiled for the IETF in RFC 5480.

Working Group Summary

The publication announcement for this I-D was forwarded to the PKIX WG
for comment. Reviews resulted in 3 versions.  The 1st revision replaced
the conversion routine with an existing routine from RFC 3447 (reuse is
better than reinventing), added an acknowledgments section, and updated
a reference for Base64 encodings.  The 2nd revision added an other
considerations section to discuss transfer and local storage encoding
and required the presence of parameters.

Document Quality

This text is short (4 pages) and so is the ASN.1 (5 lines).  It is based
on the SECG document whose text and ASN.1 has been stable for many
years.  OpenSSL supports the structure as defined in this document.

Personnel

Carl Wallace is the document Shepherd.  Tim Polk is the responsible AD.