Hey all, Sorry this response is so delayed. I think the suggestions made in the proposed text ( http://www.ietf.org/mail-archive/web/dane/current/msg06180.html ) make quite a bit of sense. In particular, I think the proposal to add the Usage #4 (reject) is likely to be very important. Specifically, DANE is (imho) excellent example of a standard architecture for certificate discovery using DNS. From this perspective it seems opportune for it to capitalize on the nuanced difference between saying, ``don't use this cert for this operation,'' and ``this cert is universally revoked.'' These really are fundamentally different, and DANE lets us express them that way.
Also, I think the certificate access field (Section 2.1.4, which enables alternate discovery mechanisms) could actually be a great facility for incremental deployment and transition schemes. It seems to me that the flexibility added could be crucial as would-be adopters incrementally roll their constituency off of (say) an AD solution and onto a DANE solution. Finally, I think the ``_encr'' and ``_sign'' labels are excellent additions to the _discovery_ mechanism that DANE enables. Viewing DANE as a discovery mechanism for certs, I can't help but feel that the process of trying to discover a signing key vs.trying to discover an encryption key a first class element of the protocol. Rather than asking for all keys and then selecting from them, I (as an RP) likely already know which of these I want, and I should be able to discover them separately in DANE (and owners should be able to manage them separately in DANE). Based on that, these changes really seems like great fodder for being encoded in the domain name, imho. I noticed that the current (-04?) draft doesn't seem to have taken these recommendations, but I think they should be incorporated. Eric On Jan 8, 2014, at 9:58 AM, Scott Rose <[email protected]> wrote: > I support this work and would like to see more discussion on the list. Some > of us have even proposed text with additions > (http://www.ietf.org/mail-archive/web/dane/current/msg06180.html). > > Haven't seen much discussion on the list, and missed the informal DANE lunch > at the last IETF. Is there enough interest in having the SMIMEA RR? Some of > the changes we offered: > > 1. naming convention to help distinguish between signing and encryption key > certs (for enterprises that use separate certs for encrypting and signing). > It helps reduce the size of the SMIMEA RRset a bit, but admittedly minor > compared to the size of an X.509 cert. > > 2. a new CU value for "revoked" to indicate that this user's certificates > have been revoked. > > There are some signed/encrypted email projects rolling out now that are using > CERT RR's or combinations of SRV RR's and LDAP servers. Having something > like SMIME would be an improvement, but the spec needs to be finalized. > > Scott > > > On Jan 6, 2014, at 4:29 PM, [email protected] wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the DNS-based Authentication of Named Entities >> Working Group of the IETF. >> >> Title : Using Secure DNS to Associate Certificates with >> Domain Names For S/MIME >> Authors : Paul Hoffman >> Jakob Schlyter >> Filename : draft-ietf-dane-smime-03.txt >> Pages : 6 >> Date : 2014-01-06 >> >> Abstract: >> This document describes how to use secure DNS to associate an S/MIME >> user's certificate with the intended domain name, similar to the way >> that DANE (RFC 6698) does for TLS. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dane-smime-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-03 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> dane mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
