Key lookup service via draft-bhjl-x509-srv-00

(was from: why you shouldn't even try to canonicalize local parts)

On Sun, Mar 13, 2016 at 1:25 PM, John Levine <[email protected]> wrote:
>
>
> If you're going to do local signing, the reasonable way to publish the
> signing cert is with DNSSEC as I suggest in draft-bhjl-x509-srv-00
> section 5.
>

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.  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.  As a key lookup
service this proposal resolves the barrier of an initial key lookup i.e.
given an email address for a person the sender has never corresponded with,
can provide a means to get their certificate.  Currently initial
conversations must happen in cleartext until the certificates are
exchanged.  Also as the author points out, this service can also provides a
means to potentially resolve potentially different email addresses for the
same user i.e. resolving capitalization differences or addresses with
subaddressing.  The draft proposes using DNSSEC to  authenticates and
protects the integrity of the the SRV record.

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?  What should
be the response when the key server is aware that the certificate has been
revoked, and there is no replacement?  The draft specifies that if multiple
certificates are returned, that they are embedded in a mime/multipart
format.  It may be useful to always return in this format even for a single
certificate.  The multipart format likely was to allow for multiple entity
certificates to be returned.  In another discussion it was mentioned
providing the full certificate chain to the trust anchor certificate would
be very helpful for interoperability as not everyone may have access to the
CA certificates.  Providing further structure via content-description could
allow for embedding full chains with multiple entity certificates.

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.  Understandably the authors may want to keep the scope narrow but
ideas would certainly be welcome.  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.  One purely
PKIX based trust solution may be to adapt the mechanism that Margolis used
in draft-margolis-smtp-sts-00
<https://tools.ietf.org/html/draft-margolis-smtp-sts-00> to mirror the SRV
record on an HTTPS served page as an intermediate step.

-Wei

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