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

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

Regarding NAPTR...

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

> -- 1.4.2, 2nd bullet item: "We also do not address identifiers
> derived from Naming Authority Pointer (NAPTR) DNS resource records
> [NAPTR] and related technologies such as [S-NAPTR], since such
> identifiers cannot be validated in a trusted manner in the absence of
> [DNSSEC]."
> 
> Does that mean validation of a source domain that will be used to
> construct a NAPTR request is out of scope, or just validation against
> the result of a NAPTR query? (I note SIP may require the first).

Ben, the current text in the I-D is lame. The points we were trying to
make, but poorly, are that (1) there are no identifiers for NAPTR
records, as there are for SRV records, and (2) from the perspective of
this spec it doesn't really matter how you get from the source domain to
the IP address you use for communication (perhaps you do the A/AAAA
one-step, the SRV two-step, or the NAPTR three-step, but that's
immaterial for the purpose of identity checking).

Point #1 is close to obvious, so I suggest that we remove the offending
sentence and add this paragraph near the end of Section 1.4.2:

   Although the process whereby a client resolves the DNS domain name of
   an application service can involve several steps (e.g., this is true
   of resolutions that depend on DNS SRV resource records, Naming
   Authority Pointer (NAPTR) DNS resource records [NAPTR], and related
   technologies such as [S-NAPTR]), for our purposes we care only about
   the fact that the client needs to verify the identity of the entity
   with which it communicates as a result of the resolution process.
   The resolution process itself is out of scope.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 07 Dec 2010 15:14:29 -0700

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:[email-masked] and sips:[email-masked]) 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
   "[email-masked]" 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/

---

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Dec 2010 18:10:08 -0600

I'm jumping in a bit late with some review followup. It's not entirely clear to me where in the thread I should re-insert myself, so I apologize if I bring up stuff that would have been resolved or otherwise obvious at other points in the thread--I'll dig back through and respond further as appropriate.

(And I realize I'm doing lots of arm-waving around whats-really-going-on with URI-IDs and SIP. If we need a higher bandwidth communication, I can be available.)

Comments inline:

> uniformResourceIdentifier SAN.

Understood. It may be that the answer is that the use of URI-ID is not sufficiently understood to offer general guidance. OTOH, in the case of SIP, the URI-ID appears to be solely for the purpose of binding a domain name to the service. Otherwise, the use as defined in RFC5922 would be substantially identical to using a DNS-ID. More to the point, RFC5922 does not use URI-ID to specify a user identity, only a host identity. Would you recommend designers of a new protocol to follow that pattern? I note that (unless I missed it) the 5922 doesn't seem to allow for falling back to a dNSName. Is that a reasonable choice for a new protocol to make? (And doesn't this feel a lot like using SRV-IDs?)

Now compare that to HTTP using a DNS-ID. The two are trying to accomplish the same thing, in that they are identifying a domain name, not a resource (in the case of HTTP) or a user (in the case of SIP). Can we generalize anything from that? If we were starting over with either, would we recommend HTTP use URI-ID, or perhaps SIP should not?

I almost wonder if the best thing would be a discussion of what you might could do with URI-ID, with very little normative stuff. If you want to identify a host and service only, here's how. If you want to identify something more like a resource, then do this other thing (or say it''s out of scope). 

> so that's a further SIP-specific wrinkle.

Yeah, that's an interesting one. On reflection, I think RFC 5922 is, again, trying to match  _service_ more than a URI scheme. The service is "sip" regardless of whether you started with a SIPS URI.   When you consider the further complication of TEL URIs (e.g. tel:+18005551212), you're _still_ looking for a SIP service. This is pretty much what I think you had in mind in the section 4.3 text on URI_IDs, except that the service is implied by the fact that its a SIP application in the first place, rather than simply copied from some specific URI. 

If this is the correct interpretation of 5922, then the SIPS/SIP equivalence is probably a red herring.  I'd certainly be interested to hear the RFC 5922 author's thoughts on that.

For that matter, I think that XMPP and SIP both needed to accomplish the same thing--match a source domain name and a service. Both SRV-IDs and URI-IDs can do that, but they made opposite choices. I suspect the choices were along the lines of "XMPP doesn't _use_ URIs, and SIP does". But it doesn't seem like SIP is really matching against a URI . And you could just as easily synthesize an XMPP scheme and use URI-IDs--but the awkwardness becomes more obvious there.

