Digital Signatures on RFC and Internet-Draft Documents
draft-housley-rfc-and-id-signatures-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2016-02-23
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
INTERNET-DRAFT                                                  R. Housley
Intended Status: Informational                              Vigil Security
Obsoletes RFC 5485 (once approved)
Expires: 25 August 2016                                   23 February 2016

         Digital Signatures on RFC and Internet-Draft Documents
              <draft-housley-rfc-and-id-signatures-00.txt>

Abstract

   This document specifies the conventions for digital signatures on
   RFCs and Internet-Draft documents.  For most file types, 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.  For Portable Document Format (PDF) files types, embedded
   signatures are supported.

   This document (once approved) obsoletes RFC 5485.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on 25 August 2016.

Copyright Notice

   Copyright (c) 2016 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Housley                                                         [Page 1]
INTERNET-DRAFT                                             February 2016

   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   This document specifies the conventions for storing a digital
   signature on RFC and Internet-Draft documents.   For most file types,
   the Cryptographic Message Syntax (CMS) [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.  For Portable Document Format (PDF) files types,
   embedded signatures are supported.

   This document (once approved) obsoletes RFC 5485 [RFC5485], which
   contains the conventions that have been used by IETF Secretariat to
   digitally sign Internet-Drafts for the past few years.

   The digital signature allows anyone to confirm that the contents of
   the RFC or Internet-Draft have not been altered since the time that
   the document was signed.

   For RFCs, the RFC Production Center [RFCED] will generate the digital
   signature as the final step before passing the completed documents to
   the RFC Publisher.

   For Internet-Drafts, the IETF Secretariat will generate the digital
   signature shortly after the Internet-Draft is posted in the
   repository.

   The signature of the RFC Editor or 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
   RFC Editor or the IETF Secretariat.  The signing-time associated with
   the signature provides the wall clock time at which the signature was
   generate; 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

Housley                                                         [Page 2]
INTERNET-DRAFT                                             February 2016

   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
Show full document text