Elwyn, Now we released -12 as the result of reflecting your comments.
See comments in-line, Thanks, -- Masaki SHIMAOKA <[EMAIL PROTECTED]> SECOM IS Lab. Core Technology Div. +81 422 76 2105 (4122) On Tue, 1 Jan 2008 11:11:40 +0900 島岡 政基 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > Sent: 2008/01/01 (火) 0:41 > To: General Area Review Team > Cc: Mary Barnes; 島岡 政基; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 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 > [email protected] > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ IETF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
