Re: [pkix] Fixing OCSP agility

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

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. <[e-mail]>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 [[e-mail]]
> *Sent:* Monday, November 08, 2010 8:12 PM
> *To:* Stefan Santesson; Miller, Timothy J.; Phillip Hallam-Baker
> *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 <[e-mail]>
> *Sent:* Tuesday, November 09, 2010 10:03 AM
> *To:* Miller, Timothy J. <[e-mail]> ; Phillip Hallam-Baker<[e-mail]>
> *Cc:* [e-mail] ; Jim Schaad <[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]<[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
>



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