Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11

[Ben Campbell <[e-mail]>]

On Dec 6, 2010, at 7:00 PM, =JeffH wrote:

> a followup on aspects of PeterSA's response..
> 
> 
> Peter Saint-Andre <[e-mail]> replied..
> >
> > On 12/3/10 2:24 PM, "Ben Campbell" <[e-mail]> wrote:
> >
> 
> thanks for the review.
> 
> 
> >> -- 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.)
> >
> > Given that a user agent would not connect to sip:example.com or
> > http://example.com/ via SSL/TLS, it seems appropriate for the certificate to
> >  include only the TLS-aware scheme (sips:, https:, etc.).
> 
> Yes, the latter seems appropriate, however RFC 5922 "Domain Certificates in the Session Initiation Protocol (SIP)" seems to be ambiguous (or maybe broken) on this point. Eg [S7.1] of RFC 5922 says in part..
> 
>   1.  Examine each value in the subjectAltName field.  ... Each
>       value in the subjectAltName has a type; the only types acceptable
>       for encoding a SIP domain identity SHALL be:
> 
>       URI   If the scheme of the URI is not "sip", then the
>             implementation MUST NOT accept the value as a SIP domain
>             identity.
> 
>             ...
> 
>       DNS   An implementation MUST accept a domain name system
>             identifier as a SIP domain identity if and only if no other
>             identity is found that matches the "sip" URI type described
>             above.
> 
> 
> The above is saying that "sip:example.com" is what ought to be found as a subjectAltName:uniformResourceIdentifier value -- note that it says that one MUST NOT accept the cert if the URI scheme isn't "sip".

Yes. See my comment to Peter's email. I _think_ the intent is that a SIP user agent is going to look for a "sip" scheme in subjectAltName:uniformResourceIdentifier, even the original URI that it used to invoke a service had some other SIP compatible scheme (such as SIPS or TEL). A side effect would be that you can't differentiate between a service for SIP or SIPS using the certificate--and on reflection, I think that's a good thing. 

> 
> Also, RFC 5626 "Client-Initiated Connections in SIP"
> notes in [S4.3]..
> 
>                                  ... For TLS protocols, there MUST also
>   be a match between the host production in the next hop and one of the
>   URIs contained in the subjectAltName in the peer certificate. ...
> 
> ..but doesn't say anything about the URI scheme.

Right. By host production, I _think_ that is talking about what gets fed into DNS. That is, the source domain in the parlance of the tls-server-id-check. That is, not the URI itself.

> 
> And RFC 5630 "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)" appears to not say anything about certificate validation or name matching (it appears to punt to RFC 5626).
> 
> Finally, RFC 3261 -- the base SIP spec -- appears to only really discuss S/MIME certs.
> 
> Are there other SIP RFCs we should also peruse?

I think 5922 is the one most relevant for this effort.

> 
> 
> >> -- 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).
> >
> > I think it's a terminological issue. By "profile" we mean "a specification
> > that re-uses this one" -- as, say, draft-ietf-xmpp-3920bis re-uses this I-D.
> >  The relationship is not one of defining a subset, but of being a downstream
> >  customer. Is there a good, single word for that? If not, I think we can say
> >  "Specifications that re-use this one" (ugly, but descriptive).
> 
> how about "normatively reference" rather than "re-use" ?

WFM. Or "specs that depend...":

> 
> 
> 
> >> -- 3.1, rule 6:
> >>
> >> Can you motivate why this is not a MUST NOT?
> >
> > Jeff has better numbers on this than I do, but a non-trivial number of
> > existing certificates contain multiple CN-IDs. In addition, as long as
> > control over the domain names has been certified then folks on the CertID
> > list and other reviewers did not see harm in allowing CAs to include those
> > domain names in CN-ID form, although it's not encouraged to do that.
> 
> 
> Rule 6 is..
> 
>   6.  The certificate MAY contain more than one DNS-ID, SRV-ID, or
>       URI-ID (but SHOULD NOT contain more than one CN-ID).
> 
> 
> The reason for allowing this wiggle-room is that (for better or worse)..
> 
>  1. the CA/Browser Forum Extended Validation (EV) Certificate Guidelines
>     explicitly allow for multiple CN-IDs
> 
>  2. It's a not-totally-uncommon current practice to have certs that do have
>     mutiple CN-IDs, eg from Comodo (whether EV or DV (domain valivdated)).
> 
>  3. Virtual hosting multiple distinct-domain TLS servers on one entity is
>     difficult today if one desires wide desktop client support because
>     a certain vendor's older-but-still-widely-deployed-OS does not (yet?)
>     support the TLS Server Name Indication extension. Thus having one
>     cert with all the domains jammed in it (as either/both CN-IDs or/and
>     DNS-IDs) is a workaround (eg Content Delivery Networks use this).
> 
> 
> So some argue that if we MUST NOT multiple CN-IDs at this point, it is flying in the face of present reality and might contribute to acquiring an attained reputation for this BCP that is lower than we desire.
> 
> There is also concern on the part of CA folk about client-side TLS libs and their support for name matching (ie some (old?) one(s) will only match on CN-ID).
> 
> For a CA perspective on all the above, see...
> 
> Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data
> http://www.ietf.org/mail-archive/web/certid/current/msg00502.html

I concur with Paul Hoffman's comment that putting a few words about that in the draft would be helpful.

> 
> 
> 
> >> -- 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.
> >
> > I think it's better to delete that instance from the first example.
> 
> agreed.

WFM

> 
> 
> 
> 
> >> *** 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"?)
> >
> > You're right, "largely consists" is more accurate.
> 
> agreed.

WFM

> 
> 
> >> "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.)
> >
> > How about "notion"?
> 
> "notion" sounds fine to me.

WFM

> 
> 
> >> -- 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?
> >
> > Yes indeed.
> >
> >> "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?
> >
> > I think this is better:
> >
> > This document does not supersede the rules for certificate issuance or
> > validation provided in [PKIX].  Therefore, [PKIX] is authoritative on any
> > point that might also be discussed in this document. Furthermore, [PKIX]
> > also governs any certificate-related topic on which this document is silent,
> > such as certificate syntax, certificate extensions such as name constraints
> > and extended key usage, and handling of certification paths.
> >
> > 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.  Therefore, in order to ensure proper authentication,
> > application clients need to verify the entire certification path.
> 
> looks good to me (LGTM)

Works for me (WFM)

> 
> 
> 
> >> -- 1.5, definition of "subject name"
> >>
> >> Is there a definition or reference for "composite name"?
> >
> > Hmm, I don't see anything in RFC 5280, but I'll have to check the X.5**
> > specs.
> 
> "composite name" doesn't appear in the X.5?? specs AFAICT.
> 
> how about simply s/composite name/name/  ?

WFM

> 
> 
> 
> >> -- 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.
> >
> > I've added the second sentence to this paragraph:
> >
> > When a certification authority issues a certificate based on the
> > fully-qualified DNS domain name at which the application service provider
> > will provide the relevant application, the following rules apply to the
> > representation of application service identities.  The reader needs to be
> > aware that some of these rules are cumulative and can interact in important
> > ways that are illustrated later in this document.
> 
> LGTM.

WFM

In fact, as I was re-reading RFC 5922, it occurred to me to wonder if people need guidance one way or another on the idea of "multi-purpose" certs that might have any number of subjectAltName entries for different purposes. I'm talking about virtual domain hosting, or multi-protocol hosts. I assume in the latter case, you would expect a host to use different certs for different protocols. In the first case, is their any guidance to give. I can't remember, do you mention the TLS server_name extension?

(I don't mean to suggest any real action here--just thinking out loud about something that would have been much better to bring up well before IETF LC. :-)  )


> 
> 
> 
> >> -- 4.3, 4th bullet item
> >>
> >> does the ABNF or URI reference define "reg-name" as well as "scheme"?
> >
> > Yes. In the URI spec, "reg-name" is an FQDN, not an IP address or mere host
> > name.
> >
> >> That seems ambiguous. If not, then it might be helpful to have an
> >> expansion, definition, or reference for "reg-name".
> >
> > Clarified as follows:
> >
> > o  For a reference identifier of type URI-ID, the DNS domain name portion is
> > the "reg-name" part of the "authority" component and the application type
> > portion is the scheme name matching the [ABNF] "scheme" rule from [URI] (not
> > including the ':' separator); note that this document specifies that a
> > URI-ID always contains an "authority" component whose "host" subcomponent
> > contains a "reg- name" (matching only the "reg-name" rule from [URI] limits
> > verification to DNS domain names, differentiating a URI-ID from a
> > uniformResourceIdentifier entry that contains an IP address or a mere host
> > name, or that does not contain an "authority" component), and that
> > extraction of the "reg-name" might necessitate normalization of the URI (as
> > explained in [URI]).
> 
> LGTM.

WFM

> 
> 
> >> -- 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."
> >
> > Heh. Corrected to:
> >
> > Furthermore, to meet the needs of clients that support presented identifiers
> > containing the wildcard character '*', we define a supplemental rule for
> > so-called "wildcard certificates".
> 
> LGTM.

WFM

> 
> thx again for your review,

Thanks for considering it!

Ben.