Subject: Re: [pkix] Fixing OCSP agility

From: Stefan Santesson <[email-masked]>
Date: Fri, 08 Oct 2010 16:15:57 +0200

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" <[email-masked]> 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: [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
> 
>  
> 
> 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: "Denis Pinkas"<[email-masked]>
Date: Fri, 8 Oct 2010 16:35:59 +0200

Stefan,

You said: "It would be good to (...) move on with a new WG last call".

I sent an email on Septembrer 20 with the following topic: 
[pkix] Comments on draft-ietf-pkix-ocspagility-09

I have not seen any response to it at this time.

So before going a  WG LC, I would like the issues raised in this email 
and the previous email to be discused and solved.

My concern is that it makes sense to be able to specify the algorithm for the key used 
by the OCSP responder, but not for the algorithm for the key used to sign the OCSP certificate.

Denis
--------- 
De : pkix-bounces 
À : Jim Schaad,pkix 
Date : 2010-10-08, 16:15:57
Sujet : Re: [pkix] Fixing OCSP agility

/Stefan

> I would like to have your opinion on how we should resolve this issue so we

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 08 Oct 2010 20:49:56 +0200

Denis

> by the OCSP responder, but not for the algorithm for the key used to sign the

I think you have misread the draft.

The draft says:

   certIdentifier specifies the subject public key algorithm identifier
   the client prefers in the server's certificate used to validate the
   OCSP response. e.g. algorithm=id-ecPublicKey and parameters=
   secp256r1.

   certIdentifier is OPTIONAL and provides means to specify parameters
   necessary to distinguish among different usages of a particular
   algorithm, e.g. it may be used by the client to specify what curve it
   supports for a given elliptic curve algorithm.

This is quite different from what you claim.

/Stefan

On 10-10-08 4:35 PM, "Denis Pinkas" <[email-masked]> wrote:

>> De  : pkix-bounces <mailto :[email-masked]>
>>  
>> À  : Jim  Schaad,pkix <mailto :[email-masked],[email-masked]>
>>  
>> On 10-09-14 8:05 AM, "Jim Schaad" <[email-masked] <mailto:
>> [email-masked]> >  wrote:
>> 
>>> Stefan,
>>> 
>>> 
>>> 
>>>  From: [email-masked] <mailto: [email-masked]>
>>> [mailto:[email-masked] <mailto: [email-masked]> ] On  Behalf
>>> Of
>>> Stefan Santesson
>>> To: [email-masked] <mailto: [email-masked]>
>> [email-masked] <mailto: [email-masked]>

---

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 11 Oct 2010 10:51:03 +0200

Stefan,
You said I misread the draft. Probably, but on Septembrer 14, I said:
On page 5, the explanations about the meaning of the fields sigIdentifier 
is not crystal clear. 

OLD: 

   sigIdentifier specifies the signature algorithm the client prefers, 
   e.g. algorithm=ecdsa-with-sha256. Parameters are absent for most 
   common signature algorithms. 

NEW: 

   sigIdentifier specifies the signature algorithm the client prefers, 
   for the OCSP responder to sign the OCSP response, e.g. 
   algorithm=ecdsa-with-sha256. Parameters are absent for most common 
   signature algorithms. 

I misread the definition of certIdentifier because the name is not well chosen.
It is currently:
   certIdentifier specifies the subject public key algorithm identifier   the client prefers in the server's certificate used to validate the   OCSP response. e.g. algorithm=id-ecPublicKey and parameters=   secp256r1.
What is the diference between "the subject public key algorithm identifier the client prefers 
in the server's certificate" and "the signature algorithm the client prefers for the OCSP responder 
to sign the OCSP response" ?
It seems that the goal of this second parameter is to be able to support RFC 5480.
RFC 5480 states:
   In the X.509 certificate, the subjectPublicKeyInfo field has the   SubjectPublicKeyInfo type, which has the following ASN.1 syntax: 
     SubjectPublicKeyInfo  ::=  SEQUENCE  {       algorithm         AlgorithmIdentifier,       subjectPublicKey  BIT STRING     }

   The fields in SubjectPublicKeyInfo have the following meanings: 
      o algorithm is the algorithm identifier and parameters for the ECC        public key.
      o subjectPublicKey is the ECC public key.  See Section 2.2.
   The AlgorithmIdentifier type, which is included for convenience   [PKI], is defined as follows:

      AlgorithmIdentifier  ::=  SEQUENCE  {        algorithm   OBJECT IDENTIFIER,        parameters  ANY DEFINED BY algorithm OPTIONAL      }

   The fields in AlgorithmIdentifier have the following meanings: 
      o algorithm identifies the cryptographic algorithm with an object        identifier.  See Section 2.1.
      o parameters, which are optional, are the associated parameters        for the algorithm identifier in the algorithm field.  See        Section 2.1.1.
It seems that the second item is an OPTIONAL item to be able to specify the parameters of the algorithm.
If it is the case, then both items should not be an AlgorithmIdentifier.
In any case, the current text is not crystal clear for me.
Denis
----- Message reçu ----- 
De : pkix-bounces 
À : denis.pinkas,pkix 
Date : 2010-10-08, 20:49:56
Sujet : Re: [pkix] Fixing OCSP agility

Denis

The draft says:

/Stefan

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Oct 2010 00:36:18 -0400

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.

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