On Sat, Nov 01, 2014 at 08:38:44PM +0000, Osterweil, Eric wrote:
> > 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.
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?
> > 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.
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).
>
> Does that make more sense?
No. The alternate sources can be published and the application
can look there if it sees fit.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
