1 / 25

ECC Design Team: Initial Report

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

mira-dillon
Download Presentation

ECC Design Team: Initial Report

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ECC Design Team:Initial 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 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

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

  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?

More Related