Re: [stir] current draft charter

[Dave Crocker <[e-mail]>]

On 6/16/2013 10:39 AM, Hadriel Kaplan wrote:
> On Jun 16, 2013, at 12:38 PM, Dave Crocker <[e-mail]>
> wrote:
>> Better still is that it's the entity making the assertion that
>> tells the verifier where to look for verification information...
>> What's seems to be missing from the text in RFC 4474 is how the
>> verifier can tell whether the credential is a valid authorization
>> for use of the From field value.
...
> I think the general idea was a DKIM-like model, so if the From field
> value is '[e-mail]', then you check the cert it points you to is
> for foo.com and signed by a CA you trust.  That works for email-style

We're in a space that requires quite a bit of care and precision, so 
forgive my pedantry when I note that DKIM does not have anything to do 
with the address in the rfc5322.From field, contrary to popular beliefs.[*]

DKIM has its own identifier field (the d= parameter of the 
DKIM-Signature header field).  It's entirely independent of all other 
identification information in the message.  But note that DKIM semantics 
are completely different than what is proposed for STIR.  The signer in 
DKIM merely asserts "some responsibility" for the message; this 
pointedly does /not/ include validating any of the message content, such 
as the From: address.

The more recent DMARC, on the other hand, does assert "alignment" 
between the d= value and the From: field domain.  However DMARC is 
intended for narrow use.  In particular, it does not work for messages 
that get re-posted, such as mailing lists.  I think that such cases 
match concerns for SIP/PSTN gateways.



> So one proposal so far is that there would be certs which identify
> the E.164 numbers they're authoritative for (in a CN/SAN field for
> example), and that cert would be signed by some CA (or chain leading
> to one) that you trust.  If it's a chain rather than directly signed
> by a CA, then it's not clear how one goes about retrieving the certs
> for the chain's links, and doing so could cause unacceptable delay.
> It also means we need revocation checks for the chain.  And I'd argue
> the management aspects for this thing would be just as difficult as
> anything else proposed so far.

Ack.  FWIW, I've always viewed the administrative requirements for DKIM 
far, far more challenging than the signing/verifying mechanisms.  After 
some years of extensive deployment experience with DKIM, my opinion has 
not changed...


d/


[*] The DKIM signing hash does include the From field, but that's 
different from using the value semantically.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net