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

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

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: Jim Schaad [mailto:[email-masked]]
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: "Jim Schaad" <[email-masked]>
Date: Tue, 18 Feb 2003 12:56:29 -0800

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.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Manger, James H
> Sent: Tuesday, February 11, 2003 10:30 PM
> To: [email-masked]
> Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - 
> binding key to 1 alg
> 
> 
> 
> 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).
> 
> 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.
> 
> 	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
> 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.
>

---

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

Jim:

You and I are closer to agreement than I realized.  That is a good sign.

I do not want to have more than one parameter syntax associated with a 
single OID.  I do not want the RSAES-OAEP OID to have one parameter syntax 
when it is used in subject public key info and another parameter syntax 
when it is used in EnvelopedData.  In my opinion, each OID should only have 
a single parameter syntax, otherwise the automatic parsing of the 
parameters filed will become context sensitive.

Russ