Subject: Re: [pkix] Fixing OCSP agility

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 6 Nov 2010 00:23:38 -0400

Again, I have still not had any reply.

On Thu, Oct 14, 2010 at 12:36 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> I posted this on Sept 13th but did not get any reply either.
>
> I had some pushback from our technical/product management folk at Comodo who
> reviewed this pointed out that we are not solving algorithm agility issues
> associated with the OCSPRequest->CertID->hashAlgorithm
> This situation is worse than I thought as the OCSP spec does not actually
> consider the case of what to do if the CertID algorithm presented is
> unknown. The only thing that the responder can do is report 'unknown'. The
> OCSP spec does not distinguish between 'unknown cert' and 'unknown hash
> algorithm'.
>
> Now this does not matter at all at the moment since SHA1 is perfectly
> adequate as a hash function, it is only inadequate as a cryptographic
> digest. And in any case we definitely do not want to upgrade from SHA1 to
> SHA256 for this specific purpose. We would want to hop straight from SHA1 to
> SHA3.
> I suggest a fix as follows:
> 1) Define an OCSP response extension as follows:
>
> id-pkix-ocsp-certid-hashAlgorithm-Unkown OBJECT IDENTIFIER ::= {
> id-pkix-ocsp TBS }
>
>   AcceptableCertIDHashAlgorithms ::= SEQUENCE OF OBJECT IDENTIFIER
>
> This means that in ten years time when we have people telling us that we
> have to stop using SHA1 and show that we are not using it, that we will at
> least have a means of tracking the error.
> While the use of SHA1 for this purpose is safe, it is not inexpensive if you
> are running systems in a regulated environment with a requirement for annual
> audits. Every use of an obsolete crypto alg is going to mean auditor time.
>
> 2) Note in the security considerations
> Note that SHA1 is also used for OCSPRequest->CertID->hashAlgorithm
> Note that this purpose has been reviewed and is considered safe since there
> is negligible chance of an accidental collision and the existence of a
> deliberate collision would at worst cause a response for the wrong cert
> which would in turn mean the response did not match and chain validation
> would fail which is probably what you SHOULD want in that particular case.
>
> On Fri, Oct 8, 2010 at 10:15 AM, Stefan Santesson <[email-masked]>
> wrote:
>>
>> I would like to know who favors using the S/MIME Capabilities way of
>> specifying preferred algorithm instead of algorithmIdentifier?
>>
>> I have no problem using S/MIME Capability if that makes things clearer.
>> The ASN.1 syntax is the same for these. The only thing that differs is the
>> rules regarding parameters and potentially they may use different OIDs for
>> the same algorithm even though neither I nor Jim can think of one that
>> differs of the algorithms we normally are interested in.
>>
>> It would be good to determine this now and move on with a new WG last
>> call.
>>
>> /Stefan
>>
>>
>>
>> On 10-09-14 8:05 AM, "Jim Schaad" <[email-masked]> wrote:
>>
>> > Stefan,
>> >
>> >
>> >
>> > The big difference between using the algorithm identifier and the S/MIME
>> > Capability is a question of what is placed in the parameters field.
>> >  Thus
>> > for example the signature algorithm for RSA-PKCS#1 uses a NULL for the
>> > parameters field while the S/MIME Capability uses an empty parameter
>> > field.
>> > The parameters are supposed to only be present in the S/MIME Capability
>> > when
>> > they are needed to differentiate between different levels or pieces of
>> > an
>> > algorithm.  (The classic one being the effective key length of RC2.)
>> >
>> >
>> >
>> > We chose not to include the hash algorithm in RSA-PSS but could have
>> > re-defined the S/MIME Capability parameters for this algorithm to have
>> > been
>> > a sequence of hash algorithms and a sequence of masking functions that
>> > specified which ones were supported.
>> >
>> >
>> >
>> > In every case that I can currently remember, the OID is actually the
>> > same
>> > between the algorithm identifier and the s/mime capability.  The weasel
>> > wording was put in place to deal with the fact that originally the same
>> > OID
>> > was being used to identify both the RSA-PKCS#1 signature algorithm and
>> > the
>> > RSA public key.  (The RSA public key OID being used in both locations.)
>> > This is no longer an acceptable practice.
>> >
>> >
>> >
>> > Jim
>> >
>> >
>> >
>> >
>> >
>> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> > Stefan Santesson
>> > Sent: Tuesday, September 07, 2010 5:07 AM
>> > To: [email-masked]
>> > Subject: [pkix] Fixing OCSP agility
>> >
>> >
>> >
>> > At the last IETF meeting it was concluded that the OCSP Agility draft
>> > needed
>> > another round in the WG with a new WG Last Call.
>> >
>> > http://tools.ietf.org/html/draft-ietf-pkix-ocspagility-09
>> >
>> > Generally people were unhappy with the specified solution for specifying
>> > signature algorithms with specific parameter constraints.
>> > Jim has suggested to use the SMIME capabilities form instead.
>> >
>> > The current structure for algorithm preferences in ocspagility is:
>> >
>> >     PreferredSignatureAlgorithms ::= SEQUENCE OF
>> >                                       PreferredSignatureAlgorithm
>> >
>> >      PreferredSignatureAlgorithm ::= SEQUENCE {
>> >         sigIdentifier   AlgorithmIdentifier,
>> >         certIdentifier  AlgorithmIdentifier OPTIONAL
>> >         }
>> >
>> > The structure of SMIME Capabilities is:
>> >
>> >      SMIMECapabilities ::= SEQUENCE OF SMIMECapability
>> >
>> >       SMIMECapability ::= SEQUENCE {
>> >          capabilityID   OBJECT IDENTIFIER,
>> >          parameters     ANY DEFINED BY capabilityID OPTIONAL }
>> >
>> >
>> > AlgorithmIdentifier has the same syntax as SMIME Capabilities, being:
>> >
>> >   AlgorithmIdentifier  ::=  SEQUENCE  {
>> >         algorithm               OBJECT IDENTIFIER,
>> >         parameters              ANY DEFINED BY algorithm OPTIONAL  }
>> >
>> >
>> > So one could ask what the benefit here is.
>> >
>> > The difference to my understanding lies in the assignment of algorithm
>> > OIDs
>> > and their parameters dependent on whether this is a pure signature
>> > algorithm
>> > OID, a public key algorithm OID or whether it is an OID for
>> > SMIMECapabilites
>> > (which SHOULD be the algorithm OID).
>> >
>> > RFC 5751 (SMIME Capabilities 2.5.2):
>> >      "The OIDs that correspond to algorithms SHOULD use the same OID as
>> > the
>> >    actual algorithm, except in the case where the algorithm usage is
>> >    ambiguous from the OID."
>> >
>> > I would like to have your opinion on how we should resolve this issue so
>> > we
>> > can move on.
>> >
>> > /Stefan
>> >
>>
>>
>> _______________________________________________
>> pkix mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>
>
>
> --
> Website: http://hallambaker.com/
>
>

-- 
Website: http://hallambaker.com/

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 06 Nov 2010 13:38:47 +0100

Hi Phil,

Sorry for holding with the reply.
I'm not sure about this. One has to decide what is reasonable to handle in
a protocol.

Generally in a request response protocol the requestor need to choose
algorithms, formatting syntax etc according to valid choices in the
protocol.
One protocol style is to exchange capabilities and the agree on
capabilities, like TSL handshake.
Another protocol style is that the requestor sends what it hopes the
responder will be able to digest, and the responder delivers what it can
produce with status and error codes.

In the second case the protocol may fail gracefully and the requestor can
retry the request with other parameters.

This is currently a non issues since SHA-1 is fine and because this is not
a security critical function. In other words, there is not reason to pick
an obscure algorithm that causes interoperability issues. Thus, this issue
feels highly theoretical to me and I'm not convinced that this motivates
an effort by implementors to integrate this mechanism.

Does implementers of OCSP see this as a problem in need of a fix?
If the community think this is motivated, I have no problem adding it. But
if not, I'd rather keep the protocol simple.

/Stefan

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 8 Nov 2010 10:18:13 -0500

I agree that for CertID purposes, hash agility isn't needed.

However, I don't see a need to extend OCSP to signal errors where a requested CertID was created with an unsupported hash algorithm.  In the case where a request arrives with CertID derived from some non-SHA1 hash, then the existing logic covers the possible results.  Either the server finds a match, in which case that result is sent and the client is left to work it out; or it fails to find a match, in which case the proper response is 'unknown' because this case is indistinguishable from all the other client errors (e.g., requesting from the wrong OCSP service, client canonicalization errors, client hash algorithm errors, etc.).

