Re: Drop material on KCM?

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:38:41 UTC