Re: Public Key Look Up

Matthias,

I found this very helpful ... and quite consistent with my
experience and predictions from very different contexts.  I
think we need to be aware of the tempting target presented by an
organizational server that holds and manages private keys but,
in the grand scheme of things, that may be less problematic and
risky than, e.g., hop by hop encryption with messages in clear
on poorly protected relay boxes.

thanks,
   john


--On Friday, May 14, 2021 09:22 +0200 Matthias Leisi
<[email protected]> wrote:

> 
> 
>> Am 13.05.2021 um 03:45 schrieb John C Klensin
>> <[email protected]>:
> 
>> And that is the practice that goes with the theory.  We really
>> don't have a shortage of mechanisms for locating and
>> retrieving keys. Unless something changes the conditions that
>> have frustrated deployment and use, there is no evidence that
>> adding another mechanism would make enough difference to be
>> worth the effort (and, as John Levine pointed out,
>> statistically probably no difference at all).   I can imagine
>> scenarios that would change the situation, but I don't expect
>> any of them soon and none of them would cause the presence or
>> absence of one more key location and retrieval mechanism to
>> be an impediment.
> 
> Speaking from practice (offering encrypted mail services to
> local clients), the following are positive drivers for
> end-to-end encryption:
> 
> 1) Network effects: community of users / industry /
> geographical area. In our case: local lawyers driven by
> compliance have considerable uptake of encryption. 
> 
> 2) Ease-of-use: Non-technical people have little patience to
> care about the details of encryption, key handling and similar
> non-productive use of their time. In our case: a server-based
> solution greatly simplifies these things. Yes, this breaks the
> end-to-end mantra, but it blends in better with other
> compliance requirements (eg archiving). Additional
> improvement: simple, rule-based encryption. If the
> „Confidential" flag is ticked or a specific tag is in the
> subject, require encryption. 
> 
> 3) Be pragmatic. In our case: solutions that „know" each
> other (from the same vendor) share a list of trusted
> domain-based certificates, and always sign/encrypt amongst
> themselves transparently. This protects against interceptions
> or falsifications in transit, regardless of the number of
> intermediate hops. Nothing more, but nothing less. And it lays
> the ground for improvements over time.
> 
> Drivers that hinder adoption:
> 
> 1) Lack of standard to share & trust domain-based
> certificates. Standardising on a Public Key Lookup mechanism
> could be very helpful.
> 
> 2) Access to and handling of certificates: We miss a
> „Let's Encrypt for E-Mail". And the MUAs are woefully
> inadequate to request, renew etc keys and certificates. In our
> service, we handle the keys and certificates server-side
> through a managed PKI service, but adoption would be _much_
> better if the MUAs would do a better job.
> 
> 3) Bureaucracy, organizational inertia: We found that many
> organizations have some encryption capability, but strictly
> limit its use. Funky PDF-based processes are required to get
> it to work for very narrow sets of users and use cases. Some
> best practice document may help those organizations to better
> adopt what they already have. 
> 
> A data point: while we offer both PGP and S/MIME-based
> service, we have exactly 0% adoption of PGP (even though it is
> slightly cheaper due to the lack of certificate cost).
> 
> — Matthias
> 
> 
> 
> _______________________________________________
> ietf-smtp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-smtp


_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp