Subject: [dane] draft-ietf-dane-smime-11.txt

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 08 Jul 2016 08:35:53 -0700

Greetings. Jakob and I have made a large number of changes to 
draft-ietf-dane-smime to incorporate the related WG changes that were 
made to draft-ietf-dane-openpgpkey during its last calls. We think 
draft-ietf-dane-smime-11 is ready for WG Last Call and progression.

--Jakob Schlyter and Paul Hoffman

---

From: Jim Schaad <[email-masked]>
Date: Fri, 8 Jul 2016 12:40:46 -0700

Since I have never been in the camp of believing that the email matching
problem has been solved, I have not really looked very hard at these drafts.
However, in the process of getting updates to S/MIME ready I got an item
pinged into my mind that they probably need to address.  How are the
capabilities of an S/MIME client for encryption to be obtained as part of
this query?  Today getting a signed message will provide those capabilities,
it is possible to put them into a certificate (RFC 4262) but this has
problems when they change (you need to get a new certificate) and LDAP has
the userSMIMECertificate field which contains both the certificates and the
capabilities.  

Since knowing what content encryption algorithm is supported can be
considered critical, this should be covered in the draft.

Jim

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Friday, July 08, 2016 8:36 AM
> To: [email-masked]
> Subject: [dane] draft-ietf-dane-smime-11.txt
> 
draft-ietf-dane-
> smime to incorporate the related WG changes that were made to draft-ietf-
> dane-openpgpkey during its last calls. We think
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Florian Kirstein <[email-masked]>
Date: Mon, 25 Jul 2016 20:42:27 +0200

Hello,

> problem has been solved
Time will tell, but I think we are on a good path. Regarding S/MIME:
looks like Mozilla "fixed" it (after some RFC discussions) to case
insensitive matching in 2002:
https://bugzilla.mozilla.org/show_bug.cgi?id=130692

But regarding your actual concern:

> this query?
This is out of the scope of this proposal. Even without DANE you
could want to send a mail to someone without having received a signed
mail from him before. As well as you can and would and should use DANE key
lookup also WHEN replying to a signed mail.

> problems when they change (you need to get a new certificate)
Still RFC4262 is the RFC to address this problem. Not our key lookup.

Of course it would be possible to add some information about that
also into the DNS - but that would be a third way to publish this
information without any need. Publishing a new cert in DNS isn't
a real problem and CAs (if you for some reason want your cert signed)
might even offer free resigning if only RFC4262 info is changed in
the future. 

It's good you brought this up but I don't see a real problem here
to be solved in the draft...

Greetings,

Florian
-- 
[*] sys4 AG                                                                     
https://sys4.de, +49 (89) 30 90 46 64
Schleissheimer Strasse 26/MG, 80333 Muenchen
Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein