On 14 Apr 2014, at 11:21 pm, Sandra Murphy <[email protected]> wrote:
> Speaking as regular ol' member > > Some comments on draft-ietf-sidr-rfc6485bis-01.txt > > Most of my comments are related to the attempt to add a new OID to > RFC6485, which previously had only one to specify. > > * 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]. > > 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. > > Hashing algorithms > are not identified individually in certificates and CRLs, > ... > For generating and verifying certificates, and CRLs the hashing and > digital signature algorithms are referred to together, > > And the PKCS/CMRF signatures? See comment below. 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? > > > Locations for this OID are as follows: > > The previous text talks about three OIDs, so "this" OID is ambiguous. > Perhaps you just meant "The places where OIDs appear are:". > The text that follows would then say "an OID appears", not "the > OID appears". Not only is there more than one OID to mention, in some > of those messages, more than one OID appears in the message. what about: "The locations where algorithm object identifiers appear are:" > > [[I think this discussion of "where" could go better above the two prior > paragraphs that talk about what-goes-in-the-where.]] > > 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]. > > The PKCS and CRMF uses of crypto algorithms are not mentioned in the > discussion preceding. The change in the bis draft were limited to the CMS issue. The addition of explicit mention of PCKS #10 and CRMF would be a further change to this document. It seems to me to be a logical change. > I presume the "the OID" text is left over from > the original RFC6485 and what was meant was the sha256WithRSAEncryption > OID. Most of this draft is RFC6485, including this. I also presume that the value of the OID in this case is sha256WithRSAEncryption. > It looks to me like RC2986 leaves that choice free, so this > text need to say which > > For CMS SignedData, the object identifier and parameters for SHA-256 > in [RFC5754] MUST be used for the SignedData digestAlgorithms field > and the SignerInfo digestAlgorithm field when generating and > verifying CMS SignedData objects. > ... > RPKI implementations MUST accept CMS SignedData objects that use the > object identifier and parameters for either rsaEncryption or > sha256WithRSAEncryption for the SignerInfo signatureAlgorithm field > when verifying CMS SignedData objects. > > I presume accepting sha256WithRSAEncryption is backward compatibiilty > - just in case some new implementation should appear that implements > RFC6485, before this spec is published, right? Since all known > implementations currently follow this spec? Personal opinion: maybe > we should not permit the backward compatibility with some hypothetical > implementation in this short interval, so future coding errors get > caught? Or at least note the reason, so future readers are not confused? I am already hopelessly confused by this situation, and I'm in no position to answer this. The issue was noted first by Andrew Chi and David Mandelberg, and Rob Austein provided text, which formed the basis of this bis draft. As to the precise nature of the backward compatibility, and what this spec should or should not allow, I'm afraid that I have no useful opinion. I would like to hope that Rob, Andrew and David are carefully reading this thread and will respond to your query better than I can. > > Nits: > > Repetition: > > 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. > ... > > For generating and verifying certificates, and CRLs the hashing and > digital signature algorithms are referred to together, > > I presume this is just repetition, right? I always wonder about > repeated messages - is there a difference I did not notice? So for > those similarly anxious, maybe a "as noted above"? (Or leave out the > first mention - that section is talking about what algorithms there > are to specify, you could leave it to later to talk about the format of > expressing a particular choice of algorithm. Quibble.) This was text that was originally in RFC6485. I am unsure why there is repetition, but I believe that the repetition is at worst gratuitous rather than mutually inconsistent. > > For CMS SignedData, the object identifier and parameters for SHA-256 > in [RFC5754] MUST be used for the SignedData digestAlgorithms field > <etc> > ... > In CMS SignedData, the OID appears in each SignerInfo > signatureAlgorithm field, the SignerInfo digestAlgorithm field, > and in the SignedData digestAlgorithms [RFC5652]; and, > > I presume this is just repetition (reinforcement, for completeness), > right? (There's no difference I just don't see?) > I thought the first says what OID value is to be used and the second says where this OID appears. > truly nitty: > > FROM > For generating and verifying certificates, and CRLs the hashing > TO > For generating and verifying certificates and CRLs, the hashing yup! Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
