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

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 26 Mar 2009 22:39:56 -0400

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

---

From: Tom Gindin <[email-masked]>
Date: Mon, 30 Mar 2009 19:46:25 -0400

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

Santosh Chokhani
CygnaCom Solutions

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 31 Mar 2009 09:29:02 -0400

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

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 31 Mar 2009 13:37:07 -0400

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

-- 

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: "Santosh Chokhani" <[email-masked]>
Date: Tue, 31 Mar 2009 12:51:25 -0400

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. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Massimiliano Pala
> Sent: Tuesday, March 31, 2009 1:37 PM
> To: IETF-pkix
> 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,
> > 
> > If one were to add something, one should describe how this 
> field can 
> > be used to select from multiple Responder certificates.
> > 
> >> 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
> >>
> >> "Santosh Chokhani" <[email-masked]> Sent by: 
> >> [email-masked]
> >> 03/26/2009 10:39 PM
> >>
> >> To
> >> Section 4.3 lists SHA-1 as mandatory and RSA as optional.  We can 
> >> update this to add SHA-2 series as optional.
> >>
> >> 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.
> >>
> >> response type and enhance the key ID ASN.1 syntax so that hash 
> >> algorithm is identified.
> >>
> People who think they know everything are a great annoyance 
> to those of us who do.
> 							   -- 
> Isaac Asimov
>