1 / 18

Algorithm Agility in PKIX

Algorithm Agility in PKIX. Tim Polk March 20, 2006. Deploying a New Hash Algorithm. Bellovin/Rescorla paper presented at NDSS conference Difficulty of transitioning to SHA-2 in particular and crypto algorithms in general Established rough criteria for algorithm agility

macj
Download Presentation

Algorithm Agility in PKIX

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. Algorithm Agility in PKIX Tim Polk March 20, 2006

  2. Deploying a New Hash Algorithm • Bellovin/Rescorla paper presented at NDSS conference • Difficulty of transitioning to SHA-2 in particular and crypto algorithms in general • Established rough criteria for algorithm agility • Specifications are algorithm independent • Client & server securely signal capabilities/requirements

  3. Scope of Certificate Agility • Certificates themselves are NOT agile! • 1 key, 1 signature • Agility for a sender implies multiple certificates for each type of key… • In general, it is the relying parties responsibility to accept multiple algorithms

  4. As a general rule… • PKIX certificate/CRL/message formats are algorithm neutral • OIDs are used to identify public keys, signatures, and hashes • ASN.1 based message formats are flexible with respect to size of cryptographic elements • But our specs rely on an algorithm suite that is currently incomplete. When this is complete, most specs will be okay…

  5. Core Signature Specifications • RFC 3279, RFC 4055, specify • DSA with SHA-1 • RSA PKCS#1 with MD5 and SHA-1 thru SHA-512 • RSA PSS with SHA-1 thru SHA-512 • ECDSA with SHA-1 • GOST spec will provide additional options • New ID ready for submission with DSA and ECDSA with SHA-2 family • Desperately need a DSA reference!

  6. Certificate Agility Issues • Implicit assumption that certificate status mechanisms use consistent cryptography • This precludes transitioning to new algorithms • No direct support for multi-alg status mechanisms • If two CRLs are available, client has to download both and parse the CRLs in turn until one with an acceptable signature alg is found • If multiple OCSP servers are available, client doesn’t know which to contact

  7. Protocol Considerations • Can messages be constructed with different algorithms? • Yes, algorithms specified by OID • Can participants signal which algorithms they support/prefer? • Are references in place for using SHA-2 hash algorithms?

  8. SCVP -23 • Revised to explicitly support signaling by both client and server • Fairly granular specification • Server policy response message specifies • Signature generation, Signature verification, Hash algorithms, Key agreement keys (inc. algs, params, and kdf) • Client requests Server use… • Signature algorithm, Hash algorithm • However, no provision to limit key sizes • E.g., cannot indicate “verify RSA 1024 thru 3072”

  9. RFC 4211: CRMF • Cannot explicitly request signing algorithm • signingAlg is specified in the certTemplate • But text explicitly requires that it be omitted! • Can implicitly request a signing algorithm using the policy OID in current spec • If explicit signaling is required • Could add a signature control to the specify the signature/hash algorithm for the new certificate

  10. Certificate Management Protocols (CMP/CMC) • Secure communication between infrastructure components (E.g., CA and RA) and subscribers • algorithm suite is generally known out of band • CA & RA have trusted relationship • Subscribers in organization PKIs using known services • Signaling would be helpful if • Subscriber interacts with a public service provider • Org. PKI is transitioning its algorithm suite • So, is algorithm agility really a requirement?

  11. CMP/CMC • Can argue that clients implicitly signal some algorithm requirements • For user certs, signature algorithm should be “consistent” with user public keys • but hash algorithm isn’t specified • CA requirements are conveyed out of band information • Current error messages limited to “badAlg” • Is the problem the algorithm or key size? • Could specify accepted algs in extension (CMP) or extended error message (CMC)

  12. RFC 2560: OCSP • Signature and hash algorithms specified by OID, so could use any well-defined algs • Client Support for DSA required, RSA recommended • OCSP responders MUST support SHA-1 • Error messages do not address algorithm suite • And error messages are not signed…

  13. OCSP Modes • Two modes • Authoritative OCSP server identified in AIA extension • Algorithm Suite consistent with certificate? • ECC signed OCSP for RSA signed makes no sense, but may want to update key size or hash algorithm! • Locally configured • Algorithm suite known out of band? • Any locally used algorithm could be acceptable

  14. OCSP - What’s Missing • Client cannot signal which signature/hash algorithms it supports • Server can reject unsigned requests, but cannot indicate that a request was rejected because of an unacceptable algorithm choice • Server cannot signal which algorithms it supports or can

  15. OCSP - Adding Agility • Both the request and response include extensions • Client can request server algs • Server can return accepted algs in error message • First roundtrip effectively reduces to negotiation, second RT uses negotiated cipher suite • But requests and error messages would need to be signed! • Negotiating algorithm suites with unsigned messages is vulnerable to downgrade attacks

  16. Lightweight OCSP • This profile of OCSP is not algorithm independent • “Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values.” • Question for ADs: Is this acceptable?

  17. 3161: Time Stamp Protocol • TSA rejects requests that weak or unknown hash algorithm, but cannot specify the set of acceptable algorithms • Time Stamp error responses have no extension field • TSA client could implicitly request signature/hash algorithm by specifying a TSAPolicyId • Time Stamp request has an extension field that could be used for explicit signaling

  18. To Do List? • Complete signature suite • Determine appropriate scope for signaling in PKIX • Add signaling where appropriate • Does PKIX need to document common assumptions? • In protocol specs or separate BCPs?

More Related