[Top] [All Lists]

Re: [smime] eContentType for detached signatures

2014-05-02 10:52:49

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


smime mailing list