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 <sa...@tislabs.com> wrote:
>
> Speaking as regular ol' member.
>
> On Apr 21, 2014, at 11:55 PM, Geoff Huston <g...@apnic.net> 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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
