On Thu, 2 Apr 2015, Viktor Dukhovni wrote:
Your initial thinking was right, the private key is used for signing, but the public key is published so that verifiers can validate the signature. The proposal is to publish verification (public) keys (that validate received mail) separately from encryption (public) keys that enable encryption of outgoing mail.
Right, and: for email signing): - must have the Digital Signature or Non-Repudiation OID’s as a Key Usage. (for email encryption): - must have the Key Agreement or Data Encipherment OID’s as a Key Usage. So why add the dns complexity for _sign and _encrypt. While it is nice that you can skip fetching an smime cert if you need to sign but the you cannot find it at the _sign prefix, once you have the cert and then you need to encrypt, you either need to repeat a DNS lookup for a cert you already have or you need to store the "sign" or "encrypt" flags, meaning you will want to do two lookups always even if you only want to sign or encrypt now. And then you still need to check for conflicts within the smime certificate's OID. When you drink the X.509 kool-aid, you have to play by its rules, which means full PKIX validation of the EKU. Paul _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane
