[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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:
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:jimsch@xxxxxxxxxx]
Sent: Saturday, 8 February 2003 4:59 AM
Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt

...

----------
From: Internet-Drafts@xxxxxxxx [mailto:Internet-Drafts@xxxxxxxx]
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