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

[=JeffH <[e-mail]>]

<snip/>

 > stpete sez..
 >> 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.
 >>
 >>   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
                            ^^^^^^^^^^

I suggest we change this to "deriving".


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


BenC replies..
 >
<snip/>
 > 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.


So after the second para quoted above (from [S4.2.1]) how 'bout we add this..


For example, given an input URI of 
"sip:alice:[e-mail];transport=tcp?subject=project%20x&priority=urgent", 
the client derives the service type "sip" from the scheme, and the domain name 
"example.net" from the authority component. Also, given an input URI of 
"im:[e-mail]", the derived service type is "sip" (since the "im" 
scheme is defined as an abstract scheme in the SIP context by [SIP-IM] (RFC 
3428)), and the domain name is again "example.net".


?

=JeffH