On 2015-05-21 17:08, Sandra Murphy wrote: > On May 20, 2015, at 4:03 PM, Richard Hansen <[email protected]> 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. 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 >> * the OID and meaning of rsaEncryption is not defined in this >> document, and there is no normative reference to a definition > > 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. >> * 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. 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
