- From: Thomas Roessler <tlr@w3.org>
- Date: Mon, 22 Dec 2008 16:51:03 +0100
- To: Anil Saldhana <Anil.Saldhana@redhat.com>
- Cc: WSC WG <public-wsc-wg@w3.org>
That would be ACTION-529, I think. I wonder whether this one is obsolete given the remarks in 5.1.5 done today, and the reference to Gutman's Internet-Draft. In any event, this point is only tangentially relevant to this thread -- what I meant is that we seem to be about to drop those pieces of the spec that are closest to any KCM-like ideas; I don't want us to do that unless we're positive that these things have no chance of being implemented before hell freezes over. ;-) Happy holidays, -- Thomas Roessler, W3C <tlr@w3.org> On 22 Dec 2008, at 16:38, Anil Saldhana wrote: > Thomas, > I have had a long outstanding action on KCM which I have not > performed because I am not fully sure that the references to KCM are > good. > > Regards, > Anil > > Thomas Roessler wrote: >> >> Hello, >> >> at the face-to-face on 10/23, we minuted a resolution to drop >> points 5.4.1B-F (and 5.1.5E along with them). >> >> That is, fundamentally, the material we have about Key Continuity >> Management. Looking at the minutes in more detail, I see that the >> discussion had this agreement as tentative, specifically pending >> feed-back from Johnathan. >> >> The text concerned is the following: >>> When, for a TLS-protected HTTP connection, the certificate chain >>> presented by the server does not lead to a trusted root >>> certificate, and the certificate chain presented was not pinned to >>> the destination at hand, the following applies to user agents that >>> are capable of storing and using information about certificates >>> that were previously encountered: >>> >>> • If a validated certificate (including an augmented assurance >>> certificate) was previously presented by the same destination, >>> then error signalling of class danger (6.4.4 Danger Messages) MUST >>> be used. >>> • If a different certificate was previously pinned to the same >>> destination, then error signalling of class warning or higher >>> (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages) MUST be >>> used. User agents MAY offer the possibility to pin the newly >>> encountered certificate to the destination at hand. >>> • Otherwise, user agents MAY use error signalling of class >>> notification (6.4.2 Notifications and Status Indicators ) to offer >>> pinning a given certificate, consistent with 5.1.5 Self-signed >>> Certificates and Untrusted Root Certificates. >>> • Otherwise, user agents SHOULD use error signalling of class >>> warning or higher (6.4.3 Warning/Caution Messages , 6.4.4 Danger >>> Messages). >> >> -- http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tlserrors >> >> Along with it goes the following language in the section on self- >> signed certificates: >> >>> If a client is able to automatically accept a self-signed >>> certificate, or recover from similar problem without user >>> interaction, it MUST support a mechanism to store and use >>> information about certificates that were previously encountered, >>> and to detect changes against historical usage of certificates as >>> described in more detail in section 5.4.1 TLS errors. >> >> -- http://www.w3.org/2006/WSC/drafts/rec/ >> rewrite.html#selfsignedcerts >> >> Given that the decision was minuted as a tentative one, I propose >> finalizing it on an upcoming conference call. >> >> Note that I'm commenting out the material in question in the next >> editor's draft. >> >> -- >> Thomas Roessler, W3C <tlr@w3.org> >> >> >
Received on Monday, 22 December 2008 15:51:13 UTC