Subject: [pkix] Fixing OCSP agility

From: Stefan Santesson <[email-masked]>
Date: Tue, 07 Sep 2010 14:06:30 +0200

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Sep 2010 13:27:58 -0400

I had some pushback from our product management folk 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.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 13 Sep 2010 23:05:44 -0700

WARNING: contains banned part

Subject: RE: [pkix] Fixing OCSP agility
From: "Jim Schaad" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Date: Mon, 13 Sep 2010 23:05:44 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Tuesday, September 07, 2010 5:07 AM
To: [email-masked]
Subject: [pkix] Fixing OCSP agility

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."

/Stefan