Before I do a detailed review of the document, I have a question about the problem that this document is trying to solve. I can see three different problems that one could try and solve with this document.
1. I have been given a certificate. That certificate contains an email address. I want establish that I should trust the certificate. 2. I have been given a certificate. I have gotten an email address from the email message, but there is no email address in the certificate. I want to establish that I should trust the certificate. Additionally, I may want to establish that the certificate has a binding with the email address. 3. I have an email address. I need to a) find a certificate for the email address (either for encryption or because the signed message did not have a certificate in it) and b) establish that I should trust the certificate. Given the current document, I believe that I can do problem #1. The population code will be able to map the email address in the certificate to the correct DNS name and the client will be able to do the lookup using the same process. The DNS could have different names for different capitalizations based on what is in the certificate. No problems. Problem #2 is harder. If the email address is capitalized correctly, then I can find the certificate, but depending on what is in the DNS record, I may or may not be able to establish that the certificate and the email address should be bound together. The capitalization issue could be addressed by the DNS populator, depending on what the local mail server does, by creating a record for every possible capitalization if the local mail server will do case folding. This is not needed if the local mail server does not do case folding of mailbox names. For messages coming from a user, it might be sufficient to assume that they are going to put the correct capitalization in the email message itself if folding is not done by the mail server. This may not be the case if folding is done by the mail server. Problem #3 is almost impossible. It would require that only end-entity certificate be listed, and this would mean that either it would be directly trusted or one would need to have both an EE certificate and a trust anchor listed in the DNS entry. The capitalization issue would need to be addressed as in the previous paragraph, but is harder given that the sender may have never seen the mailbox name for the recipient and may be guessing at what the string should be if the DNS namespace is not over-populated. Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Jakob Schlyter > Sent: Monday, September 10, 2012 1:15 PM > To: IETF DANE WG list > Subject: [dane] FYI: New Version Notification for draft-hoffman-dane- > smime-04.txt > > FYI, we've made a last-minute update to the DANE S/MIME draft based on > the input from the list. > If the WG would like to adopt this draft (which we hope it will), we'd be > happy to continue as editors. > > Chairs: Will the WG meet in Atlanta? > > > Jakob & Paul > > > Begin forwarded message: > > > From: [email protected] > > Subject: New Version Notification for draft-hoffman-dane-smime-04.txt > > Date: 8 september 2012 18:13:45 CEST > > To: [email protected] > > Cc: [email protected] > > > > > > A new version of I-D, draft-hoffman-dane-smime-04.txt has been > > successfully submitted by Paul Hoffman and posted to the IETF > > repository. > > > > Filename: draft-hoffman-dane-smime > > Revision: 04 > > Title: Using Secure DNS to Associate Certificates with Domain > Names For S/MIME > > Creation date: 2012-09-06 > > WG ID: Individual Submission > > Number of pages: 6 > > URL: http://www.ietf.org/internet-drafts/draft-hoffman-dane- > smime-04.txt > > Status: http://datatracker.ietf.org/doc/draft-hoffman-dane-smime > > Htmlized: http://tools.ietf.org/html/draft-hoffman-dane-smime-04 > > Diff: http://www.ietf.org/rfcdiff?url2=draft-hoffman-dane-smime-04 > > > > 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 Secretariat > > > > -- > Jakob Schlyter > Kirei AB - http://www.kirei.se/ > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
