On 10/06/2010, at 5:38 AM, 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?
Thank you for this analysis Steve. Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
