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

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

Hi Ben, I've looked again at the URI-ID issue, with special reference to
SIP domain certs (RFC 5922) because SIP seems to be the main technology
that uses URI-IDs. Some of what follows is me thinking out loud. I'll
need to check any tentative conclusions with my co-author.

Also, please note that in this I-D Jeff and I have been working to
generalize from current practices. That's a bit difficult in the case of
URI-IDs because we seem to have only one instance (RFC 5922). I'll ask
the PKIX WG if folks are aware of any other "customers" for the
uniformResourceIdentifier SAN.

On 12/6/10 10:19 AM, Ben Campbell wrote:

> -- [ Not so much a "major issue" as a "slightly less minor" one] I'd
> like to see more discussion around URI-IDs. These seem to me to be
> the most complex ID type to get right, but there are no examples and
> limited discussion. Picking on SIP, purely as an example for which I
> have a passing familiarity: Would a SIP reference identity match a
> SIPS URI-ID in a certificate? 

RFC 5630 states:

   SIP and SIPS URIs that are identical except for the scheme itself
   (e.g., sip:[e-mail] and sips:[e-mail]) refer to the
   same resource.  This requirement is implicit in [RFC3261], Section
   19.1, which states that "any resource described by a SIP URI can be
   'upgraded' to a SIPS URI by just changing the scheme, if it is
   desired to communicate with that resource securely".

So the two are interchangeable: a SIPS reference identity can be
compared against a SIP URI-ID and vice-versa. However, that equivalence
is stipulated by the SIP specs and it is not something we could
generalize to all uses of URI-IDs (say, http and https). And RFC 5922
says that the scheme of the presented identifier MUST be sip, not sips,
so that's a further SIP-specific wrinkle.

> Do I put both a URI-ID and an SRV-ID in
> my reference set and/or certificate? 

That depends. :) A using protocol needs to specify what identifier types
are required and recommended for that application type. For example, in
draft-ietf-xmpp-3920bis we've specified some guidelines for XMPP server
certificates, but the guidelines used in the SIP or HTTP or IMAP
community would be different (if those communities ever become
"customers" of the server-id-check specification).

> How do I handle the fact that I
> sometimes need to do a NAPTR query, before the SRV query depending on
> whether I know the transport protocol? (I realize SIP already defines
> cert ID matching, but what would I do for a new application protocol
> URI with similar properties?)

I think you would take the input to the NAPTR lookup as the source
domain, just as you would for an SRV lookup or an A or AAAA lookup.
Potentially there are more complexities in a NAPTR lookup (all that
regex fun). Furthermore, the NAPTR result might lead the user agent to
then perform an SRV lookup and then an A/AAAA lookup on the result of
the SRV lookup (which is why I call it "the NAPTR three-step"). But I
think that from the perspective of identity checking it doesn't make a
difference how many steps are contained in the resolution process. See
previous message.

> I wonder if the answer is that such things are scheme specific, and
> that its hard to say much about the generic handling of URI-IDs. 

I think we can say that the client needs to separate the application
type aspect of the URI-ID from the the DNS domain name aspect, and we do
say that in Section 4.3:

###

   Before applying the comparison rules provided in the following
   sections, the client might need to split the reference identifier
   into its DNS domain name portion and its application type portion, 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]).

###

The client then follows the rules for matching the DNS domain name
portion as specified in server-id-check document. So I think that the
URI-ID type is not all that different from the others.

(There are complexities caused by URI normalization. I think it's best
to point to RFC 3986 regarding such issues, rather than trying to
describe them all in this spec.)

> If
> so, it might be worth mentioning that, and maybe discuss what things
> the designer of a new scheme should keep in mind.

The designer of a new scheme, or the author of a specification that
re-uses the recommendations in the server-id-check document?

If the former, I think that's a job for other documents (4395bis?).

If the latter, I don't particularly see that we can say much -- this is
something that each technology community will need to consider, but
really the only choices are:

1. Which of CN-ID, DNS-ID, SRV-ID, and URI-ID do we recommend?

2. Do we allow wildcards? If so, exactly where?

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

Right, so that is a third choice facing authors of specifications that
re-use this one. I propose modifying the relevant paragraph in Section
3.1 as follows:

   3.  If the service using the certificate deploys a technology in
       which a server is typically associated with a URI (e.g., this is
       true of [SIP]), then the certificate SHOULD include a URI-ID; the
       scheme SHALL be that of the protocol associated with the service
       type and the "authority" component SHALL be the fully-qualified
       DNS domain name of the service.  A specification that re-uses
       this one MUST specify whether particular URI schemes are to be
       considered equivalent (e.g., http and https, or sip and sips as
       described in [RFC5630]).

