[webauthn] hostname canonicalization in {#makeCredential} section?

equalsJeffH has just created a new issue for 
https://github.com/w3c/webauthn:

== hostname canonicalization in {#makeCredential} section? ==
webauthn says (in 
https://github.com/w3c/webauthn/pull/154/files#diff-ec9cfa5f3f35ec1f84feb2e59686c34dR391
 L391-L396...
```
3. Set |callerOrigin| to the origin of the caller. Derive 
the RP ID from |callerOrigin| by computing the "public suffix + 1" or 
"PS+1" 
(which is also referred to as the "Effective Top-Level Domain plus 
One" or 
"eTLD+1") part of |callerOrigin| [[PSL]]. Let |rpId| be the lowercase 
form of this RP ID. Set |rpIdHash| to the SHA-256 hash of the UTF-8 
encoding 
of |rpId|.
```
this is apparently operating on the `hostname` component of 
`|callerOrigin|`.  (this itself needs to be clarified but tracked in a
 separate issue)

instead of simply lower casing the hostname and ensuring utf-8 
encoding (as done in 3d and 4th sentences), should we not be 
specifying something essentially the same as done in RFC6265 
<https://tools.ietf.org/html/rfc6265#section-5.1.2> ?
```
5.1.2.  Canonicalized Host Names

   A canonicalized host name is the string generated by the following
   algorithm:

   1.  Convert the host name to a sequence of individual domain name
       labels.

   2.  Convert each label that is not a Non-Reserved LDH (NR-LDH) 
label,
       to an A-label (see Section 2.3.2.1 of [RFC5890] for the former
       and latter), or to a "punycode label" (a label resulting from 
the
       "ToASCII" conversion in Section 4 of [RFC3490]), as appropriate
       (see Section 6.3 of this specification).

   3.  Concatenate the resulting labels, separated by a %x2E (".")
       character.
```
this is because in this world of deployed IDNA (RFC5890 and RFC3490, 
see also [1]), all operations on domain names must be done 
label-by-label, on A-labels and Non-Reserved LDH (NR-LDH) labels. 

Alternatively, if it is assumed that a user agent implementing 
webauthn will have already performed "host name canonicalization", the
 webauthn spec should state that and cite the appropriate (likely W3C)
 spec requiring that processing. 

[1] https://tools.ietf.org/html/rfc6265#section-6.3
```
6.3.  IDNA Dependency and Migration

   IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490].  However, there 
are
   differences between the two specifications, and thus there can be
   differences in processing (e.g., converting) domain name labels 
that
   have been registered under one from those registered under the 
other.
   There will be a transition period of some time during which 
IDNA2003-
   based domain name labels will exist in the wild.  User agents 
SHOULD
   implement IDNA2008 [RFC5890] and MAY implement [UTS46] or [RFC5895]
   in order to facilitate their IDNA transition.  If a user agent does
   not implement IDNA2008, the user agent MUST implement IDNA2003
   [RFC3490].
```









Please view or discuss this issue at 
https://github.com/w3c/webauthn/issues/167 using your GitHub account

Received on Tuesday, 16 August 2016 22:20:53 UTC