Re: [dane] Question regarding RFC 8162

[Viktor Dukhovni <[e-mail]>]

On Fri, Sep 09, 2022 at 03:41:39PM +0200, Metin Savignano wrote:

> We’re a team working on an email encryption app. I am always a looking
> for better ways to simplify the use of S/MIME, because I believe that
> the current PKI is the main reason for people not to use S/MIME. 

I believe this misses much deeper reasons why S/MIME and PGP are not
in common use:

    * Even with key distribution solved, once S/MIME or PGP email
      is delivered, it is basically unusable with today's email
      client software and storage architecture.

      - Encrypted messages are not indexed and cannot be
        effectively searched.

      - Encrypted messages are not re-encrypted for long-term
        storage under managed storage keys, independent of the
        "short-term" recipient keys.

      - Signature verification at time of receipt is not securely
        recorded along with the message.  Messages look invalid
        when signer keys later expire.

      - If E2E key discovery becomes broadly available, spam and
        malware defence at the gateway becomes problematic.

      - Which probably means that E2E encrypted email can't be as
        permissionless (and therefore as ubiquitous) as mainstream
        email (ideally with hop-by-hop encrypted transport).  The
        architecture for managing permitted senders of E2E-encrypted
        email is not in place, and in any case limits its use-cases.

Poor *usability* of already delivered E2E-encrypted email is a much more
important barrier than lack of key discovery, which IMHO is mostly for
lack of demand, than lack of potential ways to scalably distribute keys.

> Let me explain what I’m trying to achieve:
> 
> There are numerous companies (including my own little team) that
> establish there own CA. I’m looking for a way to publish to the root
> certificate of such a CA in a way that it can automatically be
> retrieved and trusted by a remote mail client. It seemed like this
> could be with DANE using the SMIMEA record. I would expect that I can
> publish an SMIMEA record with certificate usage 0 (PKIX-TA) that would
> be retrieved and used to validate the PKIX path. 

If you're looking for S/MIME restricted to just *signing*, this could
work, but S/MIME supports encryption as a primary use-case, and for that
per-recipient public keys need to be available, not just the issuing
CA's.

-- 
    Viktor.