Subject: Re: [sidr] comments on draft-ietf-sidr-rfc6485bis

From: Sandra Murphy <[email-masked]>
Date: Tue, 20 May 2014 13:49:52 -0400

Speaking as regular ol' member.

On Apr 21, 2014, at 11:55 PM, Geoff Huston <[email-masked]> wrote:

======================

>>Except that the signed object signature algorithm OID will be
>>rsaEncryption which I think is still PKCS#1v1.5, but is not in section
>>5 of rfc4055.  
>
>
>I am unsure what you mean here. Perhaps if you send what you think the
>text should say it would be helpful.  

The comment is about the correctness of the reference.  But that
should not have an impact on implementation, so I withdraw the
comment.

=================

>what about:
>
>"The locations where algorithm object identifiers appear are:"

Works for me.

======================

>I think this was a failing in RFC6485 itself. 

>RFC6487 has forward pointers to RFC6485 in the algorithm section for
>PKCS , but the text in RFC64845 refers to "certificates, CRLs and
>signed objects".
>
>Do you have alternative text to suggest here?
>

Defending RFC6485: RFC6485 only had one OID to talk about, so any
reference to an OID could be assumed to be that one OID.  So the
choice for cert requests might not have been direct in RFC6485, but
there was no ambiguity.

But, yes, with the added mention of new OIDs, the text retained from
RFC6485 is no longer clear about implementation of cert requests.

I suggest the following alternative text would make the choice clear.
The changes add cert requests where the choice for certs and CRLs is
mentioned.  

From:

      *  The signature algorithm used in certificates, CRLs, and signed
         objects is RSA Public-Key Cryptography Standards (PKCS) #1
         Version 1.5 (sometimes referred to as "RSASSA-PKCS1-v1_5") from
         Section 5 of [RFC4055].

To:

      *  The signature algorithm used in certificates, CRLs, signed
         objects, and certification requests is RSA Public-Key Cryptography 
         Standards (PKCS) #1 Version 1.5 (sometimes referred to as 
         "RSASSA-PKCS1-v1_5") from Section 5 of [RFC4055].

From:

      *  The hashing algorithm used in certificates, CRLs, and signed
         objects is SHA-256 [SHS] (see note below).  Hashing algorithms
         are not identified individually in certificates and CRLs, as
         the identity of the hashing algorithm is combined with the
         identity of the digital signature algorithm.

To:

      *  The hashing algorithm used in certificates, CRLs, signed
         objects, and certification requests is SHA-256 [SHS] 
         (see note below).  Hashing algorithms are not identified 
         individually in certificates, CRLs, and certificate requests
         as the identity of the hashing algorithm is combined with 
         the identity of the digital signature algorithm.

From:

   For generating and verifying certificates, and CRLs the hashing and
   digital signature algorithms are referred to together, i.e., "RSA
   PKCS#1 v1.5 with SHA-256" or more simply "RSA with SHA-256".  The
   Object Identifier (OID) sha256WithRSAEncryption from [RFC4055] MUST
   be used in this case.

To:

   For generating and verifying certificates, CRLs, and certification
   requests, the hashing and digital signature algorithms are referred 
   to together, i.e., "RSA PKCS#1 v1.5 with SHA-256" or more simply "RSA 
   with SHA-256".  The Object Identifier (OID) sha256WithRSAEncryption 
   from [RFC4055] MUST be used in this case.

========================

A couple of typos in the new section 8 explaining the changes:

From:

   Section 2 of [RFC6485] specified a single signature algorithm (SHA-
   256) 

To:

   Section 2 of [RFC6485] specified a single signature algorithm (RSA
   PKCS#1 v1.5)

(I'm guessing here what you mean, but I'm pretty sure the text did not
mean SHA-256 is a signature algorithm. It could also be that the
text meant:

To:

   Section 2 of [RFC6485] specified a single signature algorithm (RSA
   <or "RSASSA-PKCS1-v1_5"> and a single hash algorithm (SHA-256) 

or ... something else?)

This section is an explanation of the change, so it is intended for
the IESG, and is not crucial to implementation.  I think it would be
better to change to say what you mean, but I can accept it.

There's also this typo:

From:

   This document changes Section 2 of [RFC4055].

To:

   This document changes Section 2 of [RFC6485].

That also is not crucial to implementation, but it might confuse the
secretariat to have this text claim that the draft updates 4055.  If
anyone notices.

==========================

>> I presume accepting sha256WithRSAEncryption is backward compatibiilty
...
>
>I am already hopelessly confused by this situation, and I'm in no
>position to answer this.

No one else has expressed any concern over the backward compatibility,
so I withdraw the comment.

==============================

Then there's this new bit, which I noticed in the midst of checking
what was needed for the certificate requests.

In Section 2, the text says

      In a certification request, the OID appears in the PKCS #10
      signatureAlgorithm field [RFC2986], or in the Certificate Request
      Message Format (CRMF) POPOSigningKey signature field [RFC4211].

RFC4211 says that the POPOSigningKey is:

   POPOSigningKey ::= SEQUENCE {
       poposkInput         [0] POPOSigningKeyInput OPTIONAL,
       algorithmIdentifier     AlgorithmIdentifier,
       signature               BIT STRING }

I'm pretty sure the text should say the OID goes in the POPOSigningKey
algorithmIdentifier field, not the POPOSigningKey signature field.

[[While this looks clear to me, the comment could use some review by
someone comfortable with ASN.1 overloaded and inconsistent field
names.]]

That text is in the original RFC6485 and it has no relationship with the
problem with the OID choice in CMS, the reason for this bis.

However, if true, this has implementation impact, so I think this
should be considered at some point.

*IF* people agree that this is wrong, do the authors have any
problem with changing the text in this bis?

FROM:

      Message Format (CRMF) POPOSigningKey signature field [RFC4211].

TO:

      Message Format (CRMF) POPOSigningKey algorithmIdentifier field 
      [RFC4211].

--Sandy, speaking as regular ol' member