Re: Call for Comment: "Issues in Identifier Comparison for SecurityPurposes"

[t.p. <[e-mail]>]

>From the title, I was expecting something a little deeper; I find this
I-D strong on current detail, less so on the underlying, perhaps
more lasting issues.

For example, as has been pointed out on these lists before, identifiers
refer to an identity and an object may have multiple identities in
different contexts and each identity may have multiple identifiers.  (Is
an SSN a different identifier to the same identity as a passport number,
or to a different identity? DISCUSS).  This I-D seems to skate over this
issue seeming to assume for the most part that there is one identity and
one identifier.  I think the I-D should at least mention to this
underlying complexity.

Equally, in the discussion of tests, the I-D rightly points out the
concepts of false negative and false positive but could go further.  The
gold standard test, one that is always right, is a fine concept that
does not exist in our engineered world.  Rather, most, if not all, tests
can be modified to increase the probability of false positives and
decrease the probability of false negatives, or vice versa; and which
outcome  is better depends on the context.  (The example of this last I
see quoted is a test for a serious disease, when a false (positive)
diagnosis is usually seen as the preferred outcome).  Again, this is the
sort of background I would expect to see some reference to.

The distinction between host names and domain names is also one that
surfaces regularly here.  Section 3.1 alludes to this but, for me, is
not clear enough about the definitions thereof that the IETF has made;
this recurs in section 3.4.  This last section seems imprecise about
e-mail addresses; RFC5321 is specific -  "The local-part of a mailbox
MUST BE treated as case sensitive" - so I think that that could be
brought out more strongly here.  There is a more general issue
underlying this, that a body such as the IETF produces a precise
specification but manufacturers, or other SDOs or even later WGs within
the IETF, then make it looser, with local  variations, which may in time
come to be taken as the standard.  In this case, a sharper distinction
could be drawn between an e-mail address, as the IETF has specified, and
an e-mail-like address, as used in other contexts.

Tom Petch

----- Original Message -----
From: "IAB Chair" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, January 09, 2013 8:42 PM

This is an announcement of an IETF-wide Call for Comment on 'Issues in
Identifier Comparison for Security Purposes'.

The document is being considered for publication as an Informational RFC
within the IAB stream, and is available for inspection here:
http://tools.ietf.org/html/draft-iab-identifier-comparison

The Call for Comment will last until February 10, 2013. Please send
comments to iab at iab.org or submit them via TRAC (see below).
===============================================================
Submitting Comments via TRAC
1. To submit an issue in TRAC, you first need to login to the IAB site
on the tools server:
http://tools.ietf.org/wg/iab/trac/login

2. If you don't already have a login ID, you can obtain one by
navigating to this site:
http://trac.tools.ietf.org/newlogin

3. Once you have obtained an account, and have logged in, you can file
an issue by navigating to the ticket entry form:
http://trac.tools.ietf.org/wg/iab/trac/newticket

4. When opening an issue:
a. The Type: field should be set to "defect" for an issue with the
current document text, or "enhancement" for a proposed addition of
functionality (such as an additional requirement).
b. The Priority: field is set based on the severity of the Issue. For
example, editorial issues are typically "minor" or "trivial".
c. The Milestone: field should be set to milestone1 (useless, I know).
d. The Component: field should be set to the document you are filing the
issue on.
e. The Version: field should be set to "1.0".
f. The Severity: field should be set to based on the status of the
document (e.g. "In WG Last Call" for a document in IAB last call)
g. The Keywords: and CC: fields can be left blank unless inspiration
seizes you.
h. The Assign To: field is generally filled in with the email address of
the editor.

5. Typically it won't be necessary to enclose a file with the ticket,
but if you need to, select "I have files to attach to this ticket".

6. If you want to preview your Issue, click on the "Preview" button.
When you're ready to submit the issue, click on the "Create Ticket"
button.

7. If you want to update an issue, go to the "View Tickets" page:
http://trac.tools.ietf.org/wg/iab/trac/report/1

Click on the ticket # you want to update, and then modify the ticket
fields as required.