Re: URLs and TLS

[Mike Macgirvin <MAX@xxxxxxxxxxxx>]

> Here's an initial strawman to shoot at:
> 
> If a URL includes a ";TLS=" parameter after the user name, that means TLS
> support is required to resolve that URL.  My initial proposal for values
> of this parameter is as follows:
> 
> anon       Anonymous encryption must be used to prevent passive attacks (?)
> integrity  Server-side authentication and integrity protection must be used
> privacy    Server-side authentication and encryption must be used
> auth       Server and client certs must be used to mutually authenticate
>            via TLS (takes precedence over any ";AUTH=" parameter) and
>            integrity protect the session.
> full       Same as "auth", except encryption must also be used.
> 
> Resolution of the URL fails if the security requirements in the URL
> can't be met.  The client is free to use a higher level of TLS facilities
> than the URL specifies.

This may not be quite sufficient to adequately specify the desired policy.
Perhaps an additional minimum cipher length would be useful. 

	;MINCIPHER=

	with the most commonly used values being: 128, 40 and 0. 

0 (or unspecified) means whatever can be agreed on, and doesn't guarantee
that any encryption will occur. No doubt this will raise calls to include
the entire cipher list; which may be the only way to completely specify the
connection, but I'll toss it out as a counter strawman anyway. I'd hate to
saddle the URL with something like 

TLSCIPHERS=+rsa_rc4_128_md5,+rsa_3des_sha,+rsa_des_sha,+rsa_rc4_40_md5,+rsa_rc2_40_md5

begin:          vcard
fn:             Mike Macgirvin
n:              Macgirvin;Mike
org:            Netscape Communications Corporation
adr:            Mail Stop MV029;;501 E. Middlefield Road;Mountain View;California;94043;USA
email;internet: MAX@xxxxxxxxxxxx
title:          Postmaster General
tel;work:       (650) 937-3798
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard