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).
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/
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