> "customers" of the server-id-check specification).

Right. But this document endeavors to recommend what people should put in their specs for future protocols, right? Or does it just discuss things they need to think about in their specs? I meant the SIP questions as examples. They would probably been better stated as "What should the new FUBAR protocol, which uses URIs and DNS in a way functionally identical to SIP, do?"

The bottom line is, should this draft offer guidance on the best way to match a source domain and service? Or is it to say "here's some ways you can do it, pick one (or some)." I'm okay either way, but it would be best to be explicit.

> difference how many steps are contained in the resolution process. See

I agree, that's the way it is supposed to work for SIP. Do you think that it would be obvious to the hypothetical FUBAR designers whether they should do the same? (I'm not saying it's not--I would need to reread the draft with that in mind, and haven't done so yet.)

> URI-ID type is not all that different from the others.

Is it your expectation that no protocol should try to include other, more resourcey parts of a URI for the purposes of cert matching? Or that that sort of thing should be out of scope?

> re-uses the recommendations in the server-id-check document?

The second, keeping in mine that new scheme design often happens as a part of such an effort, even if the documents are split. (Would cert matching be scheme specific, or protocol specific?)

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

 Recommendations about how to choose between DNS-ID, SRV-ID, and URI-ID would be out of scope for this document, then, right? I think that answers my previous question about how much the draft tries to recommend.

>       considered equivalent (e.g., http and https, or sip and sips as

Given the previous conversation about how SIP seems to be the only protocol with the equivalent scheme issue that actually uses URI-IDs, and that it doesn't seem to need to worry about which scheme its using at the moment, I no longer think this draft needs to worry about it. If it were to say anything at all along those lines, it would probably need to be along the lines of KISS. For example, I don't think you want designers trying to assert security properties by which scheme they include in a cert (i.e. "foo" vs "foos")

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

No, I think that's a good one based on the discussion so far. (assuming I am correct in my understanding that you don't expect to ever see protocols match on user or resource information inside the URI.) It might be worth mentioning in the example why the "user@" part is not used.

>   unexpected application service.

WFM

>   identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]).

Would it make sense to say something to indicate this is true, even though the connection may have been opened based on a URI of "sip:[email-masked]"? (I'm trying to figure out the best way to word that without trying to invoke SIP request-URI vs route set complexities, but my brain is tired. I will think further about it.)

> have a URI-ID example for HTTP.

Sure, the reason HTTP does not use is because HTTP isn't specified that way :-)  (i.e. for historical reasons.)

>       (e.g., http and https, or sip and sips as described in

I think this is pretty close, modulo previous comments above. I wonder if the fact that SIP appears to abstract the scheme rather than use the scheme of any particular URI is relevant here, or just adds too much complexity to the language.

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

Ah, okay. I was mainly picking on URI-IDs due to the lack of examples elsewhere. But more examples (almost) never hurt.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Dec 2010 18:14:41 -0600

WFM, thanks.

On Dec 7, 2010, at 1:29 PM, Peter Saint-Andre wrote:

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

---

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

Thanks, Ben.

In general, I think this document is describing the tools available to
protocol designers, not telling protocol designers which tools to use.

More comments inline.

On 12/7/10 5:10 PM, Ben Campbell wrote:
> I'm jumping in a bit late with some review followup. It's not
> entirely clear to me where in the thread I should re-insert myself,
> so I apologize if I bring up stuff that would have been resolved or
> otherwise obvious at other points in the thread--I'll dig back
> through and respond further as appropriate.
> 
> (And I realize I'm doing lots of arm-waving around
> whats-really-going-on with URI-IDs and SIP. If we need a higher
> bandwidth communication, I can be available.)
> 
> Comments inline:
> 
>> 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.
>> 
>> 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.
>> 
> 
> Understood. It may be that the answer is that the use of URI-ID is
> not sufficiently understood to offer general guidance. OTOH, in the
> case of SIP, the URI-ID appears to be solely for the purpose of
> binding a domain name to the service. Otherwise, the use as defined
> in RFC5922 would be substantially identical to using a DNS-ID. More
> to the point, RFC5922 does not use URI-ID to specify a user identity,
> only a host identity. Would you recommend designers of a new protocol
> to follow that pattern? 

Well, this document is about host ("application service") identity, so
user identity is conveniently out of scope.

> I note that (unless I missed it) the 5922
> doesn't seem to allow for falling back to a dNSName. Is that a
> reasonable choice for a new protocol to make? 

I think not. IMHO the fallback is a good idea.

> (And doesn't this feel
> a lot like using SRV-IDs?)

Yes.

> Now compare that to HTTP using a DNS-ID. The two are trying to
> accomplish the same thing, in that they are identifying a domain
> name, not a resource (in the case of HTTP) or a user (in the case of
> SIP). Can we generalize anything from that? If we were starting over
> with either, would we recommend HTTP use URI-ID, or perhaps SIP
> should not?
> 
> I almost wonder if the best thing would be a discussion of what you
> might could do with URI-ID, with very little normative stuff. If you
> want to identify a host and service only, here's how. 

Yes, and I think that's what our text is doing. Or trying to.

> If you want to
> identify something more like a resource, then do this other thing (or
> say it''s out of scope).

The latter.

>>> -- [ 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:
>> 
>> (e.g., sip:[email-masked] and sips:[email-masked]) 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".
>> 
>> 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.
> 
> Yeah, that's an interesting one. On reflection, I think RFC 5922 is,
> again, trying to match  _service_ more than a URI scheme. The service
> is "sip" regardless of whether you started with a SIPS URI.   When
> you consider the further complication of TEL URIs (e.g.
> tel:+18005551212), you're _still_ looking for a SIP service. This is
> pretty much what I think you had in mind in the section 4.3 text on
> URI_IDs, except that the service is implied by the fact that its a
> SIP application in the first place, rather than simply copied from
> some specific URI.
> 
> If this is the correct interpretation of 5922, then the SIPS/SIP
> equivalence is probably a red herring.  I'd certainly be interested
> to hear the RFC 5922 author's thoughts on that.
> 
> For that matter, I think that XMPP and SIP both needed to accomplish
> the same thing--match a source domain name and a service. Both
> SRV-IDs and URI-IDs can do that, but they made opposite choices. I
> suspect the choices were along the lines of "XMPP doesn't _use_ URIs,
> and SIP does". But it doesn't seem like SIP is really matching
> against a URI . And you could just as easily synthesize an XMPP
> scheme and use URI-IDs--but the awkwardness becomes more obvious
> there.

Yes, we really care about the combination of DNS domain name and
application type. That can be represented via SRV-IDs or URI-IDs.

>>> 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).
> 
> Right. But this document endeavors to recommend what people should
> put in their specs for future protocols, right? Or does it just
> discuss things they need to think about in their specs? I meant the
> SIP questions as examples. They would probably been better stated as
> "What should the new FUBAR protocol, which uses URIs and DNS in a way
> functionally identical to SIP, do?"
> 
> The bottom line is, should this draft offer guidance on the best way
> to match a source domain and service? Or is it to say "here's some
> ways you can do it, pick one (or some)." I'm okay either way, but it
> would be best to be explicit.

I think we're saying "here's some ways you can do it, pick one" (either
SRV-ID or URI-ID, with DNS-ID as a fallback).

>>> 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?)
>> 
>> 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 agree, that's the way it is supposed to work for SIP. Do you think
> that it would be obvious to the hypothetical FUBAR designers whether
> they should do the same? (I'm not saying it's not--I would need to
> reread the draft with that in mind, and haven't done so yet.)

This document says "if you use a SRV-ID (or URI-ID or DNS-ID), here's
how to represent and verify it".

>>> 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:
>> 
>> ###
>> 
>> into its DNS domain name portion and its application type portion,
>> as follows:
>> 
>> [...]
>> 
>> 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 
>> 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]).
>> 
>> ###
>> 
>> portion as specified in server-id-check document. So I think that
>> the URI-ID type is not all that different from the others.
> 
> Is it your expectation that no protocol should try to include other,
> more resourcey parts of a URI for the purposes of cert matching? Or
> that that sort of thing should be out of scope?

I think it should be out of scope.

Let's imagine that the HTTP community decided to use URI-IDs. Even if
the URI-ID in a certificate were http://www.example.com/foobar.html, a
client would need to connect to the IP address resolved for
www.example.com in order to retrieve foodar.html. Here again, it's the
application service that matters.

>> (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?
> 
> The second, keeping in mine that new scheme design often happens as a
> part of such an effort, even if the documents are split. (Would cert
> matching be scheme specific, or protocol specific?)
> 
>> 
>> 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:
>> 
> Recommendations about how to choose between DNS-ID, SRV-ID, and
> URI-ID would be out of scope for this document, then, right? I think
> that answers my previous question about how much the draft tries to
> recommend.

Yes, we were not thinking that this document would provide guidelines
about how protocol designers would choose between identifier types.

>>> -- 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:
>> 
>> 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]).
> 
> Given the previous conversation about how SIP seems to be the only
> protocol with the equivalent scheme issue that actually uses URI-IDs,
> and that it doesn't seem to need to worry about which scheme its
> using at the moment, I no longer think this draft needs to worry
> about it. If it were to say anything at all along those lines, it
> would probably need to be along the lines of KISS. For example, I
> don't think you want designers trying to assert security properties
> by which scheme they include in a cert (i.e. "foo" vs "foos")

Well, I do think a using protocol does need to specify which URI scheme
names are acceptable for the application protocol. You wouldn't want a
client to think that fubar://example.com identifies a SIP service. The
tel: URI scheme is an interesting counter-example in some ways.

>> (But see below, where I propose further modifications to that
>> paragraph to address another issue you've raised.)
>> 
>>> -- section 3.2:
>>> 
>> <sip:voice.example.edu>.  A certificate for this service would
>> include a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]).
>> 
> No, I think that's a good one based on the discussion so far.
> (assuming I am correct in my understanding that you don't expect to
> ever see protocols match on user or resource information inside the
> URI.) It might be worth mentioning in the example why the "user@"
> part is not used.

Because [email-masked] is not an application service. :)

>>> 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.
>> 
> 
> WFM
> 
>>> -- 4.2.2:
>>> 
>> 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]).
>> 
> 
> Would it make sense to say something to indicate this is true, even
> though the connection may have been opened based on a URI of
> "sip:[email-masked]"? (I'm trying to figure out the best way
> to word that without trying to invoke SIP request-URI vs route set
> complexities, but my brain is tired. I will think further about it.)

What do you mean by "the connection was opened based on a URI of
sip:[email-masked]"? Yes, the client might know that it is
configured for an account with that URI, but in order to communicate
with the application service it will need to resolve the DNS domain name
(and application type) to an IP address. So that's the reference
identifier. The presented identifier in the certificate will also be of
the form sip:domain, not sip:user@domain.

>>> (and maybe an explanation why the HTTP example doesn't use one?)
>> 
>> Specifically, we might need to say "programatically associated with
>> a URI for security purposes" or somesuch.
>> 
>> technologies use PKIX certificates, so it would be improper for us
>> to have a URI-ID example for HTTP.
> 
> Sure, the reason HTTP does not use is because HTTP isn't specified
> that way :-)  (i.e. for historical reasons.)

Yep. :)

>> 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]).
> 
> I think this is pretty close, modulo previous comments above. I
> wonder if the fact that SIP appears to abstract the scheme rather
> than use the scheme of any particular URI is relevant here, or just
> adds too much complexity to the language.

My first thought it that it adds too much complexity, but I'll consider
it further tomorrow.

> Ah, okay. I was mainly picking on URI-IDs due to the lack of examples
> elsewhere. But more examples (almost) never hurt.
> 
>> 
>> ###
>> 
>> into its DNS domain name portion and its application type portion,
>> as follows:
>> 
>> 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).
>> 
>> 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]).
>> 
>> 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 
>> 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. :)

Feedback is welcome on that text.

Peter

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

---

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

> protocol designers, not telling protocol designers which tools to use.

Okay, then :-)

On re-reading the thread, I realize I did a lot of dead-horse beating. Further comments below, with the areas I think we are in agreement elided. 

[...]

> user identity is conveniently out of scope.

Okay

> I think not. IMHO the fallback is a good idea.

But, from previous comments, such guidance does not belong in this draft, right?

[...]

> tel: URI scheme is an interesting counter-example in some ways.

Not to mention "im:" and "pres:" :-)

