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

From: Sandra Murphy <[email-masked]>
Date: Fri, 3 Jul 2015 06:39:05 -0400

Speaking as regular ol' member
On May 21, 2015, at 6:38 PM, Richard Hansen <[email-masked]> wrote:

> On 2015-05-21 17:08, Sandra Murphy wrote:
>> On May 20, 2015, at 4:03 PM, Richard Hansen <[email-masked]> wrote:
>>> * 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)
>> 
> [...]
>> 
>> 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.

You and I disagree here.

To be clear: our disagreement is whether the description of the motivation for the change to RFC6485 is ambiguous or not.

Personally, I do not consider that an important matter.  The description of the motivation does not change the specification, it does not change implementation, and it does not confuse implementors about implementation.

To recap:
RFC6485 chose to mandate an algorithm id.
That choice is compliant with the CMS RFCs.
The CMS RFCs make a choice of a mandatory to implement algorithm ID.
RFC6485's choice is not the CMS mandatory to implement choice.
Unfortunately, common CMS implementations chose to support only the CMS mandatory to implement algorithm ID.
So common CMS implementations can not be compliant with RFC6485.
By aligning our choice of mandatory algorithm ID with the mandatory algorithm in the CMS RFCs, we make it possible for common CMS implementations to be compliant with RFC6485.
By aligning our choice of mandatory algorithm ID with the mandatory algorithm in the CMS RFCs, we eliminate the problem that a compliant RPKI signed object would be rejected by the common CMS implementations.

wrt:

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

Perhaps you are reading too much into the use of "conforming to"?  Perhaps saying "aligning with" would make it more clear to you?

I do not know what current CMS implementations would do if they were presented with a RFC6485 compliant RPKI signed object.  They may indeed report the signed object is "non-conformant with the CMS standards".   So I can not say that "rejected as non-conformant with the CMS standards" is incorrect.  Error message aside, it is clear that any RFC6485 compliant RPKI signed object (if we could find one) would be rejected by existing implementations.  There might be ways to improve that "rejected as non-conformant" phrase of the text, but I don't think it is necessarily wrong.

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

My reading of the previous discussions is that it is worse than "didn't make it easy" -  the crypto libs made it *impossible* for implementations to be compliant with RFC6485 - they did not implement support for the algorithm RF6485 mandated.

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

Really?  I think that would be a very bad thing!  But not our problem, I think.

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

I think your "and thus not suitable" is a bit of a stretch.  And it would appear that the existing implementations we are talking about did not make this same interpretation - we are in this mess because they use rsaEncryption as a signature algorithm identifier.

Again, speaking as a regular ol' member.

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Mon, 06 Jul 2015 10:44:22 -0400

Sandy,

> Perhaps you are reading too much into the use of "conforming to"? 
> Perhaps saying "aligning with" would make it more clear to you? I do 
> not know what current CMS implementations would do if they were 
> presented with a RFC6485 compliant RPKI signed object. They may indeed 
> report the signed object is "non-conformant with the CMS standards". 
> So I can not say that "rejected as non-conformant with the CMS 
> standards" is incorrect. Error message aside, it is clear that any 
> RFC6485 compliant RPKI signed object (if we could find one) would be 
> rejected by existing implementations. There might be ways to improve 
> that "rejected as non-conformant" phrase of the text, but I don't 
> think it is necessarily wrong. 
you and I disagree here ;-).  Conforming, in my mind, implies that we 
use the same syntax,
validity checks, same alg requirements, etc. What we need to say is that 
we profile the CMS
spec, deviating only with respect to the MTI algorithm.  Using a phrase 
like "aligning with"
seems needlessly ambiguous.
>> xxxWithRSAEncryption instead to specify the digest).
To avoid potential confusion we need to avoid ambiguity in specifying 
alg identifiers.
RFC 3280 didn't resolve this particular ambiguity for PKIX, nor did 
3370. However,
this ambiguity was later addressed in RFC 4055 and RFC 5756. We should 
figure out
which RSA-based signature alg we're mandating, and then cite the 
relevant, recent RFC.

Steve

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 7 Jul 2015 13:03:32 -0400

On Jul 6, 2015, at 10:44 AM, Stephen Kent <[email-masked]> wrote:

