I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-saintandre-tls-server-id-check-11
Reviewer: Ben Campbell
Review Date: 2010-12-03
IETF LC End Date: 2010-12-16
Summary: This draft is almost ready for publication as a BCP. I have a few
questions and comments that I think should be considered first, as well as a
few editorial comments.
*** Major issues:
-- [ Not so much a "major issue" as a "slightly less minor" one] I'd like to
see more discussion around URI-IDs. These seem to me to be the most complex ID
type to get right, but there are no examples and limited discussion. Picking on
SIP, purely as an example for which I have a passing familiarity: Would a SIP
reference identity match a SIPS URI-ID in a certificate? Do I put both a URI-ID
and an SRV-ID in my reference set and/or certificate? How do I handle the fact
that I sometimes need to do a NAPTR query, before the SRV query depending on
whether I know the transport protocol? (I realize SIP already defines cert ID
matching, but what would I do for a new application protocol URI with similar
properties?)
I wonder if the answer is that such things are scheme specific, and that its
hard to say much about the generic handling of URI-IDs. If so, it might be
worth mentioning that, and maybe discuss what things the designer of a new
scheme should keep in mind.
*** Minor issues:
-- 1.2, last paragraph:
Nothing normative here? Do we think that protocol designers SHOULD reference
document instead of rolling their own? For example, would you expect additional
IESG or SECDIR scrutiny for a new spec that rolls its own rather than referenda
this? As stated, this paragraph makes it sound like this is something designers
could use, rather than something designers should use. It seems like a BCP
might take a stronger position.
-- 1.4.2, 2nd bullet item: "We also do not address identifiers derived from
Naming Authority Pointer (NAPTR) DNS resource records [NAPTR] and related
technologies such as [S-NAPTR], since such identifiers cannot be validated in a
trusted manner in the absence of [DNSSEC]."
Does that mean validation of a source domain that will be used to construct a
NAPTR request is out of scope, or just validation against the result of a NAPTR
query? (I note SIP may require the first).
-- 2.3, paragraph 1:
A DN example might be helpful.
-- 2.3, paragraph 3: "application service is identified by a name or names
carried in the subject field and/or in one of the following identifier types"
May be identified, right? Since, as you mentioned earlier, it is common to
identify a service with a name plus service designator, and only the SRV-ID and
URI-ID intrinsically do this.
-- 3.1, rule 3:
What happens when you have multiple schemes that are defined to refer to the
same resource. For example, SIP and SIPS? Does a SIP URI-ID match an otherwise
identical SIPS URI-ID? (Maybe this should be left to the URI definitions
themselves, but it might be worth mentioning the complication somewhere.)
-- 3.1, rule 5: "... unless a profile of this specification... "
This pattern recurs throughout the document. Can you elaborate on what you mean
by "profile"? Normally I think of a "profile" as defining a subset of choices
for some particular application. But if a profile relaxes a requirement (i.e.
encouraging something that is a SHOULD NOT here), that's not really a subset.
Are you referring to an application protocol spec that refers to this document?
Updates to this document? (I'm not sure if this should count as a minor issue
or an editorial comment. It depends on whether its just a confusion around the
word choice, or whether you have something specific in mind that I did not
grok).
-- 3.1, rule 6:
Can you motivate why this is not a MUST NOT?
-- section 3.2:
I'd like to see a (non-trivial) URL-ID example.
-- 3.2, first example:
Since we say you SHOULD NOT put the FQDN in a CN-ID, why include it in
examples? The example does seem to make sense, but it makes me wonder if the
SHOULD NOT would be better placed on the client verification process not the
cert generation process.
--4.2.1, paragraph 3:
It's probably out of scope, but it might be useful to offer some guidance on
how ensuring the extraction is "not subject to subversion" is not always
trivial. For example, if you got your input URI by clicking on a link in a
phishing email, that can be almost isomorphic to using a delegation from a
non-trusted source.
-- 4.2.2:
Can we have a URI-ID example? (and maybe an explanation why the HTTP example
doesn't use one?)
-- 4.3, 4th bullet item:
An example would be helpful here.
-- 4.4, rule 1:
Why not MUST NOT?
-- 5.1:
Should this doc mention anything about the ability to unpin?
*** Nits/editorial comments:
-- 1.1, paragraph 1: "...visible face of the Internet consists of services that
employ a client-server architecture..."
This seems a little overstated. Client-server applications are certainly
common, but they don't represent all common uses of the Internet. (Or do I
misinterpret what you mean by "visible face"?)
"references some conception... of... identity"
I'm not sure what that means. Can you state this more plainly? Maybe "concept
of identity" or "idea of identity"? (I realize "conception" can mean "concept",
but it sounds strained to my mental ear.)
-- 1.2, Paragraph 1: "document does not supersede the rules for certificate
issuance or validation provided in [PKIX]"
If this document does not supercede PKIX, then that also means that PKIX is
authoritative on any point for which is draft may be in conflict with it, right?
"Specifically, in order to ensure proper authentication, application clients
need to verify the entire certification path, because this document addresses
only name forms in the leaf server certificate, not any name forms in the chain
of certificates used to validate the server certificate."
Sentence hard to parse. Can it be broken up or simplified?
-- 1.2, Paragraph 2: "existing application protocols"
Probably worth tying that to a point in time, as in "application protocols that
were specified prior to the publication of this BCP"
-- 1.5, first paragraph: "each entry is preceded by a dollar sign ($) and a
space."
I don't see any $'s
-- 1.5, definition of "delegated domain": "connecting to the source domain"
Is connecting to really the term you want here? Maybe "associated with"? In the
context of this draft, I'm afraid people will think of connection in terms of
tcp connections, etc.
-- 1.5, definition of "subject name"
Is there a definition or reference for "composite name"?
-- 1.6:
I don't know if it matters, but I usually see contributors and acknowledgments
sections near the end. It seems sort of abrupt to find them imbedded between
technical content sections.
-- 3.1, 1st paragraph:
It's probably worth emphasizing that the rules are often cumulative. I think
someone thinking about these for the first time might not grasp that until they
see examples later in the doc.
-- 4.3, implementation note: "although such behavior is not forbidden by this
document"
The "SHOULD stop the search" language in previous paragraph implies that you
SHOULD NOT do this, doesn't it? So while it's not strictly forbidden, it's
strongly discouraged. The implementation note makes it sound more like it is
merely out of scope.
-- 4.3, 4th bullet item
does the ABNF or URI reference define "reg-name" as well as "scheme"? That
seems ambiguous. If not, then it might be helpful to have an expansion,
definition, or reference for "reg-name".
-- 4.4: "Furthermore, if the client supports presented identifiers that
contain the wildcard character ’*’, we define a supplemental rule for so-called
"wildcard certificates".
I think the definition will stay there regardless of the intent of the client
:-) Perhaps something to the effect of "... We define a supplemental
rule...which may be used by clients that support wildcards."
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf