petname implementation recommendation proposal

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.509 certificate 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

Received on Friday, 14 March 2008 23:25:46 UTC