Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg

From: "Manger, James H" <[email-masked]>
Date: Wed, 19 Feb 2003 10:29:29 +1000

Jim,
I am not entirely clear which fields you are referring to when you say "the Alg.Id field" and "the algorithm location".  I guess these refer to components within a certificate's subjectPublicKeyInfo field.

> specify the necessary constraints in the parameters of the algorithm location.

The subjectPublicKeyInfo.algorithm.parameters field is already needed to specify parameters for the public key: NULL for an RSA key; {p, q, g} for a DSA key; a curve for an ECDSA key; {prime, base, len} for a DH key; ...
Do you really think we should change all these existing syntaxes to include constraints, instead of placing the constraints in their own field?

The constraints are specific to signature or encryption algorithms -- not directly to key types.

There are a number of supporting techniques (hash functions, mask generation algorithms etc) that many signature and encryption algorithms have in common.  These are the sort of items that we will want to constrain.  However, these supporting techniques have nothing to do with the type of key.  Combining key parameters with constraints on supporting techniques does not seem that sensible.

> "My software should only use alg X, but display as alg Y"

Is this referring to my point 4?  This is not what I was suggesting.
The criticality flag in an extension allows you to choose your own balance between security & backward-compatibility.  Placing constraints in the subjectPublicKeyInfo.algorithm.parameters fields does not allow this choice.

>  -----Original Message-----
> From: 	Jim Schaad [mailto:[email-masked]] 
> Sent:	Wednesday, 19 February 2003 7:56 AM
> To:	Manger, James H; [email-masked]
> Subject:	RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg
> 
> I disagree that the problem of specifing the constraints is based on the
> fact that the restraints are specified in the Alg.Id field.  
> 
> I do agree that the constraints should be expressed differently.  I
> think that the signature and public key parameters structures should be
> specified as different structures.  I am not even sure that I like the
> fact that PSS is using DEFAULT parameters.  (This has the potential to
> slow down moving to a larger hash algorithm since the size of the
> certificate is going to increase.)
> 
> My preference would be to specify the necessary constraints in the
> parameters of the algorithm location.
> 
> I disagree that there is a reason to worry about specifying a constraint
> that says "My software should only use alg X, but display as alg Y".
> This is an internal issue to the software and should not be imposed
> externally.
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Manger, James H
> > Sent: Tuesday, February 11, 2003 10:30 PM
> > 
> > Constraining the algorithms with which a key is used is good 
> > security practice so there is sense in including a constraint 
> > to this effect in a certificate.  However, I am not sure that:
> > a) the subjectPublicKeyInfo field should hold this constraint and
> > b) the syntax for the constraint should be an Alg.Id.
> > 
> > Jim Schaad's comments #8 and #13 (confusion about how to 
> > compare the parameters of a signature or encryption with the 
> > parameters from subjectPublicKeyInfo) are due to the 
> > constraint being specified with an Alg.Id, which is not quite 
> > appropriate (e.g. by including a saltLength field that is irrelevant).
> > 
> > Consider other possible (& reasonable?) constraints that you 
> > may wish to express:
> > 
> > 1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 
> > as the hash algorithm.
> > [Cannot be expressed as RSASSA-PSS-params only has a single 
> > hashAlgorithm field]
> > 
> > 2* Use this key for RSASSA-PSS signatures or RSAES-OAEP 
> > encryption, but not with any other algorithms.> 
> > [Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id]
> > 
> > 3* Only use id-sha1-with-dss-signature for signing.
> > [Cannot be expressed as this signature OID has NULL 
> > parameters, but {p, q, g} need to be specified.]
> > 
> > 4* Tell your signing software only to use RSASSA-PSS with 
> > this key, but don't prevent some legacy apps from accepting 
> > your signature.
> > [Cannot be expressed as legacy apps reject the cert as they 
> > don't accept id-RSASSA-PSS in subjectPublicKeyInfo.  To work, 
> > the constraint needs to be in a non-critical extension.]
> > 
> > 
> > A better solution would be to define a new extension to hold 
> > the constraint.  Mark it critical to guarantee enforcement of 
> > the constraint, or non-critical to supply the info but 
> > maintain some backward compatibility.
> > 
> > algorithmConstraints EXTENSION ::= {
> > 	SYNTAX         AlgConstraintsSyntax
> > 	IDENTIFIED By  id-ce-algorithmConstraints }
> > 
> > AlgConstraintsSyntax ::= ...???????... this is the hard bit
> > 
> > 
> > A simple syntax would be:
> > 	SEQUENCE OF OBJECT IDENTIFIER
> > 	-- An Alg.Id is acceptable iff its OID is in the sequence.
> > 
> > Or the same simple syntax with more complex semantics:
> > 	SEQUENCE OF OBJECT IDENTIFIER
> > 	-- An Alg.Id is acceptable iff its OID
> > 	-- and all the OIDs of any other Alg.Ids
> > 	-- in its parameters field (inc. defaults if absent)
> > 	-- are all in the sequence
> > 
> > Or something really generic:
> > 	Filter	-- see X.511 
> > 	-- applied to a "virtual entry" containing just the 
> > Alg.Id in question
> > 
> > Or...
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 21 Feb 2003 12:14:34 -0500

James:

Let be give you some background. PKCS#1 v2.1 includes a recommendation that 
RSA private key only be used with one scheme (such as PSS, OAEP, PKCS#1 
v1.5 Signature, PKCS#1 v1.5 key transport, ...).  Further, in the case of 
OAEP, PKCS#1 v2.1 recommends that an RSA private key make use only one mask 
generation function.

The key usage extension can be used to distinguish RSA signature 
verification keys and RSA key transport keys.  But it does not meet the 
above requirements.  So, how can the private key owner's intentions be 
conveyed to another party?  The use of subject public key info seems 
natural to me.  This algorithm identifier is intended to convey to the 
certificate user information about the public key algorithm.

I am opposed to a new certificate extension for algorithm constraints.  In 
RFC 3279, there is a list of public key algorithms.  For each algorithm, it 
specifies the OID to be carried in subject public key info and the format 
of the public key itself.  If the algorithm is a signature algorithm, then 
there are additional OIDs that imply the use of particular one-way hash 
functions and the format of the signature value.  Perhaps the explosion of 
OIDs for signature algorithm plus one-way hash function could have been 
avoided by using a parameter with an OID identifying the one-way hash 
function, but historically this was not done.  People have code that 
handles this situation in a straightforward manner.  While I do not mind 
exploring other alternatives,  I do not think that we should deviate for 
the historical convention unless there are real unmet needs.  In my 
opinion, the current convention is meeting all of the needs of today's 
certificate using applications.

Russ

At 04:29 PM 2/12/2003 +1000, Manger, James H wrote:

>Constraining the algorithms with which a key is used is good security 
>practice so there is sense in including a constraint to this effect in a 
>certificate.  However, I am not sure that:
>Jim Schaad's comments #8 and #13 (confusion about how to compare the 
>parameters of a signature or encryption with the parameters from 
>subjectPublicKeyInfo) are due to the constraint being specified with an 
>Alg.Id, which is not quite appropriate (e.g. by including a saltLength 
>field that is irrelevant).
>
>Consider other possible (& reasonable?) constraints that you may wish to 
>express:
>
>1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 as the hash 
>algorithm.
>[Cannot be expressed as RSASSA-PSS-params only has a single hashAlgorithm 
>field]
>
>2* Use this key for RSASSA-PSS signatures or RSAES-OAEP encryption, but 
>not with any other algorithms.
>[Cannot be expressed as this signature OID has NULL parameters, but {p, q, 
>g} need to be specified.]
>
>4* Tell your signing software only to use RSASSA-PSS with this key, but 
>don't prevent some legacy apps from accepting your signature.
>[Cannot be expressed as legacy apps reject the cert as they don't accept 
>id-RSASSA-PSS in subjectPublicKeyInfo.  To work, the constraint needs to 
>be in a non-critical extension.]
>
>
>A better solution would be to define a new extension to hold the 
>constraint.  Mark it critical to guarantee enforcement of the constraint, 
>or non-critical to supply the info but maintain some backward compatibility.
>
>         -- applied to a "virtual entry" containing just the Alg.Id in 
> question
>
>Or...
>
>
>----------
>Sent: Saturday, 8 February 2003 4:59 AM
>Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt
>
>...
>
>----------
>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, 8 January 2003 12:30 AM
>
>         Title           : Additional Algorithms and Identifiers for RSA 
> Cryptography for use in the Internet X.509 Public Key Infrastructure 
> Certificate and Certificate Revocation List (CRL) Profile
>         Author(s)       : R. Housley, B. Kaliski
>         Filename        : draft-ietf-pkix-rsa-pkalgs-00.txt
>         Pages           : 22
>         Date            : 2003-1-6
>
>This document supplements RFC 3279.  It describes the conventions for 
>using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport 
>algorithm, and additional one-way hash functions with the PKCS #1 version 
>1.5 signature algorithm in the Internet X.509 Public Key Infrastructure 
>(PKI).  Encoding formats, algorithm identifiers, and parameter formats are 
>specified.
>
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt

---

From: "Tom Gindin" <[email-masked]>
Date: Sat, 22 Feb 2003 08:14:53 -0500

Russ, Burt:

      Is the statement in section 6 of RFC 3447 (PKCS #2 2.1) really
intended to suggest that TLS/SSL servers and S/MIME clients should not be
implemented with single RSA key pairs which use RSA-PSS for signatures and
also use RSA-OAEP for key encipherment?  It seems to cover that case,
although the examples given suggest that using two distinct
signature-capable schemes is undesirable, as is using two distinct
encryption-capable schemes, and so it is wrong to use PKCS1-V1_5 with
either of the newer schemes.

            Tom Gindin

Russ Housley <[email-masked]>@mail.imc.org on 02/21/2003 12:14:34 PM

Sent by:    [email-masked]

To:    "Manger, James H" <[email-masked]>
cc:    [email-masked], [email-masked]
Subject:    RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key
       to 1 alg

James:

generation function.

Russ

---

From: "Kaliski, Burt" <[email-masked]>
Date: Wed, 26 Feb 2003 14:56:18 -0500

Tom,

Our intent is the encourage the use of a key pair with only one algorithm.
The security analysis for each algorithm assumes a key pair is used with
only the particular algorithm (and with a generally fixed set of underlying
components).  While we are not aware of any "bad" interactions if a key is
used for both RSAES-OAEP and RSASSA-PSS, the security "assurance" may be
reduced because the security analysis is no longer directly applicable.

(If someone were to do the full security analysis for the use of a key pair
with both algorithms, and the result were positive, then there would be
motivation to change this recommendation.)

Similarly, we would not recommend using a key with PKCS1-V1_5 and either of
the newer schemes.

But I understand that to encourage adoption of the new schemes, it may be
necessary to allow a key pair to be used with more than one algorithm in the
interim.

-- Burt

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Saturday, February 22, 2003 8:15 AM
To: Russ Housley; Kaliski, Burt
Cc: Manger, James H; [email-masked]
Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to
1 alg

      Russ, Burt:

            Tom Gindin