Subject: SignatureAlgorithms in draft-ietf-pkix-3281update-03

From: Alfred Hönes <[email-masked]>
Date: Mon, 2 Feb 2009 11:17:09 +0100 (MEZ)

During my ongoing review of the New ASN.1 drafts, I had to revisit
RFC 3281 and draft-ietf-pkix-3281update.

Section 4.2.4 says ...

|4.2.4. Signature
|
|  Contains the algorithm identifier used to validate the AC signature.
|
|  This MUST be one of the signing algorithms defined in [PKIXALGS].
|  Conforming implementations MUST honor all MUST/SHOULD/MAY signing
|  algorithm statements specified in [PKIXALGS].

... and 10.1 (Normative References) contains:

|  [PKIXALGS]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
|    Identifiers for the Internet X.509 Public Key Infrastructure
|    Certificate and Certificate Revocation Lists CRL Profile",
|    RFC 3279, April 2002.

However, RFC 3279 has been Updated substantially in the meantime --
by RFC 4055, RFC 4491, and RFC-to-be 5480 (I-D.ecc-subpubkeyinfo).

I'm in serious doubt whether draft-ietf-pkix-3281update indeed
should want to exclude these extensions / updates / restrictions.
(Note that RFC-to-be 5480 *excludes* some of the ECC options present
in RFC 3279!)
I suspect that the text in Section 4.2.4 simply has been carried over
literally from RFC 3281 (where it was consistent state-of-the-art),
without reconsidering the signature algorithms in detail.

IMO, the set of signature algorithms in 3281update should be based
on the currently reached evolutionary state of what we understand
as [PKIXALGS].

To this end, I suggest that, in the same way as the S/MIME v3.2 drafts
contain 'collective references', the 3281update section 10.1 entry
[PKIXALGS] should be extended by adding citations to the
abovementioned three RFCs.  (I-D.ecc-subpubkeyinfo / RFC-to-be 5480
currently is in AUTH48, so the next draft version could already be
written refering to RFC 5480.)

Note that draft-ietf-pkix-new-asn1-02 already contains a New ASN.1
modules for RFC 3279 that corresponds to the unified Old ASN.1 module
in RFC-to-be 5480.

Kind regards,
  Alfred.

P.S.: Another typo in draft-ietf-pkix-3281update, Appendix B:
      s/attribe/attribute/  .

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Sean Turner <[email-masked]>
Date: Mon, 02 Feb 2009 09:10:57 -0500

> written refering to RFC 5480.)

The only thing I'd add to the list is the update to RFC 4055.

Replace:

[PKIXALGS]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
             Identifiers for the Internet X.509 Public Key Infrastructure
             Certificate and Certificate Revocation Lists CRL Profile",
             RFC 3279, April 2002.

With:

[PKIXALGS]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
             Identifiers for the Internet X.509 Public Key Infrastructure
             Certificate and Certificate Revocation Lists CRL Profile",
             RFC 3279, April 2002.

             Turner, S., Polk, W., Housley, R., Yiu, K., D. Brown,
             "Elliptic Curve Cryptography Subject Public Key
             Information", RFC 5480, February 2009.

             Schaad, J., Kaliski, B., and R. Housley, "Additional
             Algorithms and Identifiers for RSA Cryptography for use in
             the Internet X.509 Public Key Infrastructure Certificate and
             Certificate Revocation List (CRL) Profile", RFC 4055, June
             2005.

             Turner, S., Polk, W., Housley, R., Yiu, K., D. Brown,
             "Update for RSAES-OAEP Algorithm Parameters",
              draft-ietf-pkix-rfc4055-update-01.txt, work-in-progress.

spt

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Feb 2009 09:14:38 -0800

>by RFC 4055, RFC 4491, and RFC-to-be 5480 (I-D.ecc-subpubkeyinfo).

Good catch, Alfred!

>written refering to RFC 5480.)

I disagree that simply changing the mapping of [PKIXALGS] to include the *current* set up updates is sufficient. Doing so certainly does not have algorithm agility for future updates.

Instead, I think that 4.2.4 should say "This MUST be one of the signing algorithms defined in [PKIXALGS] or defined in any IETF-approved update to [PKIXALGS]."

--Paul Hoffman, Director
--VPN Consortium