Document: draft-shimaoka-multidomain-pki-11.txt
Reviewer: Elwyn Davies
Review Date: 28 December 2007
IETF LC End Date: 1 January 2008
IESG Telechat date: -

Summary:
In general this is a well written and, as far as I can see, comprehensive document.  
I have one major problem with it: it far exceeds the scope advertised in the 
Introduction.  It is very definitely not just about terminology.  It certainly 
gives definitions for names in a taxonomy of PKI Domains but it also defines the requirements and relationships of the components in the various models.  At the very 
least it should advertise itself as a framework or architecture.  Given the degree of detail and the (indirect) specification of bits on the wire, I would classify it as 
a standard.  Whether it is a standard rather than a framework depends to some extent 
on what else you could or would need to specify a fully working system.  Personally, 
not being an expert, the specification seems pretty complete. Not much would need to 
be changed IMO to make it good as a standard (just saying what it is and  removing 
what appear to be unnecessary weasel words from the security section).  This seems 
to complement PKIX work and has had input for PKIX in the past.

Aside from this there are a few minor issues and some editorial nits noted below. 

Comments:

Abstract/s1.1: 
  "The objective of this document is to establish a standard terminology 
   that can be used by different Public Key Infrastructure (PKI)
   authorities who are considering establishing trust relationships with
   each other."
I think that the document goes way beyond the stated aim of establishing terminology.  
I have no problem with what it does, but there should be honesty in advertising.  
At the very least this could be described as a framework document or maybe an 
architecture, but the degree of detailed requirements for the various different 
models which in many cases (indirectly) specifies the bits on the wire means that 
it would be quite possible to see this as a standard for PKI Domains.  
Not being an expert in this area, I am not sure what else a 'standard' might specify 
if it was built using this document as a 'framework':  my immediate reaction is 
that there isn't much else to specify.. so is it really a standard?  Or are we shying
away from trying to make standards in this arena (the  idea of creating standard 
terminology argues against this)? 

s6:  Related to the previous point, stating
  "Because this RFC defines terminology and not protocols or technology
   for implementing the terminology, technology-specific security
   considerations are not applicable."
seems disingenuous. Actually quite a lot of specific technology is mandated.  
On the other hand, the actual security discussion seems to cover the situation quite 
well, and I think the disclaimer is unnecessary.  Whether the document is recast as 
a framework or becomes a standard, I don't think much, if any, extra would be needed 
in the security section. 

s2.2, para 2: The second sentence appears to be incomplete: "A CA which issued a 
public-key certificate to another (subordinate) CA."

s3.2 and many other places: "inadvertent trust" - This term grates on my tongue.  
I am unsure if this is just that using it 'intransitively' in this way is not 
good English.  The alternatives such as "inadvertent creation of trust relationships" 
are a little clumsy given the number of times it is used - maybe use an acronym?

s3.2.3, last para: s/MUST inform all PKI Domains of its membership in all other PKI Domains./MUST inform all those PKI Domains of its membership in any other PKI Domains./ (really informing *all* PKI domains might prove a little onerous!)

s3.3.2.1, Considerations: I believe that the first SHOULD is inappropriate. 
 s/SHOULD consider/needs to take into account/

s3.3.2.2, Considerations: /For using the name constraints, the Bridge CA SHOULD 
pay attention to preventing a conflict of each name space/When applying the 
name constraints, the Bridge CA needs to avoid creating conflicts between the
name spaces.../  I don't think this is a SHOULD:  The system is likely to fail 
if name conflicts are created.

Editorial:
s2.3.2.1, 3rd sentence: "The root CAs MUST distribute trust anchor.."
s/CAs/CA/, s/trust/a trust/

s2.3.2.3, Trust Anchor part: s/inappropriate/an inappropriate/

s2.4, para 1: s/Trust List/a Trust List/ (2 places), s/Trust Anchor/Trust Anchors/

s2.4, para 2: s/Detail information of each model is described/The two models are 
described in detail/; Also there is a duplicate cross reference to s4.1 at the end 
of the sentence. 

s3, PKI Domain: "NOTE: This definition specifies how domain consists, besides 
"CA domain" defined in RFC 4949 [5]."  I am not sure exactly what this trying to 
say: perhaps something like "NOTE: This definition specifies a PKI Domain recursively in terms of 
its constituent domains; this is different to the definition in [5] that 
gives PKI Domain as synonym for CA domain and defines it in terms of a CA and
its subject entities."

s3.3.3.1, para 1: s/defined as Unifying CA/defined as a Unifying CA/

s3.3.2.1, first sentence:  This sentence has no main verb. s/The model/This is a 
model/

s3.3.2.2, first sentence: same as  last comment.

s3.3.2.2, first para: s/relying party's PKI Domain via Bridge CA/the relying party's
PKI Domain via a Bridge CA/

s3.3.2.2, 'requirements bullets': s/Bridge/The Bridge/(I think I count 11 instances including one in the heading.)

s3.3.2.2, Considerations: s/representation/representatives/

s4.1.1, para 2: s/likes/is similar to/, s/prefer the word/prefers the term/, s/against "Trust Authority" after mentioned/contrasting with "Trust Authority" defined below/