(But see below, where I propose further modifications to that paragraph
to address another issue you've raised.)

> -- section 3.2:
> 
> I'd like to see a (non-trivial) URL-ID example.

How's this?

   Consider a SIP-accessible voice-over-IP (VoIP) server at
   "voice.example.edu" servicing SIP addresses of the form
   "[e-mail]" and located at a URI of
   <sip:voice.example.edu>.  A certificate for this service
   would include a URI-ID of "sip:voice.example.edu" (see
   [SIP-CERTS]).

Is that example "trivial", compared to the other examples in the spec?

> --4.2.1, paragraph 3:
> 
> It's probably out of scope, but it might be useful to offer some
> guidance on how ensuring the extraction is "not subject to
> subversion" is not always trivial. For example, if you got your input
> URI by clicking on a link in a phishing email, that can be almost
> isomorphic to using a delegation from a non-trusted source.

I suggest modifying the relevant paragraph as follows (see the last
sentence):

   The client might need to extract the source domain and service type
   from the input(s) it has received.  The extracted data MUST include
   only information that can be securely parsed out of the inputs (e.g.,
   extracting the fully-qualified DNS domain name from the "authority"
   component of a URI or extracting the service type from the scheme of
   a URI) or information for which the extraction is performed in a
   manner that is not subject to subversion by network attackers (e.g.,
   pulling the data from a delegated domain that is explicitly
   established via client or system configuration, resolving the data
   via [DNSSEC], or obtaining the data from a third-party domain mapping
   service in which a human user has explicitly placed trust and with
   which the client communicates over a connection that provides both
   mutual authentication and integrity checking).  These considerations
   apply only to extraction of the source domain from the inputs;
   naturally, if the inputs themselves are invalid or corrupt (e.g., a
   user has clicked a link provided by a malicious entity in a phishing
   attack), then the client might end up communicating with an
   unexpected application service.

> -- 4.2.2:
> 
> Can we have a URI-ID example? 

How's this?

   A voice-over-IP (VoIP) user agent that is connecting via SIP to the
   voice service at "voice.example.edu" might have only one reference
   identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]).

> (and maybe an explanation why the HTTP
> example doesn't use one?)

Well, we happen to know that no one does it that way. :)

However, we might need to tighten up the wording here:

   3.  If the service using the certificate deploys a technology in
       which a server is typically associated with a URI (e.g., this is
       true of [SIP]), then the certificate SHOULD include a URI-ID....

Specifically, we might need to say "programatically associated with a
URI for security purposes" or somesuch.

This I-D is decidedly *not* attempting to modify how existing
technologies use PKIX certificates, so it would be improper for us to
have a URI-ID example for HTTP.

I suggest the following tweaks:

   3.  If the service using the certificate deploys a technology in
       which a server is programatically associated with a URI for
       security purposes (e.g., this is true of [SIP] as specified by
       [SIP-CERTS]), but not true of [HTTP] since [HTTP-TLS] does not
       describe usage of a URI-ID for HTTP services), then the
       certificate SHOULD include a URI-ID; the scheme SHALL be that of
       the protocol associated with the service type and the "authority"
       component SHALL be the fully-qualified DNS domain name of the
       service.  A specification that re-uses this one MUST specify
       whether particular URI schemes are to be considered equivalent
       (e.g., http and https, or sip and sips as described in
       [SIP-SIPS]).

> -- 4.3, 4th bullet item:
> 
> An example would be helpful here.

Yep, I propose that we add examples to all of those bullet points:

###

   Before applying the comparison rules provided in the following
   sections, the client might need to split the reference identifier
   into its DNS domain name portion and its application type portion, as
   follows:

   o  A reference identifier of type DNS-ID does not include an
      application type portion and thus can be used directly as the DNS
      domain name for comparison purposes.  As an example, a DNS-ID of
      "www.example.com" would result in a DNS domain name portion of
      "www.example.com".

   o  A reference identifier of type CN-ID also does not include an
      application type portion and thus can be used directly as the DNS
      domain name for comparison purposes.  As previously mentioned,
      this document specifies that a CN-ID always contains a string
      whose form matches that of a DNS domain name (thus differentiating
      a CN-ID from a Common Name containing a human-friendly name).

   o  For a reference identifier of type SRV-ID, the DNS domain name
      portion is the Name and the application type portion is the
      Service.  As an example, an SRV-ID of "_imaps.mail.example.net"
      would be split into a DNS domain name portion of
      "mail.example.net" and an application type portion of "imaps"
      (mapping to an application protocol of IMAP as explained in
      [EMAIL-SRV]).

   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).
      As previously mentioned, 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, thereby
      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 at all.).  Furthermore, note that
      extraction of the "reg-name" might necessitate normalization of
      the URI (as explained in [URI].  As an example, a URI-ID of "sip:
      voice.example.edu" would be split into a DNS domain name portion
      of "voice.example.edu" and an application type of "sip" (mapping
      to an application protocol of SIP as explained in [SIP-CERTS]).

###

Again, those are all proposals. Ben, let us know if those address your
questions. Jeff, let me know if you disagree with your co-author. :)

Peter

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