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

[=JeffH <[e-mail]>]

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

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