Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters
draft-ietf-pkix-rfc4055-update-02

[Ballot discuss]
This is a good spec, but there were two easily correctable problems.

First, Section 2 says: "CAs that issue certificates with the
id-RSASSA-PSS algorithm identifier SHOULD require the presence of
parameters in the subjectPublicKeyInfo algorithm field if the cA
boolean flag is set in the basic constraints certificate extension."

By reading this, it is not clear to me if you are talking about
something that the CA should do for the certificate it is creating,
or if it needs to verify something from the certificate request.
Either way, the text should probably be written slightly differently
to make it clear to implementors what they need to do. For instance,
"... SHOULD include parameters ..." or "... in the subjectPublicKeyInfo
algorithm field of the certificate request, if ..."

Secondly, Sections 3 and 4 introduce changes where the presence of a
field goes from SHOULD include to MUST NOT include. By reading the
writeup I understand that this does not have interoperability
implications, as it has not been implemented anyway (but it speaks
only about CAs, what about hosts?). Could you add a sentence or two
to the document to say the same thing? The writeup is not easily
accessible for anyone reading the RFC later.

This is the proto writeup for draft-ietf-pkix-rfc4055-update-01.txt.

Responses to questions 1.a-1.h in RFC 4858:

1.a - Steve Kent is the Shepherd.  He has personally reviewed the document
and asserts that it is ready for IESG publication.

1.b - The document has been reviewed by key WG members.  There are no
concerns about depth or breadth of the reviews.

1.c - I see no need for wider review.

1.d - There are no specific concerns of which the AD and/or IESG should be aware.

1.e - The WG consensus is now solid.

1.f - There has been no threat of an appeal by an WG members.

1.g - I have personally verified that the document satisfies all ID nits.

1.h - The document splits it references into normative and informative as required.

1.i - The document has an IANA consideration and it is consistent with the
main body (there are no IANA considerations).

1.j - There is no formal language in this document.

1.k - Write-up is as follows:

Technical Summary

The subjectPublicKeyInfo field of an X.509 certificate carries three data items: an algorithm identifier, optional parameters, and a bit string that represents the public key. The parameters are specific to the algorithm and this field usually contains simple values needed to characterize the public key algorithm, e.g., the generator and modulus for Diffie-Hellman. However, X.509 does not constrain the scope of this parameters field. The ANSI X9.62 standards committee elected to use this field to express potentially complex limitations on how the public key in the certificate can be used, e.g., which key derivation functions can be applied to the bit string that results from a Diffie-Hellman key exchange.

After considerable debate, the PKIX WG has decided to not express key usage constraints via this field. Instead, the WG decided that this sort of information should be expressed via use of distinct algorithm identifiers. (This  decision is consistent with the observation that current products are not deigned to handle such key usage restrictions expressed in the subjectPublicKeyInfo field.)

RFC 4055 such allowed restrictions to be placed in this field when used with RSA-OAEP.  This document changes RFC 4055 to say that restrictions MUST NOT be present in the certificate's subjectPublicKeyInfo field when used with RSA-OAEP. It also replaces incorrect references to the publicKeyAlgorithm field with references to the subjectPublicKeyInfo field. As a result, this revised version of RFC 4055 will be consistent with the PKIX WG conventions  adopted for this field.

Working Group Summary

This ID was discussed on the mailing list. A poll was taken on the PKIX list to determine whether the proposed change was the way forward and another poll was taken to determine whether the change would adversely affect implementations. The WG was in favor of the change and no implementer said it would adversely affect their products. Further, vendors that implement RFC 4055 support the change.

Document Quality

This document is a short update of an existing draft and is comparable in quality to its predecessor.

Personnel

Steve Kent is the document Shepherd.  Tim Polk is the responsible Security Area AD.