On 12/8/10 12: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".
After an IM chat with Jeff, I agree. >>> 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:p...@example.net;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. Looks good. I love gnarly URIs. :) > Also, given an > input URI of "im:al...@example.net", 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". Well, the im: and pres: URIs can result in a derived service type of "xmpp", too. It depends on what a service has deployed... http://tools.ietf.org/html/rfc3860 http://www.iana.org/assignments/im-srv-labels/im-srv-labels.xhtml Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
