Re: petname implementation recommendation proposal

Sorry to ask a question that seems indirectly related to this thread, but it
seems like a good place to ask a process question.
It seems that we've been able to successfully raise technical issues against
proposals (e.g., how to bind a petname to a public key).  This is good as it
results in discussion and then iteration of the proposal.  But we do not see
as many usability issues being raised against the proposals.  For example,
with petnames, I think before we even debate implementation details, I would
question the cognitive burden that it places on users.  It requires the user
to take extra effort in coming up with a petname for a site, entering it,
and then noticing and recognizing it in the future.  This is not
"cognitively scalable".

Would it be helpful if we raised usability concerns as "issues" against
proposals, rather than having them live on a lonely page on the wiki?

and Tyler, forgive me for using your proposal as an example, but I think
I've made these points before.  You deserve lots of credit for being
innovative, responding to the group's concerns and iterating.

Rachna

On Fri, Mar 14, 2008 at 4:23 PM, Close, Tyler J. <tyler.close@hp.com> wrote:

>
>
> I wrote:
> > 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?
>
> I've worked up a rough outline of what a petname implementation
> recommendation could look like. Since looking at information in an X.509certificate other than the host identifier generates controversy, I'll
> instead propose a petname implementation that relies solely on this
> information:
>
> If the current web page is "strongly TLS-protected", the user may assign
> the authenticated entity a petname. If the web page uses a "validated
> certificate", this assignment MUST create a binding from the petname to each
> of the host identifiers the certificate is valid for. These identifiers are
> found in the CN attribute and the subjectAltNames attribute, as specified by
> HTTPS. If the web-page uses a pinned self-signed certificate, this
> assignment MUST ONLY create a binding from the petname to the pinned
> destination.
>
> When browsing a "strongly TLS-protected" web page, the petname
> presentation MUST present the petname corresponding to the host identifier
> specified by the dereferenced URL.
>
> When comparing host identifiers, the petname presentation implementation
> MUST use the same algorithm used by HTTPS, in particular, a wildcard match
> MUST be supported where HTTPS would support it.
>
> The petname presentation MUST support renaming and deletion of a petname
> binding.
>
> When the user assigns a petname, the petname presentation implementation
> MUST warn the user if the chosen petname is similar to one currently in use.
> The meaning of similar is up to the implementation, but MUST at least
> include an identical petname.
>
> --Tyler
>
>