> Sandy,
> 
>> Perhaps you are reading too much into the use of "conforming to"? Perhaps saying "aligning with" would make it more clear to you? I do not know what current CMS implementations would do if they were presented with a RFC6485 compliant RPKI signed object. They may indeed report the signed object is "non-conformant with the CMS standards". So I can not say that "rejected as non-conformant with the CMS standards" is incorrect. Error message aside, it is clear that any RFC6485 compliant RPKI signed object (if we could find one) would be rejected by existing implementations. There might be ways to improve that "rejected as non-conformant" phrase of the text, but I don't think it is necessarily wrong. 
> you and I disagree here ;-).  Conforming, in my mind, implies that we use the same syntax,
> validity checks, same alg requirements, etc. What we need to say is that we profile the CMS
> spec, deviating only with respect to the MTI algorithm.  Using a phrase like "aligning with"

[I'll repeat myself.  This argument is about the clarity of the description of the motivation for the change.  There's no specification or implementation impact.]

I am not certain I am understanding your point.  So I'll review the background as I know it.

Richard's view is that the word "conforming" in "By conforming to the CMS specifications" makes it sounds as if RFC6485 were not in compliance with the CMS specs. 

But RFC6485 is definitely in compliance with the CMS specs.

The mandatory algorithm choice in RFC6485 is not the same as the MTI choice in the CMS specs.  That is allowed.

Unfortunately, that mandatory algorithm choice made RFC6485, er, uh, out-of-step with common CMS implementations.

So RPKI signed objects that were compliant with RFC6485 would be rejected by the common CMS implementations - they support only the CMS MTI algorithm.

This bis changes the mandatory algorithm choice so it is the same as the CMS MTI choice.

Richard thinks "conforming" implies something not true, you think "aligning" is ambiguous - do you have a different verb to suggest?

> What we need to say is that we profile the CMS
> spec, deviating only with respect to the MTI algorithm.  

This bis removes the deviation, and makes the MTI algorithms the same.  So I disagree with this sentence.

--Sandy, speaking as regular ol' member

> To avoid potential confusion we need to avoid ambiguity in specifying alg identifiers.
> RFC 3280 didn't resolve this particular ambiguity for PKIX, nor did 3370. However,
> this ambiguity was later addressed in RFC 4055 and RFC 5756. We should figure out
> which RSA-based signature alg we're mandating, and then cite the relevant, recent RFC.

The idea here is to use whatever CMS uses.  Whether CMS is ambiguous in its specification of the alg identifier, or correct in using rsaEncryption as a signature algorithm identifier, we definitely want to use whatever it is that CMS is using, because we want to be using CMS implementations.  
> 
> Steve
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Richard Hansen <[email-masked]>
Date: Wed, 15 Jul 2015 19:44:06 -0400

On 2015-07-03 06:39, Sandra Murphy wrote:
> To be clear: our disagreement is whether the description of the
> motivation for the change to RFC6485 is ambiguous or not.

I feel that Section 8 is incorrect, not just unclear.  (If I'm
interpreting it in a way that is not intended by the authors, and I
don't think I am, then this disagreement *is* just about clarity, not
correctness.)

> 
> Personally, I do not consider that an important matter.  The
> description of the motivation does not change the specification, it
> does not change implementation, and it does not confuse implementors
> about implementation.

I agree that Section 8 as worded does not impact implementations of
*this* standard.

My concern is that the current wording adds to the existing confusion
surrounding the CMS signed object spec, and that people trying to
understand the CMS standard will see this section and reach an incorrect
conclusion.

> By aligning our choice of mandatory algorithm ID with the mandatory
>   algorithm in the CMS RFCs, we make it possible for common CMS
>   implementations to be compliant with RFC6485.
> By aligning our choice of mandatory algorithm ID with the mandatory
>   algorithm in the CMS RFCs, we eliminate the problem that a compliant
>   RPKI signed object would be rejected by the common CMS
>   implementations.

Yes, I agree with this recap.

> Perhaps you are reading too much into the use of "conforming to"?

There is a chance I am interpreting that sentence in a way not intended
by the authors.  If I am, then something should be done to reduce the
difficulty of interpreting the sentence correctly.  If I am not, then
something should be done to correct the sentence.  Either way, something
should be done.

> Perhaps saying "aligning with" would make it more clear to you?

That's an improvement, but still not sufficient.  I sent a suggested
rewrite of Section 8 to the authors on 2015-05-20 with no response;
here's a more minimal rewrite of just that sentence:

   [...]                                          By requiring RPKI CMS
   signed objects to use an OID that is widely supported by existing
   libraries, implementations are less likely to reject valid RPKI CMS
   signed objects due to incomplete algorithm support.

> 
> I do not know what current CMS implementations would do if they were
> presented with a RFC6485 compliant RPKI signed object.

RPSTIR currently accepts either OID.

Before this OID issue was raised, RPSTIR only accepted CMS signed
objects that used sha256WithRSAEncryption.  CMS signed objects that used
rsaEncryption were rejected due to non-conformance with RFC6485.

> They may indeed report the signed object is "non-conformant with the
> CMS standards".

I suspect the other implementations would have rejected CMS signed
objects that use sha256WithRSAEncryption with "unsupported algorithm",
not "non-conformant with the CMS standard" (but I can't say for sure).

> So I can not say that "rejected as non-conformant with
> the CMS standards" is incorrect.  Error message aside, it is clear
> that any RFC6485 compliant RPKI signed object (if we could find one)

Before this OID issue was raised, RPSTIR's test cases generated valid
CMS signed objects that used sha256WithRSAEncryption.  Those test cases
were changed once everyone agreed to switch to rsaEncryption.

We will add a sha256WithRSAEncryption test case once the rfc6485bis dust
settles (to require RPs to either accept or reject depending on what the
final RFC says).  In the meantime, it would be fairly trivial for us to
manually generate such an object.

> would be rejected by existing implementations.

except RPSTIR

> There might be ways to improve that "rejected as non-conformant"
> phrase of the text, but I don't think it is necessarily wrong.

I do, because I doubt that's an accurate reflection of history.

> My reading of the previous discussions is that it is worse than
> "didn't make it easy" -  the crypto libs made it *impossible* for
> implementations to be compliant with RFC6485 - they did not implement
> support for the algorithm RF6485 mandated.

RPSTIR did support RFC6485 as written until this OID issue came up, at
which point we also started accepting rsaEncryption.

(In order to support sha256WithRSAEncryption we had to reinvent much of
the wheel via manual ASN.1 parsing and calls to primitive crypto
functions.  I suspect the other RP implementations call easy-to-use
high-level OpenSSL functions that don't understand sha256WithRSAEncryption.)

> Really?  I think that would be a very bad thing!  But not our problem, I think.

The multiple meanings for rsaEncryption is not our problem, but not
specifying which meaning we want *is* our problem.

> I think your "and thus not suitable" is a bit of a stretch.

rsaEncryption can't be used to identify a signature algorithm in a PKIX
certificate because it doesn't specify the hash algorithm (PKIX doesn't
have a separate signature hash algorithm OID like CMS does).

It can be (and is) used to identify the PKIX key type, however.

> And it would appear that the existing implementations we are talking
> about did not make this same interpretation - we are in this mess
> because they use rsaEncryption as a signature algorithm identifier.

The story with CMS is different -- and considerably more murky -- than
PKIX because CMS has a separate hash OID for signatures.

I asked the smime mailing list [1] if they could point me to text that
clarifies the relationship between the signatureAlgorithm and
digestAlgorithm fields, and what it means to choose a signatureAlgorithm
OID that also specifies a digest algorithm.  My conclusion is:

  * the CMS RFCs are woefully unclear about this

  * practically speaking, you should never choose a signatureAlgorithm
    OID that conflicts with the digestAlgorithm OID (you're asking for
    trouble if you pick md5WithRSAEncryption and sha-1 for the two OIDs)

  * assuming the digest algorithm is x, then practically speaking it
    shouldn't matter whether the signatureAlgorithm is
    xWithRSAEncryption or just rsaEncryption; implementations will
    probably do the same thing either way (assuming they understand
    both OIDs, which isn't true for sha256WithRSAEncryption)

[1] http://thread.gmane.org/gmane.ietf.smime/7053

-Richard

---

From: Richard Hansen <[email-masked]>
Date: Thu, 16 Jul 2015 19:17:08 -0400

> rsaEncryption were rejected due to non-conformance with RFC6485.

Apologies; this is incorrect.

Up to and including v0.3 (released 2012-03-05), RPSTIR only accepted
rsaEncryption.

From v0.4 (released 2012-06-08) to v0.9 (released 2013-10-13) inclusive,
RPSTIR accepted both but warned on rsaEncryption.

Starting in v0.10 (released 2014-02-25), RPSTIR quietly accepts both.

We added rigorous test cases in v0.4.  The thread that brought this OID
issue to SIDR's attention [1] was started shortly after RPSTIR v0.4 was
released.

[1] http://thread.gmane.org/gmane.ietf.sidr/4706

-Richard