Subject: Please review draft-housley-internet-draft-sig-file-00.txt

From: Russ Housley <[email-masked]>
Date: Wed, 23 Jan 2008 10:05:10 -0500

This document makes use of CMS, so I'd appreciate review from this group.

Russ

>draft-housley-internet-draft-sig-file-00.txt has been submitted to 
>the IETF repository.
>
>Filename:       draft-housley-internet-draft-sig-file
>Revision:       00
>Title:          Digital Signatures on Internet-Draft Documents
>Creation_date:  2008-01-23
>WG ID:          Independent Submission
>Number_of_pages: 12
>
>Abstract:
>This document specifies the conventions for digital signatures on
>Internet-Drafts.  The Cryptographic Message Syntax (CMS) is used to
>create a detached signature, which is stored in a separate companion
>file so that no existing utilities are impacted by the addition of
>the digital signature.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 23 Jan 2008 18:40:24 +0100

While strictly not CMS related (is there a more appropriate mailing list
to discuss the draft?), I wonder whether using *.sig as the extension
for detached CMS signatures is standardized?  That file extension is
frequently used for OpenPGP signatures in practice.

It may be nice to consider using another file extension, to avoid format
confusion.  I realize that if use of *.sig is already wide-spread for
detached CMS signatures, the document might as well follow that
precedent.  Further, I don't know whether the practice of using *.sig
for OpenPGP signatures is standardized.

/Simon

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Jan 2008 13:56:32 -0500

Simon:

You raise an important consideration.  I do not know the answer.  Do others?

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Jan 2008 11:06:00 -0800

>frequently used for OpenPGP signatures in practice.

It is not standardized for either (I believe), and it is already 
common for both.

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Jan 2008 15:34:46 -0500

Blake:

Maybe I'm reading it wrong.  Where is the MIME type in my specification?

Russ

At 03:19 PM 1/23/2008, Blake Ramsdell wrote:
>On Wed, Jan 23, 2008 at 06:40:24PM +0100, Simon Josefsson wrote:
> > for detached CMS signatures is standardized?
>
>RFC 3851 (the S/MIME message spec) indicates the use of ".p7s" for detached
>signatures in section 3.2.1:
>
>] 3.2.1. The name and filename Parameters
>]
>]    For the application/pkcs7-mime, sending agents SHOULD emit the
>]    optional "name" parameter to the Content-Type field for compatibility
>]    with older systems.  Sending agents SHOULD also emit the optional
>]    Content-Disposition field [CONTDISP] with the "filename" parameter.
>]    If a sending agent emits the above parameters, the value of the
>]    parameters SHOULD be a file name with the appropriate extension:
>] ...
>] application/pkcs7-signature (SignedData)                .p7s
>
>In the old days I made a .p7s handler for Windows so if you double-clicked on
>a .p7s file, it would look for another file with the same base filename and
>validate the signature on it. Not sure if this practice is common with
>contemporary agents.
>
>Blake
>--
>Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

---

From: Blake Ramsdell <[email-masked]>
Date: Wed, 23 Jan 2008 12:19:48 -0800

Blake

---

From: Blake Ramsdell <[email-masked]>
Date: Wed, 23 Jan 2008 16:23:11 -0800

>  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

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 24 Jan 2008 17:00:23 +1300

>You raise an important consideration.  I do not know the answer.  Do others?

The de facto standard for classic PGP is .asc (for ASCII-armoured detached
sigs).  GPG used to use .sig, but I don't know if it still does.

What's wrong with using the traditional .p7s?

Peter.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 Jan 2008 08:54:24 +0100

> sigs).  GPG used to use .sig, but I don't know if it still does.

GnuPG uses *.sig for detached binary signatures, and *.asc for ASCII
armored.  GnuPG still does this, all releases of my projects are signed
with a *.sig file.  I wouldn't be surprised if this was inherited from
original PGP, but I don't know for sure.

> What's wrong with using the traditional .p7s?

I would prefer that as well, unless there are good reasons not to.

/Simon

---

From: Russ Housley <[email-masked]>
Date: Thu, 24 Jan 2008 09:31:39 -0500

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 24 Jan 2008 13:51:42 -0500

I just submitted -01, which changes ".sig" to ".p7s"

Russ

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 Jan 2008 22:05:20 +0100

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 24 Jan 2008 18:02:17 -0500

>useful, as RFC 3852 doesn't require correctness of the value in that

Good suggestion.  Will do.

>same that was submitted to the IETF.

Yes, I thought about it, but I do not want to require authors to have 
certificates.

Russ