Re: [pkix] Fixing OCSP agility

[Stefan Santesson <[e-mail]>]

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


On 10-11-06 5:23 AM, "Phillip Hallam-Baker" <[e-mail]> wrote:

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