Elwyn,
Now we released -12 as the result of reflecting your comments.
See comments in-line,
Thanks,
--
Masaki SHIMAOKA <m-shimaoka(_at_)secom(_dot_)co(_dot_)jp>
SECOM IS Lab.
Core Technology Div.
+81 422 76 2105 (4122)
On Tue, 1 Jan 2008 11:11:40 +0900
島岡 政基 <m-shimaoka(_at_)secom(_dot_)co(_dot_)jp> 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(_at_)dial(_dot_)pipex(_dot_)com]
Sent: 2008/01/01 (火) 0:41
To: General Area Review Team
Cc: Mary Barnes; 島岡 政基; nelson(_dot_)hastings(_at_)nist(_dot_)gov;
nielsen_rebecca(_at_)bah(_dot_)com; 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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf