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

[Peter Saint-Andre <[e-mail]>]

On 12/6/10 6:00 PM, =JeffH wrote:
> a followup on aspects of PeterSA's response..

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

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

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

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

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

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

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

+1 to all that.

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

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/