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

From: =JeffH <[email-masked]>
Date: Mon, 06 Dec 2010 17:00:33 -0800

a followup on aspects of PeterSA's response..

Peter Saint-Andre <[email-masked]> replied..
 >
 > On 12/3/10 2:24 PM, "Ben Campbell" <[email-masked]> 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".

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.

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?

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

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

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

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

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

 >> -- 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)

 >> -- 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/  ?

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

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

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

thx again for your review,

=JeffH

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 06 Dec 2010 21:10:55 -0700

> a followup on aspects of PeterSA's response..

Thanks, Jeff. A few comments inline from your co-author. :)

> 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..
> 
> 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, that seems strange -- why not "sips"?

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

That seems to be the right set of documents. We just need to figure out
how to interpret them. Not that our I-D needs to legislate for the SIP
community (but it would be nice if that community could re-use our I-D
in the future if desired).

> how about "normatively reference" rather than "re-use" ?

I keep thinking that it's possible to normatively reference this spec
without re-using its rules -- perhaps someone likes our terminology and
normatively references the spec for our definitions of "source domain"
and "derived domain".

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

+1 to all that.

> how about simply s/composite name/name/  ?

Sure. I got "composite name" from you and I thought perhaps it was some
sacred term from the X.5** series. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Dec 2010 07:01:00 -0800

[[ Much abbreviated ]]

>> http://www.ietf.org/mail-archive/web/certid/current/msg00502.html

Putting an explanation such as the above in the document will help future IETFs to decide when to make this a MUST NOT. It might also help the CA/Browser Forum and specific CAs see that they should stop doing this ASAP, and maybe even convince a particular legacy OS vendor to support TLS SNI.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 07 Dec 2010 12:56:09 -0700

> Putting an explanation such as the above in the document will help future IETFs to decide when to make this a MUST NOT. It might also help the CA/Browser Forum and specific CAs see that they should…

Sigh. I don't particularly want to add a long informational note that
qualifies eight words in the spec, but you're right. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Dec 2010 19:35:35 -0600

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

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

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

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

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

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

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

> > I think it's better to delete that instance from the first example.

WFM

> > You're right, "largely consists" is more accurate.

WFM

> "notion" sounds fine to me.

WFM

> > application clients need to verify the entire certification path.

Works for me (WFM)

> how about simply s/composite name/name/  ?

WFM

> > ways that are illustrated later in this document.

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. :-)  )

> > extraction of the "reg-name" might necessitate normalization of the URI (as

WFM

> > so-called "wildcard certificates".

WFM

> thx again for your review,

Thanks for considering it!

Ben.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 07 Dec 2010 22:12:38 -0700

>>> On 12/3/10 2:24 PM, "Ben Campbell" <[email-masked]> wrote:

<snip/>

>>>> -- 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.
>>> 
>>> 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. :-)  )

Those scenarios are important, but IMHO how the server determines which
certificate to present (e.g., based on the SNI or something else, such
as the 'to' address on an XMPP stream header) is something that an
application protocol specification needs to define.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Dec 2010 23:45:50 -0600

> application protocol specification needs to define.

Agreed. Does this draft need to say that, or do we just take it as given?

> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Dec 2010 06:10:59 -0700

> Agreed. Does this draft need to say that, or do we just take it as given?

I think it's appropriate to add a few words about that. I suggest...

1.1

   ... When a client connects to an
   application service using Transport Layer Security [TLS] or Datagram
   Transport Layer Security [DTLS], it references some notion of the
   server's identity while attempting to establish a secure connection
   (e.g., "the website at example.com") and typically specifies at least
   the DNS domain name with which it is trying to communicate (e.g.,
   using a Server Name Indication during TLS negotiation as described in
   [TLS-EXT]).

1.5

   presented identifier:  An identifier that is presented by a server to
      a client within a PKIX certificate when the client attempts to
      establish a secure connection with the server; the certificate can
      include one or more presented identifiers of different types, and
      the certificate presented is typically based on a DNS domain name
      specified by the client when initiating communication (e.g., using
      a Server Name Indication during TLS negotiation as described in
      [TLS-EXT]).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ben Campbell <[email-masked]>
Date: Wed, 8 Dec 2010 08:37:10 -0600

>      a Server Name Indication during TLS negotiation as described in

Do you think server_name extension use is actually common enough to call typical? I'm not saying it's not--I don't really know one way or another. Otherwise, WFM.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Dec 2010 07:54:52 -0700

On 12/8/10 7:37 AM, Ben Campbell wrote:
>>>>>>>> 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.
>>>>>>> 
>>>>>>> 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 
>>>>> 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. :-)  )
>>>> 
>>>> Those scenarios are important, but IMHO how the server
>>>> determines which certificate to present (e.g., based on the SNI
>>>> or something else, such as the 'to' address on an XMPP stream
>>>> header) is something that an application protocol specification
>>>> needs to define.
>>> 
>> ... When a client connects to an application service using
>> Transport Layer Security [TLS] or Datagram Transport Layer Security
>> [DTLS], it references some notion of the server's identity while
>> attempting to establish a secure connection (e.g., "the website at
>> example.com") and typically specifies at least the DNS domain name
>> with which it is trying to communicate (e.g., using a Server Name
>> Indication during TLS negotiation as described in [TLS-EXT]).
>> 
>> 1.5
>> 
>> presented identifier:  An identifier that is presented by a server
>> to a client within a PKIX certificate when the client attempts to 
> Do you think server_name extension use is actually common enough to
> call typical? I'm not saying it's not--I don't really know one way or
> another. Otherwise, WFM.

We could say "and if the server hosts more than one domain then the
certificate presented is typically based..."

Peter

-- 
Peter Saint-Andre
https://stpeter.im/