Subject: [dane] I-D Action: draft-ietf-dane-smime-03.txt

From: [email-masked]
Date: Mon, 06 Jan 2014 13:29:11 -0800

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/

---

From: Scott Rose <[email-masked]>
Date: Wed, 8 Jan 2014 09:58:31 -0500

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-masked] wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Jan 2014 07:54:26 -0800

Thanks for the review, Scott. I didn't see it until I has pulled the lever on -04 to deal with a few of Mark's comments.

> 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…

The slight saving of space also introduces a new, significant failure mode, namely that if the person listing the cert in the DNS gets the type wrong then the receiver can't use it. I'd say "no" on this one.

> 2. a new CU value for "revoked" to indicate that this user's certificates have been revoked.  

We considered things like this for TLSA, and the WG seemed very hesitant to have the DNS be used as a second, unofficial revocation mechanism. For instance, what would it mean for the DNS to say that an S/MIME cert is revoked, but when the user pulls a fresh CRL, the cert isn't there? The best we might do is to have a signal for "go refresh your revocation view" in the DNS, but that seems like very marginal value.

> 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 s…

And Jakob and I apologize for the long lag since the earlier draft. We too would like to see this finished.

--Paul Hoffman

---

From: Scott Rose <[email-masked]>
Date: Wed, 8 Jan 2014 15:34:19 -0500

> Thanks for the review, Scott. I didn't see it until I has pulled the lever on -04 to deal with a few of Mark's comments.
I'd rather hear negative reviews of bad ideas than no reviews of good ones. 

> The slight saving of space also introduces a new, significant failure mode, namely that if the person listing the cert in the DNS gets the type wrong then the receiver can't use it. I'd say "no" on…

Admittedly it doesn't save much.  

> We considered things like this for TLSA, and the WG seemed very hesitant to have the DNS be used as a second, unofficial revocation mechanism. For instance, what would it mean for the DNS to say th…

Our thinking was with local trust anchors where places may not keep their CRL's up to date or even make it available.  I hope it's not optimistic in thinking that new DANE uses will encourage people to keep CRL's current.

> And Jakob and I apologize for the long lag since the earlier draft. We too would like to see this finished.

Count me as a reviewer.

Scott

---

From: Scott Rose <[email-masked]>
Date: Tue, 14 Jan 2014 08:56:33 -0500

Count me as a reviewer.

Scott