Elwyn, Now we released -12 as the result of reflecting your comments. See comments in-line, Thanks, -- Masaki SHIMAOKA <m-shimaoka@xxxxxxxxxxx> SECOM IS Lab. Core Technology Div. +81 422 76 2105 (4122) On Tue, 1 Jan 2008 11:11:40 +0900 島岡 政基 <m-shimaoka@xxxxxxxxxxx> wrote: > 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)? We revised the objective of the document as the following: Abstract: "The objective of this document is to establish a terminology framework and to suggest the operational requirements of PKI domain for interoperability of multi-domain Public Key Infrastructure, ..." s1.1: "The objective of this document is to establish a terminology framework and to provide the operational requirements, which can be used by different Public Key Infrastructure (PKI) authorities who are considering establishing trust relationships with each other." > 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. deleted. > s2.2, para 2: The second sentence appears to be incomplete: "A CA which issued a public-key certificate to another (subordinate) CA." deleted. > 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? replaced "inadvertent trust" with "creating inadvertent trust relationships" > 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." Revised as the following: "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 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 mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf