INTERNET DRAFT R. Housley
Intended Status: Informational Vigil Security
Expires: 14 November 2008 14 May 2008
Digital Signatures on Internet-Draft Documents
<draft-housley-internet-draft-sig-file-04.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
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.
Housley [Page 1]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
1. Introduction
This document specifies the conventions for storing a digital
signature on Internet-Drafts. The Cryptographic Message Syntax (CMS)
[CMS] is used to create a detached signature. The signature is
stored in a separate companion file so that no existing utilities are
impacted by the addition of the digital signature.
At the time the IETF Secretariat posts the Internet-Draft in the
repository, the digital signature is generated and posted as a
companion file in the same repository. The digital signature allows
anyone to confirm that the contents of the Internet-Draft have not
been altered since the time that the document was posted in the
repository.
The signature of the IETF Secretariat is intended to provide a
straightforward way for anyone to determine whether a particular file
contains the document that was made available by the IETF
Secretariat. The signing-time included by the IETF Secretariat
provides the wall clock time; it is not intended to provide a trusted
timestamp.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [STDWORDS].
1.2. ASN.1
The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is
a formal notation used for describing data protocols, regardless of
the programming language used by the implementation. Encoding rules
describe how the values defined in ASN.1 will be represented for
transmission. The Basic Encoding Rules (BER) [X.690] are the most
widely employed rule set, but they offer more than one way to
represent data structures. For example, definite length encoding and
indefinite length encoding are supported. This flexibility is not
desirable when digital signatures are used. As a result, the
Distinguished Encoding Rules (DER) [X.690] were invented. DER is a
subset of BER that ensures a single way to represent a given value.
For example, DER always employs definite length encoding.
2. Internet-Draft Signature File
All Internet-Draft file names begin with "draft-". The next portion
of the file name depends on the source of the document. For example,
documents from IETF working groups will have "ietf-" followed by the
Housley [Page 2]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
working group abbreviation, and this is followed by a string that
helps people figure out the subject of the document.
All Internet-Draft file names end with a hyphen followed by a two
digit version number and a suffix. The suffix indicates the type of
file. A plain text file with a suffix of ".txt" is required. Other
formats may also be provided, and they employ the appropriate suffix
for the file format.
The companion signature file has exactly the same file name as the
Internet-Draft, except that ".p7s" is added to the end. This file
name suffix conforms to the conventions in [MSG]. Here are a few
example names:
Internet-Draft: draft-ietf-example-widgets-03.txt
Signature File: draft-ietf-example-widgets-03.txt.p7s
Internet-Draft: draft-ietf-example-widgets-03.ps
Signature File: draft-ietf-example-widgets-03.ps.p7s
Internet-Draft: draft-housley-internet-draft-sig-file-00.txt
Signature File: draft-housley-internet-draft-sig-file-00.txt.p7s
The IETF Secretariat will post the signature file in the repository
at the same time that the Internet-Draft is posted.
2.1. Need for Canonicalization of Text Files
In general, the content of the Internet-Draft is treated like a
single octet string for the generation of the digital signature.
Unfortunately, the plain text file requires canonicalization to avoid
signature validation problems. The primary concern is the manner in
which different operating systems indicate the end of a line of text.
Some systems use a single new-line character, and other systems use
the combination of the carriage-return character followed by a line-
feed character. For the digital signature to validate properly, a
single convention must be employed.
2.2. Text File Canonicalization
The canonicalization procedure follows the conventions used for text
files in the File Transfer Protocol (FTP) [FTP]. Such files must be
supported by FTP implementations, so code reuse seems likely.
The canonicalization procedure converts the data from its internal
character representation to the standard 8-bit NVT-ASCII
representation (see TELNET [TELNET]). In accordance with the NVT
standard, the <CRLF> sequence MUST be used to denote the end of a
Housley [Page 3]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
line of text. Using the standard NVT-ASCII representation means that
data MUST be interpreted as 8-bit bytes.
The form-feed nonprintable character (0x0C) is expected in Internet-
Drafts. Other nonprintable characters, such as tab and backspace,
are not expected, but they do occur. For robustness, any
nonprintable characters (ones outside the range 0x20 to 0x7E) MUST
NOT be changed in any way not covered by the rules for end-of-line
handling in the previous paragraph.
Note: This text file canonicalization procedure is consistent with
the ASCII NVT Definition offered in Appendix B of RFC 5198 [UFNI].
2.3. Canonicalization of Other File Formats
No canonicalization is needed for the other file formats discussed in
this document. They are treated as a simple sequence of octets by
the signature algorithm.
3. CMS Profile
CMS is used to construct the detached signature of the Internet-
Draft. The CMS ContentInfo content type MUST always be present, and
it MUST encapsulate the CMS SignedData content type. Since a
detached signature is being created, the CMS SignedData content type
MUST NOT encapsulate the Internet-Draft. The CMS detached signature
is summarized by:
ContentInfo {
contentType id-signedData, -- (1.2.840.113549.1.7.2)
content SignedData
}
SignedData {
version CMSVersion, -- Always set to 3
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates CertificateSet, -- Secretariat certificate(s)
crls CertificateRevocationLists, -- Optional
signerInfos SET OF SignerInfo -- Only one signer
}
Housley [Page 4]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
SignerInfo {
version CMSVersion, -- Always set to 3
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs SignedAttributes, -- Always present
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs UnsignedAttributes -- Optional
}
EncapsulatedContentInfo {
eContentType id-ct-asciiTextWithCRLF,
-- (1.2.840.113549.1.9.16.1.27)
eContent OCTET STRING -- Always absent
}
3.1. ContentInfo
The CMS requires the outer-most encapsulation to be ContentInfo
[CMS]. The fields of ContentInfo are used as follows:
contentType
indicates the type of the associated content, and for the
detached Internet-Draft signature file, the encapsulated type
is always SignedData, so the id-signedData
(1.2.840.113549.1.7.2) object identifier MUST be present in
this field.
content
holds the content, and for the detached Internet-Draft
signature file, the content is always a SignedData content.
3.2. SignedData
The SignedData content type [CMS] contains the signature of the
Internet-Draft and information to aid in the validation of that
signature. The fields of SignedData are used as follows:
version
is the syntax version number, and for this specification, the
version number MUST be set to 3.
digestAlgorithms
is a collection of one-way hash function identifiers. It MUST
contain the identifier used by the IETF Secretariat to generate
the digital signature. See the discussion of digestAlgorithm
in Section 3.2.1.
Housley [Page 5]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
encapContentInfo
is the signed content, including a content type identifier.
Since a detached signature is being created, it does not
encapsulate the Internet-Draft. The use of the
EncapsulatedContentInfo type is discussed further in Section
3.2.2.
certificates
is an optional collection of certificates. It SHOULD include
the X.509 certificate needed to validate the digital signature
value. Certification Authority (CA) certificates and end
entity certificates MUST conform to the certificate profile
specified in [PKIX1].
crls
is an optional collection of certificate revocation lists
(CRLs). It SHOULD NOT include any CRLs; however, any CRLs that
are present MUST conform to the CRL profile specified in
[PKIX1].
signerInfos
is a collection of per-signer information, and for this
specification, each item in the collection must represent the
IETF Secretariat. More than one SignerInfo MAY appear to
facilitate transitions between keys or algorithms. The use of
the SignerInfo type is discussed further in Section 3.2.1.
3.2.1. SignerInfo
The IETF Secretariat is represented in the SignerInfo type. The
fields of SignerInfo are used as follows:
version
is the syntax version number. In this specification, the
version MUST be set to 3.
sid
identifies the IETF Secretariat's public key. In this
specification, the subjectKeyIdentifier alternative is always
used, which identifies the public key directly. This
identifier MUST match the value included in the
subjectKeyIdentifier certificate extension in the IETF
Secretariat's X.509 certificate.
digestAlgorithm
identifies the one-way hash function, and any associated
parameters, used by the IETF Secretariat to generate the
digital signature.
Housley [Page 6]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
signedAttrs
is an optional set of attributes that are signed along with the
content. The signedAttrs are optional in the CMS, but
signedAttrs is required by this specification. The SET OF
Attribute must be encoded with the distinguished encoding rules
(DER) [X.690]. Section 2.2.3 of this document lists the signed
attributes that MUST be included in the collection. Other
signed attributes MAY also be included.
signatureAlgorithm
identifies the digital signature algorithm, and any associated
parameters, used by the IETF Secretariat to generate the
digital signature.
signature
is the digital signature value generated by the IETF
Secretariat.
unsignedAttrs
is an optional set of attributes that are not signed. Unsigned
attributes are usually omitted; however, the unsigned
attributes MAY hold a trusted timestamp generated in accordance
with [TSP]. Section 2.2.4 of [TSP] provides more information
about this unsigned attribute.
3.2.2. EncapsulatedContentInfo
The EncapsulatedContentInfo structure contains a content type
identifier. Since a detached signature is being created, it does not
encapsulate the Internet-Draft. The fields of
EncapsulatedContentInfo are used as follows:
eContentType
is an object identifier that uniquely specifies the content
type. The content type associated with the plain text file
MUST be id-ct-asciiTextWithCRLF. Other file formats may also
be posted, and the appropriate content type for each format is
discussed in Section 4. Additional file formats can be added
if the Internet community chooses.
eContent
is optional. When an encapsulated signature is generated, the
content to be signed is carried in this field. Since a
detached signature is being created, eContent MUST be absent.
Housley [Page 7]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
3.2.3. Signed Attributes
The IETF Secretariat MUST digitally sign a collection of attributes
along with the Internet-Draft. Each attribute in the collection MUST
be DER-encoded. The syntax for attributes is defined in [X.501], and
the X.500 Directory provides a rich attribute syntax. A very simple
subset of this syntax is used extensively in [CMS], where
ATTRIBUTE.&Type and ATTRIBUTE.&id are the only parts of the ATTRIBUTE
class that are employed.
Each of the attributes used with this CMS profile has a single
attribute value. Even though the syntax is defined as a SET OF
AttributeValue, there MUST be exactly one instance of AttributeValue
present.
The SignedAttributes syntax within signerInfo is defined as a SET OF
Attribute. The SignedAttributes MUST include only one instance of
any particular attribute.
The IETF Secretariat MUST include the content-type, message-digest,
and signing-time attributes. The IETF Secretariat MAY also include
the binary-signing-time signed attribute as well as any other
attribute that is deemed appropriate. The intent is to allow
additional signed attributes to be included if a future need is
identified. This does not cause an interoperability concern because
unrecognized signed attributes are ignored at verification.
3.2.3.1. Content-Type Attribute
A content-type attribute is required to contain the same object
identifier as the content type contained in the
EncapsulatedContentInfo. The appropriate content type for each
format is discussed in Section 4. The IETF Secretariat MUST include
a content-type attribute containing the appropriate content type.
Section 11.1 of [CMS] defines the content-type attribute.
3.2.3.2. Message-Digest Attribute
The IETF Secretariat MUST include a message-digest attribute, having
as its value the output of a one-way hash function computed on the
Internet-Draft that is being signed. Section 11.2 of [CMS] defines
the message-digest attribute.
Housley [Page 8]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
3.2.3.3. Signing-Time Attribute
The IETF Secretariat MUST include signing-time attribute, specifying
the time, based on the local system clock, at which the digital
signature was applied to the Internet-Draft. Section 11.3 of [CMS]
defines the content-type attribute.
3.2.3.4. Binary-Signing-Time Attribute
The IETF Secretariat MAY include a binary-signing-time attribute,
specifying the time at which the digital signature was applied to the
Internet-Draft. If present, the time that is represented MUST match
the time represented in the signing-time attribute. The binary-
signing-time attribute is defined in [BinTime].
3.2.4. Unsigned Attributes
Unsigned attributes are usually omitted. However, an unsigned
attribute MAY hold a trusted timestamp generated in accordance with
[TSP]. The idea is to time-stamp the IETF Secretariat digital
signature to prove that it was created before a given time. If the
IETF Secretariat's certificate is revoked the time stamp allows a
verifier to know whether the signature was created before or after
the revocation date. Appendix A of [TSP] defines the signature time-
stamp attribute that can be used to time-stamp a digital signature.
4. Content Types
This section lists the content types that are used in this
specification. The eContentType field as described in Section 3.2.2
contains a content type identifier, and the same value appears in the
content-type attribute as described in Section 3.2.3.1.
The following table lists the file formats and the associated content
type.
File Format Content Type
----------- ------------
Plain text id-ct-asciiTextWithCRLF
Extensible Markup Language (XML) id-ct-xml
Portable Document Format (PDF) id-ct-pdf
PostScript id-ct-postscript
Housley [Page 9]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
The object identifiers associated with the content types listed in
the above table are:
id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 }
id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 }
id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 }
id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 }
5. Security Considerations
The IETF Secretariat MUST protect its private key. The use of a
hardware security module is RECOMMENDED because compromise of the
IETF Secretariat's private key permits masquerade.
The generation of a public/private key pair for signature operations
relies on random number generation. The use of an inadequate pseudo-
random number generator (PRNG) can result in little or no security.
An attacker may find it much easier to reproduce the PRNG environment
that produced the key pair, searching the resulting small set of
possibilities, rather than brute force searching the whole private
key space. The generation of quality random numbers is difficult,
but [RANDOM] offers important guidance in this area.
The IETF Secretariat should be aware that cryptographic algorithms
become weaker with time. As new cryptoanalysis techniques are
developed and computing performance improves, the work factor to
break a particular digital signature algorithm or one-way hash
function will be reduced. Therefore, it SHOULD be possible to
migrate these algorithms. That is, the IETF Secretariat SHOULD be
prepared for the supported algorithms to change over time.
The IETF Secretariat must take care to use the correct time in
signing-time and binary-signing-time attributes. The inclusion of a
compatible date within the Internet-Draft by the authors and the
signing time attributes by the IETF Secretariat provides confidence
about the date that the Internet-Draft was posted to the repository.
Housley [Page 10]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
6. Deployment and Operational Considerations
The private key used to generate the IETF Secretariat signature ought
to be stored in a hardware security module to provide protection from
unauthorized disclosure. While the hardware security module will be
operated by the IETF Secretariat, it ought to be owned by the IETF
Trust. Accordingly, the Trustees of the IETF Trust will designate an
appropriate certification authority to issue a certificate to the
IETF Secretariat, and they will and approve any procedures used by
the IETF Secretariat for signing documents consistent with this
specification.
7. References
7.1. Normative References
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[PKIX1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation.
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding rules: Specification
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
and Distinguished Encoding Rules (DER).
7.2. Informative References
[BinTime] Housley, R., "BinaryTime: An Alternate Format for
Representing Date and Time in ASN.1", RFC 4049,
April 2005.
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
Housley [Page 11]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
[OpenSSL] http://www.openssl.org/
[RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Recommendations for Security", RFC 4086, June 2005.
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
[UFNI] J. Klensin, J. and M. Padlipsky, "Unicode Format for
Network Interchange", RFC 5198, March 2008.
[X.501] ITU-T Recommendation X.501: Information Technology -
Open Systems Interconnection - The Directory: Models,
1993.
8. Acknowledgements
The idea for the Internet-Draft signature file came from a discussion
with Scott Bradner at IETF 69 in Chicago. Many helpful suggestions
came from Jim Schaad.
9. IANA Considerations
None.
{{{ RFC Editor: Please remove this section prior to publication. }}}
Housley [Page 12]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
Appendix: A
OpenSSL 0.9.9 [OpenSSL] includes an implementation of CMS. The
following command line can be used to verify an Internet-Draft
signature:
openssl cms -verify -CAfile <cert-file> -content <internet-draft> /
-inform DER -in <p7s-file> -out /dev/null
The arguments need to be provided as follows:
<cert-file>
the name of the file containing the trust anchor, which is
typically the self-signed certificate of the certification
authority that issued a certificate to the IETF Secretariat.
<internet-draft>
the name of the file containing the signed Internet-Draft.
<p7s-file>
the name of the file containing the detached signature that was
generated in accordance with this specification.
Author's Address
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com
Copyright and IPR Statements
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
Housley [Page 13]
INTERNET DRAFT Digital Signatures on Internet-Drafts May 2008
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Housley [Page 14]
