Subject: Re: [dane] draft-ietf-dane-smime

From: "Osterweil, Eric" <[email-masked]>
Date: Sat, 1 Nov 2014 20:38:44 +0000

On Oct 31, 2014, at 1:28 PM, Viktor Dukhovni <[email-masked]> wrote:

> On Fri, Oct 31, 2014 at 02:47:19PM +0000, Osterweil, Eric wrote:
> 
>>   4 or REJECT -- REJECT is used by the domain owner to assert that at
>>   the time of querying the DNS, this user's certificate MUST be considered
>>   invalid for the requested function (i.e. signature or encryption).
>>   This is a stronger assertion than a failed certificate validation check.
>>   Possible usage scenarios include de-authorizing stale employee
>>   credentials by selectively overriding TAs that are used to authorize
>>   entire organizations.
> 
> Which certificate is being invalidated? Why is this needed?  What's
> wrong with publishing a "3 1 1" association with an impossible key?

Thanks for sending this note!  The idea here is to say, ``this specific key (which an RP may or may not have used before) is not to be used for this inbox, at this time.''  An impossible key just means _that_ key can’t be used.  This idea isn’t trying to disable an email inbox, just ensure that a key that may pass (or may have passed, once upon a time) other verification is unambiguously de-authorized.

> 
>    $ openssl dgst -sha256 </dev/null
>    (stdin)= e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
> 
>    ;; User's public key cannot be empty, so will never match this record.
>    ;;
>    1c190a039a9c355fba9eb653eb52cd64e2fbe76db2588fc5a2b5c5d4._sign._smimecert.example.com.  IN SMIMEA ( DANE-EE SPKI SHA2-256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 )
> 
>> 2.1.4.  Certificate Access Field
>> 
>> This one octet value indicates an alternative method for certificate
>> discovery.  Some domain owners may not want to publish user
>> certificates via DNS but may want to use the DNS to advertise the
>> means to access them.  If full user certificates are not included in
>> the Certificate Association Data this field MAY be used to indicate
>> how the user's certificate can be obtained.  The RDATA certificate
>> association data MUST be used to validate certificates obtained by
>> the alternative method.
>> 
>>   0 or NO: No alternative method advertised.
>> 
>>   1 or NAPTR : NAPTR record available.  The same domain name used
>>   for this SMIMEA request MAY be used again with type NAPTR
>>   [RFC3403] to retrieve the URI for certificate access.
>> 
>>   2 or WF: X.509 certificates available in WebFinger [RFC7033].
> 
> Once this field is not "NO", what is the meaning of the associated
> data field carried with such a record?  Is it still providing a
> valid DANE association?

Yeah, I would say so.  I think this is the case most akin to the TLSA model.  I would say:
0 == use TLSA-style DANE
1 == look for info from a service that is described by NAPTR
2 == Look for info served from a WebFinger service.

> If so, when would one also need to use the "alternative access”?

I think this would allow the provisioning system to either put certs in DNS, or put them elsewhere and have DNS point to where.  I’m not sure I’m answering your question though?

> If not, how is this a DANE SMIMEA record?  At the very least changing
> the semantics of the associated data should lead to a new selector
> or usage, but more likely an entirely separate DNSSEC validated
> record, at which point the application can just query for these
> alternative records if it sees fit.  Why does SMIMEA need to
> explicitly signal the use of other mechanisms?

I don’t understand this comment, but I think it stems from a miscommunication above.  This field would be used to say, ``look over there for the cert.’’  If the cert info is encoded in SMIMEA, or its retrieval is outside of the DANE scope (i.e., the cert is included in an email message), then this field is left as 0 (not used).

Does that make more sense?

Eric

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 1 Nov 2014 23:33:22 +0000

On Sat, Nov 01, 2014 at 08:38:44PM +0000, Osterweil, Eric wrote:

> Thanks for sending this note!  The idea here is to say, ``this
> specific key (which an RP may or may not have used before) is not
> to be used for this inbox, at this time.''  An impossible key just
> means _that_ key can?t be used.  This idea isn?t trying to disable
> an email inbox, just ensure that a key that may pass (or may have
> passed, once upon a time) other verification is unambiguously
> de-authorized.

Well, in *that* case the association data MUST be the leaf digest!
At least that would comport much better with the other DANE usages,
and allow selective "revocation" of one or more records.

However, it seems to me that *any* record which does not match the
current SMIME RR is implicitly invalid to valid new messages.  What
purpose does "reject" serve?

> 2 == Look for info served from a WebFinger service.

What is the meaning of the associated *DATA* field?  Why should
this be an SMIMEA record.  I think this is misuse of that record.

> I don?t understand this comment, but I think it stems from a miscommunication above.  This field would be used to say, ``look over there for the cert.??  If the cert info is encoded in SMIMEA, or its retrieval is outside of the DANE scope (i.e., the cert is included in an email message), then this field is left as 0 (not used).
> 

No.  The alternate sources can be published and the application
can look there if it sees fit.

-- 
	Viktor.

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 8 Nov 2014 17:32:57 -1000

> this be an SMIMEA record.  I think this is misuse of that record.

I believe the CERT RR would be more appropriate for redirects to other access methods. Or perhaps the proposed URI RR (draft-faltstrom-uri).

The proposal is similar to publishing an MX RR with an extra option to indicate that X.400 should be used for delivery.

	jakob