draft-ietf-smime-cades-06.txt   draft-ietf-smime-cades-07.txt 
S/MIME Working Group D.Pinkas (Bull SAS) S/MIME Working Group D.Pinkas (Bull SAS)
INTERNET-DRAFT N.Pope (Thales eSecurity) INTERNET-DRAFT N.Pope (Thales eSecurity)
Expires April 2008 J.Ross (Security and Standards) Expires May 2008 J.Ross (Security and Standards)
Obsoletes: RFC 3126 October 2007 Obsoletes: RFC 3126 November 2007
Intended status: Informational Intended status: Informational
CMS Advanced Electronic Signatures (CAdES) CMS Advanced Electronic Signatures (CAdES)
<draft-ietf-smime-cades-06.txt> <draft-ietf-smime-cades-07.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines the format of an electronic signature that can This document defines the format of an electronic signature that can
remain valid over long periods. This includes evidence as to its remain valid over long periods. This includes evidence as to its
validity even if the signer or verifying party later attempts to deny validity even if the signer or verifying party later attempts to deny
(i.e., repudiates the validity of the signature). (i.e., repudiates) the validity of the signature.
The format can be considered as an extension to RFC 3852 [4] and The format can be considered as an extension to RFC 3852 [4] and
RFC 2634 [5], where, when appropriate additional signed and RFC 2634 [5], where, when appropriate, additional signed and
unsigned attributes have been defined. unsigned attributes have been defined.
The contents of this Informational RFC amounts to a The contents of this Informational RFC amounts to a
transposition of the ETSI TS 101 733 V.1.7.3 (CMS Advanced transposition of the ETSI TS 101 733 V.1.7.4 (CMS Advanced
Electronic Signatures - CAdES) [TS101733] and is technically Electronic Signatures - CAdES) [TS101733] and is technically
equivalent to it. equivalent to it.
The technical contents of this specification are maintained by ETSI.
The ETSI TS and further updates are available free of charge at :
http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx
Table of Contents Table of Contents
1. Introduction 6 1. Introduction 6
2. Scope 6 2. Scope 6
3. Definitions and abbreviations 8 3. Definitions and abbreviations 8
3.1 Definitions 8 3.1 Definitions 8
3.2 Abbreviations 11 3.2 Abbreviations 11
skipping to change at page 3, line 47 skipping to change at page 3, line 47
7.4 Time-stamp token format 55 7.4 Time-stamp token format 55
7.5 Name and attribute formats 55 7.5 Name and attribute formats 55
7.6 Attribute certificate 56 7.6 Attribute certificate 56
8. Conformance requirements 56 8. Conformance requirements 56
8.1 CAdES-Basic Electronic Signature (CAdES-BES) 56 8.1 CAdES-Basic Electronic Signature (CAdES-BES) 56
8.2 CAdES-Explicit Policy-based Electronic Signature 57 8.2 CAdES-Explicit Policy-based Electronic Signature 57
8.3 Verification using time-stamping 57 8.3 Verification using time-stamping 57
8.4 Verification using secure records 58 8.4 Verification using secure records 58
9. Security considerations 58 9. IANA Considerations 58
9.1 Protection of private key 58
9.2 Choice of algorithms 58
10. IANA Considerations 59
11. References 59 10. References 58
11.1 Normative references 58 10.1 Normative references 58
11.2 Informative references 60 10.2 Informative references 59
12. Authors' addresses 62 11. Authors' addresses 62
13. Acknowledgments 63 12. Acknowledgments 62
Annex A (normative): ASN.1 definitions 64 Annex A (normative): ASN.1 definitions 63
A.1 Signature format definitions using X.208 ASN.1 syntax 64 A.1 Signature format definitions using X.208 ASN.1 syntax 63
A.2 Signature format definitions using X.680 ASN.1 syntax 72 A.2 Signature format definitions using X.680 ASN.1 syntax 71
Annex B (informative): Extended forms of Electronic Signatures 81 Annex B (informative): Extended forms of Electronic Signatures 80
B.1 Extended forms of validation data 81 B.1 Extended forms of validation data 80
B.1.1 CAdES-X Long 82 B.1.1 CAdES-X Long 81
B.1.2 CAdES-X Type 1 83 B.1.2 CAdES-X Type 1 82
B.1.3 CAdES-X Type 2 84 B.1.3 CAdES-X Type 2 83
B.1.4 CAdES-X Long Type 1 and CAdES-X Long Type 2 85 B.1.4 CAdES-X Long Type 1 and CAdES-X Long Type 2 85
B.2 Timestamp extensions 87 B.2 Timestamp extensions 86
B.3 Archive validation data (CAdES-A) 88 B.3 Archive validation data (CAdES-A) 87
B.4 Example validation sequence 90 B.4 Example validation sequence 89
B.5 Additional optional features 95 B.5 Additional optional features 94
Annex C (informative):General description 96 Annex C (informative):General description 95
C.1 The signature policy 96 C.1 The signature policy 95
C.2 Signed information 97 C.2 Signed information 96
C.3 Components of an electronic signature 97 C.3 Components of an electronic signature 96
C.3.1 Reference to the signature policy 97 C.3.1 Reference to the signature policy 96
C.3.2 Commitment type indication 98 C.3.2 Commitment type indication 97
C.3.3 Certificate identifier from the signer 98 C.3.3 Certificate identifier from the signer 97
C.3.4 Role attributes 99 C.3.4 Role attributes 98
C.3.4.1 Claimed role 99 C.3.4.1 Claimed role 98
C.3.4.2 Certified role 100 C.3.4.2 Certified role 99
C.3.5 Signer location 100 C.3.5 Signer location 99
C.3.6 Signing time 100 C.3.6 Signing time 99
C.3.7 Content format 101 C.3.7 Content format 100
C.3.8 Content hints 101 C.3.8 Content hints 100
C.3.9 Content cross referencing 101 C.3.9 Content cross referencing 100
C.4 Components of validation data 101 C.4 Components of validation data 100
C.4.1 Revocation status information 101 C.4.1 Revocation status information 100
C.4.1.1 CRL information 102 C.4.1.1 CRL information 101
C.4.1.2 OCSP information 102 C.4.1.2 OCSP information 101
C.4.2 Certification path 103 C.4.2 Certification path 102
C.4.3 Time-stamping for long life of signatures 103 C.4.3 Time-stamping for long life of signatures 102
C.4.4 Time-stamping for long life of signature before CA key C.4.4 Time-stamping for long life of signature before CA key
compromises 104 compromises 103
C.4.4.1 Time-stamping the ES with complete validation data 105 C.4.4.1 Time-stamping the ES with complete validation data 104
C.4.4.2 Time-stamping certificates and revocation information C.4.4.2 Time-stamping certificates and revocation information
references 106 references 105
C.4.5 Time-stamping for archive of signature 107 C.4.5 Time-stamping for archive of signature 106
C.4.6 Reference to additional data 108 C.4.6 Reference to additional data 107
C.4.7 Time-stamping for mutual recognition 108 C.4.7 Time-stamping for mutual recognition 107
C.4.8 TSA key compromise 109 C.4.8 TSA key compromise 108
C.5 Multiple signatures 109 C.5 Multiple signatures 108
Annex D (informative):Data protocols to interoperate with TSPs 110 Annex D (informative):Data protocols to interoperate with TSPs 109
D.1 Operational protocols 110 D.1 Operational protocols 109
D.1.1 Certificate retrieval 110 D.1.1 Certificate retrieval 109
D.1.2 CRL retrieval 110 D.1.2 CRL retrieval 109
D.1.3 OnLine certificate status 109
D.1.4 Time-stamping 109
D.1.3 OnLine certificate status 110 D.2 Management protocols 109
D.1.4 Time-stamping 110 D.2.1 Request for certificate revocation 109
D.2 Management protocols 110
D.2.1 Request for certificate revocation 110
Annex E (informative): Guidance on naming 111 Annex E (informative): Security Considerations 110
E.1 Allocation of names 111 E.1 Protection of private key 110
E.2 Providing access to registration information 111 E.2 Choice of algorithms 110
E.3 Naming schemes 112
E.3.1 Naming schemes for individual citizens 112
E.3.2 Naming schemes for employees of an organization 113
Annex F (informative): Example structured contents and MIME 114 Annex F (informative): Example structured contents and MIME 111
F.1 General description 114 F.1 General description 111
F.2 Header information 114 F.2 Header information 111
F.3 Content encoding 116 F.3 Content encoding 113
F.4 Multi-part content 116 F.4 Multi-part content 113
F.5 S/MIME 116 F.5 S/MIME 113
Annex G (informative): Relationship to the European Directive Annex G (informative): Relationship to the European Directive
and EESSI 119 and EESSI 115
G.1 Introduction 119 G.1 Introduction 116
G.2 Electronic signatures and the directive 119 G.2 Electronic signatures and the directive 116
G.3 ETSI electronic signature formats and the directive 120 G.3 ETSI electronic signature formats and the directive 117
G.4 EESSI standards and classes of electronic signature 120 G.4 EESSI standards and classes of electronic signature 117
G.4.1 Structure of EESSI standardization 120 G.4.1 Structure of EESSI standardization 117
G.4.2 Classes of electronic signatures 121 G.4.2 Classes of electronic signatures 118
G.4.3 EESSI classes and the ETSI electronic signature format 121 G.4.3 EESSI classes and the ETSI electronic signature format 118
Annex H (informative): APIs for the generation and verification Annex H (informative): APIs for the generation and verification
of electronic signatures tokens 121 of electronic signatures tokens 118
H.1 Data framing 122 H.1 Data framing 119
H.2 IDUP-GSS-APIs defined by the IETF 123 H.2 IDUP-GSS-APIs defined by the IETF 120
H.3 CORBA security interfaces defined by the OMG 124 H.3 CORBA security interfaces defined by the OMG 121
Annex I (informative):Cryptographic algorithms 126
I.1 Digest algorithms 126
I.1.1 SHA-1 126
I.1.2 General 126
I.2 Digital signature algorithms 127
I.2.1 DSA 127
I.2.2 RSA 127
I.2.3 General 128
Annex J (informative): Changes from the previous version 130 Annex I (informative):Cryptographic algorithms 123
I.1 Digest algorithms 123
I.1.1 SHA-1 123
I.1.2 General 123
I.2 Digital signature algorithms 124
I.2.1 DSA 124
I.2.2 RSA 124
I.2.3 General 125
Full Copyright Statement 131 Annex J (informative): Guidance on naming 127
J.1 Allocation of names 127
J.2 Providing access to registration information 127
J.3 Naming schemes 128
J.3.1 Naming schemes for individual citizens 128
J.3.2 Naming schemes for employees of an organization 128
Disclaimer 131 Annex K (informative): Changes from the previous version 130
Full Copyright Statement 131
Intellectual Property 131 Intellectual Property 131
Acknowledgements 132
1. Introduction 1. Introduction
This document is intended to cover electronic signatures for various This document is intended to cover electronic signatures for various
types of transactions, including business transactions (e.g. purchase types of transactions, including business transactions (e.g. purchase
requisition, contract, and invoice applications) where long term requisition, contract, and invoice applications) where long term
validity of such signatures is important. This includes evidence as validity of such signatures is important. This includes evidence as
to its validity even if the signer or verifying party later attempts to its validity even if the signer or verifying party later attempts
to deny (i.e., repudiates, see ISO/IEC 10181-5 [ISO10181-5]) the to deny (i.e., repudiates, see ISO/IEC 10181-5 [ISO10181-5]) the
validity of the signature). validity of the signature).
skipping to change at page 52, line 43 skipping to change at page 52, line 43
of the ASN.1structures being time-stamped should be preserved to of the ASN.1structures being time-stamped should be preserved to
ensure that the recalculation of the data hash is consistent. ensure that the recalculation of the data hash is consistent.
NOTE 2: Each attribute is included in the hash with the attrType and NOTE 2: Each attribute is included in the hash with the attrType and
attrValues (including type and length) but without the type and attrValues (including type and length) but without the type and
length of the outer SEQUENCE length of the outer SEQUENCE
The following object identifier identifies the time-stamped-certs-crls- The following object identifier identifies the time-stamped-certs-crls-
references attribute: references attribute:
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) memberus(840) id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::=
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) id-aa(2) 26}
The attribute value has the ASN.1 syntax TimestampedCertsCRLs : The attribute value has the ASN.1 syntax TimestampedCertsCRLs :
TimestampedCertsCRLs ::= TimeStampToken TimestampedCertsCRLs ::= TimeStampToken
The value of messageImprint field within TimeStampToken shall be a hash The value of messageImprint field within TimeStampToken shall be a hash
of the concatenated values (without the type or length encoding for of the concatenated values (without the type or length encoding for
that value) of the following data objects as present in the ES with that value) of the following data objects as present in the ES with
Complete validation data (CAdES-C): Complete validation data (CAdES-C):
skipping to change at page 58, line 37 skipping to change at page 58, line 37
[1] (see section 8.1); and [1] (see section 8.1); and
- either of: - either of:
- Certificate Revocation Lists. as defined in ITU-T - Certificate Revocation Lists. as defined in ITU-T
Recommendation X.509 [1] (see section 8.2); or Recommendation X.509 [1] (see section 8.2); or
- on-line Certificate Status Protocol, as defined in RFC 2560 - on-line Certificate Status Protocol, as defined in RFC 2560
[3] (see section 8.3). [3] (see section 8.3).
9. Security considerations 9. IANA Considerations
9.1 Protection of private key
The security of the electronic signature mechanism defined in the
present document depends on the privacy of the signer's private key.
Implementations should take steps to ensure that private keys cannot
be compromised.
9.2 Choice of algorithms
Implementers 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
cryptographic algorithm will reduce. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms to
be readily inserted. That is, implementers should be prepared for the
set of mandatory to implement algorithms to change over time.
10. IANA Considerations
No IANA actions required. No IANA actions required.
11. References 10. References
11.1 Normative references 10.1 Normative references
[1] ITU-T Recommendation X.509 (2000)/ISO/IEC 9594-8 (2001): [1] ITU-T Recommendation X.509 (2000)/ISO/IEC 9594-8 (2001):
"Information technology - Open Systems Interconnection - "Information technology - Open Systems Interconnection -
The Directory: Authentication framework". The Directory: Authentication framework".
[2] IETF RFC 3280 (2002): "Internet X.509 Public Key [2] IETF RFC 3280 (2002): "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile". (CRL) Profile".
[3] IETF RFC 2560 (1999): "X.509 Internet Public Key [3] IETF RFC 2560 (1999): "X.509 Internet Public Key
skipping to change at page 60, line 13 skipping to change at page 59, line 48
Syntax Notation One (ASN.1)". Syntax Notation One (ASN.1)".
[15] IETF RFC 5035 (2007). ESS Update: Adding CertID Algorithm [15] IETF RFC 5035 (2007). ESS Update: Adding CertID Algorithm
Agility. Agility.
[16] ITU-T Recommendation X.690 (2002): "Information technology [16] ITU-T Recommendation X.690 (2002): "Information technology
ASN.1 encoding rules: Specification of Basic Encoding Rules ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER) Encoding Rules (DER)
11.2 Informative references 10.2 Informative references
ETSI technical specifications can be downloaded free of charge ETSI technical specifications can be downloaded free of charge
via the Services and Products Download Area at: via the Services and Products Download Area at:
http://www.etsi.org/services_products/freestandard/home.htm http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx
[EU Directive] Directive 1999/93/EC of the European Parliament and [EU Directive] Directive 1999/93/EC of the European Parliament and
of the Council of 13 December 1999 on a Community framework for of the Council of 13 December 1999 on a Community framework for
electronic signatures. electronic signatures.
[TS101733] ETSI Standard TS 101 733 V.1.7.3 (2005-06) Electronic [TS101733] ETSI Standard TS 101 733 V.1.7.3 (2005-06) Electronic
Signature Formats. Signature Formats.
[TS101861] ETSI TS 101 861: "Time stamping profile". [TS101861] ETSI TS 101 861: "Time stamping profile".
skipping to change at page 111, line 5 skipping to change at page 110, line 5
Signers and verifiers can use the following management protocols to Signers and verifiers can use the following management protocols to
manage the use of certificates. manage the use of certificates.
D.2.1 Request for certificate revocation D.2.1 Request for certificate revocation
Request for a certificate to be revoked can be made using the Request for a certificate to be revoked can be made using the
revocation request and response messages defined in revocation request and response messages defined in
RFC 4210 [RFC4210]. RFC 4210 [RFC4210].
Annex E (informative): Guidance on naming Annex E (informative): Security considerations
E.1 Allocation of names
The subject name shall be allocated through a registration scheme
administered through a Registration Authority (RA) to ensure
uniqueness. This RA may be an independent body or a function carried
out by the Certification Authority.
In addition to ensuring uniqueness, the RA shall verify that the name
allocated properly identifies the applicant and that authentication
checks are carried out to protect against masquerade.
The name allocated by an RA is based on registration information
provided by, or relating to, the applicant (e.g. his personal name,
date of birth, residence address) and information allocated by the RA.
Three variations commonly exist:
- the name is based entirely on registration information which
uniquely identifies the applicant (e.g. "Pierre Durand (born on)
July 6, 1956");
- the name is based on registration information with the addition
of qualifiers added by the registration authority to ensure
uniqueness (e.g. "Pierre Durand 12");
- the registration information is kept private by the registration
authority and the registration authority allocates a "pseudonym".
E.2 Providing access to registration information
Under certain circumstances it may be necessary for information used
during registration, but not published in the certificate, to be made
available to third parties (e.g. to an arbitrator to resolve a dispute
or for law enforcement). This registration information is likely to
include personal and sensitive information.
Thus the RA needs to establish a policy for:
- whether the registration information should be disclosed;
- to whom such information should be disclosed;
- under what circumstances such information should be disclosed.
This policy may be different whether the RA is being used only within a
company or for public use. The policy will have to take into account
national legislation and in particular any data protection and privacy
legislation.
Currently, the provision of access to registration is a local matter
for the RA. However, if open access is required, standard protocols
such as HTTP - RFC 2068 (Internet Web Access Protocol) may be employed
with the addition of security mechanisms necessary to meet the data
protection requirements (e.g. Transport Layer Security - RFC 4346
[RFC4346] with client authentication).
E.3 Naming schemes
E.3.1 Naming schemes for individual citizens
In some cases the subject name that is contained in a public key
certificate may not be meaningful enough. This may happen because of
the existence of homonyms or because of the use of pseudonyms. A
distinction could be made if more attributes were present. However,
adding more attributes to a public key certificate placed in a public
repository would be going against the privacy protection requirements.
In any case the Registration Authority will get information at the time
of registration but not all that information will be placed in the
certificate. In order to achieve a balance between these two opposite
requirements the hash values of some additional attributes can be
placed in a public key certificate. When the certificate owner
provides these additional attributes, then they can be verified. Using
biometrics attributes may unambiguously identify a person. Example of
biometrics attributes that can be used include: a picture or a manual
signature from the certificate owner.
NOTE: Using hash values protects privacy only if the possible inputs
are large enough. For example, using the hash of a person's
social security number is generally not sufficient since it
can easily be reversed.
A picture can be used if the verifier once met the person and later on
wants to verify that the certificate that he or she got relates to the
person whom was met. In such a case, at the first exchange the picture
is sent and the hash contained in the certificate may be used by the
verifier to verify that it is the right person. At the next exchange
the picture does not need to be sent again.
A manual signature may be used if a signed document has been received
beforehand. In such a case, at the first exchange the drawing of the
manual signature is sent and the hash contained in the certificate may
be used by the verifier to verify that it is the right manual
signature. At the next exchange the manual signature does not need to
be sent again.
E.3.2 Naming schemes for employees of an organization E.1 Protection of private key
The name of an employee within an organization is likely to be some The security of the electronic signature mechanism defined in the
combination of the name of the organization and the identifier of the present document depends on the privacy of the signer's private key.
employee within that organization.
An organization name is usually a registered name, i.e. business or Implementations should take steps to ensure that private keys cannot
trading name used in day to day business. This name is registered by a be compromised.
Naming Authority, which guarantees that the organization's registered
name is unambiguous and cannot be confused with another organization.
In order to get more information about a given registered organization
name, it is necessary to go back to a publicly available directory
maintained by the Naming Authority.
The identifier may be a name or a pseudonym (e.g. a nickname or a E.2 Choice of algorithms
employee number). When it is a name, it is supposed to be descriptive
enough to unambiguously identify the person. When it is a pseudonym,
the certificate does not disclose the identity of the person. However
it ensures that the person has been correctly authenticated at the time
of registration and therefore may be eligible to some advantages
implicitly or explicitly obtained through the possession of the
certificate. In either case, however, this can be insufficient because
of the existence of homonyms.
Placing more attributes in the certificate may be one solution, for Implementers should be aware that cryptographic algorithms become
example by giving the organization unit of the person or the name of a weaker with time. As new cryptoanalysis techniques are developed and
city where the office is located. However the more information is computing performance improves, the work factor to break a particular
placed in the certificate the more problems arise if there is a change cryptographic algorithm will reduce. Therefore, cryptographic
in the organization structure or the place of work. So this may not be algorithm implementations should be modular allowing new algorithms to
the best solution. An alternative is to provide more attributes (like be readily inserted. That is, implementers should be prepared for the
the organization unit and the place of work) through access to a set of mandatory to implement algorithms to change over time.
directory maintained by the company. It is likely that at the time of
registration the Registration Authority got more information than what
was placed in the certificate, if such additional information is placed
in a repository accessible only to the organization.
Annex F (informative): Example structured contents and MIME Annex F (informative): Example structured contents and MIME
F.1 Use of MIME to encode data F.1 Use of MIME to encode data
The signed content may be structured as using MIME (Multipurpose The signed content may be structured as using MIME (Multipurpose
Internet Mail Extensions - RFC 2045 [6]. Whilst the MIME structure was Internet Mail Extensions - RFC 2045 [6]. Whilst the MIME structure was
initially developed for Internet e-mail, it has a number of features initially developed for Internet e-mail, it has a number of features
which make it useful to provide a common structure for encoding a range which make it useful to provide a common structure for encoding a range
of electronic documents and other multi-media data (e.g. photographs, of electronic documents and other multi-media data (e.g. photographs,
skipping to change at page 118, line 41 skipping to change at page 115, line 41
|Content-Type= ||SignedData||Content-Type=||Dear MrSmith| |Content-Type= ||SignedData||Content-Type=||Dear MrSmith|
|multipart/ || ||application/ ||Received | |multipart/ || ||application/ ||Received |
|signed || ||pdf || 100 tins | |signed || ||pdf || 100 tins |
| /| || || || | | /| || || || |
| / -------------------+ /| || Mr.Jones | | / -------------------+ /| || Mr.Jones |
| \ -------------------+ / -----+ | | \ -------------------+ / -----+ |
| \| || || \ -----+ | | \| || || \ -----+ |
|Content-Type= || || \| |+------------+ |Content-Type= || || \| |+------------+
|application/ || |+-------------+ |application/ || |+-------------+
|pdf || | |pdf || |
| || | |Content-Type= || | | || |
|Content-Type= || |
|application/ || | |application/ || |
|pkcs7-signature|| | |pkcs7-signature|| |
| || | | || |
| /| || | | /| || |
| / -------+ | | / -------+ |
| \ -------+ | | \ -------+ |
| \| ||----------+ | \| ||----------+
| | | |
+---------------+ +---------------+
skipping to change at page 130, line 5 skipping to change at page 127, line 5
specifies the DSA, NIST's Digital Signature Algorithm. specifies the DSA, NIST's Digital Signature Algorithm.
- ANSI X9.62 (1998) [X9.62]: "Public Key Cryptography for the - ANSI X9.62 (1998) [X9.62]: "Public Key Cryptography for the
Financial Services Industry - The Elliptic Curve Digital Financial Services Industry - The Elliptic Curve Digital
Signature Algorithm (ECDSA)". ANSI X9.62 specifies the Elliptic Signature Algorithm (ECDSA)". ANSI X9.62 specifies the Elliptic
Curve Digital Signature Algorithm, an analog of NIST's Digital Curve Digital Signature Algorithm, an analog of NIST's Digital
Signature Algorithm (DSA) using elliptic curves. The appendices Signature Algorithm (DSA) using elliptic curves. The appendices
provide tutorial information on the underlying mathematics for provide tutorial information on the underlying mathematics for
elliptic curve cryptography and many examples. elliptic curve cryptography and many examples.
Annex J (informative): Changes from the previous version Annex J (informative): Guidance on naming
J.1 Allocation of names
The subject name shall be allocated through a registration scheme
administered through a Registration Authority (RA) to ensure
uniqueness. This RA may be an independent body or a function carried
out by the Certification Authority.
In addition to ensuring uniqueness, the RA shall verify that the name
allocated properly identifies the applicant and that authentication
checks are carried out to protect against masquerade.
The name allocated by an RA is based on registration information
provided by, or relating to, the applicant (e.g. his personal name,
date of birth, residence address) and information allocated by the RA.
Three variations commonly exist:
- the name is based entirely on registration information which
uniquely identifies the applicant (e.g. "Pierre Durand (born on)
July 6, 1956");
- the name is based on registration information with the addition
of qualifiers added by the registration authority to ensure
uniqueness (e.g. "Pierre Durand 12");
- the registration information is kept private by the registration
authority and the registration authority allocates a "pseudonym".
J.2 Providing access to registration information
Under certain circumstances it may be necessary for information used
during registration, but not published in the certificate, to be made
available to third parties (e.g. to an arbitrator to resolve a dispute
or for law enforcement). This registration information is likely to
include personal and sensitive information.
Thus the RA needs to establish a policy for:
- whether the registration information should be disclosed;
- to whom such information should be disclosed;
- under what circumstances such information should be disclosed.
This policy may be different whether the RA is being used only within a
company or for public use. The policy will have to take into account
national legislation and in particular any data protection and privacy
legislation.
Currently, the provision of access to registration is a local matter
for the RA. However, if open access is required, standard protocols
such as HTTP - RFC 2068 (Internet Web Access Protocol) may be employed
with the addition of security mechanisms necessary to meet the data
protection requirements (e.g. Transport Layer Security - RFC 4346
[RFC4346] with client authentication).
J.3 Naming schemes
J.3.1 Naming schemes for individual citizens
In some cases the subject name that is contained in a public key
certificate may not be meaningful enough. This may happen because of
the existence of homonyms or because of the use of pseudonyms. A
distinction could be made if more attributes were present. However,
adding more attributes to a public key certificate placed in a public
repository would be going against the privacy protection requirements.
In any case the Registration Authority will get information at the time
of registration but not all that information will be placed in the
certificate. In order to achieve a balance between these two opposite
requirements the hash values of some additional attributes can be
placed in a public key certificate. When the certificate owner
provides these additional attributes, then they can be verified. Using
biometrics attributes may unambiguously identify a person. Example of
biometrics attributes that can be used include: a picture or a manual
signature from the certificate owner.
NOTE: Using hash values protects privacy only if the possible inputs
are large enough. For example, using the hash of a person's
social security number is generally not sufficient since it
can easily be reversed.
A picture can be used if the verifier once met the person and later on
wants to verify that the certificate that he or she got relates to the
person whom was met. In such a case, at the first exchange the picture
is sent and the hash contained in the certificate may be used by the
verifier to verify that it is the right person. At the next exchange
the picture does not need to be sent again.
A manual signature may be used if a signed document has been received
beforehand. In such a case, at the first exchange the drawing of the
manual signature is sent and the hash contained in the certificate may
be used by the verifier to verify that it is the right manual
signature. At the next exchange the manual signature does not need to
be sent again.
J.3.2 Naming schemes for employees of an organization
The name of an employee within an organization is likely to be some
combination of the name of the organization and the identifier of the
employee within that organization.
An organization name is usually a registered name, i.e. business or
trading name used in day to day business. This name is registered by a
Naming Authority, which guarantees that the organization's registered
name is unambiguous and cannot be confused with another organization.
In order to get more information about a given registered organization
name, it is necessary to go back to a publicly available directory
maintained by the Naming Authority.
The identifier may be a name or a pseudonym (e.g. a nickname or a
employee number). When it is a name, it is supposed to be descriptive
enough to unambiguously identify the person. When it is a pseudonym,
the certificate does not disclose the identity of the person. However
it ensures that the person has been correctly authenticated at the time
of registration and therefore may be eligible to some advantages
implicitly or explicitly obtained through the possession of the
certificate. In either case, however, this can be insufficient because
of the existence of homonyms.
Placing more attributes in the certificate may be one solution, for
example by giving the organization unit of the person or the name of a
city where the office is located. However the more information is
placed in the certificate the more problems arise if there is a change
in the organization structure or the place of work. So this may not be
the best solution. An alternative is to provide more attributes (like
the organization unit and the place of work) through access to a
directory maintained by the company. It is likely that at the time of
registration the Registration Authority got more information than what
was placed in the certificate, if such additional information is placed
in a repository accessible only to the organization.
Annex K (informative): Changes from the previous version
The title of the document has changed to be aligned with the title The title of the document has changed to be aligned with the title
of XAdES (XML Advanced Electronic Signatures), the vocabulary used of XAdES (XML Advanced Electronic Signatures), the vocabulary used
within the present document has been aligned with the vocabulary within the present document has been aligned with the vocabulary
used in XAdES, used in XAdES,
If the hash of the signature policy is unknown, then, by If the hash of the signature policy is unknown, then, by
convention, the sigPolicyHash shall be set to all zeros. convention, the sigPolicyHash shall be set to all zeros.
The OIDs from the ASN.1 modules have changed for the following The OIDs from the ASN.1 modules have changed for the following
 End of changes. 42 change blocks. 
256 lines changed or deleted 260 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/