Re: [pkix] Fixing OCSP agility

[Stefan Santesson <[e-mail]>]

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 <[e-mail]>
Date:  Tue, 9 Nov 2010 10:12:17 +0800
To:  Stefan Santesson <[e-mail]>, "Miller, Timothy J."
<[e-mail]>, Phillip Hallam-Baker <[e-mail]>
Cc:  <[e-mail]>
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:[e-mail]>
Sent: Tuesday, November 09, 2010 10:03 AM
To: Miller, Timothy J. <mailto:[e-mail]>  ; Phillip Hallam-Baker
<mailto:[e-mail]>
Cc: [e-mail] ; Jim Schaad <mailto:[e-mail]>
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
 
From: "Miller, Timothy J." <[e-mail]>
Date: Mon, 8 Nov 2010 10:18:13 -0500
To: Phillip Hallam-Baker <[e-mail]>, Stefan Santesson
<[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Jim Schaad <[e-mail]>
Subject: RE: [pkix] Fixing OCSP agility
 
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: [e-mail] [[e-mail]] On Behalf Of Phillip
Hallam-Baker [[e-mail]]
Sent: Friday, November 05, 2010 11:23 PM
To: Stefan Santesson
Cc: [e-mail]; Jim Schaad
Subject: Re: [pkix] Fixing OCSP agility

Again, I have still not had any reply.

On Thu, Oct 14, 2010 at 12:36 AM, Phillip Hallam-Baker <[e-mail]>
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 <[e-mail]>
> 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" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
>> > Stefan Santesson
>> > Sent: Tuesday, September 07, 2010 5:07 AM
>> > To: [e-mail]
>> > 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pkix
>
>
>
> --
> Website: http://hallambaker.com/
>
>



-- 
Website: http://hallambaker.com/
_______________________________________________
pkix mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pkix