<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:[email protected];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:[email protected]", 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
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
