On 2017-04-11 at 14:39 -0400, Viktor Dukhovni wrote:
> > On Apr 11, 2017, at 1:38 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> >
> > If the design were up to me, I'd not have published per-user keys.
> > Instead a site-wide trust-anchor record scales better to large user
> > communities, and mostly addresses your concerns.
>
> I should note that one can of course implement one's SMIMEA deployment
> in exactly this way, something along the lines of:
>
> *._smimecert.example.net. IN SMIMEA 2 1 1
> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
>
> would associate the same TA public key digest with every user, and would
> not enable user enumeration.
FWIW, I did something similar to this. Of course, there's a chicken/egg
problem in _getting_ the CA cert for private CAs, unless you put the
whole cert into DNS. And wildcards for something that large would be
cache-unpleasant, but I did the same thing I do for TLSA records: define
one SMIMEA record and CNAME to it elsewhere. Much more cache friendly.
I never thought I'd see the day that I willingly chose to deploy a
wildcard CNAME. :^D
$ORIGIN spodhuis.org.
*._smimecert CNAME _globnix-smimea
_globnix-smimea SMIMEA ( ; GlobnixCA5 PKIX-less trust anchor
02 00 00
; SKIP: binary blob for an ECDSA CA
; SMIMEA DANE-TA CERT FULL
)
I can't attest that this _works_. As far as I know, it's entirely
draft-spec compliant.
If anyone has tooling which actually _uses_ SMIMEA, I'm happy to send
you a test mail, or be given pointers to how to try it out. So far, I
have an SMIME setup to theoretically let others verify mail I send, and
that's it.
-Phil
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
