ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft Errata on RFC 4871

2009-01-26 21:05:25
John R. Levine wrote:
Except that the UAID might or might not be an e-mail address.  The one
on this messgage isn't.
      
So, for clarity, can you (or someone) call out what you think is
the impact, if any, for ADSP, caused by this proposed change to
4871.
    

Nothing.  ADSP's attempt to force i= to be an identifier that is an e-mail 
address was wrong before, and the errata doesn't change that.

I've put a note pointing that out in the proposed next draft, with a 
kludgy workaround being a second signature with no i= field.

If it were up to me, I'd remove all the references to i= from ADSP, but 
there seem to be people who believe that it will be useful.
  
Nevertheless, what's in the specification represents working group rough
consensus, in connection with issues 1399 and 1519.  There have been
opportunities in WG Last Call and IETF Last Call to reconsider that
decision.

In response to Stephen's question, there are several things that I see
as problems relative to ADSP:

The position of ADSP in the verification process hasn't been defined,
which is reasonable since ADSP is an add-on.  Therefore, it must be part
of the Assessor rather than part of the verification process itself. 
This document makes the passing of the i= value (referred to as UAID)
optional, which means that some verifiers will not provide a value
required by the ADSP specification.

Section 5, paragraph 4, "responsible Identifiers that are individual,
opaque values" can be interpreted as requiring that an opaque value be
chosen by the signer, which would prohibit Author Signatures as defined
in ADSP.

Section 5, last paragraph, argues that interpreting any structured
semantics for either of the identifiers is "heuristic".  To the extent
that a signing domain publishes an ADSP "All" or "Discardable" record,
they are making an assertion of the semantics of the i= identifier so it
is not a heuristic.

I have many other comments about this draft, which I will save for
another message.

-Jim

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html