RE: OCSP Algorithm Agility

["Santosh Chokhani" <[e-mail]>]

The approach has practical problems for the pre-signed responses.  I
looked at the ASN.1 for 2560 and it does not seem to support more than
one independently signed response to a request.

 

One practical approach that would work well for delegated model (both
pre-signed and standard OCSP) would be to do this using OCSP URL in the
certificate.  The same OCSP Responder/Repeater could support two
different URL and sign/fetch SHA1 or SHA256 responses based on the URL.
These URL will be populated by the CA depending on the hash used to sign
the user certificate.  (If you like, SHA-256 clients can verify that the
SHA-256 certificate status was signed using SHA 256.)

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Hallam-Baker, Phillip
Sent: Friday, September 21, 2007 10:04 AM
To: Andrews, Rick; Santosh Chokhani; pkix
Subject: RE: OCSP Algorithm Agility

 

The way I see it, the process of transition from one algorithm to
another has two sets of constraints, the first is the security
considerations, the second is the operational/management considerations.

 

In the past security issues have been the alpha and omega of PKI. The
only justification accepted for a change has been to improve security.
So we end up with a whole slew of arbitrary operational constraints and
then wonder why people have such difficulty deploying and maintaining
these systems.

 

If we want to deploy new algorithms we have to decouple the OCSP and
Cert issuing infrastructures, otherswise we will perpetually be in
situations where we are waiting for an evolution in one infrastructure
before a change can be made in the other.

 

 

We have to get PKIX in order before we start proposing work for the TLS
group. Than means making OCSP algorithm agile.

 

	 

	
________________________________


	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Andrews, Rick
	Sent: Thursday, September 20, 2007 9:29 PM
	To: Santosh Chokhani; pkix
	Subject: RE: OCSP Algorithm Agility

	Santosh,

	 

	I don't think that's realistic in the mass market. Let's say a
major financial institution wants to buy a SHA-256 cert from us because
they're concerned about SHA-1 weaknesses. Their clients might be
ordinary users with ordinary browsers on ordinary OSes, who will then
need to rely on the SHA-256 cert (and therefore need SHA-256 to check
the signature on the FI's cert as well as the signature on the OCSP
responder's cert). The financial institution has no way to force these
clients to upgrade to SHA-256. Even if clients really want to rely on
the cert they have to wait until their browser vendor or their OS vendor
build in SHA-256 support.

	 

	Even if we created separate CAs to sign SHA-1 certs and SHA-256
certs, the situation would not be improved for the end client.

	 

	The alternative is for the FI to set up two parallel web sites,
once with a SHA-1 cert and one with a SHA-256 cert, and somehow direct
clients to the appropriate site. I doubt anyone would want to do this.

	 

	-Rick Andrews

		 

		
________________________________


		From: Santosh Chokhani [mailto:[e-mail]] 
		Sent: Thursday, September 20, 2007 5:40 PM
		To: Andrews, Rick; pkix
		Subject: RE: OCSP Algorithm Agility

		Rick,

		 

		Let us say that CA X starts issuing SHa-256
certificates.  Clients that rely on that CA, will need to upgrade to
SHA-256.  The CA can start signing the CRLs using SHA-256.  The OCSP
Responder R can take its cue from the CRL and sign those responses with
SHA-256.

		 

		Now, if the same OCSP Responder R also serves CA Y who
is still using SHA-1.  Again, taking the cue from CRL, the same
Responder R can sign the responses using SHA-1.

		 

		Next, you might argue that VeriSign has a large set of
disjoint customers using the same CA.  I, do not think it is a big deal
to have two physically or logically distinct CAs one for SHA-256
population and one for SHA-1 population.

		 

		
________________________________


		From: [e-mail]
[mailto:[e-mail]] On Behalf Of Andrews, Rick
		Sent: Thursday, September 20, 2007 5:49 PM
		To: Santosh Chokhani; Hallam-Baker, Phillip; pkix
		Subject: RE: OCSP Algorithm Agility

		 

		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.