ECC Design Team: Initial Report
description
Transcript of ECC Design Team: Initial Report
![Page 1: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/1.jpg)
ECC Design Team:Initial Report
Brian Minard, Tolga Acar, Tim Polk
November 8, 2006
![Page 2: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/2.jpg)
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
![Page 3: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/3.jpg)
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
![Page 4: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/4.jpg)
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
![Page 5: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/5.jpg)
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
![Page 6: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/6.jpg)
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
![Page 7: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/7.jpg)
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)
![Page 8: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/8.jpg)
Certificate Extension, II
• Where noncritical, compatible with vanilla 3279 systems but may be used in less desirable modes
• Where critical, interoperability sacrificed for control
![Page 9: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/9.jpg)
Decision Criteria
• Security
• Interoperability & Ease of Deployment
• Cryptographic Agility
• Simplicity
• Red Herring - CMVP process impact
![Page 10: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/10.jpg)
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
![Page 11: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/11.jpg)
Interoperability & Ease of Deployment
• Interoperability with installed base
• Interoperability with IETF protocols
• Communicating Limitations in Cryptographic Support
![Page 12: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/12.jpg)
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
![Page 13: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/13.jpg)
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.
![Page 14: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/14.jpg)
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
![Page 15: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/15.jpg)
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.
![Page 16: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/16.jpg)
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
![Page 17: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/17.jpg)
Simplicity
• Should express common limitations in a (relatively) simple form
![Page 18: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/18.jpg)
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
![Page 19: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/19.jpg)
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
![Page 20: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/20.jpg)
Decision Time
• Any of these solutions is technically feasible
• Each of these solutions has advantages and disadvantages
• So, by process of elimination…
![Page 21: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/21.jpg)
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
![Page 22: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/22.jpg)
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
![Page 23: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/23.jpg)
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)
![Page 24: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/24.jpg)
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.
![Page 25: ECC Design Team: Initial Report](https://reader036.fdocuments.us/reader036/viewer/2022081520/568149c5550346895db6f70a/html5/thumbnails/25.jpg)
Questions?