Am I correct in assuming you mean that in the context of what schemes they will put in a certificate, or match to a certificate, right? As opposed to what schemes are legal in the application protocol as a whole--since these are probably somewhat separate dimensions of extensibility. (If the second, then I'm in over my depth in meta-protocol design, and would certainly defer to an apps area expert if one were handy ;-)  )

[...]

> the form sip:domain, not sip:user@domain.

Sure, and I guess what I am talking about is how one derives a reference identifier of sip:voice.example.edu from an address of record (AoR) of sip:[email-masked]. For example, I click on the AoR on a web page, or I type it from Mr. User's business card. I guess my point is it would be useful for the example to show that, given the URI of a _resource_, you derive (extract?) a URI of a _service_ to be the reference entry. You've mentioned that in text, but it would be useful for the example to show it as well.

[...]

> My first thought it that it adds too much complexity, but I'll consider

Okay. I can't off-hand think of a simple way to put it, so you are probably right. 

[...]

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Dec 2010 08:45:48 -0700

[further elided]

On 12/7/10 10:44 PM, Ben Campbell wrote:
>>> I note that (unless I missed it) the 5922 doesn't seem to allow
>>> for falling back to a dNSName. Is that a reasonable choice for a
>>> new protocol to make?
>> 

I think that's right.

>>> Given the previous conversation about how SIP seems to be the
>>> only protocol with the equivalent scheme issue that actually uses
>>> URI-IDs, and that it doesn't seem to need to worry about which
>>> scheme its using at the moment, I no longer think this draft
>>> needs to worry about it. If it were to say anything at all along
>>> those lines, it would probably need to be along the lines of
>>> KISS. For example, I don't think you want designers trying to
>>> assert security properties by which scheme they include in a cert
>>> (i.e. "foo" vs "foos")
>> 
>> Well, I do think a using protocol does need to specify which URI
>> scheme names are acceptable for the application protocol. You
>> wouldn't want a client to think that fubar://example.com identifies
>> a SIP service. The tel: URI scheme is an interesting
>> counter-example in some ways.
> 
> Am I correct in assuming you mean that in the context of what schemes
> they will put in a certificate, or match to a certificate, right? 

Correct. I think this text is clearer in Section 3.1:

   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
       which URI schemes are to be considered acceptable in URI-IDs
       contained in PKIX certificates used for the application protocol
       (e.g., "sip" but not "sips" or "tel" for SIP as described in
       [SIP-SIPS], or perhaps http and https for HTTP as might be
       described in a future specification).

> As
> opposed to what schemes are legal in the application protocol as a
> whole--since these are probably somewhat separate dimensions of
> extensibility. (If the second, then I'm in over my depth in
> meta-protocol design, and would certainly defer to an apps area
> expert if one were handy ;-)  )

Yeah, let's avoid that rat-hole. :)

>>>> 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]).
>>>> 
>>> 
>>> Would it make sense to say something to indicate this is true,
>>> even though the connection may have been opened based on a URI
>>> of "sip:[email-masked]"? (I'm trying to figure out the
>>> best way to word that without trying to invoke SIP request-URI vs
>>> route set complexities, but my brain is tired. I will think
>>> further about it.)
>> 
>> configured for an account with that URI, but in order to
>> communicate with the application service it will need to resolve
>> the DNS domain name (and application type) to an IP address. So
>> that's the reference identifier. The presented identifier in the
>> certificate will also be of the form sip:domain, not
>> sip:user@domain.
>> 
> 
> Sure, and I guess what I am talking about is how one derives a
> reference identifier of sip:voice.example.edu from an address of
> record (AoR) of sip:[email-masked]. For example, I click on
> the AoR on a web page, or I type it from Mr. User's business card. I
> guess my point is it would be useful for the example to show that,
> given the URI of a _resource_, you derive (extract?) a URI of a
> _service_ to be the reference entry. You've mentioned that in text,
> but it would be useful for the example to show it as well.

Isn't that a matter for the application protocol?

I want to authenticate with my IMAP server as [email-masked], so
my client needs to figure out which DNS domain name(s) it will attempt
to resolve in order to communicate with the right IMAP server (perhaps
the client checks its configuration or simply chops off the "user@" from
the front). The result of that process is the source domain that's used
as input to the verification procedures described in this I-D. It seems
to me that the same goes for XMPP, SIP, etc.

