Subject: OCSP Algorithm Agility

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 18 Sep 2007 11:52:56 -0700

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.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 18 Sep 2007 22:09:20 +0100

Phil,

Good that you bring this subject on the table again. We have agreed for quite some time that something needs to be done.
Nothing has happened in the absence of any volunteers to actually do the work.

I think it would be great if you want to formalize your proposal in an ID. In the end we need to develop any solution we choose as a PKIX document, if our ADs give us their blessing.
It would be great to know if we now have enough people interested to actually contribute to such an effort.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
Sent: den 18 september 2007 11:53
To: pkix
Subject: OCSP Algorithm Agility

or

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 18 Sep 2007 16:07:24 -0800

Phil,

I tried in April of 2006 to stir up interest on this issue.

http://www.imc.org/ietf-pkix/mail-archive/msg03318.html

Given your recent concern, what are your thoughts regarding this prior
posting?

Mike

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 19 Sep 2007 07:49:46 -0700

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

________________________________

From: [email-masked] [mailto:[email-masked]]
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:  

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

    }

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:

{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.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 19 Sep 2007 10:04:43 -0700

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:[email-masked]] 
	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.

	    }

	or

	 

	{DigestAlgorithm      SHA-1 }

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 19 Sep 2007 10:58:01 -0700

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:[email-masked]] 
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.

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

	From: [email-masked]
[mailto:[email-masked]] 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:  

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

	    }

	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:

	{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.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 19 Sep 2007 14:38:00 -0700

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: [email-masked] [mailto:[email-masked]] 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.

	 

	 

		

		

		    }

		or

		 

		{DigestAlgorithm      SHA-1 }

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 19 Sep 2007 15:00:55 -0700

I meant the responder certificate delegated by the signing CA.  I can
envision responder having SHA-1 and SHA 256 certificates to facilitate
transition.  But, practically, I do not see responder having different
size RSA keys or different algorithms.  But, one could argue that
transition from RSA to EC might dictate this.  What I have found in
these transition scenarios is that having two homogenous PKI is better. 

I agree with your argument that if cipher suites are acceptable to
client and server, the attack more of a theoretical interest.

From: Hallam-Baker, Phillip [mailto:[email-masked]] 
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.

[mailto:[email-masked]] On Behalf Of Santosh Chokhani

	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.

	

	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.

	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.

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

		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:  

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

		AlgorithmSelectors ::= SEQUENCE OF
AlgorithmSelectorEntry 

		    }

		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:

		{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.

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 19 Sep 2007 14:39:01 -0800

Humming in Arizona . . .

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Michael Myers
Sent: Tuesday, September 18, 2007 4:07 PM
To: Hallam-Baker, Phillip; pkix
Subject: RE: OCSP Algorithm Agility

Phil,

Mike

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 20 Sep 2007 10:53:51 -0700

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.

 

 

	

	 

	 

		

		

		    }

		or

		 

		{DigestAlgorithm      SHA-1 }

---

From: "Andrews, Rick" <[email-masked]>
Date: Thu, 20 Sep 2007 14:49:01 -0700

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

	Sent: Thursday, September 20, 2007 10:54 AM

	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.

	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.

		

		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.

		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:[email-masked]] 
			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.

			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).

			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.

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

			    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:

			{DigestAlgorithm      SHA-1 }

			{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.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 20 Sep 2007 17:39:57 -0700

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: [email-masked] [mailto:[email-masked]]
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,

-Rick Andrews

	 

	

		

		 

		 

			

			From: Santosh Chokhani

			

			    }

			or

			 

			{DigestAlgorithm      SHA-1 }

---

From: "Andrews, Rick" <[email-masked]>
Date: Thu, 20 Sep 2007 18:28:58 -0700

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:[email-masked]] 
	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.

	

[mailto:[email-masked]] On Behalf Of Andrews, Rick

	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

		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.

		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.

			

			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:[email-masked]] 
			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:[email-masked]] 
				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: [email-masked]
[mailto:[email-masked]] 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

				    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:

				{DigestAlgorithm      SHA-1 }

				{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.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 21 Sep 2007 05:02:16 -0700

Rick,

Let us say that the Bank uses SHA-1 certificate only.  We call it
(bank)CA-SHA1.  Now the OCSP Responder receives (CRL)CA-SHA1 and
provides the client with response using SHA1 and all is well.

Let us say that the Bank uses SHA-256 certificate only.  This would be
(bank)CA-SHA256.  Now the responder will gets (CRL)CA-SHA256 and
provides the client with response using SHA256.  Now, SHA1 clients are
hosed.  But, OCSP is not going to help them since the certificate itself
is SHA256.  if you can not process the certificate, there is no
particular benefit to processing its revocation status.

Finally, let us say that the Bank has both (bank)CA-SHA1 and
bank)CA-SHA256 certificates and provides both to the client in SSL.  The
client processes (bank)CA-SHA1 and asks the same Responder for its
status.  The responder had gotten (CRL)CA-SHA1 for this and hence signs
the response using SHA1 and all is well.

Thus, OCSP Responder may need to be agile, but does not need any in-band
signaling by the client.

