[whatwg] meta="encrypt" tag is needed

Fri May 7 10:06:26 PDT 2010

I was expecting criticism; as is unavoidable with all crypto issues.

You asked many questions, and unfortunately all you missed the  
auth="verisign" argument, which _is_ enough to prevent all practical  
(,even if they are all theoretical!,) man-in-the-middle attacks.

<html>
<head>
   <meta encrypt pubkey="ABABAEFEF2626EFEFEF" pubtool="EC256-AES"  
passsalt="colordev.com" auth="verisign"/>
</head>
<body>
   <form method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>">
   Username: <input type="text" name="user" /><br />
   Password: <input type="password" name="password" />
	<input type="submit" value="Submit" /><br />
   </form>
</body>
</html>

the above 'page' using the meta-encrypt tag, which is enough for a  
client browser to submit to site
a) a salted password
b) and a user name transported in encrypted form; over the internet

Maybe someone can show a _complete_ alternative Javascript & https  
solution about how those can be achieved in a computer or PDA-device  
without javascript support.

I am not suggesting replacing https with anything, government and  
business sites can and should keep on using it.  I am suggesting a  
small easy to use mini-encryption which would be enough for those 90%  
of sites should salt their passwords and encrypt sensitive data and  
but who currently aren't.

question 1:
> The server has to read and correctly parse each HTML page to decide
> whether to encrypt it? (And how does the browser know that the page is
> encrypted, vs. a legacy server that doesn't encrypt?)

answer 1:
Most servers are already configured to read the requested pages before  
submitting those over the internet. For example my above form-page has  
a small php-script inside which the server program must notice; as the  
PHP-program needs to compile the script. Client never sees the <?php  
echo $_SERVER['PHP_SELF']; ?> part but is instead shown an URL. To  
implement meta-encrypt tag would just require (on/off) configuring  
server program to read the header of requested page and see if there  
is a meta-encrypt tag in there the server calls a program which  
decrypts! the client submitted data.

Obviously you people will keep complaining, so what do you want to  
complain next
1) Man-in-the-middle problem; which doesn't exists because
	a) those are just academic mind games
	b) if auth="verisign" is used as external CA
2) HTTPS = good (even if it is typically NOT used with forms
3) password salting = webmasters duty to do it (which 50% forget),  
after using the HTTPS (which 90% forget)
4) Declaring encrypt action doesn't fit into HTML (; then why is there  
a form method get/post)

Juuso Hukkanen
www.colordev.com