RE: ACTION-555: Proposed change to petnames

As discussed during today's telecon, I believe it's best to remove the current petname text from the rec document and instead simply include a mention and link to them in some non-normative section of the document. The latest iteration of the normative language doesn't define any constraints that site developers can rely upon when setting up their hostnames and certificates. The current text only serves as a notice that enough members of the WG believe in the utility of petnames and so want to include them in the document. I think it's better to just state that explicitly somwhere in the document rather than create an unreliable specification of what the implementation MAY be. There's a readily available implementation of petnames, with full source code, should a browser vendor be interested in the these details (https://addons.mozilla.org/en-US/firefox/addon/957).

I recommend we remove all references to petnames, other than the current section 8.4:

"8.4 Binding "human readable" names to domain names"
http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#security-considerations-petnames

The contained link to petnames should be changed from the document internal link to:

http://www.hpl.hp.com/techreports/2005/HPL-2005-148.html

This email should close out ACTION-650. As a result, I think ACTION-513 and ACTION-528, which were concerned with the current rec text, should be closed as no longer relevant.

--Tyler
 

> -----Original Message-----
> From: Thomas Roessler [mailto:tlr@w3.org] 
> Sent: Sunday, January 11, 2009 5:45 AM
> To: Close, Tyler J.
> Cc: WSC WG
> Subject: ACTION-555: Proposed change to petnames
> 
> Tyler,
> 
> here's my proposed text for the petnames chapter to take care 
> of the "base domain" notion; this addresses ISSUE-224 if you agree:
> 
> > 	<p>
> 
> > 	  For <termref def="def-secure-page">TLS-secured 
> pages</termref>, the 
> > user agent MAY allow the user to assign the authenticated entity a 
> > <termdef id="def-petname">petname</termdef>. This assignment MUST 
> > create a binding between the petname and the domain name 
> part of the 
> > URI that is dereferenced.  Implementations MAY instead choose to 
> > create this binding with a suffix of that domain part.  How such a 
> > suffix is determined is implementation-specific behavior.
> 
> > 	</p>
> 
> > 	<p>
> 
> > 	  Note: Some Web user agents attempt to determine the 
> minimum domain 
> > name suffix that is likely to represent an administrative 
> separation 
> > of domains.  E.g., for a domain name 
> <code>www.example.co.uk </code>, 
> > this suffix would be <code>example.co.uk</code>, while the 
> suffix for 
> > <code>www.example.com</code> would be <code>example.com</
> > code> <bibref ref="ref-effective"/>.  Implementations that use such
> > suffixes for other security decisions (e.g., to determine 
> the shortest 
> > possible suffix that  <code>document.location.href</code>
> > can be shortened to) should use the same mechanism to determine the 
> > suffix to which a petname can be bound.
> 
> > 	</p>
> 
> > 	<p>
> 
> > 	  Presentation of a petname MUST support renaming and 
> deleting of a 
> > petname binding.
> 
> > 	</p>
> 
> 
> The additional reference is this one:
> 
> > 	<bibl id="ref-effective" key="EFFECTIVE">
> > 	  <titleref ref="https://wiki.mozilla.org/ 
> > Gecko:TLD_Service">Effective TLD
> > 	  Service</titleref>, Mozilla Wiki, last checked on 
> 2009-01-11.  https://wiki.mozilla.org/Gecko:TLD_Service
> > 	</bibl>
> 
> Regards,
> --
> Thomas Roessler, W3C  <tlr@w3.org>
> 
> 
> 
> 
> 
> 
> 
>

Received on Wednesday, 14 January 2009 18:06:48 UTC