rfc3126.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,554 行 · 第 1/5 页
TXT
1,554 行
Network Working Group D. Pinkas
Request for Comments: 3126 Integris
Category: Informational J. Ross
N. Pope
Security & Standards
September 2001
Electronic Signature Formats
for long term electronic signatures
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 Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document defines the format of an electronic signature that can
remain valid over long periods. This includes evidence as to its
validity even if the signer or verifying party later attempts to deny
(i.e., repudiates the validity of the signature).
The format can be considered as an extension to RFC 2630 and RFC
2634, where, when appropriate additional signed and unsigned
attributes have been defined.
The contents of this Informational RFC is technically equivalent to
ETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C).
Individual copies of this ETSI deliverable can be downloaded from
http://www.etsi.org
Pinkas, et al. Informational [Page 1]
RFC 3126 Electronic Signature Formats September 2001
Table of Contents
1. Introduction 4
2 Overview 5
2.1 Aim 5
2.2 Basis of Present Document 5
2.3 Major Parties 6
2.4 Electronic Signatures and Validation Data 7
2.5 Forms of Validation Data 8
2.6 Extended Forms of Validation Data 11
2.7 Archive Validation Data 13
2.8 Arbitration 15
2.9 Validation Process 15
2.10 Example Validation Sequence 16
2.11 Additional optional features 21
3. Data structure of an Electronic Signature 22
3.1 General Syntax 22
3.2 Data Content Type 22
3.3 Signed-data Content Type 22
3.4 SignedData Type 22
3.5 EncapsulatedContentInfo Type 23
3.6 SignerInfo Type 23
3.6.1 Message Digest Calculation Process 23
3.6.2 Message Signature Generation Process 24
3.6.3 Message Signature Verification Process 24
3.7 CMS Imported Mandatory Present Attributes 24
3.7.1 Content Type 24
3.7.2 Message Digest 24
3.7.3 Signing Time 24
3.8 Alternative Signing Certificate Attributes 24
3.8.1 ESS Signing Certificate Attribute Definition 25
3.8.2 Other Signing Certificate Attribute Definition 25
3.9 Additional Mandatory Attributes 26
3.9.1 Signature policy Identifier 26
3.10 CMS Imported Optional Attributes 28
3.10.1 Countersignature 29
3.11 ESS Imported Optional Attributes 29
3.11.1 Content Reference Attribute 29
3.11.2 Content Identifier Attribute 29
3.11.3 Content Hints Attribute 29
3.12 Additional Optional Attributes 30
3.12.1 Commitment Type Indication Attribute 30
3.12.2 Signer Location attribute 32
3.12.3 Signer Attributes attribute 33
3.12.4 Content Time-Stamp attribute 34
3.13 Support for Multiple Signatures 34
3.13.1 Independent Signatures 34
3.13.2 Embedded Signatures 34
Pinkas, et al. Informational [Page 2]
RFC 3126 Electronic Signature Formats September 2001
4. Validation Data 35
4.1 Electronic Signature Time-Stamp 36
4.1.1 Signature Time-Stamp Attribute Definition 36
4.2 Complete Validation Data 37
4.2.1 Complete Certificate Refs Attribute Definition 38
4.2.2 Complete Revocation Refs Attribute Definition 38
4.3 Extended Validation Data 40
4.3.1 Certificate Values Attribute Definition 40
4.3.2 Revocation Values Attribute Definition 41
4.3.3 ES-C Time-Stamp Attribute Definition 42
4.3.4 Time-Stamped Certificates and CRLs Attribute Definition 42
4.4 Archive Validation Data 43
4.4.1 Archive Time-Stamp Attribute Definition 43
5. Security Considerations 44
5.1 Protection of Private Key 44
5.2 Choice of Algorithms 44
6. Conformance Requirements 45
6.1 Signer 45
6.2 Verifier using time-stamping 46
6.3 Verifier using secure records 46
7. References 47
8. Authors' Addresses 48
Annex A (normative): ASN.1 Definitions 49
A.1 Definitions Using X.208 (1988) ASN.1 Syntax 49
A.2 Definitions Using X.680 1997 ASN.1 Syntax 57
Annex B (informative): General Description 66
B.1 The Signature Policy 66
B.2 Signed Information 67
B.3 Components of an Electronic Signature 68
B.3.1 Reference to the Signature Policy 68
B.3.2 Commitment Type Indication 69
B.3.3 Certificate Identifier from the Signer 69
B.3.4. Role Attributes 70
B.3.4.1 Claimed Role 71
B.3.4.2 Certified Role 71
B.3.5 Signer Location 72
B.3.6 Signing Time 72
B.3.7 Content Format 73
B.4 Components of Validation Data 73
B.4.1 Revocation Status Information 73
B.4.2 CRL Information 74
B.4.3 OCSP Information 74
B.4.4 Certification Path 75
B.4.5 Time-Stamping for Long Life of Signature 76
B.4.6 Time-Stamping before CA Key Compromises 77
B.4.6.1 Time-Stamping the ES with Complete validation data 77
B.4.6.2 Time-Stamping Certificates and Revocation Information 78
B.4.7 Time-Stamping for Long Life of Signature 79
Pinkas, et al. Informational [Page 3]
RFC 3126 Electronic Signature Formats September 2001
B.4.8 Reference to Additional Data 80
B.4.9 Time-Stamping for Mutual Recognition 80
B.4.10 TSA Key Compromise 81
B.5 Multiple Signatures 81
Annex C (informative): Identifiers and roles 82
C.1 Signer Name Forms 82
C.2 TSP Name Forms 82
C.3 Roles and Signer Attributes 83
Full Copyright Statement 84
1. Introduction
This document is intended to cover electronic signatures for various
types of transactions, including business transactions (e.g.,
purchase requisition, contract, and invoice applications) where long
term validity of such signatures is important. This includes
evidence as to its validity even if the signer or verifying party
later attempts to deny (i.e., repudiates, see [ISONR]) the validity
of the signature).
Electronic signatures can be used for any transaction between an
individual and a company, between two companies, between an
individual and a governmental body, etc. This document is
independent of any environment. It can be applied to any environment
e.g., smart cards, GSM SIM cards, special programs for electronic
signatures etc.
An electronic signature produced in accordance with this document
provides evidence that can be processed to get confidence that some
commitment has been explicitly endorsed under a signature policy, at
a given time, by a signer under an identifier, e.g., a name or a
pseudonym, and optionally a role.
The European Directive on a community framework for Electronic
Signatures defines an electronic signature as: "data in electronic
form which is attached to or logically associated with other
electronic data and which serves as a method of authentication". An
electronic signature as used in the current document is a form of
advanced electronic signature as defined in the Directive.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
as shown) are to be interpreted as described in [RFC2119].
Pinkas, et al. Informational [Page 4]
RFC 3126 Electronic Signature Formats September 2001
2 Overview
2.1 Aim
The aim of this document is to define an Electronic Signature (ES)
that remains valid over long periods. This includes evidence as to
its validity even if the signer or verifying party later attempts to
deny (repudiates) the validity of the signature.
This document specifies the use of trusted service providers (e.g.,
Time-Stamping Authorities (TSA)), and the data that needs to be
archived (e.g., cross certificates and revocation lists) to meet the
requirements of long term electronic signatures. An electronic
signature defined by this document can be used for arbitration in
case of a dispute between the signer and verifier, which may occur at
some later time, even years later. This document uses a signature
policy, referenced by the signer, as the basis for establishing the
validity of an electronic signature.
2.2 Basis of Present Document
This document is based on the use of public key cryptography to
produce digital signatures, supported by public key certificates.
A Public key certificate is a public keys of a user, together with
some other information, rendered unforgeable by encipherment with the
private key of the Certification Authority (CA) which issued it
(ITU-T Recommendation X.509 [1]).
This document also specifies the uses of time-stamping services to
prove the validity of a signature long after the normal lifetime of
critical elements of an electronic signature and to support non-
repudiation. It also, as an option, defines the use of additional
time-stamps to provide very long-term protection against key
compromise or weakened algorithms.
This document builds on existing standards that are widely adopted.
This includes:
* RFC 2459 [RFC2459] Internet X.509 Public Key Infrastructure
Certificate and CRL Profile (PKIX);
* RFC 2630 [CMS] Crytographic Message Syntax (CMS);
* RFC 2634 [ESS] Enhanced Security Services (ESS);
* RFC 2439 [OCSP] One-line Certificate Status Protocol (OCSP);
* ITU-T Recommendation X.509 [1] Authentication framework;
* RFC (to be published) [TSP] PKIX Time Stamping protocol (TSP).
NOTE: See clause 8 for a full set of references.
Pinkas, et al. Informational [Page 5]
RFC 3126 Electronic Signature Formats September 2001
2.3 Major Parties
The following are the major parties involved in a business
transaction supported by electronic signatures as defined in this
document:
* the Signer;
* the Verifier;
* the Arbitrator;
* Trusted Service Providers (TSP).
A Signer is an entity that initially creates the electronic
signature. When the signer digitally signs over data using the
prescribed format, this represents a commitment on behalf of the
signing entity to the data being signed.
A verifier is an entity that verifies an evidence. (ISO/IEC 13888-1
[13]). Within the context of this document this is an entity that
validates an electronic signature.
An arbitrator, is an entity which arbitrates disputes between a
signer and a verifier when there is a disagreement on the validity of
a digital signature.
Trusted Service Providers (TSPs) are one or more entities that help
to build trust relationships between the signer and verifier. Use of
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?