Re: Discussion of 6.1 for LC June

On 2008-03-07 08:58:55 -0500, Mary Ellen Zurko wrote:

> Issue 4) remove must on displaying CA or keep only for installed trust 
> roots 
> 
> The term [Definition: validated certificate ] is used to denote a public 
> key certificate that has been verified by chaining up to a locally 
> configured trust anchor. The set of trust anchors used by a given Web User 
> agent is implementation-dependent.
> We have text about not allowing the user to configure local trust anchors 
> when they're doing something else.
> We have text about pinning SSC (but not how that relates to a local trust 
> anchor)

We have text that says explicitly that SSCs are *never* validated
certificates.

> Issue 6) need to allow for o= not being present
> MUST include the Subject field's Organization attribute 
> 
> Proposal
> MUST include the Subject field's Organization attribute, if present,

This is for AA certificates, and I'm wondering if "if present" is
the right resolution here.  The basic point here is "show the
human-readable name of the certificate subject".  The very point of
AA certificates is to have that information *somewhere*.

So, I'd suggest that the section on AA certificates asserts this
property as a condition of AA-ness, spells out the sequence of
attributes to use for deriving the human readable name, and we then
refer back to that for the identity signal content.

If there is no human readable name of the certificate subject, then
we declare the certificate non-augmented-assurance, and handling for
domain validated certificates applies.

> Issue 7) objections to "unless a change of security level" -
> we've dropped that concept anyway - it shoudl be removed, leading
> to: During interactions with a Web page for which any of the
> resources involved was retrieved through a weakly TLS-protected
> transaction, the identity signal must be indistinguishable from
> one that would be shown for an unprotected HTTP transaction.

I've played a bit more with this piece of text, and propose the
following instead:

	During interactions with a Web page for which any of the
	resources involved was retrieved through a weakly
	TLS-protected or unprotected transaction, the identity
	signal MUST NOT include any positive trust indicators
	exceeding those in use for unprotected HTTP transactions. In
	this situation, the identity signal MAY include indicators
	that point out any error conditions that occurred.

This moves away a little bit from the consistency notion, and also
keeps the door open for some more error signalling.  Let me know
what you think.

> Please send any updates and reactions by Wednesday, the 12th (we
> have no meeting then, so you can use that time on this). I'll
> develop a logical sequence of proposals for a meeting for us to
> work through these to come to some text in 6.1 that we have
> consensus on. 

Finally, I've shuffled the text in 6.1.2 a bit, and organized it by
connection type.  That should make it easier to quickly understand
what parts belong together; I hope it makes our discussion a bit
easier.  In particular, the conditions about interactions only occur
once, each. :)

Web Security Context: Experience, Indicators, and Trust
Editor's Draft 8 March 2008
$Revision: 1.187 $ $Date: 2008/03/08 12:58:50 $

http://www.w3.org/2006/WSC/drafts/rec/#IdentitySignal

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Saturday, 8 March 2008 13:17:35 UTC