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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
