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

[Sandra Murphy <[e-mail]>]

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 <[e-mail]> 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