I still fail to see the problem we are trying to solve.  There is lot of
benefit to keeping standard simple and secure.

Sent: Thursday, September 20, 2007 9:29 PM

Santosh,

-Rick Andrews

	Rick,

	

	Santosh,

	-Rick Andrews

		 

		

			

			 

			 

				

				From: Santosh Chokhani

				

				    }

				or

				 

				{DigestAlgorithm      SHA-1 }

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 21 Sep 2007 07:04:07 -0700

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: [email-masked] [mailto:[email-masked]] 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

		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: [email-masked] [mailto:[email-masked]] 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

			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.

			 

			

				

				 

				 

					

					

					    }

					or

					 

					{DigestAlgorithm      SHA-1 }

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Sep 2007 10:15:06 -0700

At 7:04 AM -0700 9/21/07, Hallam-Baker, Phillip wrote:
>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.

Fully agree up to here.

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

And mostly agree with this. Where I disagree with Phill (I think) is 
what "algorithm agile" means. My reading of OCSP is that it is 
*already* fully algorithm agile.

 From Phill's message at the start of this thread, I think what he 
means is "agile in a way that is not susceptible to downgrade attacks 
by a MITM". The list then went into the design of an anti-downgrade 
revision to OCSP. This is quite similar to the discussion we had in 
the DKIM WG on a very similar topic.

The most important feature of these attacks is that Mallory can 
impersonate the OCSP responder by signing a message with a 
compromised algorithm. I contend that this attack is isomorphic to 
the problem of, even with no algorithm agility, Mallory impersonating 
the OCSP responder using a stolen signing key. In fact, the latter 
seems much more likely than the former in the real world.

We haven't even thought about how an OCSP responder could say in an 
unspoofable fashion "here is my legitimate signing key, don't trust 
that stolen key". That is been a non-issue for all these years, 
probably because it is intractable without going out-of-band. The 
compromised-algorithm problem is likely to be just as intractable 
without going out of band. Once we go out of band, the OCSP responder 
simply gives the key and algorithm of the day.

So, can we can safely say that OCSP is algorithm agile without 
needing a solution to the compromised algorithm problem? If not, how 
is the problem different operationally from the stolen-key problem?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 21 Sep 2007 10:31:25 -0700

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: [email-masked] [mailto:[email-masked]]
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.

	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

	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

		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.

		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

			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.

			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.

				

				Sent: Wednesday, September 19, 2007 1:58

				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.

				Sent: Wednesday, September 19, 2007 1:05

				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

				

				    }

				or

				 

				{DigestAlgorithm      SHA-1 }

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 21 Sep 2007 18:38:07 +0100

Phil and Rick,

Even if you don't agree with Santosh I still think it is fair to make a clear and direct response to his comment.

Where would it not work to inherit the algorithm used to sign the certificate being checked for revocation?

I can think of some but not sure if they qualify for an algorithm negotiation:

-          The certificates supported by the responder may be signed by a wide range of signature algorithm (e.g. mix of RSA and ECC). By practical reasons the OCSP responder may not support all these signature algorithms, but needs to limit to a few choices.

-          It is obvious that SHA-1 is weaker than SHA-256. But what about RSA x, versus ECC y? Is hash negotiation the only thing of interest?

For me this is not mainly a security issue, but a practical migration enabler. The client should never accept anything it doesn't consider good enough.

Stefan Santesson
Senior Program Manager

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hallam-Baker, Phillip
Sent: den 21 september 2007 07:04
To: Andrews, Rick; Santosh Chokhani; pkix
Subject: RE: OCSP Algorithm Agility

-Rick Andrews

Santosh,

-Rick Andrews

or

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Sep 2007 14:07:44 -0400

Folks,

How about defining an extension to be included in the cert issued to 
an OCSP responder by a CA.  The extension would have an ordered list 
of algorithms (hash and signature if we want to address more than the 
hash agility issue) accepted by the OCSP responder.  An OCSP client 
can use this info to determine what is the "best" algorithm (or alg 
pair) that it and the responder share. The combination of this 
extension and an OCSP negotiation procedure will allow the client to 
detect MITM downgrade attacks. In fact, if the client acquires the 
responder's cert prior to making a request, there would not even be a 
need for real negotiation, since the client would know what alg to 
request in a response.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 21 Sep 2007 19:08:21 +0100

Also,

There may be signature algorithms that you are capable of verifying, but you do not have the means to use them for signing.

Stefan Santesson
Senior Program Manager

From: Hallam-Baker, Phillip [mailto:[email-masked]]
Sent: den 21 september 2007 11:00
To: Stefan Santesson; Andrews, Rick; Santosh Chokhani; pkix
Subject: RE: OCSP Algorithm Agility

The ECC algorithms make the issue somewhat clearer.

For example imagine that we have an SCVP or XKMS responder that is constructing a trust path for a client, let us also assume that we are dealling with the case where the client is only requesting path construction and is not going to perform validation.

It is quite easy to see cases where the service would want to provide path results for algorithms it cannot actually verify. The whole point of SCVP/XKMS is to separate out the task of processing trust decisions.

