Thomas Roessler wrote:
> On 2008-03-07 16:12:57 +0000, Web Security Context Working Group
> Issue Tracker wrote:
>
> > I propose adding petname to the recommendations in 6.1.
> > Specifically, the petname definition from the following email:
>
> > http://lists.w3.org/Archives/Public/public-wsc-wg/2008Mar/0025.html
>
> > with this normative text added to 6.1.2:
>
> > Information displayed in the identity signal MAY include a petname.
>
> Reviewing Tyler's message, I notice that this petname definition is
> (unlike what we have in the safe form bar) not currently tied to any
> certificates.
There are a couple reasons for this. The action only asked for a definition of a petname, not an implementation recommendation for X.509 certificates, so that's all I did. I also didn't venture beyond a definition because the implementation strategy I proposed generated controversy over the way it correlates certificate chains. Do we want to try to reach consensus on a petname <=> X.509 cert chain binding, or leave that to implementers?
> So, for inclusion with 6.1.2:
>
> - Under what conditions should petnames, if present, be displayed?
>
> - Do we want to say anything about what the presence of petnames
> should be keyed on?
>
> One direction could be the following:
>
> - Display when strong TLS (including "pinned" SSCs), don't display
> when weak TLS (including unpinned SSCs)?
>
> - Key off domain name and/or certificate that's used.
>
> Note, incidentally, that this would help us fill another gap in
> 6.1.2 (that I'm realizing got introduced -- but rightly so -- when I
> cleaned up the relationship between validated and self-signed
> certificates): What do we do if there is strong TLS protection, but
> it doesn't involve a validated certificate?
Answering the above questions requires specifying the petname <=> X.509 binding. Are you saying the WG wants to try to put this in the first rec document? I'm willing to put a concrete proposal on the table, but will need some more time to do so. My memory of the last round of discussion is that the controversial techniques were: determining a correlation between cert chains based on reuse of a public key; and assuming the tuple (CA cert, end-entity DN - CN) is a GUID. I think there are still interesting proposals to be made that don't use these techniques. We could try another round of discussion on a proposal that doesn't use either of these techniques. Is that what you want to do?
--Tyler