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

From: Sandra Murphy <[email-masked]>
Date: Fri, 12 Sep 2014 07:29:33 -0400

speaking as regular ol' member

It has been some months.  Sean Turner did respond to the last point.  Is there any comment from the authors?

--Sandy, speaking as regular ol' member

On May 20, 2014, at 1:49 PM, Sandra Murphy <[email-masked]> wrote:

> 
> 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
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr