On Dec 8, 2010, at 1:50 PM, =JeffH wrote: > <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". > >
WFM > >> 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". That's pretty much what I had in mind, although the URI is more complex that you are likely to see as user input. just "sip:[email protected]" would probably get the idea across. > > > ? > > =JeffH > > > _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
