On Dec 6, 2010, at 7:00 PM, =JeffH wrote: > a followup on aspects of PeterSA's response.. > > > Peter Saint-Andre <[email protected]> replied.. > > > > On 12/3/10 2:24 PM, "Ben Campbell" <[email protected]> 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. _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
