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
