Re: [pkix] Fixing OCSP agility

[Phillip Hallam-Baker <[e-mail]>]

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/