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.
We offered it to DANE, but it appears that DANE is rapidly winding down so
PKIX seems as good a place as any.
I also don't know if there are other similar proposals, and if a comparison
between this and other approaches has been done. This or some other key
lookup service would be very helpful in enabling email message based
encryption/authentication.
The draft proposes a new DNS SRV record that defines a URL to lookup
certificate (both PKIX and PGP) over HTTPS for email.
Actually, they're not new, all straight out of RFC 4387. This draft is
mostly a profile of 4387, which offers multiple ways to do stuff, choosing
one option from each set so it's easier to interoperate.
The draft is pretty complete but some of the description could be
expanded. It doesn't define define behavior when the certificate is
missing or invalid. Presumably some sort of HTTP error code?
RFC 4387 says to use normal http error codes. If there's no such
certificate that would be the familiar 404 code. I suppose we could say
that but I'd prefer not to repeat material from other specs.
What should be the response when the key server is aware that the
certificate has been revoked, and there is no replacement?
I'd think it's 404, no cert for you, or maybe 410 Gone.
The set of related things outside the main scope of the draft. A tricky
problem with key lookup has been privacy. The worry is that spammers or
phishers would try to use such a key discovery service to find more
victims.
Having been in the mail business for decades, I'm not worried about it.
Bad guys already have more addresses than they know what to do with, and
there are easier ways to scrape addresses than guessing one address
per URL. We've had PGP key servers forever and bad guys don't seem to
find them attractive.
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.
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.
R's,
John
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime