Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 1 Apr 2009 10:05:24 -0400

My resident ASN.1 expert apprised me of the fact that adding a choice
will break backward compatibility.  Thus, extension is a fifth option
(probably third in the priority).

Based on what I know of OCSP implementations, not changing anything in
terms of bits on the wire and aligning the Key ID with SKID in 5280 is
the best approach.  I do not think it will hurt backward compatibility.

OCSP Responder and OCSP client vendors should speak up if I am wrong.

> -----Original Message-----
> From: Santosh Chokhani 
> Sent: Tuesday, March 31, 2009 12:51 PM
> To: 'Massimiliano Pala'; IETF-pkix
> Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1
> 
> Max,
> 
> I do not see where and what extension we need to add for 
> other digest algorithm.
> 
> For key id, we need to enhance or broaden the options. 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Massimiliano Pala
> > Sent: Tuesday, March 31, 2009 1:37 PM
> > To: IETF-pkix
> > Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
> > 
> > Hi all,
> > 
> > as I said during last meeting - as the use of SHA-1 does 
> not have any 
> > security implication in the OCSP, another viable way would be to 
> > define an extension where other digest algorithms can be 
> added to the 
> > request/responses.
> > 
> > It is a simple addition and does not require any change in 
> the RFC, it 
> > can be done as a separate document for those who what to use other 
> > digest algorithms.
> > 
> > After all, isn't this an example of why we allow extensions to the 
> > messages ?
> > 
> > Later,
> > Max
> > 
> > 
> > Santosh Chokhani wrote:
> > > Tom,
> > > 
> > > Adding a new choice and aligning it with 5280 SKID is fine.
> > > 
> > > I would not add anything about matching this field with
> > anything since
> > > RFC 2560 does not say anything about it.
> > > 
> > > If one were to add something, one should describe how this
> > field can
> > > be used to select from multiple Responder certificates.
> > > 
> > >> -----Original Message-----
> > >> From: Tom Gindin [mailto:[email-masked]]
> > >> Sent: Monday, March 30, 2009 7:46 PM
> > >> To: Santosh Chokhani
> > >> Cc: IETF-pkix
> > >> Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1
> > >>
> > >>         Santosh:
> > >>
> > >>         The RFC 5280 method just describes "two common 
> methods for 
> > >> generating key identifiers from the public key"
> > >> and says that other methods are acceptable.  The comment
> > to KeyHash
> > >> in RFC 2560 4.2.1 is not as permissive.  Of course, it's 
> the same 
> > >> field as SKID, and I would support either stating "if the
> > KeyHash is
> > >> not precisely 20 octets long, it should be matched against the 
> > >> Subject Key Identifier extension of the signing certificate" or 
> > >> adding another choice like byID [3] OCTET STRING --
> > matches the value
> > >> of SKID.
> > >>
> > >>                 Tom Gindin
> > >>
> > >> P.S. - The above opinions are mine, and not necessarily
> > those of my
> > >> employer
> > >>
> > >>
> > >>
> > >>
> > >> "Santosh Chokhani" <[email-masked]> Sent by: 
> > >> [email-masked]
> > >> 03/26/2009 10:39 PM
> > >>
> > >> To
> > >> "IETF-pkix" <[email-masked]>
> > >> cc
> > >>
> > >> Subject
> > >> OCSP RFC (RFC 2560) Dependence on SHA-1
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> RFC 2560 dependence on SHA-1 does not appear to be
> > difficult to deal
> > >> with.
> > >>
> > >> Section 4.3 lists SHA-1 as mandatory and RSA as 
> optional.  We can 
> > >> update this to add SHA-2 series as optional.
> > >>
> > >> The Responder ID has SHA-1 hardwired.  But, that is no
> > different than
> > >> key ID extensions in RFC 5280.  Here are some options in order of
> > >> preference:
> > >>
> > >> 1.  Align the language with subject key ID language in RFC 5280.
> > >>
> > >> 2.  Keep on using SHA-1.  This field is not security
> > relevant.  RFC
> > >> 2560 does not even describe how to use this field.  So,
> > having SHA-1
> > >> and accidental or intentional collisions will not hurt the
> > security
> > >> of the protocol.
> > >>
> > >> 3.  If you do not believe in KISS principle, you can
> > define another
> > >> response type and enhance the key ID ASN.1 syntax so that hash 
> > >> algorithm is identified.
> > >>
> > >> 4.  Another option is for the Responder to use the same hashing 
> > >> algorithm as the one in the first certID entry.
> > >>
> > >>
> > >> Santosh Chokhani
> > >> CygnaCom Solutions
> > >>
> > >>
> > >>
> > >>
> > > 
> > > 
> > 
> > 
> > --
> > 
> > Best Regards,
> > 
> > 	Massimiliano Pala
> > 
> > --o-----------------------------------------------------------
> > -------------
> > Massimiliano Pala [OpenCA Project Manager] 
> > [email-masked]
> >                                                   
> > [email-masked]
> > 
> > Dartmouth Computer Science Dept               Home Phone: +1 
> > (603) 369-9332
> > PKI/Trust Laboratory                          Work Phone: +1 
> > (603) 646-9179
> > --o-----------------------------------------------------------
> > -------------
> > 
> > People who think they know everything are a great annoyance 
> to those 
> > of us who do.
> > 							   --
> > Isaac Asimov
> > 
>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 01 Apr 2009 20:34:05 +0200

Santosh,

If you are talking about adding other options to calculate the KeyHash value
in ResponderID then I strongly disagree.

If you add unspecified options you change the properties of the field from
deterministic to a completely unknown value. It does not matter if RFC2560
isn't explicit in its description of the use of the field. The fact is that
OCSP explicitly defines this value and as such will allow a client to
deterministically compare this value with the certificate selected to
validate the response signature. If you allow other ways to calculate the
value but do not provide any means to signal what method that was used, then
this feature is lost.

In worst case we will cause current implementation to fail.

I really don't think its worth the effort to change this field. We have a
very large base of implementations that we really don't want to mess up
unless its absolutely necessary.

As the only property of this field is to provide a convenient identifier, it
is far from absolutely necessary to change it. Remember that there is a
second choice to to identify responder by name. For names we have accepted
the possibility of collisions. In that comparison, upgrading from SHA-1 is
really redundant.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 1 Apr 2009 16:31:58 -0400

Stefan,

See responses in-line.

> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Wednesday, April 01, 2009 2:34 PM
> To: Santosh Chokhani; Massimiliano Pala; IETF-pkix
> If you are talking about adding other options to calculate 
> the KeyHash value in ResponderID then I strongly disagree.
> 
> If you add unspecified options you change the properties of 
> the field from deterministic to a completely unknown value. 
> It does not matter if RFC2560 isn't explicit in its 
> description of the use of the field. The fact is that OCSP 
> explicitly defines this value and as such will allow a client 
> to deterministically compare this value with the certificate 
> selected to validate the response signature.

I hope no one is doing the matching of Responder ID with hash of a key
in place of responder signature verification.  That would be real bad.

> If you allow 
> other ways to calculate the value but do not provide any 
> means to signal what method that was used, then this feature is lost.

The most common use will be to use this field to prioritize the
certificates of the responder to use for sigature verification on the
response.

> In worst case we will cause current implementation to fail.

That is why I am asking what problems if any will the vendors have.

> 
> I really don't think its worth the effort to change this 
> field. We have a very large base of implementations that we 
> really don't want to mess up unless its absolutely necessary.

So, we agree that leaving this field hard wired to SHA-1 is ok and 2560
can easily accommodate new hash functions.  Right?

My only reason to align with 5280 is that if some one were ever want to
strip off SHA-1 altogether from their Responder or client, permitting
other methods does it.

> 
> As the only property of this field is to provide a convenient 
> identifier, it is far from absolutely necessary to change it. 
> Remember that there is a second choice to to identify 
> responder by name. For names we have accepted the possibility 
> of collisions. In that comparison, upgrading from SHA-1 is 
> really redundant.
> 
> /Stefan
> 
> 
> 
> 
> other digest 
> >> algorithm.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 02 Apr 2009 00:32:04 +0200

Santosh,

In-line

> in place of responder signature verification.  That would be real bad.

Yes it would. That is not at all what I talk about. But a client could use
this value to locate a responder certificate.

> certificates of the responder to use for sigature verification on the

Do you know this for a fact, or are you guessing?
If a single implementation verifies that the certificate used to validate
the response matches the ResponderID value, and choose to go into an error
state because of mismatch, then we have created great problems. So we can't
guess. We have to know that no single implementation will fail because of
this. And that may be very hard.

> That is why I am asking what problems if any will the vendors have.

Even if no vendor speaks up here, it will not guarantee that this will not
create any problems.

> can easily accommodate new hash functions.  Right?

I fail to understand this sentence. Despite reading it many times over.

> strip off SHA-1 altogether from their Responder or client, permitting

I don't believe this argument is valid as I don't think it is possible to
strip off SHA-1 in any reasonable future. In any case. If we compare the
positive side with allowing this change and the negative consequences to
make OCSP incompatible with itself, my choice is easy.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 1 Apr 2009 20:39:23 -0400

I am saying that "Do you agree that 2560 can be left alone for Responder
ID's key ID CHOICE being SHA-1 based?"

> Sent: Wednesday, April 01, 2009 6:32 PM
> To: Santosh Chokhani; IETF-pkix
> >> If you are talking about adding other options to calculate the 
> >> KeyHash value in ResponderID then I strongly disagree.
> >> 
> >> If you add unspecified options you change the properties 
> of the field 
> >> from deterministic to a completely unknown value.
> >> It does not matter if RFC2560 isn't explicit in its description of 
> >> the use of the field. The fact is that OCSP explicitly 
> defines this 
> >> value and as such will allow a client to deterministically compare 
> >> this value with the certificate selected to validate the response 
> >> signature.
> > 
> Yes it would. That is not at all what I talk about. But a 
> client could use this value to locate a responder certificate.
> 
> >> If you allow
> >> other ways to calculate the value but do not provide any means to 
> >> signal what method that was used, then this feature is lost.
> > 
> If a single implementation verifies that the certificate used 
> to validate the response matches the ResponderID value, and 
> choose to go into an error state because of mismatch, then we 
> have created great problems. So we can't guess. We have to 
> know that no single implementation will fail because of this. 
> And that may be very hard.
> 
> 
> >> 
> Even if no vendor speaks up here, it will not guarantee that 
> this will not create any problems.
> 
> >> 
> >> I really don't think its worth the effort to change this field. We 
> >> have a very large base of implementations that we really 
> don't want 
> >> to mess up unless its absolutely necessary.
> > 
> > So, we agree that leaving this field hard wired to SHA-1 is ok and 
> > 2560 can easily accommodate new hash functions.  Right?
> > 
> 
> > My only reason to align with 5280 is that if some one were 
> ever want 
> > to strip off SHA-1 altogether from their Responder or client, 
> > permitting other methods does it.
> > 
> 
> I don't believe this argument is valid as I don't think it is 
> possible to strip off SHA-1 in any reasonable future. In any 
> case. If we compare the positive side with allowing this 
> change and the negative consequences to make OCSP 
> incompatible with itself, my choice is easy.
> 
> /Stefan
>  
> 
> >> 
> >> Remember that there is a second choice to to identify responder by 
> >> name. For names we have accepted the possibility of collisions. In 
> >> that comparison, upgrading from SHA-1 is really redundant.
> >> 
> >> /Stefan
> >> 
> >> 
> >> 
> >>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 1 Apr 2009 21:52:55 -0700

I think we have no choice but to leave the Key ID CHOICE to be SHA-1 based.
 
But that does not preclude adding an extension that allows the KeyID to be specified using a stronger algorithm. There are two reasons for this:
 
1) Optics, even if there is no security implication, a protocol that uses weak crypto necessitates an (expensive) security review to prove that there is no problem. And these must be performed repeatedly by many different parties as relying on the analysis of others is a good way to cause issues. Been there, done that.
 
2) We are designing for long time spans, ten years or more. While simple compressor collisions may not be a concern, there is no guarantee that the attacks will stop at that point. MD4 has been broken repeatedly and they are now at the stage of jumping up and down on the little pieces. It will probably happen to MD5 and we should be cautious in case it happens to SHA-1.

On the claim of 'Keep it simple STUPID', I find it rather offensive to have my position characterized as stupid. My designs are not exactly known for being verbose or overly elaborate. If I propose something it is because there is a reason. It is very easy to defend the status quo by derriding proposals as unnecessary, but the fact is that making OCSP too simple will simply cause the complexity to blow out somewhere else.
 
There is an architectural princple of modular design that demands that the core of PKIX as it now stands (the certificate profile and OCSP) be capable of stand alone use. We cannot fix issues in OCSP with LTANS or other layered-on protocols as some have proposed. It does not simplify my OCSP deployment to have to graft on an entire different protocol in addition or to re-engineer my document archival protocol to cover defects in OCSP.

Simply adding new algorithms to a protocol does nothing to improve security. You only improve security if you withdraw insecure algorithms from use.
 
To make the system work you have to have a means of negotiating between the client and the server. Otherwise there is no way for an OCSP responder to ensure that it receives a secure, supported response to querries for certificates that do not exist yet or are not known to the responder.
 
In the case of an OCSP responder being driven by CRLs collected from various sources, there is no way for the CA to know if a certificate even exists, all it knows is if the status is definitively revoked.
 
In the case of many transactional architectures the OCSP validation is performed independently of certificate chain validation. 

Experience of small scale PKI deployment in which any box can be upgraded at will is simply not representative of large scale real world deployment.

________________________________

From: [email-masked] on behalf of Santosh Chokhani
Sent: Wed 4/1/2009 8:39 PM
To: Stefan Santesson; IETF-pkix
Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 2 Apr 2009 07:54:02 -0400

I have no objection to having an extension, but if in the long term
SHA-1 will not be there, it seems defining a new response type (say
basic 2) would be the way to go so that SHA-1 based key ID can be
stripped off.
 
If SHA-1 is not getting ripped off in the long term, I do not see value
in extension except that it may make every one happy: those who do not
care will not include it on the Server side and/or will ignore it on the
client side.
 
It would appear that the extension should be NC.
 
Phil,
 
I would not respond to the arguments on KISS and security since in this
case both are straightforward.  Also, in this thread, the comments were
not meant for or directed at you.
 
As you know, I have provided extensive comments to you when you first
posted the OCSP Agility I-D and my position and reasons are matter of
PKIX archives for anyone to scrutinize.  When you ignore every single
cogent point, there is no sense in me commenting on next iteration.  I
do think that the OCSP Agility I-D is a solution looking for a problem
that I do not see.

	From: Hallam-Baker, Phillip [mailto:[email-masked]] 
	Sent: Thursday, April 02, 2009 12:53 AM
	To: Santosh Chokhani; Stefan Santesson; IETF-pkix
	Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1

	I think we have no choice but to leave the Key ID CHOICE to be
SHA-1 based.
	 
	But that does not preclude adding an extension that allows the
KeyID to be specified using a stronger algorithm. There are two reasons
for this:
	 
	1) Optics, even if there is no security implication, a protocol
that uses weak crypto necessitates an (expensive) security review to
prove that there is no problem. And these must be performed repeatedly
by many different parties as relying on the analysis of others is a good
way to cause issues. Been there, done that.
	 
	2) We are designing for long time spans, ten years or more.
While simple compressor collisions may not be a concern, there is no
guarantee that the attacks will stop at that point. MD4 has been broken
repeatedly and they are now at the stage of jumping up and down on the
little pieces. It will probably happen to MD5 and we should be cautious
in case it happens to SHA-1.

	On the claim of 'Keep it simple STUPID', I find it rather
offensive to have my position characterized as stupid. My designs are
not exactly known for being verbose or overly elaborate. If I propose
something it is because there is a reason. It is very easy to defend the
status quo by derriding proposals as unnecessary, but the fact is that
making OCSP too simple will simply cause the complexity to blow out
somewhere else.
	 
	There is an architectural princple of modular design that
demands that the core of PKIX as it now stands (the certificate profile
and OCSP) be capable of stand alone use. We cannot fix issues in OCSP
with LTANS or other layered-on protocols as some have proposed. It does
not simplify my OCSP deployment to have to graft on an entire different
protocol in addition or to re-engineer my document archival protocol to
cover defects in OCSP.

	Simply adding new algorithms to a protocol does nothing to
improve security. You only improve security if you withdraw insecure
algorithms from use.
	 
	To make the system work you have to have a means of negotiating
between the client and the server. Otherwise there is no way for an OCSP
responder to ensure that it receives a secure, supported response to
querries for certificates that do not exist yet or are not known to the
responder.
	 
	In the case of an OCSP responder being driven by CRLs collected
from various sources, there is no way for the CA to know if a
certificate even exists, all it knows is if the status is definitively
revoked.
	 
	In the case of many transactional architectures the OCSP
validation is performed independently of certificate chain validation. 

	Experience of small scale PKI deployment in which any box can be
upgraded at will is simply not representative of large scale real world
deployment.

	I am saying that "Do you agree that 2560 can be left alone for
Responder
	ID's key ID CHOICE being SHA-1 based?"
	
	> >> If you are talking about adding other options to calculate
the
	> >> It does not matter if RFC2560 isn't explicit in its
description of
	> >> other ways to calculate the value but do not provide any
means to
	> >> I really don't think its worth the effort to change this
field. We
	> >> Remember that there is a second choice to to identify
responder by
	> >>> terms of bits on the wire and aligning the Key ID with
SKID
	> >> in 5280 is
	> >>> OCSP Responder and OCSP client vendors should speak up if
I
	> >> am wrong.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 02 Apr 2009 14:18:28 +0200

I do agree to most things here.

I don¹t believe that implementations can strip off SHA-1 in any foreseeable
future. It needs to be around, if nothing else, so for backwards
compatibility. SHA-1 will continue to work in situations like this where no
security properties are needed.

IMO, The added extension, even though I will not fight hard against it,
would just be redundant complexity.

/Stefan

On 4/2/09 1:54 PM, "Santosh Chokhani" <[email-masked]> wrote:

> I have no objection to having an extension, but if in the long term SHA-1 will
> not be there, it seems defining a new response type (say basic 2) would be the
> way to go so that SHA-1 based key ID can be stripped off.
>  
> If SHA-1 is not getting ripped off in the long term, I do not see value in
> extension except that it may make every one happy: those who do not care will
> not include it on the Server side and/or will ignore it on the client side.
>  
> I would not respond to the arguments on KISS and security since in this case
> both are straightforward.  Also, in this thread, the comments were not meant
> for or directed at you.
>  
> As you know, I have provided extensive comments to you when you first posted
> the OCSP Agility I-D and my position and reasons are matter of PKIX archives
> for anyone to scrutinize.  When you ignore every single cogent point, there is
> no sense in me commenting on next iteration.  I do think that the OCSP Agility
> I-D is a solution looking for a problem that I do not see.
>>  
>>  
>> 
>> But that does not preclude adding an  extension that allows the KeyID to be
>> specified using a stronger algorithm.  There are two reasons for this:
>>  
>>  
>>  
>> 1) Optics, even if there is no security  implication, a protocol that uses
>> weak crypto necessitates an (expensive)  security review to prove that there
>> is no problem. And these must be performed  repeatedly by many different
>> parties as relying on the analysis of others is a  good way to cause issues.
>> Been there, done that.
>>  
>>  
>>  
>> 2) We are designing for long time spans,  ten years or more. While simple
>> compressor collisions may not be a concern,  there is no guarantee that the
>> attacks will stop at that point. MD4 has been  broken repeatedly and they are
>> now at the stage of jumping up and down on the  little pieces. It will
>> probably happen to MD5 and we should be cautious in  case it happens to
>> SHA-1.
>>  
>>  
>>  
>>  
>>  
>> On the claim of 'Keep it simple STUPID',  I find it rather offensive to have
>> my position characterized as stupid. My  designs are not exactly known for
>> being verbose or overly elaborate. If I  propose something it is because
>> there is a reason. It is very easy to defend  the status quo by derriding
>> proposals as unnecessary, but the fact is that  making OCSP too simple will
>> simply cause the complexity to blow out somewhere  else.
>>  
>>  
>>  
>> There is an architectural princple of  modular design that demands that the
>> core of PKIX as it now stands (the  certificate profile and OCSP) be capable
>> of stand alone use. We cannot fix  issues in OCSP with LTANS or other
>> layered-on protocols as some have proposed.  It does not simplify my OCSP
>> deployment to have to graft on an entire  different protocol in addition or
>> to re-engineer my document archival protocol  to cover defects in OCSP.
>>  
>>  
>>  
>>  
>>  
>> Simply adding new algorithms to a  protocol does nothing to improve security.
>> You only improve security if you  withdraw insecure algorithms from use.
>>  
>>  
>>  
>> To make the system work you have to have  a means of negotiating between the
>> client and the server. Otherwise there is  no way for an OCSP responder to
>> ensure that it receives a secure,  supported response to querries for
>> certificates that do not exist yet or  are not known to the responder.
>>  
>>  
>>  
>> In the case of an OCSP responder being  driven by CRLs collected from various
>> sources, there is no way for the CA to  know if a certificate even exists,
>> all it knows is if the status is  definitively revoked.
>>  
>>  
>>  
>> In the case of many transactional  architectures the OCSP validation is
>> performed independently of certificate  chain validation.
>>  
>>  
>>  
>>  
>>  
>> Experience of small scale PKI deployment  in which any box can be upgraded at
>> will is simply not representative of large  scale real world deployment.
>>  
>>  
>>  
>>  
>> 
>>  
>>  
>> 
>>  
>>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 2 Apr 2009 08:41:31 -0400

Agree

	From: Stefan Santesson [mailto:[email-masked]] 
	Sent: Thursday, April 02, 2009 8:18 AM
	To: Santosh Chokhani; Hallam-Baker, Phillip; IETF-pkix
	Subject: Re: OCSP RFC (RFC 2560) Dependence on SHA-1

	I don't believe that implementations can strip off SHA-1 in any
foreseeable future. It needs to be around, if nothing else, so for
backwards compatibility. SHA-1 will continue to work in situations like
this where no security properties are needed.
	
	IMO, The added extension, even though I will not fight hard
against it,  would just be redundant complexity.
	
	/Stefan
	
	On 4/2/09 1:54 PM, "Santosh Chokhani" <[email-masked]>
wrote:

		I have no objection to having an extension, but if in
the long term SHA-1 will not be there, it seems defining a new response
type (say basic 2) would be the way to go so that SHA-1 based key ID can
be stripped off.
		
		If SHA-1 is not getting ripped off in the long term, I
do not see value in extension except that it may make every one happy:
those who do not care will not include it on the Server side and/or will
ignore it on the client side.

		Phil,
		
		I would not respond to the arguments on KISS and
security since in this case both are straightforward.  Also, in this
thread, the comments were not meant for or directed at you.
		
		As you know, I have provided extensive comments to you
when you first posted the OCSP Agility I-D and my position and reasons
are matter of PKIX archives for anyone to scrutinize.  When you ignore
every single cogent point, there is no sense in me commenting on next
iteration.  I do think that the OCSP Agility I-D is a solution looking
for a problem that I do not see.

			From: Hallam-Baker, Phillip
[mailto:[email-masked]] 
			Sent: Thursday, April 02, 2009 12:53  AM
			To: Santosh Chokhani; Stefan Santesson;
IETF-pkix
			Subject: RE: OCSP RFC (RFC 2560) Dependence on
SHA-1

			 
			I think we have no choice  but to leave the Key
ID CHOICE to be SHA-1 based.

			But that does not preclude adding an  extension
that allows the KeyID to be specified using a stronger algorithm.  There
are two reasons for this:

			1) Optics, even if there is no security
implication, a protocol that uses weak crypto necessitates an
(expensive)  security review to prove that there is no problem. And
these must be performed  repeatedly by many different parties as relying
on the analysis of others is a  good way to cause issues. Been there,
done that.

			2) We are designing for long time spans,  ten
years or more. While simple compressor collisions may not be a concern,
there is no guarantee that the attacks will stop at that point. MD4 has
been  broken repeatedly and they are now at the stage of jumping up and
down on the  little pieces. It will probably happen to MD5 and we should
be cautious in  case it happens to SHA-1.

			On the claim of 'Keep it simple STUPID',  I find
it rather offensive to have my position characterized as stupid. My
designs are not exactly known for being verbose or overly elaborate. If
I  propose something it is because there is a reason. It is very easy to
defend  the status quo by derriding proposals as unnecessary, but the
fact is that  making OCSP too simple will simply cause the complexity to
blow out somewhere  else.

			There is an architectural princple of  modular
design that demands that the core of PKIX as it now stands (the
certificate profile and OCSP) be capable of stand alone use. We cannot
fix  issues in OCSP with LTANS or other layered-on protocols as some
have proposed.  It does not simplify my OCSP deployment to have to graft
on an entire  different protocol in addition or to re-engineer my
document archival protocol  to cover defects in OCSP.

			Simply adding new algorithms to a  protocol does
nothing to improve security. You only improve security if you  withdraw
insecure algorithms from use.

			To make the system work you have to have  a
means of negotiating between the client and the server. Otherwise there
is  no way for an OCSP responder to ensure that it receives a secure,
supported response to querries for certificates that do not exist yet or
are not known to the responder.

			In the case of an OCSP responder being  driven
by CRLs collected from various sources, there is no way for the CA to
know if a certificate even exists, all it knows is if the status is
definitively revoked.

			In the case of many transactional  architectures
the OCSP validation is performed independently of certificate  chain
validation. 

			Experience of small scale PKI deployment  in
which any box can be upgraded at will is simply not representative of
large  scale real world deployment.

			 

			 
			From:  [email-masked] on behalf of
Santosh Chokhani
			Sent: Wed  4/1/2009 8:39 PM
			To: Stefan Santesson; IETF-pkix
			Subject:  RE: OCSP RFC (RFC 2560) Dependence on
SHA-1

			I am saying that "Do you agree that 2560 can be
left alone for  Responder
			ID's key ID CHOICE being SHA-1 based?"
			
			> > I hope no one is doing the matching of
Responder ID  with
			> hash of a key
			> > in place of responder signature
verification.  That would
			> be real bad.
			>  > certificates of the responder to use for
sigature
			> verification on  the
			> I fail to understand this  sentence. Despite
reading it many
			> times over.
			> >>> My resident ASN.1 expert  apprised me of
the fact that
			> >> adding a choice
			>  >>> will break backward compatibility.  Thus,
extension is  a
			> >> fifth option
			> >>> Based on what I know of  OCSP
implementations, not changing
			> >> anything in
			>  >>> terms of bits on the wire and aligning
the Key ID with  SKID
			> >> in 5280 is
			> >>> the best approach.   I do not think it
will hurt backward
			> >> compatibility.
			>  >>>
			> >>> OCSP Responder and OCSP client vendors
should speak up if I
			> >>>>> [mailto:[email-masked]]
On Behalf Of
			> >>>>> security implication in the OCSP,
another viable way
			> would be to
			>  >>>>> can be done as a separate document for
those who what  to
			> >> use other
			> >>>>> digest  algorithms.
			> >>>>>
			> >>>>> After  all, isn't this an example of why
we allow
			> >> extensions to  the
			>  >>>>>>> not precisely 20 octets long, it
should be  matched
			> against the
			> >>>>>>> Subject Key  Identifier extension of
the signing
			> certificate" or
			>  >>>>>>> key ID extensions in RFC 5280.  Here
are  some options
			> >> in order of
			> >>>>>>>  preference:
			> >>>>>>>
			>  >>>>>>> 1.  Align the language with subject
key ID  language
			> in RFC 5280.
			> >>>>>>> response type and enhance  the key ID
ASN.1 syntax so
			> that hash
			>  >>>>>>> algorithm is identified.
			>  >>>>>>>
			> >>>>>>> 4.   Another option is for the
Responder to use the
			> same hashing

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 2 Apr 2009 06:47:45 -0700

On the contrary, each time I asked for a substantive argument you used exactly the same non argument you are using here.
 
I have put a substantive argument on the table here. "I am not convinced" or "I answered the question some other time" with no links to the specific points are not a substantive response. You may think that you gave a substantive explanation of how a client that only supports ECC can obtain a comprehensible response from a generic OCSP server that also supports RSA. However I do not beleive that it is possible in the current protocol.
 
If you think you have demonstrated this in the past then please point to the email.

From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thu 4/2/2009 7:54 AM
To: Hallam-Baker, Phillip; Stefan Santesson; IETF-pkix
Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1

I have no objection to having an extension, but if in the long term SHA-1 will not be there, it seems defining a new response type (say basic 2) would be the way to go so that SHA-1 based key ID can be stripped off.
 
If SHA-1 is not getting ripped off in the long term, I do not see value in extension except that it may make every one happy: those who do not care will not include it on the Server side and/or will ignore it on the client side.

Phil,
 
I would not respond to the arguments on KISS and security since in this case both are straightforward.  Also, in this thread, the comments were not meant for or directed at you.
 
As you know, I have provided extensive comments to you when you first posted the OCSP Agility I-D and my position and reasons are matter of PKIX archives for anyone to scrutinize.  When you ignore every single cogent point, there is no sense in me commenting on next iteration.  I do think that the OCSP Agility I-D is a solution looking for a problem that I do not see.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 2 Apr 2009 07:18:28 -0700

Let us divide the problem into two. KEYID actually has two (separable) uses:

1) Client to server as a hash index to the cert
2) (Possibly implicit) Server to client as an authenticator of the actual cert
 
The situation I see here is this: The client has obtained a cert, it needs to know the status thereof. So it takes a digest of the certificate using SHA1 and sends it to the server which then uses it as a lookup key.
 
For this particular part of the problem, there does not appear to be any security concern. We are using SHA1 because it is a large hash function that has a minimal chance of accidental collision. But at this point we have not actually relied on the hash function for authentication purposes at either end. It is not being used as a cryptographic message digest.
 
So this seems to fit into a class that EKR once mentioned of cases where we use SHA1 or MD5 as a hash, not a message digest.

The second half of the equation is where we can end up in (some) difficulty. Particularly if we are working in an archival situation. Imagine the case that we have an RSA1024-SHA1 signature on a document signed using a key that was subsequently compromised and the question the infrastructure needs to answer is whether the certificate was valid at the point it was signed. This was one of the original core use cases in the design of OCSP.
 
In this case there is little choice but to use the SHA1 hash as a message digest and then we have the problem.

The simple fix here is to allow the server to specify its own digest for the actual cert whose status is being reported. You can think of it as being like using 96 bits of a digest as a hash and then supplying the full 256 bits to confirm that the located object was not subject to a collision.

The former Area Director, now the IETF chair has expressed concern as to the long term management of cryptographic algorithms on many occasions. I think that it would be very unwise for the rest of us to dismiss the chance that he has a really, really good and specific reason for this concern.
 
While the specific reason may not be imminent, the problem may well hit many years down the line after infrastructure is widely deployed and embedded. We should avoid creating additional Y2K type problems.

 

Phil,

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 2 Apr 2009 11:05:52 -0400

The second half of the equation is where we can end up in (some)
difficulty. Particularly if we are working in an archival situation.
Imagine the case that we have an RSA1024-SHA1 signature on a document
signed using a key that was subsequently compromised and the question
the infrastructure needs to answer is whether the certificate was valid
at the point it was signed. This was one of the original core use cases
in the design of OCSP.

Ignoring hash algorithms for the moment, how does a client indicate its
time of interest to the OCSP responder?

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 2 Apr 2009 10:58:47 -0400

Phil,
 
RFC 2560 already allows you to specify an algorithm for hash of cogent
data in the request.  BTW, that data is not certificate, but issuer DN
and Issuer key hash separately.
 
So, I do not see an issue with respect to security in RFC 2560 except to
add other algorithms to Section 4.3

	From: Hallam-Baker, Phillip [mailto:[email-masked]] 
	Sent: Thursday, April 02, 2009 10:18 AM
	To: Santosh Chokhani; Stefan Santesson; IETF-pkix
	Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1

	Let us divide the problem into two. KEYID actually has two
(separable) uses:

	1) Client to server as a hash index to the cert
	2) (Possibly implicit) Server to client as an authenticator of
the actual cert
	 
	The situation I see here is this: The client has obtained a
cert, it needs to know the status thereof. So it takes a digest of the
certificate using SHA1 and sends it to the server which then uses it as
a lookup key.
	 
	For this particular part of the problem, there does not appear
to be any security concern. We are using SHA1 because it is a large hash
function that has a minimal chance of accidental collision. But at this
point we have not actually relied on the hash function for
authentication purposes at either end. It is not being used as a
cryptographic message digest.
	 
	So this seems to fit into a class that EKR once mentioned of
cases where we use SHA1 or MD5 as a hash, not a message digest.

	In this case there is little choice but to use the SHA1 hash as
a message digest and then we have the problem.

	The simple fix here is to allow the server to specify its own
digest for the actual cert whose status is being reported. You can think
of it as being like using 96 bits of a digest as a hash and then
supplying the full 256 bits to confirm that the located object was not
subject to a collision.

	The former Area Director, now the IETF chair has expressed
concern as to the long term management of cryptographic algorithms on
many occasions. I think that it would be very unwise for the rest of us
to dismiss the chance that he has a really, really good and specific
reason for this concern.
	 
	While the specific reason may not be imminent, the problem may
well hit many years down the line after infrastructure is widely
deployed and embedded. We should avoid creating additional Y2K type
problems.

	I have no objection to having an extension, but if in the long
term SHA-1 will not be there, it seems defining a new response type (say
basic 2) would be the way to go so that SHA-1 based key ID can be
stripped off.
	 
	If SHA-1 is not getting ripped off in the long term, I do not
see value in extension except that it may make every one happy: those
who do not care will not include it on the Server side and/or will
ignore it on the client side.

	Phil,
	 
	I would not respond to the arguments on KISS and security since
in this case both are straightforward.  Also, in this thread, the
comments were not meant for or directed at you.
	 
	As you know, I have provided extensive comments to you when you
first posted the OCSP Agility I-D and my position and reasons are matter
of PKIX archives for anyone to scrutinize.  When you ignore every single
cogent point, there is no sense in me commenting on next iteration.  I
do think that the OCSP Agility I-D is a solution looking for a problem
that I do not see.

		I think we have no choice but to leave the Key ID CHOICE
to be SHA-1 based.
		 
		But that does not preclude adding an extension that
allows the KeyID to be specified using a stronger algorithm. There are
two reasons for this:
		 
		1) Optics, even if there is no security implication, a
protocol that uses weak crypto necessitates an (expensive) security
review to prove that there is no problem. And these must be performed
repeatedly by many different parties as relying on the analysis of
others is a good way to cause issues. Been there, done that.
		 
		2) We are designing for long time spans, ten years or
more. While simple compressor collisions may not be a concern, there is
no guarantee that the attacks will stop at that point. MD4 has been
broken repeatedly and they are now at the stage of jumping up and down
on the little pieces. It will probably happen to MD5 and we should be
cautious in case it happens to SHA-1.

		On the claim of 'Keep it simple STUPID', I find it
rather offensive to have my position characterized as stupid. My designs
are not exactly known for being verbose or overly elaborate. If I
propose something it is because there is a reason. It is very easy to
defend the status quo by derriding proposals as unnecessary, but the
fact is that making OCSP too simple will simply cause the complexity to
blow out somewhere else.
		 
		There is an architectural princple of modular design
that demands that the core of PKIX as it now stands (the certificate
profile and OCSP) be capable of stand alone use. We cannot fix issues in
OCSP with LTANS or other layered-on protocols as some have proposed. It
does not simplify my OCSP deployment to have to graft on an entire
different protocol in addition or to re-engineer my document archival
protocol to cover defects in OCSP.

		Simply adding new algorithms to a protocol does nothing
to improve security. You only improve security if you withdraw insecure
algorithms from use.
		 
		To make the system work you have to have a means of
negotiating between the client and the server. Otherwise there is no way
for an OCSP responder to ensure that it receives a secure, supported
response to querries for certificates that do not exist yet or are not
known to the responder.
		 
		In the case of an OCSP responder being driven by CRLs
collected from various sources, there is no way for the CA to know if a
certificate even exists, all it knows is if the status is definitively
revoked.

		Experience of small scale PKI deployment in which any
box can be upgraded at will is simply not representative of large scale
real world deployment.

		From: [email-masked] on behalf of Santosh
Chokhani
		Sent: Wed 4/1/2009 8:39 PM
		To: Stefan Santesson; IETF-pkix
		Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1

		I am saying that "Do you agree that 2560 can be left
alone for Responder
		ID's key ID CHOICE being SHA-1 based?"
		
description of
		> > I hope no one is doing the matching of Responder ID
with
		> hash of a key
		> > in place of responder signature verification.  That
would
		> I fail to understand this sentence. Despite reading it
many
		> >>> My resident ASN.1 expert apprised me of the fact
that
extension is a
		> >>> Based on what I know of OCSP implementations, not
changing
		> >> anything in
		> >>> terms of bits on the wire and aligning the Key ID
with SKID
		> >> in 5280 is
		> >>> the best approach.  I do not think it will hurt
backward
		> >> compatibility.
		> >>>
		> >>> OCSP Responder and OCSP client vendors should
speak up if I
SHA-1
		> >>>>> [mailto:[email-masked]] On Behalf
Of
		> >>>>> security implication in the OCSP, another viable
way
		> >>>>> can be done as a separate document for those who
what to
		> >>>>>>> not precisely 20 octets long, it should be
matched
		> against the
		> >>>>>>> Subject Key Identifier extension of the
signing
		> >>>>>>> key ID extensions in RFC 5280.  Here are some
options
		> >> in order of
		> >>>>>>> preference:
		> >>>>>>>
		> >>>>>>> 1.  Align the language with subject key ID
language
		> >>>>>>> response type and enhance the key ID ASN.1
syntax so
		> that hash
		> >>>>>>> algorithm is identified.
		> >>>>>>>
		> >>>>>>> 4.  Another option is for the Responder to use
the

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 2 Apr 2009 16:01:54 -0400

The post and attached word document with comments on Phil's draft may
not have made it to the list due to the word attachment.
 
So, the URL below can be used to download my commented version of 2007
draft from Phil.
 
http://www.orionsec.net/draft-hallambaker-ocspagility-sc-round%202.doc
<http://www.orionsec.net/draft-hallambaker-ocspagility-sc-round%202.doc>

	From: Santosh Chokhani 
	Sent: Thursday, April 02, 2009 11:12 AM
	To: 'Hallam-Baker, Phillip'; Stefan Santesson; IETF-pkix
	Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1

	Phil,
	 
	See the attached.
	 
	In addition, posts circa October 2007 on relevant thread from me
will have the comments.

		Sent: Thursday, April 02, 2009 9:48 AM
		To: Santosh Chokhani; Stefan Santesson; IETF-pkix
		Subject: RE: OCSP RFC (RFC 2560) Dependence on SHA-1

		On the contrary, each time I asked for a substantive
argument you used exactly the same non argument you are using here.
		 
		I have put a substantive argument on the table here. "I
am not convinced" or "I answered the question some other time" with no
links to the specific points are not a substantive response. You may
think that you gave a substantive explanation of how a client that only
supports ECC can obtain a comprehensible response from a generic OCSP
server that also supports RSA. However I do not beleive that it is
possible in the current protocol.
		 
		If you think you have demonstrated this in the past then
please point to the email.

		 

		Phil,

			 
			 
			1) Optics, even if there is no security
implication, a protocol that uses weak crypto necessitates an
(expensive) security review to prove that there is no problem. And these
must be performed repeatedly by many different parties as relying on the
analysis of others is a good way to cause issues. Been there, done that.

			 
			There is an architectural princple of modular
design that demands that the core of PKIX as it now stands (the
certificate profile and OCSP) be capable of stand alone use. We cannot
fix issues in OCSP with LTANS or other layered-on protocols as some have
proposed. It does not simplify my OCSP deployment to have to graft on an
entire different protocol in addition or to re-engineer my document
archival protocol to cover defects in OCSP.

			To make the system work you have to have a means
of negotiating between the client and the server. Otherwise there is no
way for an OCSP responder to ensure that it receives a secure, supported
response to querries for certificates that do not exist yet or are not
known to the responder.
			 
			In the case of an OCSP responder being driven by
CRLs collected from various sources, there is no way for the CA to know
if a certificate even exists, all it knows is if the status is
definitively revoked.

			
Responder ID with
verification.  That would
sigature
reading it many
the fact that
extension is a
			> >> anything in
			> >>> terms of bits on the wire and aligning the
Key ID with SKID
			> >> in 5280 is
			> >>> the best approach.  I do not think it will
hurt backward
should speak up if I
			> >>>>> [mailto:[email-masked]] On
Behalf Of
another viable way
those who what to
we allow
should be matched
the signing
are some options
key ID language
ASN.1 syntax so
Responder to use the

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 1 Apr 2009 16:31:58 -0400

Stefan,

See responses in-line.

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 2 Apr 2009 08:41:31 -0400

Agree

	

	/Stefan

		

		Phil,

			

			 

			 

			 

			 

			 

			 

			 

			 

			
Responder ID  with
verification.  That would
sigature
reading it many
the fact that
extension is  a
the Key ID with  SKID
will hurt backward
should speak up if I
On Behalf Of
another viable way
those who what  to
we allow
should be  matched
the signing
are  some options
key ID  language
ASN.1 syntax so
Responder to use the

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 2 Apr 2009 07:54:02 -0400

Phil,

	 

	 

	 

	
the
description of
means to
field. We
responder by
SKID
I

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 2 Apr 2009 06:47:45 -0700

Phil,

---

From: Carl Wallace <[email-masked]>
Date: Thu, 2 Apr 2009 11:05:52 -0400

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 13 Apr 2009 15:53:12 -0400

It seems that leaving responderID as is is our best course of action.
Since this field and its match is not security relevant, I do not see
this particular dependence on SHA-1 as problematic.

> From: Kelvin Yiu [mailto:[email-masked]] 
> Sent: Monday, April 13, 2009 2:50 PM
> [Sorry for jumping on this thread so late]
> 
> Santosh,
> 
> The OCSP client in Windows Vista uses the responderID field 
> to find the OCSP signer cert in the cert bag and expects the 
> key hash to be SHA-1. Otherwise, the OCSP response will be 
> rejected. Upgrading from SHA-1 will be problematic.
> 
> Kelvin Yiu
> Lead Program Manager, Windows Security
> Microsoft
> 
> 
> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
> Sent: Wednesday, April 01, 2009 1:32 PM
> the KeyHash 
> > value in ResponderID then I strongly disagree.
> > 
> the field 
> description of the 
> > use of the field. The fact is that OCSP explicitly defines 
> this value 
> > and as such will allow a client to deterministically compare this 
> > value with the certificate selected to validate the response 
> > signature.
> 
> I hope no one is doing the matching of Responder ID with hash 
> of a key in place of responder signature verification.  That 
> would be real bad.
> 
> > If you allow
> The most common use will be to use this field to prioritize 
> the certificates of the responder to use for sigature 
> verification on the response.
> 
> > 
> don't want to 
> > mess up unless its absolutely necessary.
> 
> So, we agree that leaving this field hard wired to SHA-1 is 
> ok and 2560 can easily accommodate new hash functions.  Right?
> 
> ever want to strip off SHA-1 altogether from their Responder 
> or client, permitting other methods does it.
> 
> >

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Apr 2009 11:02:52 +0200

This is also my opinion.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 14 Apr 2009 09:30:49 -0400

This also leads to the conclusion made in the initial email on this
thread that enhancing 2560 for newer hashing and signature algorithm is
a matter of requiring mandatory or optional support for added
algorithms.  As it so happens, the algorithm identifiers for these are
already registered through other RFCs.

> Sent: Tuesday, April 14, 2009 5:03 AM
> To: Santosh Chokhani; Kelvin Yiu; IETF-pkix
> >> The OCSP client in Windows Vista uses the responderID 
> field to find 
> >> the OCSP signer cert in the cert bag and expects the key 
> hash to be 
> >> SHA-1. Otherwise, the OCSP response will be rejected. 
> Upgrading from 
> >> SHA-1 will be problematic.
> >> 
> >> Kelvin Yiu
> >> Lead Program Manager, Windows Security Microsoft
> >> 
> >> 
> >> I hope no one is doing the matching of Responder ID with hash of a 
> >> key in place of responder signature verification.  That 
> would be real 
> >> bad.
> >> 
> >>> If you allow
> >>>>>>>> "IETF-pkix" <[email-masked]> cc
> >>>>>>>> 
> >>>>>>>> Subject