ECC Design Team: Initial Report

1
ECC Design TeamInitial Report

• Brian Minard, Tolga Acar, Tim Polk
• November 8, 2006

2
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

3
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

4
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

5
ANSI X9.62-2005 based solution

• Documented in Dan Browns 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

6
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

7
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)

8
Certificate Extension, II

• Where noncritical, compatible with vanilla 3279
  systems but may be used in less desirable modes
• Where critical, interoperability sacrificed for
  control

9
Decision Criteria

• Security
• Interoperability Ease of Deployment
• Cryptographic Agility
• Simplicity
• Red Herring - CMVP process impact

10
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

11
Interoperability Ease of Deployment

• Interoperability with installed base
• Interoperability with IETF protocols
• Communicating Limitations in Cryptographic Support

12
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

13
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.

14
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

15
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.

16
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

17
Simplicity

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

18
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

19
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

20
Decision Time

• Any of these solutions is technically feasible
• Each of these solutions has advantages and
  disadvantages
• So, by process of elimination

21
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

22
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

23
Design Teams 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)

24
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.

25
Questions?