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 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,
On Tue, 24 Jan 2017, Brandon Long wrote:
I'm not opposed to requiring support for different encryption algorithms,
but we really need to clean up and understand exactly how we handle
migration to a new algorithm, probably with a section in the draft specific
to it with an example.
Fortunately,
>It's been awhile since I've seen this, so it may not be a problem anymore.
>There is no obviously correct
>thing that someone won't screw up.
>
>It's probably better to specify how to put multiple strings together. RFC
>7208 has words that can probably be
>reused without modification.
Might
On January 23, 2017 10:52:06 AM EST, John Levine wrote:
>>As I recall there are issues using keys bigger than 1024 bits because
>>construction and/or correct interpretation of TXT records that contain
>keys
>>of that size or bigger has been problematic due to DNS provisioning
>As I recall there are issues using keys bigger than 1024 bits because
>construction and/or correct interpretation of TXT records that contain keys
>of that size or bigger has been problematic due to DNS provisioning
>software that does the former wrong and DKIM verifiers that do the latter