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."