-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I thought it might be useful to set out the issues around "algorithmic
dexterity" that our DKIM2 design sets out to tackle.
The first thing to say is being able to move to new crypto algorithms is
a difficult practical problem and it's not just a case of copying
another protocols highly successful approach -- because there isn't much
(anything??) to copy!
Our approach has been to allow a DKIM2 header field to contain either
one or two signatures. The detailed syntax document (which I am trying
hard to get finished !) requires s1, a1, b1 and bh2 (viz the selector,
algorithm and the body & header hashes). [these were s,a,b,bh in DKIM1]
Optionally s2,a2,b2 and bh2 may also be provided.
If there is more than one signature then a verifier MUST check both of
them and __both__ must be valid.
The design has been done this way NOT to support elliptic curve
alongside RSA ... the documents will require verifiers to support both
systems and all the interop testing that we envisage will check for this
(and we will laugh and point at any systems that don't keep up).
Although senders could send both RSA and elliptic curve this would
merely be heating up the planet to no practical purpose!
The point of the second signature is to deal with a post-quantum (PQ)
world, in particular one where one of the existing signature schemes may
be compromised. Senders can sign with an existing scheme and also with a
PQ algorithm knowing that "with-it" verifiers will check the PQ value.
However, verifiers that have yet to understand the PQ algorithm will
still be able to verify mail -- yes they take a risk that the signature
has been forged, but that is on them -- the sender has done what they
can to avoid forgery.
ie: by using two signatures we don't need a flag day, senders and
verifiers can upgrade at their own speed.
The question then arises as to when a sender can stop using old
(compromised) algorithms (which they may wish to do for simplicity or
just to save energy).
DMARC should be able to come to our rescue here if a verifier that
understood PQ was to report a failure for the non-PQ selector. The
signature has actually passed (see above) but by reporting a failure
alongside reporting a pass for the PQ signature the sender can learn
that this particular destination does not need to be sent anything other
than a PQ signature.
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBaHdK+mHfC/FfW545EQLyDACcDsmxA4b3meuOnvLCFPZINB2xcCIAoMx4
uiZ9qVbG7gmWq30OIKAgGjS3
=Bm/G
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
