Debating PKI terminology with Steve is a mug's game, and I've already stated my reasons for liking the simple format in a previous posting, so this will just be about the parts of Steve's analysis where I have something new to say or ask.
At Wed, 9 Jun 2010 15:38:24 -0400, Steve Kent wrote: ... > 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. Where in that paragraph (or anywhere in Sam's document) does it say that the TA certificate doesn't contain 3779 extensions? At least one of us is confused on this point. That said, if the text is confusing, it should be fixed. I don't think Sam intended to suggest that the certificate should not contain 3997 extensions; indeed, constraint (1) in that section says that the certificate must contain RFC 3779 resources, albeit by reference (it says that the certificate must comply with the res-cert profile). > 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. Other than the inherit bit, this is what I think the draft already says, or at least is trying to say. More on the inherit bit below. > So, the I-D could be rewritten to fix the terminology problem and the > technical problem cited above. Agreed. > 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. Using the inherit bit here is clever. I'm not sure I believe that it needs to be mandatory, that seems like a choice the operator should be allowed to make. It's straight RFC 3779 in either case, no magic, so relying parties have to cope with either option in any case. I'd have no problem with a SHOULD regarding use of the inherit bit, just don't see the need for a MUST. > 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. The current proposal says that the certificate conforms to the profile, which in turn mandates the CRL. No harm in saying so explicitly if you're more comfortable with that, but it's already part of the specification by reference as far as I can tell. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
