Thanks for the explanation.
On Tue, Mar 22, 2016 at 1:38 PM, John R Levine <johnl(_at_)taugh(_dot_)com>
wrote:
I think this draft (draft-bhjl-x509-srv-00
<https://tools.ietf.org/html/draft-bhjl-x509-srv-00>) very usefully
defines
a means to lookup certificates for S/MIME users, and wonder if we could
discuss this. As far as I can tell it hasn't been discussed else where.
Another worry is that the security of this proposal is based on DNSSEC
which is only very slowly being deployed and many clients may not be able
to interoperate with that.
Not really. The keys deliberately are *not* automatically authoritative
so it's not a privacy crisis if someone inserts a fake server. Clients
need to apply local policy to decide whether to trust them, just like you
would for keys from traditional PGP key servers or anywhere else.
I think the benefits of an authoritative server out weighs the worries that
you suggest. In the web world, its been very helpful to be certain what
one should chain up via browser certificate pinning or HPKP. A whole host
of malfeasance was found this way. Even in the limited use that S/MIME has
today, in government and defense, its likely to be very useful.
The only thing that depends on DNSSEC for trust is the new option for a
domain to publish a S/MIME signing key for its users' keys. Lacking
DNSSEC, the traditional CA PKI is still there.
There some risk in authenticating via email CA PKI. What use of S/MIME
there is suggests a fair amount of domain private issued or self issued
certificates and consequently S/MIME MUAs often make it easy to add these
private trust anchors. Due to human factors that we've often read about,
its would not be difficult to convince users to accept a fraudulent
certificate and trust anchor, and thereby lessens the strength of email CA
PKI and its ability to effectively distinguish a fake key server.
-Wei
R's,
John
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime