Network Working Group R. Housley
Request for Comments: 5485 Vigil Security
Category: Informational March 2009
Digital Signatures on Internet-Draft Documents
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 Informational [Page 1]RFC 5485 Digital Signatures on Internet-Drafts March 20091. 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.
Shortly after 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
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
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].
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, both 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.
Housley Informational [Page 2]RFC 5485 Digital Signatures on Internet-Drafts March 20092. 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 usually have "ietf-" followed by
the 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