Subject: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt

From: [email-masked]
Date: Fri, 15 May 2015 12:22:15 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

        Title           : The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure
        Authors         : Geoff Huston
                          George Michaelson
	Filename        : draft-ietf-sidr-rfc6485bis-02.txt
	Pages           : 7
	Date            : 2015-05-15

Abstract:
   This document specifies the algorithms, algorithms' parameters,
   asymmetric key formats, asymmetric key size and signature format for
   the Resource Public Key Infrastructure subscribers that generate
   digital signatures on certificates, Certificate Revocation Lists, and
   signed objects as well as for the Relying Parties that verify these
   digital signatures.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6485bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidr-rfc6485bis-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6485bis-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Richard Hansen <[email-masked]>
Date: Wed, 20 May 2015 16:03:28 -0400

Hi all,

I did a careful review of this draft and sent detailed comments to the
authors off list.  Here is a summary of my comments for everyone's
reference:

Important issues:

  * the reference to RFC6488 in the introduction was accidentally
    changed to RFC2119
  * section 8 is incorrect -- sha256WithRSAEncryption does not
    violate the CMS RFCs (implementations just choose to use
    rsaEncryption instead, which has the same meaning in this
    context)
  * the OID and meaning of rsaEncryption is not defined in this
    document, and there is no normative reference to a definition

Moderate issues:

  * section 2 is confusing (alternative wording sent to authors)
  * errata not incorporated (though their status is still "Reported"...)
  * certification requests aren't mentioned everywhere they should be

Minor issues:

  * many of the edits made by the RFC Editor are missing
  * at the beginning of section 2, the reference to RFC4055 Section 5
    should be RFC3447 Section 8.2

Nice-to-haves:

  * replace "signed object" with "CMS signed object" to avoid ambiguity
  * add a Table of Contents
  * include informative references in the introduction
  * cite the algorithm agility RFC in section 5

-Richard

On 2015-05-15 15:22, [email-masked] wrote:
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 21 May 2015 17:08:15 -0400

You are missing some history here.  When this issue arose, the agreement was that the bis would address the OID only, and changes and comments were to be only those necessary to correct that problem.

(I myself participated in that agreement and then exceeded the restriction in my own comments!  You, who were not in the working group at the time, have much less reason to know.)

--Sandy, speaking as working group chair

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 21 May 2015 17:08:59 -0400

>    rsaEncryption instead, which has the same meaning in this

You might want to review the message on the list:
https://www.ietf.org/mail-archive/web/sidr/current/msg04813.html
that covers the whole CMS mandatory-to-implement requirement, the implementations, and the whole tangled story of the document chain.  