In Section 1.2 define source domain as:

   source domain:  The fully-qualified DNS domain name that a client
      expects an application service to present in the certificate
      (e.g., "www.example.com"), typically input by a human user,
      configured into a client, or provided by reference such as in a
      hyperlink.  The combination of a source domain and, optionally, a
      service type enables a client to construct one or more reference
      identifiers.

In Section 2.1 we say:

   From the perspective of the application client or user, some names
   are direct because they are provided directly by a human user (e.g.,
   via runtime input, prior configuration, or explicit acceptance of a
   client connection attempt) whereas other names are indirect because
   they are automatically resolved by the client based on user input
   (e.g., a target name resolved from a source name using DNS SRV
   records).  This dimension matters most for certificate consumption,
   specifically verification as discussed in this document.

In Section 4.2.1 we say:

   The inputs used by the client to construct its list of reference
   identifiers might be a URI that a user has typed into an interface
   (e.g., an HTTPS URL for a web site), configured account information
   (e.g., the domain name of a particular host or URI used for
   retrieving information or connecting to a network, which might be
   different from the server portion of the user's account name), a
   hyperlink in a web page that triggers a browser to retrieve a media
   object or script, or some other combination of information that can
   yield a source domain and a service type.

Do you feel we need to say more about how an application client
determines the source domain? Is there something special about SIP AORs
that this document does not cover (but should be covering)?

Peter

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 8 Dec 2010 12:34:13 -0600

On Dec 8, 2010, at 9:45 AM, Peter Saint-Andre wrote:

[...]

WFM

[...]

> that this document does not cover (but should be covering)?

As you mention, 4.2.1 says "The inputs used by the client to construct its list of reference identifiers might be a URI that a user has typed into an interface..." and "The client might need to extract the source domain and service type from the input(s) it has received."

In the case of SIP (and of HTTP if we pretended it used URI-IDs, that input as typed in by a user is likely to contain stuff that has to be stripped out of the reference identifier. For example, in SIP, this input is very likely to be the AoR of the person you want to call. i.e. a URI identifying a user. I am suggesting a soup to nuts example of how a real world input such as that gets converted to a resulting URI reference identity.

I don't think this is peculiar to SIP, other than due to the fact that SIP uses URI-IDs. If HTTP were to use URI-IDs, then you would have similar issues of getting from the URI as entered by a user to a source identifier in URI  form.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Dec 2010 12:44:40 -0700

>>>>>> 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]).
>>>>> 
>>>>> Would it make sense to say something to indicate this is
>>>>> true, even though the connection may have been opened based
>>>>> on a URI of "sip:[email-masked]"? (I'm trying to
>>>>> figure out the best way to word that without trying to invoke
>>>>> SIP request-URI vs route set complexities, but my brain is
>>>>> tired. I will think further about it.)
>>>> 
>>>> What do you mean by "the connection was opened based on a URI
>>>> of sip:[email-masked]"? Yes, the client might know that
>>>> it is configured for an account with that URI, but in order to 
>>>> communicate with the application service it will need to
>>>> resolve the DNS domain name (and application type) to an IP
>>>> address. So that's the reference identifier. The presented
>>>> identifier in the certificate will also be of the form
>>>> sip:domain, not sip:user@domain.
>>> 
>>> record (AoR) of sip:[email-masked]. For example, I click
>>> on the AoR on a web page, or I type it from Mr. User's business
>>> card. I guess my point is it would be useful for the example to
>>> show that, given the URI of a _resource_, you derive (extract?) a
>>> URI of a _service_ to be the reference entry. You've mentioned
>>> that in text, but it would be useful for the example to show it
>>> as well.
>> 
>> I want to authenticate with my IMAP server as
>> [email-masked], so my client needs to figure out which DNS
>> domain name(s) it will attempt to resolve in order to communicate
>> with the right IMAP server (perhaps the client checks its
>> configuration or simply chops off the "user@" from the front). The
>> result of that process is the source domain that's used as input to
>> the verification procedures described in this I-D. It seems to me
>> that the same goes for XMPP, SIP, etc.
>> 
>> expects an application service to present in the certificate (e.g.,
>> "www.example.com"), typically input by a human user, configured
>> into a client, or provided by reference such as in a hyperlink.
>> The combination of a source domain and, optionally, a service type
>> enables a client to construct one or more reference identifiers.
>> 
>> In Section 2.1 we say:
>> 
>> are direct because they are provided directly by a human user
>> (e.g., via runtime input, prior configuration, or explicit
>> acceptance of a client connection attempt) whereas other names are
>> indirect because they are automatically resolved by the client
>> based on user input (e.g., a target name resolved from a source
>> name using DNS SRV records).  This dimension matters most for
>> certificate consumption, specifically verification as discussed in
>> this document.
>> 
>> In Section 4.2.1 we say:
>> 
>> (e.g., an HTTPS URL for a web site), configured account
>> information (e.g., the domain name of a particular host or URI used
>> for retrieving information or connecting to a network, which might
>> be different from the server portion of the user's account name),
>> a hyperlink in a web page that triggers a browser to retrieve a
>> media object or script, or some other combination of information
>> that can yield a source domain and a service type.
>> 
>> determines the source domain? Is there something special about SIP
>> AORs that this document does not cover (but should be covering)?
> 
> As you mention, 4.2.1 says "The inputs used by the client to
> construct its list of reference identifiers might be a URI that a
> user has typed into an interface..." and "The client might need to
> extract the source domain and service type from the input(s) it has
> received."
> 
> In the case of SIP (and of HTTP if we pretended it used URI-IDs, that
> input as typed in by a user is likely to contain stuff that has to be
> stripped out of the reference identifier. For example, in SIP, this
> input is very likely to be the AoR of the person you want to call.

This is what I don't understand.

Let's say you are sip:[email-masked] and I am sip:[email-masked].
Why does my client need to resolve nostrum.com in order to communicate
with you? It seems to me that my client needs to resolve stpeter.im and
then connect to that as my "home" server on the SIP network. My server
then does the work of routing signalling traffic from stpeter.im to your
server at nostrum.com, but my client doesn't communicate directly with
nostrum.com because I'm not registered there.

(I freely grant that my understanding might be based on email and XMPP,
whereas SIP might have a different architecture.)

> i.e. a URI identifying a user. I am suggesting a soup to nuts example
> of how a real world input such as that gets converted to a resulting
> URI reference identity.

Yes, examples always help.

> I don't think this is peculiar to SIP, other than due to the fact
> that SIP uses URI-IDs. If HTTP were to use URI-IDs, then you would
> have similar issues of getting from the URI as entered by a user to a
> source identifier in URI  form.

In the case of HTTP, my client (browser) is going to pull out the
"authority" component of the URI:

http://www.example.com/foobar.html => www.example.com

But I think we already say that in Section 4.2.1:

See also Section 4.3:

However, perhaps we need to say more in Section 4.2.1, including some
examples?

Peter

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

---

From: Ben Campbell <[email-masked]>
Date: Wed, 8 Dec 2010 15:30:52 -0600

[...]

> nostrum.com because I'm not registered there.

It could work either way. It's common for me to have a service that I send outbound requests through, but it's not required by the protocol or the architecture so much as it is an artifact of pesky NATs and SBCs.   But even if you do connect via your own service, some device in the "stpeter.im" service is going to eventually have to connect to the "nostrum.com" service. It does that based on the original user input of "sip:[email-masked]".

> whereas SIP might have a different architecture.)

Even for XMPP and email, something in your service would eventually have to connect to something in my service, based on my JID or email address. 

HTTP might be a better example. If I enter "https://stpeter.im/index.php/2010/11/17/another-xmpp-wg-update/" into my browser, it by default attempts to form a TLS connection directly to speter.im.  (Too bad HTTP doesn't use URI-IDs, since it would make an easier to understand example than SIP.)

>      to an application protocol of SIP as explained in [SIP-CERTS]).

Most of that text is specification, not example. The example in 4.3 is trivial in the sense that all that the source URI contained was the scheme and the authority. The implementation basically had to cut out a colon :-)

> However, perhaps we need to say more in Section 4.2.1, including some

I think 4.2.1 says the right things as far as the specification language goes. Perhaps merely expanding the example in 4.3 bullet 4 to u say something along the lines of "A SIP Address of Record of "sip:[email-masked]" would yield a DNS domain portion of "voice.example.edu" and an application type of "sip", yielding a URI-ID of "sip:voice.example.net"

Alternately, a URI-ID example in 4.2.2 could work, although I realize none of the other examples in that section start with the raw user input.