Algorithm Agility in PKIX

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?