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 PKCS1 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
  doesnt 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 isnt 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 - Whats 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?