Re: [pkix] Key lookup service via draft-bhjl-x509-srv-00

["John R Levine" <[e-mail]>]

> 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