Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT)

[Stephen Farrell <[e-mail]>]

Hiya,

On 02/03/17 03:14, Peter Saint-Andre wrote:
> On 2/28/17 5:37 PM, Stephen Farrell wrote:
> 
>> - Section 8 should I think recognise the dangers inherent
>> in long-term stable identifiers helping with
>> (re-)identification of people and/or network entities.
> 
> Perhaps you could clarify what some of your concerns are here, above and
> beyond the use of URIs in general (after all, a URN is a URI). Reading
> between the lines, I imagine you might be worried that URNs within a
> particular URN namespace (e.g., for U.S. Social Security Numbers or the
> like) - once suitably resolved into one or more URLs - might enable an
> attacker to determine a person's physical location (e.g., via IP
> address) or actual identity (e.g., a pseudonym could "resolve" to a real
> name). Are these guesses on the mark?

Yep. Perhaps things like including an IMSI or IMEI (or
values easily correlated with such) in the NSS part is
what it'd useful to call out. I'm not sure if there are
real examples of such in existing URNs but if there were
it'd be a fine thing to note that including such things
imposes (often unmet) requirements for e.g. confidentiality
on protocols and applications that use those URNs. If
may also be useful to say that things like hashing the
privacy sensitive value before inclusion in the URN don't
prevent correlation and can be as "good" for re-identification
as the non-hashed value.

The argument to include text here is that it seems to be
very tempting to include that kind of information for many
folks.

I'm not sure if there's a useful bit of text in RFC6973
at which you could point, but it'd be worth a look.

> 
>> While that is not the "fault" of URNs, I'd say it is worth
>> warning folks who may just possibly think twice before
>> creating new URNs with those failings. (Though I recognise
>> that that may call for a reference to RFC6919;-)
> 
> I'm sure you meant RFC 6920. :-)

Off-by-one error:-)

Cheers,
S.

> 
> Peter
>