RE: OCSP Algorithm Agility

["Andrews, Rick" <[e-mail]>]

Santosh,
 
I think it's an installed-base problem. If we start issuing certs with
SHA-256, it will take a long time for all OCSP clients to build in the
support. Until SHA-2 is ubiqitous, we need the server to be agile with
respect to algorithms.
 
-Rick Andrews


________________________________

	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Santosh Chokhani
	Sent: Thursday, September 20, 2007 10:54 AM
	To: Hallam-Baker, Phillip; pkix
	Subject: RE: OCSP Algorithm Agility
	
	

	I am still have misgiving about the need for in-band signaling
for SHA-1 Vs SHA-256.

	 

	For practical PKI, if the certificates are still SHA-1, why does
the OCSP needs to go to SHA-256?  If the certificates have started using
SHA-256, client better process SHA-256.

	 

	I can envision the RFC to accommodate algorithms.  I am not sure
in-band signaling is that important.

	
________________________________


	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Hallam-Baker, Phillip
	Sent: Wednesday, September 19, 2007 5:38 PM
	To: Santosh Chokhani; pkix
	Subject: RE: OCSP Algorithm Agility

	 

	The problem with KISS is that the definition of simple can
depend markedly on one's point of view. Simplifying assumptions can lead
to great operational complexities, assuming the world to be simpler than
it is tends to lead to complexity in my experience.

	 

	I don't follow the assumption that the OCSP responder is using
the 'certificate signing key'. which certificate, the end entity cert
under test or the OCSP server cert? The OCSP server might well have
multiple certs. The request is asking for a response + cert chain that
meets specific criteria. The OCSP responder may not have any relation to
the certificate signer whatsoever. If it is a CRL driven responder it
might easily be using Suite B rather than RSA or vice versa.

	 

	 

	Putting a statement of the algorithms offered into the OCSP
responder cert would certainly be one approach to closing the attack. I
am not convinced that the attack is relevant but it is certainly more
relevant than a great number of features we have already included in the
PKIX stack.

	 

	
	 

		
________________________________


		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Santosh Chokhani
		Sent: Wednesday, September 19, 2007 1:58 PM
		To: Hallam-Baker, Phillip; pkix
		Subject: RE: OCSP Algorithm Agility

		Personally I believe in KISS principle, i.e., the
Responder uses the key pair (hopefully it does not generate many
different keys pairs for different algorithms and key sizes) and hash
used to sign it certificate.  Again that is the practical side of how
PKIs are deployed.

		 

		If you really wanted to protect against the attack and
want in-band algorithm negotiation, the Responder certificate could also
contain structure like you propose in a supportedAlgorithms extension.
The client could make a determination if the Responder made the proper
selection and detect the MITM attack.

		 

		This still has residual risk of certificate minting due
to weak algorithms, but that is a such as bigger problem that crypto
suite selection dwarfs in comparison.

		 

		
________________________________


		From: Hallam-Baker, Phillip [mailto:[e-mail]]

		Sent: Wednesday, September 19, 2007 1:05 PM
		To: Santosh Chokhani; pkix
		Subject: RE: OCSP Algorithm Agility

		 

		True, but the attacker can only force the selection of a
particular algorithm that is acceptable to both the requestor and
responder as acceptably secure.

		 

		A negotiation has to start somewhere and there is always
a situation where a downgrade attack is going to be possible. 

		 

		 

		What we could do is to allow the responder to echo the
algorithm request in the response so that the responder can detect a
downgrade attack. But that does not get us very much further. If a
requestor offers a weak algorithm they are vulnerable to a downgrade
attack.

		 

		We need a policy layer. One approach would be to infer
the OCSP responder policy from the certificate. If the cert has an
SHA-256 certificate the requestor might be able to presume that SHA-256
is supported by the OCSP responder. This is not necessarily the case
though since the OCSP service might be entirely separate.

		 

		A better approach would be to use security policy
statements distributed through the DNS, WS-Policy or whatever. 

		 

		 

		Downgrade attack is much less of a concern to me than
the ability to effect a transition from SHA-1 to SHA-256 before the
known vulnerabilities of SHA-1 allow an attacker to cause a compromise.
If we switch to SHA-256 before the downgrade attack gives the attacker
an advantage the problem is very small. The only circumstance where it
is relevant is if the OCSP token is to be stored and used in a
persistent document archive, and then only if it is not verified when it
was obtained.

			 

			
________________________________


			From: Santosh Chokhani
[mailto:[e-mail]] 
			Sent: Wednesday, September 19, 2007 10:50 AM
			To: Hallam-Baker, Phillip; pkix
			Subject: RE: OCSP Algorithm Agility

			The approach provides an attacker (MITM) an
opportunity to force the OCSP Responder to select weaker algorithms.

			 

			
________________________________


			From: [e-mail]
[mailto:[e-mail]] On Behalf Of Hallam-Baker, Phillip
			Sent: Tuesday, September 18, 2007 2:53 PM
			To: pkix
			Subject: OCSP Algorithm Agility

			 

			Looking at places where we currently use SHA-1
it appears that there will soon be a need to support SHA-256 in OCSP.

			In particular we need a mechanism to allow the
requestor to state which algorithms they can accept from the responder.
I did a sketch of a scheme (see below).

			The question is how best to get this processed.
Algorithm agility is one of the issues that is blocking advance of OCSP
on the standards track so if this was the only issue that was blocking
advancement it would perhaps make sense to rev the OCSP RFC.

			Alternatively it might be considered preferable
to address algorithms agility 'across the board'. Although the only
other protocol that is analagous is SCVP. I don't think the mechanism
specified there translates to OCSP.

			So I was thinking that a good place to start was
probably to submit some variation of the following as a personal ID:  

			The extension would need to be something like

			 

			id-pkix-ocsp-algorithmselectors   OBJECT
IDENTIFIER ::= { id-pkix-ocsp 3 }

			 

			AlgorithmSelectors ::= SEQUENCE OF
AlgorithmSelectorEntry 

			 

			AlgorithmSelectorEntry ::= SEQUENCE {

			    SignatureAlgorithm   [0] OBJECT IDENTIFIER
OPTIONAL,

			    DigestAlgorithm   [1] OBJECT IDENTIFIER
OPTIONAL,

			    }

			 

			The responder SHOULD sign the reponse with a
signature algorithm and digest algorithm pair that match one ot the
following criteria:

			 

			1) The Signature and Digest algorithm both match
an algorithm selector entry exactly.

			 

			or

			 

			2) The Signature Algorithm used matches an
algorithm selector entry where only the Signature Algorithm OID is
specified and the digest algorithm matches an algorithm selector entry
where only the Digest Algorithm OID is specified.

			 

			 

			So for example a requestor can stipulate that
they will accept any combination of RSA-1024, RSA-2048, SHA-1 and
SHA-256 or DSA2 with SHA-256 as follows:

			 

			{SignatureAlgorithm   RSA-1024}

			{SignatureAlgorithm   RSA-2048}

			{DigestAlgorithm      SHA-1 }

			{DigestAlgorithm      SHA-256  }

			{SignatureAlgorithm   DSA2, DigestAlgorithm
SHA-1 }

			 

			The rationale here is that in most cases the
signature and digest algorithms are 'mix and match'. But sometimes they
are not, in particular if specific signature hardware is to be used.

			 

			I note that SCVP does something rather different
but I don't see how the scheme specified there would fit OCSP.