ECC Design Team:Initial Report

Brian Minard, Tolga Acar, Tim Polk

November 8, 2006

Specifying ECC Public Keys

• RFC 3279– Algorithm OID indicates elliptic curve, and

includes algorithm parameters– In conjunction with key usage extension,

can restrict a key to signatures or key agreement

– Cannot differentiate a key intended for DH from an MQV key

Possible Ways Forward

• Two Very Different Proposals Circulate on list– RFC 4055 style solution– ANSI X9.62-2005 based solution

• Design team added a third– Certificate extension

• In conjunction with current RFC 3279 or RFC 4055 style solution

RFC 4055 Style Solution

• Described in emails to PKIX list

• Specify three new algorithm OIDS to specify restrictions to the common families of operations (ECDSA, ECDH, and ECMQV)– Parameters are the same as RFC 3279

ANSI X9.62-2005 based solution

• Documented in Dan Brown’s ecc-pkalgs-03 ID (on PKIX WG page)

• Introduces a new Algorithm OID, id-ecPublicKeyRestricted– Parameters field includes algorithm parameters

and a sequence of algorithm identifiers representing the set of ECC algorithms associated with the public key

ECC Algorithm Identifiers in ecPublicKeyrestricted

• Fine grained control– 6 DH OIDs, 6 MQV OIDs, 9 ECDSA OIDs

• Differentiates one-pass from full mode, hash algorithms for signatures

– No “family” OIDs (e.g., any MQV mode)

• Algorithm identifiers may be associated with additional parameters to specify auxiliary cryptographic functions– Can specify hash algorithms in kdfs, etc.– Includes “with recommended” feature

Certificate Extension, I

• Not currently documented• Retain current algorithm OID and parameter

specification• Define an optionally critical certificate

extension– Sequence of Algorithm Identifiers, as in X9.62

parameters– Reuse X9 algorithm Identifiers

• Deprecating “with recommended”?

– Add three “family” OIDs (ECDSA, ECDH, ECMQV)

Certificate Extension, II

• Where noncritical, compatible with vanilla 3279 systems but may be used in less desirable modes

• Where critical, interoperability sacrificed for control

Decision Criteria

• Security

• Interoperability & Ease of Deployment

• Cryptographic Agility

• Simplicity

• Red Herring - CMVP process impact

Security• Security of the key pair

– Performing both Diffie-Hellman and MQV does not impact the security of the key pair.

– Use of a key pair in both full and one-pass modes (for MQV or DH) does not impact the security of the key pair.

• Security of the protected data: ECDH/ECMQV– Recipient may wish to ensure that data is always

protected with their chosen algorithm family or mode.

• Security of the protected data: ECDSA– Specification of the hash algorithm avoids message

substitution attacks using weak hash algorithms

Interoperability & Ease of Deployment

• Interoperability with installed base

• Interoperability with IETF protocols

• Communicating Limitations in Cryptographic Support

Interoperability with Installed Base

• Installed base conforms to RFC 3279– Will be significantly augmented by Vista

• Preferably, solution would opt-in/opt-out for compatibility with “legacy” implementations

Interoperability with IETF Protocols, I

• New algorithm OIDs or critical extensions are inherently incompatible with current protocols/implementations

• Limitations on ancillary cryptographic algorithms may be incompatible with protocol details– For DH/MQV, kdfs tend to be unique to protocols

– For ECDSA, hash algorithm is already specified in the protocol stream. Specification in cert creates new verification steps.

Interoperability with IETF Protocols, II

• Restrictions on modes may impact protocols– number of round trips in a protocol may be

different for DH vs. MQV, or one-pass versus full mode

• Restrictions may preclude protocol designer from using other options– authenticated nature of MQV could also be

satisfied by a signature over ECDH

Communicating Limitations in Cryptographic Support, I

• Common restrictions are a family of operations (e.g., ECDSA, DH, MQV)– Consistent with limitations in crypto support

• Cryptographers would like to specify modes and ancillary functions (kdfs and hash algorithms)– Generally represent policy requirements rather than

limitations in crypto support

• Application developers would like as much information as possible, to eliminate extra round trips and failed negotiations.

Cryptographic Agility

• Restrictions on key use could interfere with deployment of new auxiliary functions– Changes in cryptographic suites or

deployment of new protocols could force reissuance of certificates

Simplicity

• Should express common limitations in a (relatively) simple form

Survey Process

• Emailed prospective participants– Description of alternative proposals– Description of five criteria– Two questions:

• Are additional criteria needed?• Which proposal is preferred and why

• Follow up email to PKIX list requested info on implementations

Survey Responses…

• Were amazingly diverse!– People from the same organizations and

co-editors of RFcs gave diametrically opposed responses

• Consensus was not just waiting to be discovered

Decision Time

• Any of these solutions is technically feasible

• Each of these solutions has advantages and disadvantages

• So, by process of elimination…

Why Not 4055 Style Solution?

• Incompatible with installed base, and no clear migration path – New OIDs are like unrecognized critical

extensions!

• Not widely implemented for RSA, so architectural changes would be required

• May not provide sufficient information

Why Not X9.62-2005?

• No current deployment or implementation• No clear migration path

– New OID is like an unrecognized critical extension!

• Inconsistent with current application/protocol expectations– Architectural changes will be required

• Complex specification for most common restrictions– Potential incompatibility with protocols

discourages ECC deployment

Design Team’s Proposal

• Retain 3279 OID/parameters– Critical mass is finally emerging!

• Specify certificate extension as SHOULD implement for CAs and clients– Criticality provides opt-in/opt-out mechanism to

select interoperability or control– Applications can take advantage of hints in

noncritical extension, even where unrecognized by the path validation module

• Consistent with current application/protocol expectations (Alg OID plus extensions)

However…

• X9.62-2005 restricted the use of ECDSA keys specified using id-ecPublicKey OID to SHA-1.– Without change, implementations will not

be able to conform to both the IETF and ANSI specifications!

• Fortunately, X9.63-2001 has not been updated to reflect the new syntax, so ANSI could remove the restriction.

Questions?