RE: Signed/Encrypted Mail URL

Hi Larry,

	Finally got a few minutes to go through the
	draft recommendations.  I think I see the
	general approach, but it still does not
	solve my problem.

	Let's say I am running a website and I want
	to provide a mail link for users to send some sensitive
	data to me. I want to make sure that the email	
	agent generating/sending the mail message does two
	things:

1.	Sign the mail message (with appropriate warnings
	to the user as the signature could possibly be
	legally binding)
2.	Optionally encrypt the data with my public key

	I had originally thought that just adding new
	tags (like body) to the mailto URL would do the
	trick (same as the rescap solution).  It has
	the following advantages (in reference to this problem
	only):

1.	Backward compatibility (hopefully email clients will
	not burp on new tags)
2.	No new URL is needed

	However it has the disadvantage that, potentially email
	agents not recognizing the tags will not sign (or more
	importantly, not encrypt sensitive information) being sent
	to the server, and that is why my initial request for comments.

	The server in addition to identifying that the URL content
	needs to be signed/encrypted can:

	a)	Provide default cryptographic parameters
	or
	b)	Provide pointer to rescap server to pick up parameters from

	Requiring email clients to always use rescap to figure out what
	else to interpret on the URL is not very efficient (but that is
	a very minor quibble compared to email clients sending information
	in clear when I do not want them to).

	At this stage I am not even sure this is the right group
	to debate this issue.  Advice/comments/other solutions are
	welcome.

	regards

Amit


> 
> There's no reason why 'mailto:[email protected]' shouldn't
> send a signed and encrypted message, if there's mutual
> agreement about the preference to receive and the capability
> to send.
> 
> Negotiation about capabilities and preferences seems to
> be better handled in a protocol-dependent way, for HTTP
> using UPGRADE and for mail using RESCAP.
> 
> For the former, see draft-ietf-tls-http-upgrade-02.txt;
> for the latter, see draft-hoffman-rescap-mua-01.txt
> http://www.ietf.org/ietf/99mar/rescap-agenda-99mar.txt,
> draft-beck-rescap-req-02.txt, draft-hoffman-rescap-protocol-01.txt.
> 
> There's been a lot of pushback about creating new URL
> schemes that differ from the 'original' URL scheme only
> in the security parameters (https vs http), and an intent
> to not continue in that direction.
>