Subject: [apps-discuss] draft-snell-web-index-00: hash of user-id

From: "Manger, James H" <[email-masked]>
Date: Tue, 10 Jul 2012 16:18:09 +1000

James,

> And an alternative approach would look like.. (the numbers are the
> sha-256 digest of the acct id)
> 
> GET /.well-known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d7f8
> HTTP/1.1
> Host: packetizer.com
> 
> HTTP/1.1 300 Multiple Choices
> Link: </people/paulej/images/paulej.jpg>; rel="http://webfinger.net/rel/avatar"

Using a hash instead of a user-id adds a little privacy, but it does require that both ends normalize the user-id precisely the same way. Are you confident that wouldn't be a problem in practice?

For instance, all the following are different (and none are 4564b…7f8):
1. SHA-256("paulej")
2. SHA-256("[email-masked]")
3. SHA-256("acct:[email-masked]")
4. SHA-256("ACCT:[email-masked]")
5. SHA-256("acct:[email-masked]")
6. SHA-256("acct:[email-masked]")
7. SHA-256("acct:[email-masked]")
8. SHA-256("acct:[email-masked]")
9. SHA-256("acct:[email-masked]")
10. …

Many of the above are 100% valid exact equivalents (eg .com vs .COM). Others are usually equivalent in practice (eg PaulEJ vs paulej).

--
James Manger

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Jul 2012 09:55:23 +0100

So without prejudice to webfinger/swd/snell...

If using a hash of the acct URI in the query, then...

1) Be good to put the hash function you're using into the URL,
e.g. sha-256, in case new functions are needed later

2) Be good to use the URL segment form from draft-farrell-decade-ni
(section 5), e.g. sha-256;1hlsmNC2xoyZMaLcHqzuVYrhFmmBGUj63yez2zJnrD4
That uses base64url, but that's arguably a bit better

3) I think truncated hashes are fine here and if you do
the above, that's easy, e.g. sha-256-32;1hlsmA

4) Going further, if we'd like to increase privacy then really
really truncated hashes might be even better, and its fine for
this application if there are collisions, so long as the server
can return the N colliding records. Should be easy enough to
manage so as to keep the number of records returned small and
the client knows the one it wants. (There may be a separate
argument for multiple records in the response anyway.)

I also agree with James about canonicalisation of the acct
URI, but that can just be defined in the definition of that
URI scheme. The hashes above are over "acct:[email-masked]"
(or else I mucked up:-).

Cheers,
S.

On 07/10/2012 07:18 AM, Manger, James H wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: James M Snell <[email-masked]>
Date: Tue, 10 Jul 2012 06:28:55 -0700

> That uses base64url, but that's arguably a bit better

+1... much better, in fact, since it gives us an escape hatch in cases
where not using a hash is perfectly acceptable... (I did not mean to
imply that hashes should be mandatory always...)

for instance...

GET /.well-known/index/sha-256-32;1hlsmA HTTP/1.1
GET /.well-known/index/acct:[email-masked] HTTP/1.1
GET /.well-known/index/{some-other-opaque-identifier} HTTP/1.1

One bit of complexity that my proposal does not yet resolve is how a
user-agent determines which hash methods are supported by the server.
The proposal to use the hash url segment from the
draft-farrell-decade-ni draft makes that significantly easier in that
a server can simply return a 404 if a user-agent uses an unsupported
hash function.

> argument for multiple records in the response anyway.)

+0.5 ... truncated hashes should, at least in theory, be fine here as
long as collisions were kept to an absolute minimum. I would rather
avoid, if possible, the added complexity of requiring the user-agent
to select through multiple results.

> URI scheme. The hashes above are over "acct:[email-masked]"

To be certain, some degree of normalization and c18n of the identifier
is certainly going to be generally required regardless of whether
hashing is used. Unless I missed it, neither WebFinger/RFC6415 or the
Simple Web Discovery draft deal with resource ID equivalence for the
sake of matching.

For example, are these equivalent requests in WebFinger?

GET /.well-known/host-meta.json?resource=acct:[email-masked] HTTP/1.1
GET /.well-known/host-meta.json?resource=ACCT:[email-masked]
HTTP/1.1

The spec, as currently written, does not appear to say.

- James S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Jul 2012 14:41:37 +0100

> to select through multiple results.

Yeah, probably. I guess to get any privacy enhancement
you'd need to be getting loads of records back.

OTOH, that's sort of what safe web browsing does, so
there's a precedent that's not that different.

But that could be looked at later I guess.

S.