-- Tim

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Phillip Hallam-Baker [[email-masked]]
Sent: Friday, November 05, 2010 11:23 PM
To: Stefan Santesson
Cc: [email-masked]; Jim Schaad
Subject: Re: [pkix] Fixing OCSP agility

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 09 Nov 2010 03:03:45 +0100

Not that I totally disagree, but this seems to me like one of those things
that looks bad in theory that hardly poses any practical problems in
reality.
I think I'd rather add a few MUST support algorithms. If you use any other
algorithm and get into problems, just revert to one of the MUST support
ones.

/Stefan

From:  "Miller, Timothy J." <[email-masked]>
Date:  Mon, 8 Nov 2010 10:18:13 -0500
To:  Phillip Hallam-Baker <[email-masked]>, Stefan Santesson
<[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, Jim Schaad <[email-masked]>
Subject:  RE: [pkix] Fixing OCSP agility

However, I don't see a need to extend OCSP to signal errors where a
requested CertID was created with an unsupported hash algorithm.  In the
case where a request arrives with CertID derived from some non-SHA1 hash,
then the existing logic covers the possible results.  Either the server
finds a match, in which case that result is sent and the client is left to
work it out; or it fails to find a match, in which case the proper response
is 'unknown' because this case is indistinguishable from all the other
client errors (e.g., requesting from the wrong OCSP service, client
canonicalization errors, client hash algorithm errors, etc.).
 
-- Tim 

From: [email-masked] [[email-masked]] On Behalf Of Phillip
Hallam-Baker [[email-masked]]
Sent: Friday, November 05, 2010 11:23 PM
To: Stefan Santesson
Cc: [email-masked]; Jim Schaad
Subject: Re: [pkix] Fixing OCSP agility

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 9 Nov 2010 10:12:17 +0800

There is one reason that agility is nice and that is that at some point in the future I don’t want to have to implement SHA-1 just for this purpose and for no other reason.

jim
From: Stefan Santesson 
Sent: Tuesday, November 09, 2010 10:03 AM
To: Miller, Timothy J. ; Phillip Hallam-Baker 
Cc: [email-masked] ; Jim Schaad 
Subject: Re: [pkix] Fixing OCSP agility

Not that I totally disagree, but this seems to me like one of those things that looks bad in theory that hardly poses any practical problems in reality.
I think I'd rather add a few MUST support algorithms. If you use any other algorithm and get into problems, just revert to one of the MUST support ones.

/Stefan

To: Phillip Hallam-Baker <[email-masked]>, Stefan Santesson <[email-masked]>

-- Tim 

--------------------------------------------------------------------------------

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 09 Nov 2010 07:13:46 +0100

That is true in principle,

But for the case of OCSP you need to support SHA-1 anyway for the responder
keyHash parameter.
OCSP simply was not designed for fully fledged agility and it is tough to
change that now.

/Stefan

From:  Jim Schaad <[email-masked]>
Date:  Tue, 9 Nov 2010 10:12:17 +0800
To:  Stefan Santesson <[email-masked]>, "Miller, Timothy J."
<[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [pkix] Fixing OCSP agility

There is one reason that agility is nice and that is that at some point in
the future I don¹t want to have to implement SHA-1 just for this purpose and
for no other reason.
 
jim
From: Stefan Santesson <mailto:[email-masked]>
Sent: Tuesday, November 09, 2010 10:03 AM
To: Miller, Timothy J. <mailto:[email-masked]>  ; Phillip Hallam-Baker
<mailto:[email-masked]>
Cc: [email-masked] ; Jim Schaad <mailto:[email-masked]>
Subject: Re: [pkix] Fixing OCSP agility

/Stefan

 
 
-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 9 Nov 2010 09:44:17 -0500

SHA-1 isn't going anywhere.  MD5 hasn't gone anywhere.  Heck, even MD2 hasn't gone anywhere.  The best preimage attack against SHA-1 is for a reduced-round variant.  Even MD2 still requires 2^73 amount of work for a preimage collision, which is still only considered 'practical' by the truly paranoid.  :)

-- Tim

________________________________
From: Jim Schaad [[email-masked]]
Sent: Monday, November 08, 2010 8:12 PM
To: Stefan Santesson; Miller, Timothy J.; Phillip Hallam-Baker
Cc: [email-masked]
Subject: Re: [pkix] Fixing OCSP agility

jim
From: Stefan Santesson<mailto:[email-masked]>
Sent: Tuesday, November 09, 2010 10:03 AM
To: Miller, Timothy J.<mailto:[email-masked]> ; Phillip Hallam-Baker<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]> ; Jim Schaad<mailto:[email-masked]>
Subject: Re: [pkix] Fixing OCSP agility

/Stefan

From: "Miller, Timothy J." <[email-masked]<mailto:[email-masked]>>
Date: Mon, 8 Nov 2010 10:18:13 -0500
To: Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>, Stefan Santesson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jim Schaad <[email-masked]<mailto:[email-masked]>>
Subject: RE: [pkix] Fixing OCSP agility

-- Tim

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Phillip Hallam-Baker [[email-masked]<mailto:[email-masked]>]
Sent: Friday, November 05, 2010 11:23 PM
To: Stefan Santesson
Cc: [email-masked]<mailto:[email-masked]>; Jim Schaad
Subject: Re: [pkix] Fixing OCSP agility

On Thu, Oct 14, 2010 at 12:36 AM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:
> On Fri, Oct 8, 2010 at 10:15 AM, Stefan Santesson <[email-masked]<mailto:[email-masked]>>
> wrote:
>>
>> On 10-09-14 8:05 AM, "Jim Schaad" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> > Stefan,
>> >
>> >
>> >
>> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
>> > Stefan Santesson
>> > To: [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

--
Website: http://hallambaker.com/
_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix

---

From: Rob Stradling <[email-masked]>
Date: Tue, 9 Nov 2010 16:18:15 +0000

On Tuesday 09 November 2010 02:03:45 Stefan Santesson wrote:
<snip>
> I think I'd rather add a few MUST support algorithms.
> If you use any other algorithm and get into problems, just revert to one of
> the MUST support ones.

+1.

Would the list of "MUST support algorithms" contain only SHA-1 for the 
foreseeable future?

I would really like to see the following additions made to RFC2560bis:
1. A statement in the Security Considerations section that CertID-
>hashAlgorithm is not a security critical function.
2. A list of "MUST support algorithms" for OCSPRequest->CertID->hashAlgorithm 
(and OCSPResponse->CertID->hashAlgorithm).
3. A statement that OCSPRequest->CertID->hashAlgorithm and OCSPResponse-
>CertID->hashAlgorithm either MUST be the same, SHOULD be the same, or MAY be 
different.  (I'd personally prefer "MAY be different").
4. A warning that OCSP Client implementers should expect to encounter 
interoperability problems if they choose to use a hash algorithm that is not 
in the "MUST support algorithms" list.

Comodo's OCSP Responders currently only support SHA-1 for CertID-
>hashAlgorithm.  I'd prefer to avoid having to add code to map between 
issuerNameHash/issuerKeyHash hash values generated by multiple hash algorithms 
for all of the CAs that we operate, given that there is consensus that CertID-
>hashAlgorithm is not a security critical function.

In our OCSP Responder access logs, I've only ever spotted 1 OCSP Client that 
uses anything other than SHA-1 for CertID->hashAlgorithm:
  User-Agent: Crypto-Pro ocspcli.dll
  hashAlgorithm: GOST R 34.11-94
But my fear is that some OCSP Client implementers will move from SHA-1 to 
SHA-256 without thinking, unless RFC2560bis offers some guidance.

<snip>

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 9 Nov 2010 20:30:16 -0500

I don't want to move from SHA-1 to SHA-2 for this purpose. There really
isn't the value proposition to do that given that we expect to want to
retire SHA-2 in the near future.

But equally, if I am deploying a completely green-field application of OCSP
with no legacy and constrained devices, I don't want to have to run two
different sets of hash functions just to be legacy compatible.

It is not just a question of the code, it is the hashes themselves that may
be an issue. If I have an implementation that is using SHA3-256 as the basis
for creating cert digests, I maybe don't want to have to store the same data
twice.

On Tue, Nov 9, 2010 at 9:44 AM, Miller, Timothy J. <[email-masked]>wrote:

>  SHA-1 isn't going anywhere.  MD5 hasn't gone anywhere.  Heck, even MD2
> hasn't gone anywhere.  The best preimage attack against SHA-1 is for a
> reduced-round variant.  Even MD2 still requires 2^73 amount of work for a
> preimage collision, which is still only considered 'practical' by the truly
> paranoid.  :)
>
> -- Tim
>
>  ------------------------------
> *From:* Jim Schaad [[email-masked]]
> *Sent:* Monday, November 08, 2010 8:12 PM
> *To:* Stefan Santesson; Miller, Timothy J.; Phillip Hallam-Baker
> *Cc:* [email-masked]
>
> *Subject:* Re: [pkix] Fixing OCSP agility
>
>   There is one reason that agility is nice and that is that at some point
> in the future I don’t want to have to implement SHA-1 just for this purpose
> and for no other reason.
>
> jim
>   *From:* Stefan Santesson <[email-masked]>
> *Sent:* Tuesday, November 09, 2010 10:03 AM
> *To:* Miller, Timothy J. <[email-masked]> ; Phillip Hallam-Baker<[email-masked]>
> *Cc:* [email-masked] ; Jim Schaad <[email-masked]>
> *Subject:* Re: [pkix] Fixing OCSP agility
>
>  Not that I totally disagree, but this seems to me like one of those
> things that looks bad in theory that hardly poses any practical problems in
> reality.
>  ------------------------------
> *From:* [email-masked] [[email-masked]] On Behalf Of Phillip
> *Sent:* Friday, November 05, 2010 11:23 PM
> *To:* Stefan Santesson
> *Cc:* [email-masked]; Jim Schaad
> *Subject:* Re: [pkix] Fixing OCSP agility
>
> >> > From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of
> >> > Stefan Santesson

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 9 Nov 2010 20:32:19 -0500

The issue is not just whether we want to support new algorithms or not.

Even if we don't want to ever support any other algorithm ever we should fix
the response code issue. The responder should be able to say 'hey I don't do
that digest'.

Another point to consider that could give us agility here would be to define
an extra cert extension that allows the cert to list the algorithms
supported by the responder.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 10 Nov 2010 08:29:41 +0000

On Wednesday 10 November 2010 01:32:19 Phillip Hallam-Baker wrote:
> Even if we don't want to ever support any other algorithm ever we should
> fix the response code issue. The responder should be able to say 'hey I
> don't do that digest'.

Phill, I agree that agility for CertID->hashAlgorithm would be useful, but I 
thought that any changes to "bits on the wire" were out of scope for 
RFC2560bis?

Just adding some words of advice for OCSP Client implementers won't change 
"bits on the wire".

> Another point to consider that could give us agility here would be to
> define an extra cert extension that allows the cert to list the algorithms
> > > If you use any other algorithm and get into problems, just revert to
> > > one
> > 
> > of
> > 
> > > the MUST support ones.
> > 
> > +1.
> > 
> > >CertID->hashAlgorithm either MUST be the same, SHOULD be the same, or
> > >MAY
> > 
> > be

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.