[That's Rob Austein, who also acknowledges Andrew Chi, David Mandelberg, and Russ Housley assisting in untangling the tangled web of references.]

Perhaps you are concerned mostly about the terms being used?  But the rfc6485bis document does not say "violate" and I believe that what it says agrees with the message above.  If you don't think so, you should say why.

>    document, and there is no normative reference to a definition

This is not the right place to define the OID for rsaEncryption.  It is found in 3370, which 5754 (one of the references) updates and normatively references.  

>  * errata not incorporated (though their status is still "Reported"…)

Those that are still shown as "Reported" have not yet been reviewed.  As Sean said, it is possible for an errata to be rejected.

The description of the errata process is found at https://www.ietf.org/iesg/statement/errata-processing.html.

--Sandy, speaking as regular ol' member

---

From: Richard Hansen <[email-masked]>
Date: Thu, 21 May 2015 17:15:58 -0400

On 2015-05-21 17:08, Sandra Murphy wrote:
> You are missing some history here.  When this issue arose, the
> agreement was that the bis would address the OID only, and changes
> and comments were to be only those necessary to correct that
> problem.

OK.  To keep the scope of changes limited to the OID issue, ignore the
following from my list of issues:

Moderate:
Minor:

-Richard

> 
> (I myself participated in that agreement and then exceeded the
> restriction in my own comments!  You, who were not in the working
> group at the time, have much less reason to know.)
> 
>> I did a careful review of this draft and sent detailed comments to
>> the authors off list.  Here is a summary of my comments for
>> everyone's reference:
>> 
>> Important issues:
>> 
>> changed to RFC2119 * section 8 is incorrect --
>> sha256WithRSAEncryption does not violate the CMS RFCs
>> (implementations just choose to use rsaEncryption instead, which
>> has the same meaning in this context) * the OID and meaning of
>> rsaEncryption is not defined in this document, and there is no
>> normative reference to a definition
>> 
>> Moderate issues:
>> 
>> * section 2 is confusing (alternative wording sent to authors) *
>> errata not incorporated (though their status is still
>> "Reported"...) * certification requests aren't mentioned everywhere
>> they should be
>> 
>> Minor issues:
>> 
>> * many of the edits made by the RFC Editor are missing * at the
>> beginning of section 2, the reference to RFC4055 Section 5 should
>> be RFC3447 Section 8.2
>> 
>> Nice-to-haves:
>> 
>> * replace "signed object" with "CMS signed object" to avoid
>> ambiguity * add a Table of Contents * include informative
>> references in the introduction * cite the algorithm agility RFC in
>> section 5
>> 
>> -Richard
>> 
>> 
>>> A New Internet-Draft is available from the on-line
>>> Internet-Drafts directories. This draft is a work item of the
>>> Secure Inter-Domain Routing Working Group of the IETF.
>>> 
>>> Title           : The Profile for Algorithms and Key Sizes for
>>> use in the Resource Public Key Infrastructure Authors         :
>>> Geoff Huston George Michaelson Filename        :
>>> draft-ietf-sidr-rfc6485bis-02.txt Pages           : 7 Date
>>> : 2015-05-15
>>> 
>>> Abstract: This document specifies the algorithms, algorithms'
>>> parameters, asymmetric key formats, asymmetric key size and
>>> signature format for the Resource Public Key Infrastructure
>>> subscribers that generate digital signatures on certificates,
>>> Certificate Revocation Lists, and signed objects as well as for
>>> the Relying Parties that verify these digital signatures.
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at
>>> tools.ietf.org.
>>>

---

From: Richard Hansen <[email-masked]>
Date: Thu, 21 May 2015 18:38:02 -0400

>>    rsaEncryption instead, which has the same meaning in this
[...]
> 
> Perhaps you are concerned mostly about the terms being used?  But the
> rfc6485bis document does not say "violate" and I believe that what it
> says agrees with the message above.  If you don't think so, you
> should say why.

This draft's Section 8 says:

   [...]                                    A closer reading of
   [RFC4055] and [RFC5754] has identified that the CMS SignerInfo field
   must support use of the rsaEncryption OID for full conformance with
   the CMS specifications, and the normative references in [RFC6485]
   inherited this requirement.

The phrase "the CMS SignerInfo field must support use of the
rsaEncryption OID" doesn't make much sense to me -- how can an OID field
not support an OID?  I'm not 100% sure what is meant here, but the next
paragraph provides a hint:

   [...]                                          By conforming to the
   CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects
   are less likely to be rejected as non-conformant with the CMS
   standards.

To me, this sentence and the one above are claiming that the CMS RFCs
say that the SignerInfo signatureAlgorithm field MUST contain
rsaEncryption, and that we are non-conformant (violating the spec) by
using sha256WithRSAEncryption.  Neither is true.

The CMS RFCs say that CMS signed object RP implementations MUST support
the rsaEncryption algorithm.  This is not the same as requiring the
field to contain rsaEncryption.  It's perfectly OK to put
sha256WithRSAEncryption in that field.  It's also OK for us to burden
CMS RPs with an additional requirement to support
sha256WithRSAEncryption when validating RPKI objects (which RFC6485 and
this bis both do).

RFC6485 burdened INR holders with the requirement to use
sha256WithRSAEncryption when *producing* CMS signed objects for the
RPKI, and if I understand the history correctly, this is where things
got tricky.  From a CMS RFC conformance perspective it's perfectly OK
for RFC6485 to require RPKI CMS object producers to use
sha256WithRSAEncryption, but third party crypto libs didn't make it easy
for implementations to conform.  Thus, implementations used
rsaEncryption instead.  Rather than change implementations (difficult),
we decided to unburden the CMS producers and change the spec (easy).

I provided Geoff and George with alternative wording for Section 8 that
I think is more correct, but of course they may disagree.

BTW, you may find this thread relevant:
http://thread.gmane.org/gmane.ietf.smime/7053

> This is not the right place to define the OID for rsaEncryption.

I completely agree.  All I meant here is that we need to either define
it or cite something that does.  I suggested to Geoff and George to
simply add "[RFC3370]" after rsaEncryption to fix this.

> It is found in 3370, which 5754 (one of the references) updates and
> normatively references.

I don't think that is sufficient in this case.  There are multiple RFCs
that this document directly and indirectly references that define an
algorithm identifier named rsaEncryption.  I believe they all have the
same OID value, but some of them give slightly different semantics.
Thus, I think it's important to make it clear which definition of
rsaEncryption is intended.

For example, RFC3370 (for CMS) says that rsaEncryption is either a key
type identifier or a signature algorithm identifier, while RFC3279 (for
PKIX) says that it's only a key type identifier and thus not suitable
for identifying signature algorithms in a PKIX context (you must use
xxxWithRSAEncryption instead to specify the digest).  There may be more
significant semantic differences in other RFCs; I haven't done an
exhaustive search.

> Those that are still shown as "Reported" have not yet been reviewed.
> As Sean said, it is possible for an errata to be rejected.
> 
> The description of the errata process is found at
> https://www.ietf.org/iesg/statement/errata-processing.html.

Understood -- the parenthetical was meant to be a disclaimer
acknowledging that they might get rejected.

However, if this bis is published and the errata are then set to
verified/HFDU, then what do we do?  Do we somehow move the errata over
to the new RFC?  Do we resubmit them and go through the process again?

It seems like we'd save ourselves a lot of trouble by simply
incorporating them now, especially since there's no controversy over the
changes (that I know of).

-Richard