Steve, Thanks for your report.
To summarize a little bit, we could call the mechanism in this draft "Simple Relaying Party Trust Anchor configuration", but not the TA material itself. Particularly in SEND (RFC 3971 Section 6.5) that also deals with RFC3779 extensions, the RP configuration is done with a similar mechanism. The only difference is that it adds the key algorithm too....which could be also good for this document. Roque. On Jun 9, 2010, at 9:38 PM, Stephen Kent wrote: >> ... >> >> Firstly, I'd like to point out that the approach described in this draft, >> namely that of public key plus URL and a self signed RPKI certificate) is >> the approach described in draft-ietf-sidr-res-certs-06.txt through to >> draft-ietf-sidr-res-certs-11.txt. The terminology was altered slightly >> across that sequence of drafts in response to inputs from Steve Kent, but >> the concept of using a very simple approach of using the public key plus URL >> was what was originally envisaged for the RPKI back in 2007-2008 when those >> versions of the draft were submitted to the drafts repository. >> >> The changes made in version 12 of that draft were made in response to >> messages from Steve Kent and Russ Housley, which pointed out what they >> believed to be specific weaknesses in this key plus URL approach to the TA >> that implied that in their opinion this was not a viable approach to the TA. >> If they are still of the opinion that this approach is not viable then I >> guess that they should say so once more and present their arguments in >> support of that view, this time to the WG. >> Geoff > > Geoff, > > I read the Sam's TA draft and sent comment directly to him yesterday. But, > since you requested feedback from Russ and from me on the list, I'll recap my > comments here. > > The new TA proposal has a few problems. > > From a terminology perspective it has a problem of the sort that Russ and I > noted 2 years ago in the proposal you cited. Specifically, the self-signed > cert is really the TA, as per RFC 5280 and RFC 5914. The public key and URI > are external mechanisms used to acquire and verify the TA. They are not the > TA. Such mechanisms are outside the scope of PKIX and X.509 standards, so the > proposal here is not violating any of those standards. It just defines the > wrong data as being a TA. > > There also is a technical error in the paragraph at the end of Section 4, > where the new I-D describes how one could operate the CA for the self-signed > cert in an offline fashion. The text calls for the TA to not contain a 3779 > extension. That is not compliant with 3779. RFC 3779 requires that the TA at > which a path terminates contain a 3779 extension that encompasses all > subordinate certs. > > However, if one put the 3779 extensions in the TA (self-signed cert), and set > the inherit bit in the (immediate) subordinate CA cert, one could achieve the > desired offline operation goal that the I-D describes. This would then comply > with RFC 3779. > > So, the I-D could be rewritten to fix the terminology problem and the > technical problem cited above. > > I think the notion of an offline TA and an online CA below it are important > from a secruity perspective. Both the compound TA model and this proposal can > achieve that functionality if the new proposal is modified as noted above, > and if the use of the subordinate CA (with the inherit bit) is mandated, not > an option. > > I also think it important to have an explicit, mandatory mechanism for > revocation of an online CA (TA). This is motivated by the observation that > the primary motivation for having matching online and an offline cert issuers > is because one believes that online instance is more vulnerable than the > offline one. Well, if that belief is true, one needs to be prepared to > revoke the online CA's cert, using the offline CA. The compound TA mechanism > does that by having the ETA revoke the EE cert that is used to validate the > CMS blob that holds the RTA. I don't recall the current proposal making a > mention of a comparable function. That can be fixed by having the new > proposal say that the TA will maintain a CRL and that it will revoke its > subordinate CA, if needed. > > If all of these changes were made to the new proposal, both approaches would > seem equivalent in functionality and security. The new proposal would be > somewhat simpler, as it would not make use of the CMS structure that is > employed in the compound TA model. However, code already exists for the > compound TA model, processing of signed CMS objects is pretty well understood > (based on S/MIME implementations), and the differences are relatively minor, > in my opinion. Also, once we correct the terminology and label the > self-signed cert with the 3779 extensions as a TA, we have the slightly odd > situation that the TA is not static, i.e., that cert will change with every > new resource allocation. That does not conflict with any PKIX RFC, to the > best of my knowledge, but it may confuse some folks who are accustomed to the > notion of a TA being a self-signed cert that does not change for a long time. > > Does this analysis satisfy your request? > > Steve > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
