- From: Henrik Nordström <henrik@henriknordstrom.net>
- Date: Tue, 18 May 2010 01:26:39 +0200
- To: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Cc: "public-web-security@w3.org" <public-web-security@w3.org>
mån 2010-05-17 klockan 17:33 -0400 skrev Aryeh Gregor: > Is there any specific disadvantage to having it at the HTTP level? > The goal as it stands is HTTP-specific: all HTTP traffic should be > encrypted. A policy which is equally applicable to all protocols supporting both plain-text and TLS. HTTP, SMTP, IMAP, POP-3, LDAP, you name it. > If there is a need for a flag like this in non-HTTP contexts, I'd > think site operators would want to enable it separately for separate > protocols -- e.g., they might offer HTTPS but only offer unencrypted > SMTP. Not a problem for an DNS based approach. That would need to be done similar to how SRV records is done. For the certificate based approach it's more troublesome, but only if you strictly require encryption in some application protocol but view it as optional (not unavailable) in another application protocol and do not want a separate certificate per service. The use of TLS is negotiated service. > > SSL by atting a suitable attribute to certificate. > > Wouldn't this require that you get a new certificate from your CA if > you want to change your policy on STS (even, e.g., changing the > expiration)? Yes. But also means that you via your CA certify that you fulfill STS requirements. > I assume this would inevitably be nontrivial. Also, > wouldn't CAs have to support it, instead of just browsers? CAs have to agree on including the attribute in the signed data yes. Regards Henrik
Received on Monday, 17 May 2010 23:27:39 UTC