Thanks! I prefer *.p7s for CMS.
I looked over the rest of the document, and it seems fine.
It would be useful to add to the security considerations that the
Secretariat SHOULD/MUST be careful to have correct time on their
machines. Otherwise the Signing-Time attribute is not particularly
useful, as RFC 3852 doesn't require correctness of the value in that
attribute.
Was allowing end-to-end signatures considered? That would allow people
to be certain that the draft they retrieve from the IETF actually is the
same that was submitted to the IETF.
/Simon
Russ Housley <housley(_at_)vigilsec(_dot_)com> writes:
I just submitted -01, which changes ".sig" to ".p7s"
Russ
At 09:31 AM 1/24/2008, Russ Housley wrote:
Blake:
Sorry. I was clearly too terse.
Perhaps I'm missing something, but this line:
application/pkcs7-signature (SignedData) .p7s
lead me to believe that the .p7s was used along with the
application/pkcs7-signature MIME type. Since there was no MIME
encoding involve, I though this was the wrong selection.
I'm pleased to use .p7s if my interpretation was incorrect.
Russ
At 07:23 PM 1/23/2008, Blake Ramsdell wrote:
On Wed, Jan 23, 2008 at 03:34:46PM -0500, Russ Housley wrote:
Maybe I'm reading it wrong. Where is the MIME type in my specification?
* In your draft, you say:
The companion signature file has exactly the same file name as the
Internet-Draft, except that ".sig" is added to the end.
* If I understand it right, the content of this ".sig" file is a CMS
SignedData object with no content (a detached signature)
* In the S/MIME Message specification, the file extension that is used for a
CMS SignedData object with no content (a detached signature) is .p7s
* My observation, based on Simon's observation, is that the .p7s file
extension might be more in line with current practice
Now, I'm not sure that the universe would end if this convention wasn't
followed.
Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com