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

From: Sandra Murphy <[email-masked]>
Date: Mon, 14 Apr 2014 09:21:44 -0400

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

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 14 Apr 2014 10:43:15 -0400

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?

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Apr 2014 15:21:38 -0400

The CPS was written well before 6916 was finished.

A reference to that RFC now makes sense.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Wed, 16 Apr 2014 08:00:12 +1000

> a reference would be good. If not, could you explain?

Yes, I could explain. 

<explanation>
The RFC numbers should be a huge hint here.

So why didn't RFC6485 have a reference to what was a non-existent document at that
time? 

Do I really need to answer that question?
</explanation>

So why doesn't RFC6485bis fix all this, as you are suggesting here?

So should a reference to RFC6916 be included in this draft? Well on the
one hand I can't see why not, but...

All this started out as a potential erratum note to RFC6485,
and following advice from <random AD> that this constituted a technical change
that was beyond the scope of an erratum, a bis update to RFC6485 itself was
called for, with a narrow scope to address this particular issue. Section 8
of the draft describes the nature of the change, to allow the IESG and IETF LC
review of this bis document to concentrate on precisely that change, as advised
in the WG meeting at the time from <random AD>.

But it seems that you are advocating an expanded brief for this bis document
and when cleaning up the references to related work then we should also look 
at the rest of the document to see how it meshes with later published
RFCs as well. Right?

(Parenthetically, the expanding scope of this work is a worry, and I can't
help but wonder if all this is productive use of everyone's time. Maybe we
should also be reflecting on http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/
and contemplate the nature of the difference between adequacy and a quest for
perfection.)

Thanks,

   Geoff

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Apr 2014 09:49:20 +0900

yes, the erratum exploded into a doc revision.  and then, if we're
(excuse the royal we when you are doing the heavy lifting) issuing a
new doc, well of course it should be modern and correct.  primrose path
indeed.

personally i have no dog in this fight.  both directions have my
sympathies.

i do have sympathies if/where any of the modernizations have semantic
impact.  beyond that, well, i certainly have no claim to document
flexibility per se :)

randy

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 16 Apr 2014 11:31:36 -0400

Ruefully, I note that the chairs requested that the comments be limited to those needed to introduce the correction.

It is ironic that it was a discussion at IETF76 Nov 09 about this very part of draft-ietf-sidr-rpki-algs-01 that led the Security AD to instruct the wg to produce a transition plan that became RFC6916.

I withdraw this comment.

My other comments, however, were focussed on incomplete melding of the correction with the existing text.  RC6485 mentions only one OID and algorithm so there was no question of what OID and algorithm should be used wherever such things were mentioned.  Now, with three OIDs and algorithms, the text needs to be clear as to what is used where.

---

From: Geoff Huston <[email-masked]>
Date: Thu, 17 Apr 2014 05:36:23 +1000

yes - I quite agree that your first set of comments were entirely within scope for this update to RFC6485, and well made. I will get around to a response to indicate how these issues will be integrated into the draft.

 Geoff

---

From: Geoff Huston <[email-masked]>
Date: Tue, 22 Apr 2014 13:55:09 +1000

> rsaEncryption which I think is still PKCS#1v1.5, but is not in section

I am unsure what you mean here. Perhaps if you send what you think the text should say it would be helpful.

> 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?

> of those messages, more than one OID appears in the message.

what about:

"The locations where algorithm object identifiers appear are:"

> 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
> 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
> 

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.

> 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. 

> 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.

>   For generating and verifying certificates and CRLs, the hashing

yup!

Geoff