Looking for input on the two questions at the end of this message. ECC Design Team Survey
Background The PKIX WG has been presented with two different proposals for the specification of ECC public keys in the subject public key info field of X.509 certificates. Proposal #1: A current PKIX ID (http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-pkalgs-03.txt) based on the ANSI X9.62-2005 standard specifies a structured a public key info field with (up to) four components: * the algorithm family (i.e., ECC), * the public key, * an explicit or implicit specification of ECC parameters (implicit specifications include inheritance from the CA and OIDs that specify a named curve), and * an optional set of OIDs specifying the supported modes (e.g., 1 pass DH or full MQV). The set of supported modes is very granular, and includes ancillary cryptographic functions. For signature algorithms, the mode specifies supported hash algorithms. For example, separate OIDs are defined for ECDSA with SHA-1, SHA-256, SHA-384, and SHA-512. For key agreement algorithms, the mode specifies the key establishment scheme (e.g., MQV one pass mode vs. MQV full mode) as well as the key derivation function (kdf). Proposal #2: Two PKIX specifications, RFCs 3279 and 4055, currently define the specification of RSA, DSA, Diffie-Hellman, and ECC public keys. In these specifications, the public key info field has (up to) three components: * The algorithm (e.g., RSA or ECC); * The public key; and * An optional set of parameters (parameters are omitted if they are inherited from the issuer, or where not required by the algorithm as in the case of the RSA). Where public keys are compatible with different classes of operations, restrictions are imposed using the key usage extension. When applied to ECC, this approach would provide less specific restrictions than the ANSI-based proposal. For instance, the key usage extension permits the issuer to restrict use of an ECC key to digital signatures, but would not explicitly limit use to ECDSA or specify allowable hash algorithms. As a second example, a key usage extension asserting only keyAgreement could be used to limit the use of the public key to ECDH and ECMQV, but could not be used to impose further restrictions (e.g., MQV but not Diffie-Hellman, or full MQV mode but not one pass.) The Design Team was formed to review the tradeoffs between these two approaches. As an initial step, the Design Team developed a set of design criteria, below. Note that the design team did not prioritize these criteria. The design criteria are: (1) The specified solution must support security-relevant constraints sufficient to protect the corresponding private key. In particular, the issuer must be able to prevent use of the public key in undesirable combinations of algorithms or modes. (For example, could the use of the key in both signature and key agreement modes place the private key at risk? Alternatively, could use of the key in both Diffie-Hellman and MQV modes place the private key at risk?) (2) The specified solution must promote interopability. Specific considerations include: * How should implementations of RFC 3279, the future PKIX specification, and the ANSI specification interact? * What is the impact on current and emerging protocol specifications? For example, would the resulting certificates be usable in TLS or S/MIME? * Would existing certificates specified using this solution be applicable to new or updated protocols? * Should common limitations in cryptographic support (e.g., DH but not MQV) be accommodated in the certificate format or should these limitations be discovered in the application protocols? * What is the impact on APIs? (3) The specified solution should support cryptographic agility. The cryptographic suite is evolving over time, with the introduction of new algorithms and changes in the perception of cryptographic strength. For example, new hash algorithms will probably be introduced during the life of this specification. The specification must not create an environment where certificates must be reissued to accommodate every change in the cryptographic suite. (4) The specified solution should not require revalidation of products that have been certified under FIPS 140. If the specified solution requires changes within the cryptographic module boundary, the time to market for compliant implementations will be adversely impacted. (5) The specified solution should not be unduly complex. The most common assertions should be specified in a straightforward manner. Survey Questions (1) Are there any missing important design criteria? (2) Which proposal do you prefer? Please explain your preference based on the design criteria, including any additional criteria you have identified. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
