Re: [pkix] Fixing OCSP agility

["Miller, Timothy J." <[e-mail]>]

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