Your last point is incorrect. There have been many I-D signatures that
are correct using id-ct-asciiTextWithCRLF. There are software bugs, and
they are being worked, but some of the signatures are valid.
Are you saying there will be significant negative operational impact of
replacing those signatures with new ones? Given the "some" in that last
sentence, I'm not sure I can imagine the problems.
New signatures need to be generated for the I-D where there was a
canonicalization problem. The ones that did not have a canonicalization
problem do not need new signatures.
Quite true. We could have two different content types on the signatures, the
old and the new. That seems silly, though, if no one is relying on the old
What? We cannot know that yet.
From RFC 5485:
... At this point in time, it is important to support signature
validation of expired Internet-Drafts that are obtained from non-IETF
repositories. Therefore, the appropriate value for such a signed
attribute is unclear. This specification allows an Internet-Draft
and companion signature file to be stored anywhere without hindering
The point is that the files can be gathers from anywhere on the Internet.
Then, the digital signature will show that the file has not been changed from
the one posted by the IETF Secretariat. At some point, I hope this signature
validation will allow lawyers to perform this check and stop asking the IETF to
make such confirmations in subpoenas.
smime mailing list