Hi Elwyn, Many thanks for your detailed reviews as Gen-ART. I am going to check your comments deeply next week and update the I-D. Thank you, -- Shima -----Original Message----- From: Elwyn Davies [mailto:elwynd@xxxxxxxxxxxxxx] Sent: 2008/01/01 (火) 0:41 To: General Area Review Team Cc: Mary Barnes; 島岡 政基; nelson.hastings@xxxxxxxx; nielsen_rebecca@xxxxxxx; IETF Discussion; Russ Housely Subject: Gen-art review of draft-shimaoka-multidomain-pki-11.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. 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: (if known) - 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). Th! is 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/ _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf