Memorandum for Multi-Domain Public Key Infrastructure Interoperability
Note: This ballot was opened for revision 13 and is now closed.
(Russ Housley) Yes
(Jari Arkko) (was Discuss) No Objection
Prior to establishing the trust relationship, each PKI determines the level of trust of each external PKI by reviewing external PKI Certificate Policy Document(s) and any other PKI governance documentation through a process known as policy mapping. This seems to forget the business and real-world aspects that appear to be in far greater role in determining whether to enter a relationship. Suggest edit: s/Prior to establishing the trust relationship/In addition to making a business decision to consider a trust relationship/ PKI Domain: A set of two or more PKIs that have chosen to enter into trust relationships with each other through the use of cross- certificates. Each PKI that has entered into the PKI Domain is considered a member of that PKI Domain. NOTE: This definition specifies a PKI Domain recursively in terms of its constituent domains and associated trust relationships; this is different to the definition in RFC 4949 [RFC4949] that gives PKI Domain as synonym for CA domain and defines it in terms of a CA and its subject entities. Personally, I find the terminology domain unfortunate in this context. A federation, group or some other term would perhaps be more appropriate. I found it amusing that on Page 27 there is a small section that defines the used acronyms, such as "PKI". I'm almost certain that this acronym occurred earlier in the document :-) Perhaps this section should have been merged with the terms section in the beginning of the document. I fear that no one will in practice be able to get what Section 3.2.3 says quite right. Managing these is going to be extremely difficult for everyone except perhaps a few of the most devoted organizations. Assuming there are domains and membership in multiple domains. Do implementations typically get policy mapping and name constraint correctly? I wonder...
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Cullen Jennings) No Objection
(Chris Newman) No Objection
Comment (2008-04-23 for -)
The true security of these models depends heavily on the diligence of the humans applying policy and operations as well as the people writing the software. PKI software has a long history of introducing security bugs into deployed systems simply as a side effect of the complexity of standards such as ASN.1 and PKIX. I find myself skeptical that humans can actually implement and apply the policies necessary to make the more complex PKI structures reasonably secure in practice. While these concerns could be better captured in the security considerations and that would result in a minor improvement to the document, at the root this is not an actionable concern absent significant research into practices necessary to make security policy operations actually effective. Editorial nits: Section 2.2.1: > 4949 [RFC4949]. The first definition (context for PKI) is > specifically used to 'Trust Anchor CA' in this document. I'm not sure what this means, perhaps you meant to say: 4949 [RFC4949]. The first definition (context for PKI) is referred to by the terminology 'Trust Anchor CA' in this document. or 4949 [RFC4949]. This document uses the terminology 'Trust Anchor CA' for the first definition (context for PKI) of 'Root CA' in RFC 4949. Section 18.104.22.168: > appropriate certification path to a subscriber if they chooses an s/chooses/choose/
(Mark Townsley) No Objection
(David Ward) No Objection
(Magnus Westerlund) No Objection
(Tim Polk) (was No Record, No Objection) Recuse
Comment (2008-04-24 for -)
I support publication of this document, but decided to recuse since one of the co-authors reports to me at NIST.