On Oct 31, 2014, at 1:28 PM, Viktor Dukhovni <[email protected]> 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 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
