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

[Sandra Murphy <[e-mail]>]

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

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