Signing one seems wrong, ie if the arc-seal only signs a single
arc-message-signature at a given hop, then the other signature can't be
verified, and if I can't handle the algorithm of the one that's covered,
then I can't verify the chain.
Currently away on a trip, I'll take a closer look when I
I see a rabbit hole here... So you're transitioning, so you sign twice (one
with your old, one with your new) before you send to me and hey, I'm
not the end point either, so I need to forward it along, but I'm also
transitioning, so I sign both of yours, twice? I would kind of have to,
wouldn'
Sure, with dkim. With arc, it's a bit more complicated, we need to
understand exactly how to sign the chain if there are multiple AMS and AS
headers. We probably want text about what happens if only one verifies as
well, and whether a hop should continue signing both paths or just one.
All quit
I see a rabbit hole here... So you're transitioning, so you sign twice (one
with your old, one with your new) before you send to me and hey, I'm
not the end point either, so I need to forward it along, but I'm also
transitioning, so I sign both of yours, twice? I would kind of have to,
wouldn't
And as a timely item on this topic, RFC 8032 (Edwards-Curve Digital
Signature Algorithm) was just published -
https://tools.ietf.org/html/rfc8032
It was specifically published to facilitate adoption in the Internet
community. The RFC makes no mention of any IPR claims as far as I can tell
from a q
