Re: eContentType for detached signatures

Paul:

>>>> 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 signatures.

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
   signature validation.

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.

Russ

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime