Memorandum for Multi-Domain Public Key Infrastructure Interoperability
RFC 5217

Note: This ballot was opened for revision 13 and is now closed.

(Russ Housley) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2008-04-24)
  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 2.3.2.3:
>      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.