And one "I forgot": CAs and RPs SHOULD be capable of supporting a transition to allow for the phased introduction of additional encryption algorithms and key specifications,
Is this any different than the algorithm agility in RFC6916? If so, I'd think a reference would be good. If not, could you explain? --Sandy, speaking as regular ol' member On Apr 14, 2014, at 9:21 AM, 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. > > 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. > > > 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. > > [[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. I presume the "the OID" text is left over from > the original RFC6485 and what was meant was the sha256WithRSAEncryption > OID. 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? > > 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.) > > 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?) > > truly nitty: > > FROM > For generating and verifying certificates, and CRLs the hashing > TO > For generating and verifying certificates and CRLs, the hashing > > --Sandy, speaking as regular ol' member _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