Equally if we have a real time OCSP responder that is producing the signatures on demand (and signing the nonce) it is very easy to see cases where we can't support the range of algorithms.

________________________________
From: Stefan Santesson [mailto:[email-masked]]
Sent: Friday, September 21, 2007 1:38 PM
To: Hallam-Baker, Phillip; Andrews, Rick; Santosh Chokhani; pkix
Subject: RE: OCSP Algorithm Agility
Phil and Rick,

Stefan Santesson
Senior Program Manager

-Rick Andrews

Santosh,

-Rick Andrews

or

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 21 Sep 2007 12:22:47 -0700

Agreed

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stephen Kent
Sent: Friday, September 21, 2007 2:08 PM
To: [email-masked]
Subject: RE: OCSP Algorithm Agility

Folks,

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Sep 2007 13:38:39 -0700

At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
>of algorithms (hash and signature if we want to address more than 
>the hash agility issue) accepted by the OCSP responder.  An OCSP 
>client can use this info to determine what is the "best" algorithm 
>(or alg pair) that it and the responder share. The combination of 
>this extension and an OCSP negotiation procedure will allow the 
>client to detect MITM downgrade attacks. In fact, if the client 
>acquires the responder's cert prior to making a request, there would 
>not even be a need for real negotiation, since the client would know 
>what alg to request in a response.

Imagine the list of algorithms is RSA-with-SHA1 first and 
DSA-with-SHA1 second. How does your negotiation work? The client asks 
for this message to be signed with RSA-with-SHA1. But the server 
knows that RSA-with-SHA1 has been compromised since it got that 
certificate from the CA. What does the server say to the client to 
indicate that it only wants to sign with DSA-with-SHA1? What prevents 
Mallory from saying the same thing to the client?

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Sep 2007 17:49:32 -0400

At 1:38 PM -0700 9/21/07, Paul Hoffman wrote:
>>How about defining an extension to be included in the cert issued 
>>to an OCSP responder by a CA.  The extension would have an ordered 
>>list of algorithms (hash and signature if we want to address more 
>>than the hash agility issue) accepted by the OCSP responder.  An 
>>OCSP client can use this info to determine what is the "best" 
>>algorithm (or alg pair) that it and the responder share. The 
>>combination of this extension and an OCSP negotiation procedure 
>>will allow the client to detect MITM downgrade attacks. In fact, if 
>>the client acquires the responder's cert prior to making a request, 
>>there would not even be a need for real negotiation, since the 
>>client would know what alg to request in a response.
>
>DSA-with-SHA1 second. How does your negotiation work? The client 
>asks for this message to be signed with RSA-with-SHA1. But the 
>server knows that RSA-with-SHA1 has been compromised since it got 
>that certificate from the CA. What does the server say to the client 
>to indicate that it only wants to sign with DSA-with-SHA1? What 
>prevents Mallory from saying the same thing to the client?
>
>--Paul Hoffman, Director
>--VPN Consortium

Paul,

You are correct that to impose a total ordering on what may be more 
appropriately described as a lattice implies a value judgement, and 
the responder and client might have different perspective. However, 
the responder, by publishing the list has expressed its total 
ordering, and has defined the set of algs that it supports. That 
allows the client to:

	- if the client wants to rely on the responder's total 
ordering value judgement, the extension offers a verifiable reference 
for that.

	- if the client wants to use his own total ordering, he knows 
what set he can chose from, and thus can avoid offering a subset of 
his capabilities that will not overlap with that of the responder.

Lookng at your example, the CA should revoke the OCSP responder's 
cert with the newly compromised, bad algs, and issue a new one. yes, 
this is imperfect because we an encounter a circular revocation 
status problem for a responder. but I think this can be managed in a 
practical way by establishing a reasonable re-issue frequency for the 
responder's cert.

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 21 Sep 2007 14:44:34 -0700

Paul,

Here are my views on this.

The client should be first asking for the algorithm suite that signed
the certificate in question.  There is no need for the client to ask for
anything stronger.  The client can ask for stronger suites as secondary,
if client has them.

In the scenario you cite, the Responder certificate will not include RSA
with SHA 1 any longer.  So, client will know that Responder only
supported his second choice and he should be ok with it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Paul Hoffman
Sent: Friday, September 21, 2007 4:39 PM
To: Stephen Kent; [email-masked]
Subject: RE: OCSP Algorithm Agility

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Sep 2007 15:04:46 -0700

At 5:49 PM -0400 9/21/07, Stephen Kent wrote:
>the responder and client might have different perspective.

So, how does your solution help the client decide what to do with an 
OCSP response? It seems to me that it gives them one more piece of 
data that is open to disagreement.

>status problem for a responder.

Others might say that a circular revocation status problem is "not 
helpful" or simply "broken".

>but I think this can be managed in a practical way by establishing a 
>reasonable re-issue frequency for the responder's cert.

...thereby introducing a new point of failure for OCSP response validation.

Maybe the problem of a MITM forging an OCSP response using a broken 
signing algorithm is not as bad as this solution.

--Paul Hoffman, Director
--VPN Consortium