Date post: | 31-Dec-2015 |
Category: |
Documents |
Upload: | lorimer-sutherland |
View: | 32 times |
Download: | 0 times |
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
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.