view Side-By-Side changes

S/MIME Working Group                         J Ross (Security & Standards)                                   D. Pinkas (Bull)
expires in six months                                      D Pinkas (Bull)                    J. Ross (Security & Standards)
Target Category: Informational               N           N. Pope (Security & Standards)                          
                                                                March
                                                              July 2000

                     Electronic Signature Formats
                  for long term electronic signature
                   <draft-ietf-smime-esformats-00.txt> signatures
                  <draft-ietf-smime-esformats-01.txt>


Status of this Memo

   This document is an Internet-Draft and is NOT offered in
   accordance with section of RFC 2026, and the author does not 
   provide the IETF with any rights other than to publish as an
   Internet-Draft.

   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.

   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/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

The informational RFC 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 (repudiates) (i.e. repudiates, see [ISONR]) the validity of the signature.

The format can be considered as an extension to RFC 2630 [CMS] and RFC 
2634 [ESS], where, when appropriate additional signed and unsigned 
attributes have been defined.

The contents of this Informational RFC is technically equivalent to 
ETSI ES 201 733 V.1.1.1 V.1.1.3 Copyright (C). Individual copies of this 
ETSI deliverable can be downloaded from http://www.etsi.org 

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. 

ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC        [Page 1]
Internet Draft                             Electronic Signature Formats


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.

ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 1]

Internet Draft                                   Electronic Signature Formats

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

TABLE OF CONTENTS

1.  Introduction                                                    1
2  Overview                                                         4
2.1  Aim

The aim                                                            4
2.2  Basis of this document is to define an Present Document                                      4
2.3  Major Parties                                                  5
2.4  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.  

A signer is the entity that creates an electronic signature.

This document specifies use of trusted service providers (e.g. 
TimeStamping Authorities (TSA)), and the data that needs to be archived 
(e.g. cross certificates Signatures and revocation lists) to meet the requirements Validation Data                      6
2.5  Forms of long term electronic signatures. An electronic signature defined by 
this document can be used for arbitration in case Validation Data                                       7
2.6  Extended Forms 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 Validation Data                              9
2.7  Archive Validation Data                                       11
2.8  Arbitration                                                   12
2.9  Validation Process                                            12
2.10  Example Validation Sequence                                  13
2.11  Additional optional features                                 18
3. Data structure of an electronic signature. 

A Trusted Service Provider (TSP) is an entity that helps to build trust 
relationships by making available or providing some information upon 
request.

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.

A signature policy is a set of rules for the creation and validation of 
an electronic signature, under which the signature can be determined to 
be valid

2.2	Basis of Electronic Signature                       19
3.1  General Syntax                                                19
3.2  Data Content Type                                             19
3.3  Signed-data Content Type                                      19
3.4  SignedData Type                                               19
3.5  EncapsulatedContentInfo Type                                  20
3.6  SignerInfo Type                                               20
3.6.1  Message Digest Calculation Process                          20
3.6.2  Message Signature Generation Process                        20
3.6.3  Message Signature Verification Process                      20
3.7  CMS Imported Mandatory Present Document

This document is based on the use of public key cryptography to produce 
digital signatures, supported by public key certificates. Attributes                     21
3.7.1  Content Type                                                21
3.7.2  Message Digest                                              21
3.7.3  Signing Time                                                21


ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC        [Page 2]
Internet Draft                             Electronic Signature Formats

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 uses timestamping 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, uses additional timestamps 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 2630 [9] Crytographic Message Syntax (CMS);
     * ITU-T Recommendation X.509 [1] Authentication framework;
     * RFC 2459 [7]  Internet X.509 Public Key Infrastructure (PKIX)


3.8  Alternative Signing Certificate and CRL Profile;
     * RFC (to be published) PKIX Timestamping protocol.

NOTE:	See clause 2 Attributes                    21
3.8.1  ESS Signing Certificate Attribute Definition                21
3.8.2  Other Signing Certificate Attribute Definition              22
3.9  Additional Mandatory Attributes                               23
3.9.1  Signature policy Identifier                                 23
3.10  CMS Imported Optional Attributes                             24
3.10.1  Countersignature                                           25
3.11  ESS Imported Optional Attributes                             25
3.11.1 Content Reference Attribute                                 25
3.11.2  Content Identifier Attribute                               25
3.12   Additional Optional Attributes                              25
3.12.1  Commitment Type Indication Attribute                       25
3.12.2  Signer Location attribute                                  27
3.12.3  Signer Attributes attribute                                28
3.12.4  Content Timestamp attribute                                28
3.13  Support for a full set of references.

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;
     * Trusted Service Providers (TSP);
     * the Arbitrator.

The arbitrator is an entity that may be used to arbitrate a dispute 
between a signer Multiple Signatures                              29
3.13.1  Independent Signatures                                     29
3.13.2  Embedded Signatures                                        29
4.  Validation Data                                                29
4.1  Electronic Signature Timestamp                                30
4.1.1  Signature Timestamp Attribute Definition                    30
4.2  Complete Validation Data                                      31
4.2.1  Complete Certificate Refs Attribute Definition              32
4.2.2  Complete Revocation Refs Attribute Definition               32
4.3  Extended Validation Data                                      34
4.3.1  Certificate Values Attribute Definition                     34
4.3.2  Revocation Values Attribute Definition                      35
4.3.3  ES-C Timestamp Attribute Definition                         35
4.3.4  Time-Stamped Certificates and verifier when there is a disagreement on the 
validity CRLs Attribute Definition     36
4.4  Archive Validation Data                                       36
4.4.1  Archive Timestamp Attribute Definition                      37
5.  Security considerations                                        38
5.1  Protection of a digital signature.

The Private Key                                     38
5.2  Choice of Algorithms                                          38
6.  Conformance Requirements                                       38
6.1  Signer is the entity that 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. 

The                                                        38
6.2  Verifier is the entity that validates the electronic signature, it 
may be a single entity or multiple entities.                                                      39
7. References                                                      40
8. Authors' Addresses                                              40
9. Full Copyright Statement                                        41
Annex A (normative): ASN.1 Definitions                             43
A.1  Definitions Using X.208 (1988) ASN.1 Syntax                   43
A.2  Definitions Using X.680 1997 ASN.1 Syntax                     52
Annex B (informative): General Description                         61
B.1  The Trusted Service Providers (TSPs) are one or more entities that help Signature Policy                                          61
B.2  Signed Information                                            62
B.3  Components of an Electronic Signature                         62
B.3.1  Reference to build trust relationships between the signer and verifier. They 
support Signature Policy                           62
B.3.2  Commitment Type Indication                                  63
B.3.3  Certificate Identifier from the signer and verifier by means of supporting services 
including: user certificates, cross-certificates, timestamping tokens,
CRLs, ARLs, OCSP responses. Signer                      64



ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC        [Page 3]
Internet Draft                             Electronic Signature Formats

The following TSPs are used to support the 
functions defined in this document:

     * Certification Authorities;
     * Registration Authorities;
     * Repository Authorities (e.g. a Directory);
     * TimeStamping Authorities;
     * Signature Policy Issuers.


B.3.4.  Role Attributes                                            64
B.3.4.1  Claimed Role                                              65
B.3.4.2  Certified Role                                            65
B.3.5  Signer Location                                             66
B.3.6  Signing Time                                                66
B.4  Components of Validation Data                                 67
B.4.1  Revocation Status Information                               67
B.4.2  CRL Information                                             67
B.4.3  OCSP Information                                            68
B.4.4  Certification Authorities provide users with public key certificates.

Registration Authorities allows the registration Path                                          69
B.4.5  Timestamping for Long Life of entities Signature                     69
B.4.6  Timestamping before a CA generates certificates.

Repository Authorities publish CRLs issued by CAs, signature policies 
issued by Signature Policy Issuers and optionally public key 
certificates.

TimeStamping Authorities attest that some data was formed before a 
given trusted time. 

Signature Policy Issuers define Key Compromises                      70
B.4.6.1  Timestamping the technical ES with Complete validation data         71
B.4.6.2  Timestamping Certificates and procedural 
requirements Revocation Information      72
B.4.7  Timestamping for electronic signature creation and validation, in order Long Life of Signature                     72
B.4.8  Reference to meet a particular business need.

In some cases the following additional TSPs are needed:

     * Attribute Authorities. Additional Data                                73
B.4.9  Timestamping for Mutual Recognition                         73
B.4.10  TSA Key Compromise                                         74
B.5  Multiple Signatures                                           74
Annex C (informative):  Identifiers and roles                      75
C.1  Signer Name Forms                                             75
C.2  TSP Name Forms                                                75
C.3  Roles and Signer Attributes Authorities provide users with attributes linked to public 
key certificates

An Arbitrator                                   75


2  Overview

2.1  Aim

The aim of this document is to define an entity Electronic Signature (ES) that arbitrates disputes between a 
remains valid over long periods. This includes evidence as to its 
validity even if the signer 
and a verifier.

A signature policy issuer is an entity that defines or verifying party later attempts to deny 
(repudiates) the technical validity of the signature.

This document specifies use of trusted service providers (e.g. 
TimeStamping Authorities (TSA)), and 
procedural requirements for electronic signature creation the data that needs to be archived 
(e.g. cross certificates and 
validation, in order revocation lists) to meet a particular business need


2.4	Electronic Signatures and Validation Data

Validation the requirements 
of an long term electronic signatures. An electronic signature in accordance with defined by 
this document 
requires:

     * The electronic signature; this includes:
        - 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;
        -  the signed user data;
        - 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 signature;
        - signatures, supported by public key certificates.

A Public key certificate is a public keys of a user, together with some 
other signed attributes provided information, rendered unforgeable by encipherment with the signer. 
private key of the Certification Authority (CA) which issued it (ITU-T 
Recommendation X.509 [1]). 


ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC        [Page 4]
Internet Draft                             Electronic Signature Formats

    * Validation data which is the additional data needed


This document also uses timestamping services to validate 
       the electronic signature; this includes:

        -  certificates;
        -  revocation status information,
        -  trusted time-stamps from Trusted Service Providers (TSPs).

     * The signature policy specifies prove the technical requirements on
      signature creation and validation in order to meet a particular
      business need. A given legal/contractual context may recognize a
      particular signature policy as meeting its requirements.

For example: validity of 
a specific signature policy may be recognized by court of 
law as meeting long after the requirements normal lifetime of the European Directive for critical elements of an 
electronic
commerce. A signature policy may be written using a formal notation like
ASN.1 (see 6.1) or in and to support non-repudiation. It also, as an informal free text form provided the rules of
the policy 
option, uses additional timestamps to provide very long-term protection 
against key compromise or weakened algorithms.

This document builds on existing standards that are clearly identified. However, for a given signature policy
there shall be one definitive form which has a unique binary encoded
value.
 

Signed user data is the user's data that is signed. 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.

2.3  Major Parties

The Digital Signature is the digital signature applied over the following attributes provided are the major parties involved in a business transaction 
supported by electronic signatures as defined in this document:

     * the signer: Signer;
     * hash of the user data; Verifier;
     * signature Policy Identifier; the Arbitrator;
     * other signed attributes 

The other signed attributes include any additional information which 
must be signed to conform to Trusted Service Providers (TSP).

A Signer is an entity that creates the signature policy or this document 
(e.g. signing time).

The Validation Data may be collected by electronic signature. When 
the signer and/or the verifier 
and must meet digitally signs over data using the requirements prescribed format, this 
represents a commitment on behalf of the signature policy.  Additional 
data includes CA certificates as well as revocation status information 
in signing entity to the form of Certificate Revocation Lists (CRLs) or certificate 
status information provided by an on-line service.  Additional data 
also includes timestamps and other time related data used to provide 
evidence of 
being signed. 

A verifier is an entity that verifies an evidence. (ISO/IEC 13888-1 
[13]). Within the timing context of given events.  It this document this is required, as a minimum, an entity that either the 
validates an electronic signature.
An arbitrator, is an entity which arbitrates disputes between a signer or verifier obtains 
and a timestamp over the 
signer's signature.

A Certificate Revocation List (CRL) verifier when there is signed list indicating a set disagreement on the validity of 
certificates that a 
digital signature.

Trusted Service Providers (TSPs) are no longer considered valid by the certificate 
issuer [X.509 FPAM]digital signature: data appended to, one or a 
cryptographic transformation of, a data unit more entities that allows a recipient of 
the data unit help 
to prove build trust relationships between the source signer and integrity verifier. Use of the data unit and 
protect against forgery, e.g. 
some specific TSP services MAY be mandated by signature policy. TSP 
supporting services may provide the recipient (ISO 7498-2 [12]) following information: user 
certificates, cross-certificates, timestamping tokens, CRLs, ARLs, 
OCSP responses.







ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC        [Page 5]
Internet Draft                             Electronic Signature Formats

2.5	Forms

The following TSPs are used to support the validation or 
the verification of Validation Data

An electronic signature may exist in many forms including: signatures :

     * the Electronic Signature (ES), which includes the digital 
      signature and other basic information provided by the signer; Certification Authorities;
     * the ES with Timestamp  (ES-T), which adds Registration Authorities;
     * Repository Authorities (e.g. a timestamp to the 
       Electronic Signature, to take initial steps towards providing 
       long term validity; Directory);
     * the ES TimeStamping Authorities;
     * One-line Certificate Status Protocol responders;
     * Attribute Authorities;
     * Signature Policy Issuers.

Certification Authorities provide users with Complete validation data (ES-C), which adds to the 
      ES-T references to the complete set of data supporting public key certificates.

Registration Authorities allows the 
      validity registration of the electronic signature (i.e. revocation status 
      information).

The signer must provide at least the ES form, but in entities before a 
CA generates certificates.

Repository Authorities publish CRLs issued by CAs, cross-certificates 
(i.e. CA certificates) issued by CAs, signature policies issued by 
Signature Policy Issuers and optionally public key certificates (i.e. 
leaf certificates) issued by CAs.

TimeStamping Authorities attest that some cases may 
decide to data was formed before a 
given trusted time. 

One-line Certificate Status Protocol responders (OSCP responders) 
provide information about the ES-T form status (i.e. revoked, not revoked, 
unknown) of a particular certificate.

A Signature Policy Issuer issues signatures policies that define the 
technical and procedural requirements for electronic signature 
creation, validation and verification, in the extreme case could provide 
the ES-C form. If the signer does not order to meet a particular 
business need.

Attributes Authorities provide ES-T, the verifier must 
create the ES-T on first receipt users with attributes linked to public 
key certificates

2.4  Electronic Signatures and Validation Data

Validation of an electronic signature. signature in accordance with this document 
requires:

     * The ES-T 
provides independent evidence of the existence of electronic signature; this includes:

        -  the signature at the 
time it was first verified which should be near the time it was 
created, and so protects against later repudiation of the existence of 
the signature. If the signer does not provide ES-C policy;
        -  the verifier must 
create signed user data;
        -  the ES-C when digital signature;
        -  other signed attributes provided by the complete set of revocation and signer;
.       -  other validation unsigned attributes provided by the signer.

    * Validation data which is available.

The ES satisfies the legal requirements for electronic signatures as 
defined in additional data needed to validate 
      the European Directive on electronic signatures, see Annex C 
for further discussion on relationship of signature; this document to the 
Directive. It provides basic authentication and integrity protection 
and can be created without accessing on-line (timestamping) services. 
However,  without the addition of a timestamp the electronic includes:

        -  certificates references;
        -  certificates;

ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC        [Page 6]

Internet Draft                             Electronic Signature Formats

        -  revocation status information references;
        -  revocation status information;
        -  time-stamps from Time Stamping Authorities (TSAs).

     * The signature 
does not protect against the threat that the signer later denies having 
created policy specifies the electronic technical requirements on
       signature (i.e. does not provide non-repudiation 
of its existence). 

The ES-T time-stamp should be created close to the time that ES was 
created to provide maximum protection against repudiation. At this time 
ll the data needed to complete the creation and validation in order to meet a particular
       business need. A given legal/contractual context may not be available but 
what information is readily available recognize a
       particular signature policy as meeting its requirements.

For example: a specific signature policy may be used to carry out some recognized by court 
of law as meeting the initial checks. For example, only part requirements of the revocation 
information European Directive for 
electronic commerce. A signature policy may be available for verification at that point written using a formal 
notation like ASN.1 or in time.

Generally, the ES-C an informal free text form cannot be created at provided the same time as 
rules of the ES, 
as it is necessary to allow time policy are clearly identified. However, for any revocation information to be 
captured. Also, if a certificate is found to be temporarily suspended, 
it will given 
signature policy there shall be necessary to wait until the end of one definitive form which has a unique 
binary encoded value.

Signed user data is the suspension period. user's data that is signed.

The signer should only create Digital Signature is the ES-C in situations where it was 
prepared to wait for a sufficient length digital signature applied over the 
following attributes provided by the signer:

    * hash of time after creating the ES 
form before dispatching user data (message digest);
    * signature Policy Identifier;
    * other signed attributes 

The other signed attributes include any additional information which 
must be signed to conform to the ES-C. This, however, has signature policy or this document 
(e.g. signing time).

The Validation Data may be collected by the advantage that signer and/or the verifier can be presented with 
and must meet the complete set requirements of the signature policy.  Additional 
data supporting includes CA certificates as well as revocation status information 
in the validity form of the ES.

ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 6]

Internet Draft                                   Electronic Signature Formats

Support for ES-C Certificate Revocation Lists (CRLs) or certificate 
status information provided by an on-line service.  Additional data 
also includes timestamps and other time related data used to provide 
evidence of the verifier timing of given events.  It is mandated (see clause 14 for 
specific conformance requirements).


An Electronic Signature (ES), required, as a minimum, 
that either the signer or verifier obtains a timestamp over the 
signer's signature.

A digital signature (not to be confused with an electronic signature) 
is data appended to, or a cryptographic transformation of, a data unit 
that allows a recipient of the additional validation data forming unit to prove the 
ES-T source and ES-C is illustrated in Figure 1:


+------------------------------------------------------------ES-C-----+
|+--------------------------------------------ES-T-----+              |
||+------Elect.Signature (ES)----------+ +------------+| +-----------+|
|||+---------+ +----------+ +---------+| |Timestamp   || |Complete   ||
||||Signature| |  Other   | | Digital || |over digital|| |certificate||
||||Policy ID| |  Signed  | |Signature|| |signature   || |and        ||
||||         | |Attributes| |         || +------------+| |revocation ||
|||+---------+ +----------+ +---------+|               | |references ||
||+------------------------------------+               | +-----------+|
|+-----------------------------------------------------+              |
+---------------------------------------------------------------------+


Figure 1: Illustration 
integrity of an ES, ES-T the data unit and ES-C


2.6	Extended protect against forgery, e.g. by the 
recipient (ISO 7498-2 [12])

2.5  Forms of Validation Data

The complete validation data  (ES-C) described above

An electronic signature may be extended to 
form an ES with eXtended validation data (ES-X) to meet following 
additional requirements.

Firstly, when the verifier does not has access to, 

     * the signer's certificate, 
     * all the CA certificates that make up the full certification 
       path,
     * all the associated revocation status information, as referenced exist in many forms including: 

    * the ES-C. 

then Electronic Signature (ES), which includes the values of these certificates digital 
      signature and revocation other basic information may be 
added to the ES-C. This form of extended validation data is called a 
X-Long.


Secondly, if there is a risk that any CA keys used in the certificate 
chain may be compromised, then it is necessary to additionally 
timestamp the validation data provided by either:

     * timestamping all the validation data as held with the ES(ES-C),
       this eXtended validation data is called a Type 1 X-Timestamp; or 
     * timestamping individual reference data as used for complete 
       validation. 

This form of eXtended validation data is called a Type 2 X-Timestamp. signer;



ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC        [Page 7]
Internet Draft                             Electronic Signature Formats


NOTE:

    * the ES with Timestamp (ES-T), which adds a timestamp to the 
      Electronic Signature, to take initial steps towards providing 
      long term validity;

    * the ES with Complete validation data (ES-C), which adds to the 
      ES-T references to the complete set of data supporting the 
      validity of the electronic signature (i.e. revocation status 
      information).

The advantages/drawbacks for Type 1 signer must provide at least the ES form, but in some cases may 
decide to provide the ES-T form and Type 2 X-Timestamp are 
discussed in this document (see clause 4.4.6.) the extreme case could provide 
the ES-C form. If all the above conditions occur then a combination signer does not provide ES-T, the verifier must 
create the ES-T on first receipt of an electronic signature. The ES-T 
provides independent evidence of the two formats 
above may existence of the signature at the 
time it was first verified which should be used. This form near the time it was 
created, and so protects against later repudiation of eXtended the existence of 
the signature. If the signer does not provide ES-C the verifier must 
create the ES-C when the complete set of revocation and other 
validation data is called 
a X-Long-Timestamped.

Support available.

The ES satisfies the legal requirements for electronic signatures as 
defined in the extended forms European Directive on electronic signatures, see Annex C 
for further discussion on relationship of validation data is optional.


An Electronic Signature (ES) , with this document to the additional validation data 
forming 
Directive. It provides basic authentication and integrity protection 
and can be created without accessing on-line (timestamping) services. 
However, without the ES-X long is illustrated in Figure 2:



+------------------------------------------------------- ES-X Long--+
|+--------------------------------------- EC-C --------+            |
||+---- Elect.Signature (ES)----+            +--------+| +--------+ |
|||+-------+-+-------+-+-------+| +---------+|Complete|| |Complete| |
||||Signa- | |Other  | |Digital|| |Timestamp||certi-  || |certi-  | |
||||ture   | |Signed | |Signa- || |over     ||ficate  || |ficate  | |
||||Policy | |Attri- | |ture   || |digital  ||and     || |and     | |
||||ID     | |butes  | |       || |signature||revoc.  || |revoc.  | |
|||+-------+ +-------+ +-------+| +---------+|refs    || |data    | |
||+-----------------------------+            +--------+| +--------+ |
|+-----------------------------------------------------+            |
+-------------------------------------------------------------------+


Figure 2: Illustration addition of an a timestamp the electronic signature 
does not protect against the threat that the signer later denies having 
created the electronic signature (i.e. does not provide non-repudiation 
of its existence). 

The ES-T time-stamp should be created close to the time that ES and ES-X long.


An Electronic Signature (ES) , with was 
created to provide protection against repudiation. At this time all
the additional validation data 
forming needed to complete the eXtended Validation Data - Type 1 validation may not be available but 
what information is illustrated readily available may be used to carry out some of 
the initial checks. For example, only part of the revocation 
information may be available for verification at that point in 
Figure 3:


+---------------------------------------------------------- ES-X 1 -+
|+---------------------------------------- EC-C --------+           |
|| +---- Elect.Signature (ES)----+            +--------+| +-------+ |
|| |+-------+ +-------+ +-------+| +---------+|Complete|| |       | |
|| ||Signa- | |Other  | |Digital|| |Timestamp||certifi-|| | Time- | |
|| ||ture   | |Signed | |Signa- || |over     ||cate and|| | stamp | |
|| ||Policy | |Attri- | |ture   || |digital  ||revoc.  || | over  | |
|| ||ID     | |butes  | |       || |signature||refs    || | CES   | |
|| |+-------+ +-------+ +-------+| +---------+|        || |       | |
|| +-----------------------------+            +--------+| +-------+ |
|+------------------------------------------------------+           |
+-------------------------------------------------------------------+


Figure 3: Illustration time.
Generally, the ES-C form cannot be created at the same time as the ES, 
as it is necessary to allow time for any revocation information to be 
captured. Also, if a certificate is found to be temporarily suspended, 
it will be necessary to wait until the end of the suspension period.

The signer should only create the ES-C in situations where it was 
prepared to wait for a sufficient length of time after creating the ES 
form before dispatching the ES-C. This, however, has the advantage that 
the verifier can be presented with ES-X Type 1 the complete set of data supporting 
the validity of the ES.

Support for ES-C by the verifier is mandated (see clause 6 for 
specific conformance requirements).






ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC        [Page 8]
Internet Draft                             Electronic Signature Formats

An Electronic Signature (ES) , (ES), with the additional validation data 
forming the eXtended Validation Data - Type 2 ES-T and ES-C is illustrated in Figure 4:


+-------------------------------------------------------- ES-X 2 ---+
|+--------------------------------------- EC-C --------+            |
||+---- Elect.Signature (ES)----+            +--------+| +--------+ |
|||+-------+ +-------+ +-------+| +---------+|Complete|| |Times   | |
||||Signa- | |Other 1:


+------------------------------------------------------------ES-C-----+
|+--------------------------------------------ES-T-----+              | |Digital|| |Timestamp||certs
||+------Elect.Signature (ES)----------+ +------------+| +-----------+|
|||+---------+ +----------+ +---------+| |Timestamp   || |Stamp   | |Complete   ||
||||Signature| |
||||ture  Other   | |Signed | |Signa- || |over     ||and Digital || |over    | | digital|| |certificate||
||||Policy ID| | |Attri-  Signed  | |ture |Signature|| |signature   || |digital  ||revoc. |and        || |Complete| |
||||ID     | |butes
||||         | |Attributes| |         || |signature||refs +------------+| |revocation || |certs   | |
|||+-------+ +-------+ +-------+|
|||+---------+ +----------+ +---------+|        || |and     | |
||+-----------------------------+            +--------+| |revoc.  | |
||                                                     | |refs               | |references ||
||+------------------------------------+               | +-----------+|
|+-----------------------------------------------------+ +--------+              |
+-------------------------------------------------------------------+
+---------------------------------------------------------------------+


Figure 4: 1: Illustration of ES with ES-X Type 2 


2.7	Archive an ES, ES-T and ES-C


2.6  Extended Forms of Validation Data

Before the algorithms, keys and other cryptographic

The complete validation data used at the 
time (ES-C) described above may be extended to 
form an ES with eXtended validation data (ES-X) to meet following 
additional requirements.

Firstly, when the ES-C was built become weak and verifier does not has access to, 

     * the cryptographic functions 
become vulnerable, or signer's certificate, 
     * all the CA certificates supporting previous timestamps 
expires, that make up the signed data, full certification 
       path,
     * all the ES-C associated revocation status information, as referenced 
       in the ES-C. 

then the values of these certificates and any additional revocation information 
(ES-X) should may be timestamped.  If possible this should use stronger 
algorithms (or longer key lengths) than in 
added to the original timestamp. ES-C. This additional form of extended validation data and timestamp is called Archive Validation Data
(ES-A).  The Timestamping process a 
X-Long.

Secondly, if there is a risk that any CA keys used in the certificate 
chain may be repeated every time the 
protection used compromised, then it is necessary to additionally 
timestamp a previous ES-A become weak. An ES-A 
may thus bear multiple embedded time stamps.

Support for ES-A is optional.

















ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 9]

Internet Draft                                   Electronic Signature Formats

An example of an Electronic Signature (ES), with the additional validation data for by either:

     * timestamping all the ES-C and ES-X forming validation data as held with the ES-A ES(ES-C),
       this eXtended validation data is illustrated 
in Figure 5.


+-------------------------------- ES-A --------- ----------+ 
|  +-------------------- ES-A -----------------+           | 
|  |  +--------- called a Type 1 X-Timestamp; or 
     * timestamping individual reference data as used for complete 
       validation. 

This form of eXtended validation data is called a Type 2 X-Timestamp.

NOTE:  The advantages/drawbacks for Type 1 and Type 2 X-Timestamp are 
discussed in this document (see clause B.4.6.)




ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC        [Page 9]
Internet Draft                             Electronic Signature Formats



If all the above conditions occur then a combination of the two formats 
above may be used. This form of eXtended validation data is called 
a X-Long-Timestamped.

Support for the extended forms of validation data is optional.

An Electronic Signature (ES) , with the additional validation data 
forming the ES-X -------------- +         |           | 
|  |  |..............................| +-----+ long is illustrated in Figure 2:


+------------------------------------------------------- ES-X Long--+
|+--------------------------------------- EC-C --------+            |  +-----+
||+---- Elect.Signature (ES)----+            +--------+| +--------+ |
|||+-------+-+-------+-+-------+| +---------+|Complete|| |Complete| |
||||Signa- |  |..............................| |Time |Other  | |Digital|| |Timestamp||certi-  || |certi-  |  |Time |
||||ture   | |Signed | |Signa- || |over     ||ficate  || |ficate  |  |..............................| |Stamp| |  |Stamp|
||||Policy | |Attri- | |ture   || |digital  ||and     || |and     | |
||||ID     | +-----+ |butes  |  +-----+ |       || |signature||revoc.  || |revoc.  | |  +----------------------------- +
|||+-------+ +-------+ +-------+| +---------+|refs    || |data    | |
||+-----------------------------+            +--------+| +--------+ |  +-------------------------------------------+
|+-----------------------------------------------------+            | 
+----------------------------------------------------------+
+-------------------------------------------------------------------+


Figure 5: 2: Illustration of an ES -A


2.8	Arbitration

The ES-C may be used for arbitration should there be a dispute between 
the signer and verifier, provided that:

      * the arbitrator knows where to retrieve the signer's certificate 
        (if not already present), all ES-X long.


An Electronic Signature (ES) , with the cross-certificates and additional validation data 
forming the 
        required CRLs and/or OCSPs responses referenced in the ES-C;

      * none of the issuing key from the certificate chain have ever 
        been compromised;

      * the cryptography used at the time the ES-C was built has not 
        been broken at the time the arbitration is performed.

When the first condition eXtended Validation Data - Type 1 is not met, then the plaintiff must provide 
an illustrated in 
Figure 3:


+---------------------------------------------------------- ES-X Long.

When it is known by some external means that the second condition is 
not met, then the plaintiff must provide an 1 -+
|+---------------------------------------- EC-C --------+           |
|| +---- Elect.Signature (ES)----+            +--------+| +-------+ |
|| |+-------+ +-------+ +-------+| +---------+|Complete|| |       | |
|| ||Signa- | |Other  | |Digital|| |Timestamp||certifi-|| | Time- | |
|| ||ture   | |Signed | |Signa- || |over     ||cate and|| | stamp | |
|| ||Policy | |Attri- | |ture   || |digital  ||revoc.  || | over  | |
|| ||ID     | |butes  | |       || |signature||refs    || | CES   | |
|| |+-------+ +-------+ +-------+| +---------+|        || |       | |
|| +-----------------------------+            +--------+| +-------+ |
|+------------------------------------------------------+           |
+-------------------------------------------------------------------+


Figure 3: Illustration of ES with ES-X Timestamped.

When the two previous conditions are not met, the plaintiff must 
provide Type 1 






ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 10]
Internet Draft                             Electronic Signature Formats

An Electronic Signature (ES) , with the two above information (i.e. an ES-X Timestamped and Long).

When additional validation data 
forming the last condition eXtended Validation Data - Type 2 is not met, the plaintiff must provide an ES-
A. 

It should be noticed that a verifier may need to get two time stamps at 
two different instants of time: one soon after the generation illustrated in 
Figure 4:

+-------------------------------------------------------- ES-X 2 ---+
|+--------------------------------------- EC-C --------+            |
||+---- Elect.Signature (ES)----+            +--------+| +--------+ |
|||+-------+ +-------+ +-------+| +---------+|Complete|| |Times   | |
||||Signa- | |Other  | |Digital|| |Timestamp||certs   || |Stamp   | |
||||ture   | |Signed | |Signa- || |over     ||and     || |over    | |
||||Policy | |Attri- | |ture   || |digital  ||revoc.  || |Complete| |
||||ID     | |butes  | |       || |signature||refs    || |certs   | |
|||+-------+ +-------+ +-------+| +---------+|        || |and     | |
||+-----------------------------+            +--------+| |revoc.  | |
||                                                     | |refs    | |
|+-----------------------------------------------------+ +--------+ |
+-------------------------------------------------------------------+

Figure 4: Illustration of the ES 
and one soon after some grace period allowing any entity from the 
certification chain to declare a key compromise.




ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 10]

Internet Draft                                   Electronic Signature Formats


2.9	Validation Process

The Validation Process validates an electronic signature in accordance with ES-X Type 2 


2.7  Archive Validation Data

Before the requirements of the signature policy. The output status of algorithms, keys and other cryptographic data used at the 
validation process can be:

     * valid;
     * invalid;
...  * incomplete verification.

A Valid response indicates that 
time the signature has passed verification ES-C was built become weak and it complies with the signature validation policy.

A signature validation policy is a part of cryptographic functions 
become vulnerable, or the signature policy which 
specifies certificates supporting previous timestamps 
expires, the technical requirements on signed data, the signer in creating a 
signature ES-C and verifier when validating a signature

An Invalid response indicates that either the signature format is 
incorrect or that the digital signature value fails verification 
(e.g. the integrity checks on the digital signature value fails or any 
of the certificates on which the digital signature verification depends 
is known to be invalid or revoked).

An Incomplete Validation response indicates that the format and digital 
signature verifications have not failed but there is insufficient additional information to determine if the electronic signature is valid under 
(ES-X) should be timestamped.  If possible this should use stronger 
algorithms (or longer key lengths) than in the 
signature policy. original timestamp.  

This can include situations where additional information, which does 
not effect the validity of the digital signature value, may be 
available but data and timestamp is invalid. In the case of Incomplete Validation, it called Archive Validation Data
(ES-A).  The Timestamping process may be possible to request that repeated every time the electronic signature be checked again 
at 
protection used to timestamp a later date when additional validation information might previous ES-A become 
available. Also, in the case of incomplete validation, additional 
information weak. An ES-A 
may be made available to the application or user, thus 
allowing the application or user to decide what to do with partially 
correct electronic signatures.

The validation process may also output validation data :
     * a signature timestamp;
     * the complete validation data;
     * the archive validation data.












ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 11]

Internet Draft bear multiple embedded time stamps.

An example of an Electronic Signature Formats

2.10	Example Validation Sequence

As described earlier the signer or verifier may collect all (ES), with the additional 
validation data that forms for the Electronic Signature. Figure 6, ES-C and 
subsequent description, describes how ES-X forming the validation process may build 
up a complete electronic signature over time.


+---------------------------------------- ES-C ES-A is illustrated 
in Figure 5.

+-------------------------------- ES-A --------- ----------+
|+----------------------------- ES-T -------+            |
||+--- Elect.Signature (ES) ----+           | +--------+ |
|||+-------+ +-------+ +-------+|+---------+| |Complete| |
||||Signa- | |Other  | |Digital|||Timestamp|| |certifi-| |
||||ture   | |Signed | |Signa- |||over     || |cate and| |
||||Policy | |Attri- | |ture   |||digital  || |revoca- | |
||||ID     | |butes  | |       |||signature|| |tion 
|  +-------------------- ES-A -----------------+           |
|||+-------+ +-------+ +-------+|+---------+| |referen-| 
|
||+------------\----------------+    ^  | |ces  +--------- ES-X -------------- +         |           |
||              \ 
|  | +--------+  |..............................| +-----+ |
||               \ 1                /  +-----+  |      ^ 
|
|+----------------\----------------/--------+  |  |..............................| |Time |
+------------------\--------------/-------------- /------+
                    \            /2    ----3-----/
 +----------+ |          /     /  |Time | Signed   |\       v         /  |  
 |User data 
| \     +--------------------+     +------------+
 +----------+  \--->| Validation Process |---> |- Valid  |
                    +---|--^-------|--^--+ 4   |- Invalid  |..............................| |Stamp| |  |Stamp|  | 
|  |  |        |- Validation|
                        v                              |       v +-----+ |  +-----+  |  Incomplete|
                    +---------+ +--------+     +------------+
                    |Signature| |Trusted 
|  | Policy  +----------------------------- +         | |Service           | 
| Issuer  +-------------------------------------------+           | |Provider|
                    +---------+ +--------+ 
+----------------------------------------------------------+ 

Figure 6: 5: Illustration of an ES with Complete validation data (ES-C)

Soon after receiving the electronic signature (ES) from the signer (1), 
the digital signature value -A

Support for ES-A is optional.


ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 11]
Internet Draft                             Electronic Signature Formats


2.8  Arbitration

The ES-C may be checked,  the validation process 
must at least add used for arbitration should there be a time-stamp (2), unless dispute between 
the signer has and verifier, provided one 
which is trusted that:

      * a copy of the signature policy referenced by the verifier. The validation process may also 
validate the electronic signature, as required under the identified 
signature policy, using additional data (e.g. certificates, CRL, etc.) 
provided by trusted service providers. If the validation process signer is not 
complete then 
        available;

      * the output from this stage is arbitrator knows where to retrieve the ES-T.







ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 12]

Internet Draft                                   Electronic Signature Formats


When signer's certificate 
        (if not already present), all the additional data (e.g. the complete certificate cross-certificates and 
revocation information) necessary to validate the electronic signature 
first becomes available, then 
        required CRLs and/or OCSPs responses referenced in the validation process: ES-C;

      * obtains all none of the issuing key from the necessary additional certificate and revocation 
       status information; chain have ever 
        been compromised;

      * completes all the validation checks on cryptography used at the ES, using time the 
       complete certificate and revocation information  (if a timestamp 
       is ES-C was built has not already present, this may be added 
        been broken at the same stage 
       combining ES-T and ES-C process);
     * records time the complete certificate and revocation references (3);
     * indicates arbitration is performed.

When the validity status to second condition is not met, then the user (4).

At plaintiff must provide 
an ES-X Long.

When it is known by some external means that the same time as third condition is 
not met, then the validation process creates plaintiff must provide an ES-X Timestamped.

When the ES-C, two previous conditions are not met, the 
validation process may plaintiff must 
provide and/or record the values of certificates 
and revocation status two above information used in ES-C, called the (i.e. an ES-X Long 
(5). This Timestamped and Long).

When the last condition is illustrated in figure 7:


+---------------------------------------------------- ES-X ---------+
|+--------------------------------------- ES-C --------+ +--------+ |
||+--- Elect.Signature (ES) ----+           +--------+ | |Complete| |
|||+-------+ +-------+ +-------+|+---------+|Complete| | |certifi-| |
||||Signa- | |Other  | |Digital|||Timestamp||certifi-| | |cate    | |
||||ture   | |Signed | |Signa- |||over     ||cate and| | |and     | |
||||Policy | |Attri- | |ture   |||digital  ||revoca- | | |revoca- | |
||||ID     | |butes  | |       |||signature||tion    | | |tion    | |
|||+-------+ +---|---+ +-------+|+---------+|referen-| | |Data    | |
||+--------------\--------------+    ^      |ces     | | +--------+ |
||                \                  |      +--------+ |      ^     |
||                 \ 1             2/          ^       |      |     |
|+------------------\--------------/-----------|-------+     /      |
+--------------------\------------/-----------/-------------/-------+
                      \          /    ---3---/             /   
 +----------+          |        /    /   -----------5-----/
 | Signed   |\         v       |     |  / 
 |User data | \     +--------------------+     +-----------+
 +----------+  \--->| not met, the plaintiff must provide an 
ES-A. 

It should be noticed that a verifier may need to get two time stamps 
at two different instants of time: one soon after the generation of 
the ES and one soon after some grace period allowing any entity from 
the certification chain to declare a key compromise.

2.9  Validation Process |---> | - Valid   |
                    +---|--^-------|--^--+ 4   | - Invalid |
                        |  |       |  |        +-----------+
                        v  |       v  | 
                    +---------+ +--------+
                    |Signature| |Trusted |
                    | Policy  | |Service |
                    | Issuer  | |Provider|
                    +---------+ +--------+


Figure 7: Illustration ES

The Validation Process validates an electronic signature in accordance 
with eXtended validation data (Long)



ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 13]

Internet Draft                                   Electronic Signature Formats

When the requirements of the signature policy. The output status of 
the validation process creates the ES-C can be:

     * valid;
     * invalid;
     * incomplete verification.

A Valid response indicates that the signature has passed verification 
and it may also create 
extended forms of complies with the signature validation data. policy.

A first alternative signature validation policy is to timestamp 
all data forming a part of the Type 1 X-Timestamp (6). This is illustrated signature policy which 
specifies the technical requirements on the signer in 
figure 8:


+---------------------------------------------------- ES-X -------+
|+--------------------------------------- ES-C --------+ +------+ |
||+--- Elect.Signature (ES) ----+           +--------+ | |Time- | |
|||+-------+ +-------+ +-------+|+---------+|Complete| | |stamp | |
||||Signa- | |Other  | |Digital|||Timestamp||certifi-| | |over  | |
||||ture   | |Signed | |Signa- |||over     ||cate and| | |CES   | |
||||Policy | |Attri- | |ture   |||digital  ||revoca- | | +------+ |
||||ID     | |butes  | |       |||signature||tion    | |     ^    |
|||+-------+ +--|----+ +-------+|+---------+|referen-| |     |    |
||+-------------|---------------+     ^     |ces     | |     |    |
||              |                     |     +--------+ |     |    |
||               \ 1                 2/        ^       |     |    |
|+----------------\------------------/---------|-------+     |    |
+------------------\----------------/----------/-------------/----+
                    \              /   ----3--/             /
 +----------+        |            /   /  --------------6---/ 
 | Signed   |\       v           |   |  / 
 |User data | \     +--------------------+     +-----------+
 +----------+  \--->| Validation Process |---> | - Valid   |
                    +---|--^-------|--^--+ 4   | - Invalid |
                        |  |       |  |        +-----------+
                        v  |       v  |
                    +---------+ +--------+
                    |Signature| |Trusted |
                    | Policy  | |Service |
                    | Issuer  | |Provider|
                    +---------+ +--------+

Figure 8: Illustration of ES with eXtended validation data - Type 1 X-
Timestamp creating a 
signature and verifier when validating a signature.



ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 14] 12]
Internet Draft                             Electronic Signature Formats

Another alternative is to timestamp


An Invalid response indicates that either the certificate signature format is 
incorrect or that the digital signature value fails verification 
(e.g. the integrity checks on the digital signature value fails or 
any of the certificates on which the digital signature verification 
depends is known to be invalid or revoked).

An Incomplete Validation response indicates that the format and revocation 
digital signature verifications have not failed but there is 
insufficient information references used to validate determine if the electronic signature (but 
not the signature) (6'); this 
is called Type 2 X-Timestamped. valid under the signature policy. This can include situations 
where additional information, which does not effect the validity of 
the digital signature value, may be available but is 
illustrated invalid. 

In the case of Incomplete Validation, it may be possible to request 
that the electronic signature be checked again at a later date when 
additional validation information might become available. Also, in figure 9:

+---------------------------------------------------- ES-X ----------+
|+--------------------------------------- ES-C --------+ +---------+ |
||+--- Elect.Signature the 
case of incomplete validation, additional information may be made 
available to the application or user, thus allowing the application or 
user to decide what to do with partially correct electronic signatures.

The validation process may also output validation data :

     * a signature timestamp;
     * the complete validation data;
     * the archive validation data.

2.10  Example Validation Sequence

As described earlier the signer or verifier may collect all the 
additional data that forms the Electronic Signature. Figure 6, and 
subsequent description, describes how the validation process may build 
up a complete electronic signature over time.

Soon after receiving the electronic signature (ES) ----+           +--------+ from the signer (1), 
the digital signature value may be checked,  the validation process 
must at least add a time-stamp (2), unless the signer has provided one 
which is trusted by the verifier. The validation process may also 
validate the electronic signature, as required under the identified 
signature policy, using additional data (e.g. certificates, CRL, etc.) 
provided by trusted service providers. If the validation process is not 
complete then the output from this stage is the ES-T.

When all the additional data (e.g. the complete certificate and 
revocation information) necessary to validate the electronic signature 
first becomes available, then the validation process:

     * obtains all the necessary additional certificate and revocation 
       status information;

     * completes all the validation checks on the ES, using the 
       complete certificate and revocation information  (if a timestamp 
       is not already present, this may be added at the same stage 
       combining ES-T and ES-C process);

ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 13]
Internet Draft                             Electronic Signature Formats


     * records the complete certificate and revocation references (3);

     * indicates the validity status to the user (4).

+---------------------------------------- ES-C ----------+
|+----------------------------- ES-T -------+            | |Timestamp|
||+--- Elect.Signature (ES) ----+           | +--------+ |
|||+-------+ +-------+ +-------+|+---------+|Complete| | |over     | +-------+|+---------+| |Complete| |
||||Signa- | |Other  | |Digital|||Timestamp||certifi-| | |Complete | |Digital|||Timestamp|| |certifi-| |
||||ture   | |Signed | |Signa- |||over     ||cate     || |cate and| | |Certifi- | |
||||Policy | |Attri- | |ture   |||digital  ||revoc.  | | |cate and  || |revoca- | |
||||ID     | |butes  | |       |||signature||refs    | | |revoc.       |||signature|| |tion    | |
|||+-------+ +---^---+ +-------+|+----^----++---^----+ | |refs +-------+ +-------+|+---------+| |referen-| |
||+------------\----------------+    ^      |
||+--------------\--------------+ |ces     | |
||              \                    | +---------+      |
|+----------------\------------------/----------|------+      ^ +--------+ |
+----------------1-\----------------/----------/--------------|------+
||               \ 1                /  -----3--/       |
 +----------+      ^     |           2/  /   --------------6'-----/
|+----------------\----------------/--------+      | Signed   |\       v     |
+------------------\--------------/-------------- /------+
                    \            /2    ----3-----/
 +----------+        |          /     /  
 | Signed   |\       v         /     |  
 |User data | \     +--------------------+     +-----------+     +------------+
 +----------+  \--->| Validation Process |---> | - |- Valid     |
                    +---|--^-------|--^--+ 4   | -   |- Invalid   |
                        |  |       |  |        +-----------+        |- Validation|
                        v  |       v  |        |  Incomplete|
                    +---------+ +--------+     +------------+
                    |Signature| |Trusted |
                    | Policy  | |Service |
                    | Issuer  | |Provider|
                    +---------+ +--------+


Figure 9: 6: Illustration of an ES with eXtended Complete validation data - Type 2 X-
Timestamp (ES-C)




















ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 15] 14]
Internet Draft                             Electronic Signature Formats

Before



At the algorithms used in any of electronic signatures become or 
are likely, to be compromised or rendered vulnerable in same time as the future, it 
is necessary to timestamp validation process creates the entire electronic signature, including 
all ES-C, the 
validation process may provide and/or record the values of the validation certificates 
and user data as an ES with Archive 
validation data (ES-A) 

  An ES-A revocation status information used in ES-C, called the ES-X Long 
(5). This is illustrated in figure 10:


-------------------------------------------- ES-A --------------------+
----------------------------------------------------------------+ 7:


+---------------------------------------------------- ES-X ---------+
|+--------------------------------------- ES-C --------+ +--------+ |
+------------------------------- EC-C --------++-----+
||+--- Elect.Signature (ES) ----+           +--------+ | |Complete| |
|||+-------+ +-------+ +-------+|+---------+|Complete| |                                             ||Time-| |certifi-| |
||||Signa- |
|+-- Elect.Signature (ES) -+        +--------+||stamp|  +-------+ |Other  |
||+------++-------++-------|+------+|Complete|||over |Digital|||Timestamp||certifi-| |  Complete| |cate    |
|||Signa-||Other  ||Digital||Time- ||certifi-|||CES |  |certi- |+----|
|||ture  ||Signed ||Signa- ||stamp
||||ture   | |Signed | |Signa- |||over     ||cate and||+-----+  |ficate |Arch-|
|||Policy||Attri- ||ture   ||over  ||revoca- ||+------+ and| | |and    |ive     |
|||ID    ||butes  ||       ||digit.||tion    |||Time- | |revoca-|Time
||||Policy |
||+------++---|---++-------||signa-||referen-|||stamp-| |tion   |stamp|
|+------------|------------+|ture  ||ces     |||over |Attri- | |data   |+----| |ture   |||digital  ||revoca- | |             +------++--------+|Complete\+-------+  ^ |revoca- | |
||||ID     |                ^         ^    ||cert. |butes  | |       |||signature||tion    | |
+-------------|----------------|---------|----+|and rev| |tion    | |
|||+-------+ +---|---+ +-------+|+---------+|referen-| |
               \ |Data    |         /     |refs. |
||+--------------\--------------+    ^      |ces     | | +--------+ |
||                \                  |        /      +-------+      +--------+ |      ^     |
||                 \ 1             2/          ^       |
-----------------\-------------|-------/------------------------+      |     |
+----------+      \
|+------------------\--------------/-----------|-------+     /      |
+--------------------\------------/-----------/-------------/-------+
                      \          /    ---3---/             /   
 +----------+          |        /    /   -----------5-----/
 | Signed   |\         v       |       \2          |3    /     /--------------7-------/     |  / 
 |User data | \          |    |     /                           |
+-------\--+         \         |    |    /                            |
---------\------------|--------|----|---/-----------------------------+
          \           v        |    |   | 
          1\     +--------------------+     +-----------+
            \------>|
 +----------+  \--->| Validation Process |---> | - Valid   |
                    +---|--^-------|--^--+ 4   | - Invalid |
                        |  |       |  |        +-----------+
                        v  |       v  | 
                    +---------+ +--------+
                    |Signature| |Trusted |
                    | Policy  | |Service |
                    | Issuer  | |Provider|
                    +---------+ +--------+


Figure 10: 7: Illustration of an ES with Archive eXtended validation data (ES-A)

2.11	Additional optional features

This document also defines additional optional features to:
     * indicate a commitment type being made by the signer;
     * indicate the role under which a signature was created;
     * support multiple signatures. (Long)

















ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 16] 15]
Internet Draft                             Electronic Signature Formats



3. Data structure of an Electronic Signature

This clause uses and builds upon



When the Crypographic Message Syntax (CMS), 
as defined in RFC 2630, REF [CMS] , and Enhanced Security Services 
(ESS), as defined in RFC 2634 [10], REF [ESS] . The overall structure 
of Electronic Signature is as defined in [CMS]. The Electronic 
Signature (ES) uses attributes defined in [CMS], [ESS] and 
this document. This document defines in full validation process creates the ES attributes which ES-C it 
uses and are not defined elsewhere.

The mandated set may also create 
extended forms of attributes and the digital signature value is 
defined as the minimum Electronic Signature (ES) required by this 
document. validation data. A signature policy MAY mandate other signed attributes are 
present.

3.1	General Syntax

The general syntax of the ES first alternative is as defined in [CMS].

3.2	Data Content Type 

The to timestamp 
all data content type of forming the ES is as defined in [CMS].

3.3	Signed-data Content Type

The Signed-data content type of the ES is as defined in [CMS].

To make sure that the verifier uses the right signers key, this 
document mandates that the hash of the signers certificate 1 X-Timestamp (6). This is always 
included illustrated in the Signing Certificate signed attribute.

3.4	SignedData Type

The syntax of the SignedData type 
figure 8:


+---------------------------------------------------- ES-X -------+
|+--------------------------------------- ES-C --------+ +------+ |
||+--- Elect.Signature (ES) ----+           +--------+ | |Time- | |
|||+-------+ +-------+ +-------+|+---------+|Complete| | |stamp | |
||||Signa- | |Other  | |Digital|||Timestamp||certifi-| | |over  | |
||||ture   | |Signed | |Signa- |||over     ||cate and| | |CES   | |
||||Policy | |Attri- | |ture   |||digital  ||revoca- | | +------+ |
||||ID     | |butes  | |       |||signature||tion    | |     ^    |
|||+-------+ +--|----+ +-------+|+---------+|referen-| |     |    |
||+-------------|---------------+     ^     |ces     | |     |    |
||              |                     |     +--------+ |     |    |
||               \ 1                 2/        ^       |     |    |
|+----------------\------------------/---------|-------+     |    |
+------------------\----------------/----------/-------------/----+
                    \              /   ----3--/             /
 +----------+        |            /   /  --------------6---/ 
 | Signed   |\       v           |   |  / 
 |User data | \     +--------------------+     +-----------+
 +----------+  \--->| Validation Process |---> | - Valid   |
                    +---|--^-------|--^--+ 4   | - Invalid |
                        |  |       |  |        +-----------+
                        v  |       v  |
                    +---------+ +--------+
                    |Signature| |Trusted |
                    | Policy  | |Service |
                    | Issuer  | |Provider|
                    +---------+ +--------+

Figure 8: Illustration of the ES with eXtended validation data - Type 1 X-
Timestamp

















ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 16]
Internet Draft                             Electronic Signature Formats



Another alternative is as defined in [CMS].

The fields of type SignedData have the meanings defined [CMS] except 
that:

     * version is to timestamp the syntax version number. The value of version must 
       be 3.

     * The identification of signer's certificate and revocation 
information references used to create validate the electronic signature (but 
not the signature) (6'); this is always signed. The validation policy may specify 
       requirements for the presence of certain certificates.


     * The degenerate case where there are no signers called Type 2 X-Timestamped. This is not valid 
illustrated in 
       this document. figure 9:


+---------------------------------------------------- ES-X ----------+
|+--------------------------------------- ES-C --------+ +---------+ |
||+--- Elect.Signature (ES) ----+           +--------+ | |Timestamp| |
|||+-------+ +-------+ +-------+|+---------+|Complete| | |over     | |
||||Signa- | |Other  | |Digital|||Timestamp||certifi-| | |Complete | |
||||ture   | |Signed | |Signa- |||over     ||cate and| | |Certifi- | |
||||Policy | |Attri- | |ture   |||digital  ||revoc.  | | |cate and | |
||||ID     | |butes  | |       |||signature||refs    | | |revoc.   | |
|||+-------+ +---^---+ +-------+|+----^----++---^----+ | |refs     | |
||+--------------\--------------+     |         |      | +---------+ |
|+----------------\------------------/----------|------+      ^      |
+----------------1-\----------------/----------/--------------|------+
                    \              /  -----3--/               |
 +----------+        |           2/  /   --------------6'-----/
 | Signed   |\       v           |  |   / 
 |User data | \     +--------------------+     +-----------+
 +----------+  \--->| Validation Process |---> | - Valid   |
                    +---|--^-------|--^--+ 4   | - Invalid |
                        |  |       |  |        +-----------+
                        v  |       v  | 
                    +---------+ +--------+
                    |Signature| |Trusted |
                    | Policy  | |Service |
                    | Issuer  | |Provider|
                    +---------+ +--------+

Figure 9: Illustration of ES with eXtended validation data - Type 2 X-
Timestamp



















ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 17]
Internet Draft                             Electronic Signature Formats


3.5	EncapsulatedContentInfo Type

The syntax of

Before the EncapsulatedContentInfo a type algorithms used in any of the ES is as defined electronic signatures become or 
are likely, to be compromised or rendered vulnerable in [CMS].

For the purpose of long term validation as defined by this document, future, it 
is advisable that either necessary to timestamp the eContent is present, or entire electronic signature, including 
all the data which is 
signed is archived in such as way as to preserve the any data encoding. 
It is important that the OCTET STRING used to generate the signature 
remains the same every time either the verifier or an arbitrator 
validates the signature.



The degenerate case where there are no signers is not valid in this 
document.

3.6	SignerInfo Type

The syntax of the SignerInfo a type values of the ES is validation and user data as defined in [CMS].

Per-signer information is represented in the type SignerInfo. In the 
case of multiple independent signatures, there is an instance 
of this field for each signer.

The fields of type SignerInfo have the meanings defined in [CMS} except 
that:

signedAttributes must, as a minimum, 
contain the following attributes:
* ContentType as defined in clause 3.7.1.
* MessageDigest as defined in clause 3.7.2.
* SigningTime as defined in clause 3.7.3.
* SigningCertificate as defined in clause 3.8.1.
* SignaturePolicyId as defined in clause 3.9.1.

3.6.1	Message Digest Calculation Process

The message digest calculation process is as defined in [CMS]. 

3.6.2	Message Signature Generation Process

The input to the digital signature generation process is as defined in 
[CMS]. 

3.6.3	Message Signature Verification Process

The procedures for CMS signed data ES with Archive 
validation are as defined in 
[CMS] and enhanced data (ES-A) 

  An ES-A is illustrated in this document.

The input to the signature verification process includes the signer's 
public key verified as correct using the ESS Signing Certificate or 
Other Signing Certificate attribute. 

ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 18]

Internet Draft                                   Electronic Signature Formats

3.7	CMS Imported Mandatory Present Attributes

The following attributes MUST be present with the signed-data defined 
by this document. The attributes are defined in [CMS].

3.7.1	Content Type
The syntax figure 10:

-------------------------------------------- ES-A --------------------+
----------------------------------------------------------------+     |
+------------------------------- EC-C --------++-----+          |     |
|                                             ||Time-|          |     |
|+-- Elect.Signature (ES) -+        +--------+||stamp|  +-------+     |
||+------++-------++-------|+------+|Complete|||over |  Complete|     |
|||Signa-||Other  ||Digital||Time- ||certifi-|||CES  |  |certi- |+----|
|||ture  ||Signed ||Signa- ||stamp ||cate and||+-----+  |ficate |Arch-|
|||Policy||Attri- ||ture   ||over  ||revoca- ||+------+ |and    |ive  |
|||ID    ||butes  ||       ||digit.||tion    |||Time- | |revoca-|Time |
||+------++---|---++-------||signa-||referen-|||stamp-| |tion   |stamp|
|+------------|------------+|ture  ||ces     |||over  | |data   |+----|
|             |             +------++--------+|Complete\+-------+  ^  |
|             |                ^         ^    ||cert.  |        |  |  |
+-------------|----------------|---------|----+|and rev|        |  |  |
               \               |         /     |refs.  |        |  |  |
                \              |        /      +-------+        |  |  |
-----------------\-------------|-------/------------------------+  |  |
+----------+      \            |      /                            /  |
| Signed   |       \2          |3    /     /--------------7-------/   |
|User data |        \          |    |     /                           |
+-------\--+         \         |    |    /                            |
---------\------------|--------|----|---/-----------------------------+
          \           v        |    |   | 
          1\        +--------------------+     +-----------+
            \------>| Validation Process |---> | - Valid   |
                    +---|--^-------|--^--+ 4   | - Invalid |
                        |  |       |  |        +-----------+
                        v  |       v  | 
                    +---------+ +--------+
                    |Signature| |Trusted |
                    | Policy  | |Service |
                    | Issuer  | |Provider|
                    +---------+ +--------+


Figure 10: Illustration of the content-type attribute an ES with Archive validation data (ES-A)

2.11  Additional optional features

This document also defines additional optional features to:

     * indicate a commitment type of being made by the ES is as defined 
in [CMS].

3.7.2	Message Digest
The syntax of signer;
     * indicate the message-digest attribute type role under which a signature was created;
     * support multiple signatures.


ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 18]
Internet Draft                             Electronic Signature Formats


3. Data structure of an Electronic Signature

This clause uses and builds upon the ES is Cryptographic Message Syntax 
(CMS), as defined in [CMS].

3.7.3	Signing Time RFC 2630 [CMS], and Enhanced Security Services 
(ESS), as defined in RFC 2634 [ESS]. The syntax of the message-digest attribute type overall structure 
of the ES Electronic Signature is as defined in [CMS]and further qualified by [CMS]. The Electronic 
Signature (ES) uses attributes defined in [CMS], [ESS] and 
this document.

The signing-time attribute type specifies the time at which the signer 
claims to have performed the signing process. This present document recommends defines in full the use of GeneralizedTime.

3.8	Alternative Signing Certificate Attributes

One, ES attributes which it 
uses and only one, are not defined elsewhere.

The mandated set of the following two alternative attributes MUST be 
present with and the signed-data digital signature value is 
defined as the minimum Electronic Signature (ES) required by this document to identify the 
signing certificate.   Both 
document. A signature policy MAY mandate other signed attributes include an identifier and a hash to be
present.

3.1  General Syntax

The general syntax of the signing certificate.  The first, which ES is adopted as defined in existing 
standards, may be used if with the SHA-1 hashing algorithm. [CMS].

3.2  Data Content Type 

The other 
hall be used for other hashing algorithms are to be supported. data content type of the ES is as defined in [CMS].

The signing certificate attribute data content type is designed intended to prevent refer to arbitrary octet strings, 
such as ASCII text files; the simple 
substitution and re-issue attacks, and interpretation is left to allow for a restricted set of 
authorization certificates to be used in verifying a signature.

3.8.1	ESS Signing Certificate Attribute Definition

The syntax of the signing certificate attribute 
application.  Such strings need not have any internal structure 
(although they could have their own ASN.1 definition or other 
structure).

3.3  Signed-data Content Type

The Signed-data content type of the ES is as defined in [ESS], and further qualified and profile in this document. [CMS].

The ESS signing certificate attribute must be a signed attribute.

This document mandates the presence signed-data content type consists of this attribute as a signed CMS 
attribute, content of any type and the sequence must not be empty. zero 
or more signature values. Any number of signers in parallel can sign 
any type of content. The certificate used to 
verify typical application of the signed-data content 
type represents one signer's digital signature must be identified in on content of the sequence, data 
content type.

To make sure that the Signature 
Validation Policy may mandate other certificates be present, verifier uses the right certificate, this 
document mandates that may 
include all the certificates up to hash of the point signers certificate is always 
included in the Signing Certificate signed attribute.

3.4  SignedData Type

The syntax of trust. the SignedData type of the ES is as defined in [CMS].

The encoding fields of type SignedData have the ESSCertID for this certificate must include meanings defined [CMS] except 
that:

     * version is the issuerSerial 
field. syntax version number. The value of version must 
       be 3.


ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 19]
Internet Draft                             Electronic Signature Formats

     * The issuerAndSerialNumber present in the SignerInfo must be 
consistent with issuerSerial field. The certificate identified must be 
used during the signature verification process. If the hash identification of the 
certificate does not match the signer's certificate used to verify the 
signature, create the 
       signature must be considered invalid. is always present as a signed attribute.

     * The sequence of policy information field degenerate case where there are no signers is not used valid in 
       this document.

NOTE:	Where an attribute certificate is used by

3.5  EncapsulatedContentInfo Type

The syntax of the signer to associate EncapsulatedContentInfo a role, or other attributes type of the signer, with the electronic 
signature this ES is placed as 
defined in [CMS].

For the Signer Attribute attribute purpose of long term validation as defined 
in clause 3.12.3.

3.8.2	Other Signing Certificate Attribute Definition

The following attribute by this document, it 
is identical advisable that either the eContent is present, or the data which is 
signed is archived in such as way as to preserve the ESS SigningCertificate 
defined above except any data encoding. 
It is important that this attribute can be used with hashing 
algorithms other than SHA-1.

This attribute must be the OCTET STRING used in to generate the signature 
remains the same manner every time either the verifier or an arbitrator 
validates the signature.

The degenerate case where there are no signers is not valid in this 
document.

3.6  SignerInfo Type

The syntax of the SignerInfo a type of the ES is as defined above for in [CMS].

Per-signer information is represented in the ESS SigningCertificate attribute.

The following object identifier identifies type SignerInfo. In the signing certificate 
attribute:

id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-aa(2) 19 } 
case of multiple independent signatures, there is an instance 
of this field for each signer.

The signing certificate attribute value has fields of type SignerInfo have the ASN.1 syntax 
OtherSigningCertificate

OtherSigningCertificate ::=  SEQUENCE {
    certs        SEQUENCE OF OtherCertID,
    policies     SEQUENCE OF PolicyInformation OPTIONAL
                 -- NOT USED IN THIS DOCUMENT
    }

OtherCertID ::= SEQUENCE {
    otherCertHash            OtherHash,
     issuerSerial             IssuerSerial OPTIONAL }

OtherHash ::= CHOICE {
    sha1Hash OtherHashValue,  -- This contains meanings defined in [CMS] 
except that signedAttributes must, as a SHA-1 hash
    otherHash OtherHashAlgAndValue}

OtherHashValue ::= OCTET STRING

OtherHashAlgAndValue ::= SEQUENCE {
	hashAlgorithm	AlgorithmIdentifier,
	hashValue		OtherHashValue } minimum, contain the following 
attributes:

* ContentType as defined in clause 3.7.1.
* MessageDigest as defined in clause 3.7.2.
* SigningTime as defined in clause 3.7.3.
* SigningCertificate as defined in clause 3.8.1.
* SignaturePolicyId as defined in clause 3.9.1.

3.6.1  Message Digest Calculation Process

The message digest calculation process is as defined in [CMS]. 

3.6.2  Message Signature Generation Process

The input to the digital signature generation process is as defined in 
[CMS]. 

3.6.3  Message Signature Verification Process

The procedures for CMS signed data validation are as defined in 
[CMS] and enhanced in this document.



ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 20]
Internet Draft                             Electronic Signature Formats


3.9	Additional Mandatory Attributes 

3.9.1	Signature policy Identifier

This document mandates that a reference

The input to the signature policy, which 
defines verification process includes the rules for creation and validation of an electronic 
signature, is included signer's 
public key verified as a signed correct using either the ESS Signing 
Certificate attribute with every signature. The 
signature policy identifier must be a signed or the Other Signing Certificate attribute. 

3.7  CMS Imported Mandatory Present Attributes

The following object identifier identifies attributes MUST be present with the signature policy 
identifier attribute:

id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-aa(2) 15 }


Signature-policy-identifier attribute values have ASN.1 type 
SignaturePolicyIdentifier.
SignaturePolicyIdentifier ::= SEQUENCE {
        sigPolicyIdentifier   SigPolicyId,
		sigPolicyHash         SigPolicyHash,
        sigPolicyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                SigPolicyQualifierInfo OPTIONAL} signed-data defined 
by this document. The sigPolicyIdentifier field contains an object-identifier which 
uniquely identifies a specific version of the signature policy. attributes are defined in [CMS].

3.7.1  Content Type

The syntax of this field is as follows:

   SigPolicyId ::= OBJECT IDENTIFIER

The sigPolicyHash field contains the identifier content-type attribute type of the hash algorithm 
and the hash ES is as defined 
in [CMS].

3.7.2  Message Digest

The syntax of the value message-digest attribute type of the signature policy.

If the signature policy ES is as defined using ASN.1 (see 6.1) the hash is 
calculated on the value without 
in [CMS].

3.7.3  Signing Time

The syntax of the outer message-digest attribute type and length fields and of the hashing algorithm must be ES is as specified defined 
in [CMS] and further qualified by this document.

The signing-time attribute type specifies the field 
signPolicyHshAlg.

If time at which the signature policy is defined using another structure, signer 
claims to have performed the type signing process. 

This present document recommends the use of 
structure GeneralizedTime.

3.8  Alternative Signing Certificate Attributes

One, and the hashing algorithm must be either specified as part only one, of the signature policy, or indicated using a signature policy 
qualifier. 

   SigPolicyHash ::= ETSIHashAlgAndValue







ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 21]

Internet Draft                                   Electronic Signature Formats


A signature policy identifier may following two alternative attributes MUST be qualified 
present with other information 
about the qualifier. The semantics signed-data defined by this document to identify the 
signing certificate. Both attributes include an identifier and syntax a hash 
of the qualifier signing certificate. The first, which is as 
associated with the object-identifier adopted in existing 
standards, may be only used with the sigPolicyQualifierId 
field. SHA-1 hashing algorithm. The general syntax of this qualifier is as follows:

   SigPolicyQualifierInfo ::= SEQUENCE {
        sigPolicyQualifierId  SigPolicyQualifierId,
        sigQualifier          ANY DEFINED BY sigPolicyQualifierId }


This document specifies the following qualifiers:
    * spuri: This contains the web URI or URL reference 
other shall be used when other hashing algorithms are to the 
      signature policy

    * spUserNotice: This contains a user notice which should be 
     displayed whenever the signature is validated.

-- sigpolicyQualifierIds defined in this document

SigPolicyQualifierId ::=
        OBJECT IDENTIFIER 

	id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-spq(5) 1 }


   SPuri ::= IA5String

	id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-spq(5) 2 }


   SPUserNotice ::= SEQUENCE {
        noticeRef        NoticeReference OPTIONAL,
        explicitText     DisplayText OPTIONAL}

  

 NoticeReference ::= SEQUENCE {
        organization     DisplayText,
        noticeNumbers    SEQUENCE OF INTEGER }

   DisplayText ::= CHOICE {
        visibleString    VisibleString  (SIZE (1..200)),
        bmpString        BMPString      (SIZE (1..200)),
        utf8String       UTF8String     (SIZE (1..200)) }





ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 22]

Internet Draft                                   Electronic Signature Formats



3.10	CMS Imported Optional Attributes supported.

The following attributes MAY be present with signing certificate attribute is designed to prevent the signed-data defined by 
this document. The attributes are defined in ref [CMS] and are imported 
into this specification simple 
substitution and were appropriate qualified re-issue attacks, and profiling  by 
this document.

3.10.1	Countersignature to allow for a restricted set of 
authorization certificates to be used in verifying a signature.

3.8.1  ESS Signing Certificate Attribute Definition

The syntax of the countersignature signing certificate attribute type of the ES is as 
defined in [CMS].

The countersignature attribute must be an unsigned attribute


3.11	ESS Imported Optional Attributes

The following attributes MAY be present with the signed-data defined by 
this document. The attributes are defined in ref [ESS] and are imported 
into this specification [ESS], and were appropriate further qualified and profiling  by profile in this document.

3.11.1	Signed Content Reference Attribute

The content reference ESS signing certificate attribute is a link from one SignedData to 
another. It may must be used to link a reply to signed attribute.

This document mandates the original message to 
which it refers, or to incorporate by reference one SignedData into 
another. 

The content reference presence of this attribute MUST be used as defined in [ESS].

The content reference MUST be a signed attribute.

The syntax of the content reference attribute type of CMS 
attribute, and the ES is as 
defined in [ESS].

3.11.2	Content Identifier Attribute sequence must not be empty. The content identifier attribute provides an identifier for certificate used to 
verify the signed 
content for use when reference may signature must be later required to that content, 
for example identified in the content reference attribute in sequence, the Signature 
Validation Policy may mandate other signed data sent 
later. 

The content identifier must certificate references to be a signed attribute.

The syntax of 
present, that may include all the content identifier attribute type of certificates up to the ES is as 
defined in [ESS].

The minimal signedContentIdentifier should contain a concatenation point of 
user-specific identification information (such as a user name or public 
keying material identification information), a GeneralizedTime string, 
and a random number. 

ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 23] 21]
Internet Draft                             Electronic Signature Formats


3.12	 Additional Optional Attributes 

3.12.1	Commitment Type Indication Attribute

There may be situation were a signer wants to explicitly indicate to a 
verifier that by signing the data, it illustrates a type of commitment 
on behalf

trust. The encoding of the signer. The commitmentTypeIndication attribute conveys 
such information. ESSCertID for this certificate must include 
the issuerSerial field. 

The commitmentTypeIndication attribute issuerAndSerialNumber present in the SignerInfo must be a signed attribute 
consistent with issuerSerial field. The commitment type may be:

    * defined as part of certificate identified must be 
used during the signature policy, in which case verification process. If the 
      commitment type has precise semantics that is defined as part hash of the signature policy. 

    * be a registered type, in which case 
certificate does not match the commitment type has 
     precise semantics defined by registration, under certificate used to verify the rules of 
signature, the
     registration authority. Such a registration authority may signature must be a
     trading association or a legislative authority. considered invalid.

The signature sequence of policy specifies information field is not used in this document.

NOTE: Where an attribute certificate is used by the signer to associate 
a set of role, or other attributes that it 
"recognizes". This "recognized" set includes all those commitment types 
defined as part of the signer, with the electronic 
signature policy as well this is placed in the Signer Attribute attribute as any externally defined commitment types that the policy may choose to recognize. Only 
recognized commitment types are allowed 
in clause 3.12.3.

3.8.2  Other Signing Certificate Attribute Definition

The following attribute is identical to the ESS SigningCertificate 
defined above except that this field. attribute can be used with hashing 
algorithms other than SHA-1.

This attribute must be used in the same manner as defined above for 
the ESS SigningCertificate attribute.

The following object identifier identifies the commitment type 
indication signing certificate 
attribute:

id-aa-ets-commitmentType

id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) pkcs9(9)
    smime(16) id-aa(2) 16}

Commitment-Type-Indication 19 }

The signing certificate attribute values have value has the ASN.1 type 
CommitmentTypeIndication.
CommitmentTypeIndication syntax 
OtherSigningCertificate

OtherSigningCertificate ::=  SEQUENCE {
  commitmentTypeId CommitmentTypeIdentifier,
  commitmentTypeQualifier
    certs        SEQUENCE SIZE (1..MAX) OF 
CommitmentTypeQualifier 
OPTIONAL}

CommitmentTypeIdentifier ::= OBJECT IDENTIFIER

CommitmentTypeQualifier OtherCertID,
    policies     SEQUENCE OF PolicyInformation OPTIONAL
                 -- NOT USED IN THIS DOCUMENT
}

OtherCertID ::= SEQUENCE {
		commitmentTypeIdentifier CommitmentTypeIdentifier,
		qualifier	ANY DEFINED BY commitmentTypeIdentifier
     otherCertHash            OtherHash,
     issuerSerial             IssuerSerial OPTIONAL
}


The use of any qualifiers to the commitment type is outside the scope 
of this document.

OtherHash ::= CHOICE {
    sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
    otherHash OtherHashAlgAndValue
}

OtherHashValue ::= OCTET STRING



ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 24] 22]
Internet Draft                             Electronic Signature Formats

OtherHashAlgAndValue ::= SEQUENCE {
  hashAlgorithm  AlgorithmIdentifier,
  hashValue      OtherHashValue
}

3.9  Additional Mandatory Attributes 

3.9.1  Signature policy Identifier

This document mandates that a reference to the signature policy, which 
defines the rules for creation and validation of an electronic 
signature, is included as a signed attribute with every signature. The 
signature policy identifier must be a signed attribute.

The following generic commitment types are defined in this document:
       id-cti-ets-proofOfOrigin object identifier identifies the signature policy 
identifier attribute:

id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1) member-
       body(2)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) pkcs9(9)
    smime(16)
       cti(6) 1}

       id-cti-ets-proofOfReceipt OBJECT IDENTIFIER id-aa(2) 15 }

Signature-policy-identifier attribute values have ASN.1 type 
SignaturePolicyIdentifier.

SignaturePolicyIdentifier ::= SEQUENCE { iso(1) member-
       body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
       cti(6) 2}

       id-cti-ets-proofOfDelivery
        sigPolicyIdentifier   SigPolicyId,
        sigPolicyHash         SigPolicyHash,
        sigPolicyQualifiers   SEQUENCE SIZE (1..MAX) OF
                              SigPolicyQualifierInfo      OPTIONAL
}

The sigPolicyIdentifier field contains an object-identifier which 
uniquely identifies a specific version of the signature policy. The 
syntax of this field is as follows:

   SigPolicyId ::= OBJECT IDENTIFIER ::= { iso(1)
       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
       smime(16) cti(6) 3}

       id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-
       body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
       cti(6) 4}

       id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1)
       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
       smime(16) cti(6) 5}

       id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1)
       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
       smime(16) cti(6) 6}


These generic commitment types have

The sigPolicyHash field contains the following meaning: 

Proof identifier of origin indicates that the signer recognizes to have created, 
approved hash algorithm 
and sent the message.

Proof hash of receipt indicates that signer recognizes to have received the 
content value of the message.

Proof of delivery indicates that signature policy.

If the TSP providing that indication has 
delivered a message in signature policy is defined using a local store accessible to computer processable 
notation like ASN.1, then the recipient of hash is calculated on the 
message.

Proof of sender indicates that value without 
the entity providing that indication has 
sent outer type and length fields and the message (but not necessarily created it).

Proof of approval indicates that hashing algorithm must be as 
specified in the signer has approved field signPolicyHshAlg.

If the content of signature policy is defined using another structure, the message.

Proof type of creation indicates that the signer has created 
structure and the message 
(but not necessarily approved, nor sent it).

NOTE:	See clause A.3 for a full description hashing algorithm must be either specified as part 
of the commitment types 
defined above. signature policy, or indicated using a signature policy 
qualifier. 

   SigPolicyHash ::= ETSIHashAlgAndValue




ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 25] 23]
Internet Draft                             Electronic Signature Formats


3.12.2	Signer Location


A signature policy identifier may be qualified with other information 
about the qualifier. The signer-location attribute is an attribute which specifies a 
mnemonic for an address associated with semantics and syntax of the signer at a particular 
geographical (e.g. city) location. The mnemonic qualifier is registered in as 
associated with the 
country object-identifier in which the signer is located and sigPolicyQualifierId 
field. The general syntax of this qualifier is used in as follows:

   SigPolicyQualifierInfo ::= SEQUENCE {
        sigPolicyQualifierId  SigPolicyQualifierId,
        sigQualifier          ANY DEFINED BY sigPolicyQualifierId
}

This document specifies the provision of following qualifiers:

    * spuri: This contains the Public Telegram Service (according web URI or URL reference to ITU-T Recommendation F.1
[5?????]).

The signer-location attribute must be the 
      signature policy

    * spUserNotice: This contains a signed attribute.

The following object identifier identifies user notice which should be 
      displayed whenever the signer-location 
attribute:

id-aa-ets-signerLocation signature is validated.

-- sigpolicyQualifierIds defined in this document

SigPolicyQualifierId ::=  OBJECT IDENTIFIER 

    id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) pkcs9(9)
    smime(16) id-aa(2) 17}


Signer-location attribute values have ASN.1 type SignerLocation:
      SignerLocation id-spq(5) 1 }

   SPuri ::= IA5String

    id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-spq(5) 2 }

   SPUserNotice ::= SEQUENCE { 
-- at least one of the following must be present
			countryName [0] DirectoryString OPTIONAL, 
				-- As used to name a Country in X.500
			localityName [1] DirectoryString
        noticeRef        NoticeReference OPTIONAL, 
 				-- As used to name a locality in X.500
			postalAdddress [2] PostalAddress
        explicitText     DisplayText OPTIONAL
}
	
	PostalAddress

   NoticeReference ::= SEQUENCE SIZE(1..6) {
        organization     DisplayText,
        noticeNumbers    SEQUENCE OF DirectoryString

3.12.3	Signer INTEGER
}

   DisplayText ::= CHOICE {
        visibleString    VisibleString  (SIZE (1..200)),
        bmpString        BMPString      (SIZE (1..200)),
        utf8String       UTF8String     (SIZE (1..200))
}

3.10  CMS Imported Optional Attributes

The signer-attributes attribute is an attribute which specifies 
additional following attributes of the signer (e.g. role). 

It may MAY be either:
     * claimed attributes of the signer;
     * certified attributes of the signer;
     * present with the signer-attribute attribute must be a signed attribute 
       attributes.

The signer-attributes attribute must be a signed attribute. signed-data defined by 
this document. The following object identifier identifies the signer-attribute 
attribute:

id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18}


signer-attribute attribute values have ASN.1 type SignerAttribute.
SignerAttribute ::= SEQUENCE OF CHOICE {
			claimedAttributes	[0] ClaimedAttributes,
			certifiedAttributes [1] CertifiedAttributes } attributes are defined in ref [CMS] and are imported


ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 26] 24]
Internet Draft                             Electronic Signature Formats



ClaimedAttributes ::= SEQUENCE OF Attribute 

CertifiedAttributes ::= AttributeCertificate  
         -- As

into this specification and were appropriate qualified and profiling by 
this document.

3.10.1  Countersignature

The syntax of the countersignature attribute type of the ES is as 
defined in X.509 : see section 10.3


NOTE: [CMS]. The claimed and certified countersignature attribute must be an unsigned 
attribute.

3.11  ESS Imported Optional Attributes

The following attributes MAY be present with the signed-data defined by 
this document. The attributes are defined in ref [ESS] and are imported from ITU-T 
Recommendations X.501 [16] 
into this specification and ITU-T Recommendation X.509 : Draft 
Amendment on Certificate Extensions, October 1999.

3.12.3 were appropriate qualified and profiling 
by this document.

3.11.1 Content Timestamp Reference Attribute 

The content timestamp attribute is an reference attribute which is a link from one SignedData to 
another. It may be used to link a reply to the timestamp 
of the signed data content before original message to 
which it is signed. refers, or to incorporate by reference one SignedData into 
another. 

The content timestamp reference attribute must MUST be used as defined in [ESS].  The 
content reference MUST be a signed attribute.

The following object identifier identifies syntax of the signer-attribute 
attribute:

     id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) 
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
     smime(16) id-aa(2) 20}


Content timestamp content reference attribute values have ASN.1 type ContentTimestamp:
ContentTimestamp::= TimeStampToken

The value of messageImprint field within TimeStampToken must be a hash 
of the value of eContent field within encapContentInfo within the 
signedData.

For further information and definition of TimeStampToken see ref .. temp 
note; need to add ES is as 
defined in [ESS].

3.11.2  Content Identifier Attribute 

The content identifier attribute provides an identifier for the signed 
content for use when reference may be later required to the timestamping RFC.

3.13	Support that content, 
for Multiple Signatures

3.13.1	Independent Signatures

Multiple independent signatures (see clause 55) are supported by 
independent SignerInfo from each signer.

Each SignerInfo must include all example in the attributes required under this 
document and content reference attribute in other signed data 
sent later.

The content identifier must be processed independently by the verifier.

3.13.2	Embedded Signatures

Multiple embedded signatures (see clause B.6) are supported using a signed attribute.

The syntax of the 
counter-signature unsigned content identifier attribute (see clause 10.1). Each counter 
signature type of the ES is carried as 
defined in Countersignature held [ESS].

The minimal signedContentIdentifier should contain a concatenation of 
user-specific identification information (such as an unsigned attribute a user name or public 
keying material identification information), a GeneralizedTime string, 
and a random number.

3.12   Additional Optional Attributes 

3.12.1  Commitment Type Indication Attribute

There may be situation were a signer wants to the SignerInfo explicitly indicate to which a 
verifier that by signing the counter-signature is applied.



ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 27]

Internet Draft                                   Electronic Signature Formats

4.	Validation Data

This clause specifies the validation data structures which builds data, it illustrates a type of commitment 
on behalf of the  electronic signature specified in clause 3. This includes: signer. The commitmentTypeIndication attribute conveys 
such information.

ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 25]
Internet Draft                             Electronic Signature Formats

The commitmentTypeIndication attribute must be a signed attribute.

The commitment type may be:

    * Timestamp applied to defined as part of the electronic signature value.


    * Complete validation data policy, in which comprises case the timestamp 
      commitment type has precise semantics that is defined as part of 
      the signature value, plus references to all the certificates and 
      revocation information used for full validation of the electronic 
      signature.

The following optional eXtended forms of validation data are also 
defined: policy. 

    * X-timestamp: There are two types of timestamp used be a registered type, in extended 
       validation data which case the commitment type has 
      precise semantics defined by this document.

        - Type 1 -Timestamp which comprises a timestamp over registration, under the ES
          with Complete validation data (ES-C).

        - Type 2 X-Timestamp which comprises rules of a timestamp over the 
          certification path references and the revocation information 
          references used to support the ES-C.

               * X-Long : This comprises
      registration authority. Such a  Complete validation data 
               plus the actual values of all the certificates and 
               revocation information used in the ES-C.

              * X-Long-Timestamp: This comprises registration authority may be a Type 1
      trading association or Type 2 
                X-Timestamp plus the actual values a legislative authority.

The signature policy specifies a set of attributes that it 
"recognizes". This "recognized" set includes all those commitment types 
defined as part of the 
                certificates and revocation information used in the
                ES-C.

This clause also specifies the data structures used in Archive 
validation data: 

      * Archive validation data comprises a  Complete validation data,
        the certificate and revocation values (as in a X-Long 
        validation data), signature policy as well as any other existing X-timestamps, plus the
        Signed User data and an additional archive timestamp over all externally 
defined commitment types that data. An archive timestamp the policy may be repeatedly applied 
        after long periods choose to maintain validity when electronic 
        signature and timestamping algorithms weaken. recognize. Only 
recognized commitment types are allowed in this field.

The additional data required to create following object identifier identifies the forms commitment type 
indication attribute:

id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16}

Commitment-Type-Indication attribute values have ASN.1 type 
CommitmentTypeIndication.

CommitmentTypeIndication ::= SEQUENCE {
   commitmentTypeId            CommitmentTypeIdentifier,
   commitmentTypeQualifier     SEQUENCE SIZE (1..MAX) OF 
                               CommitmentTypeQualifier      OPTIONAL
}

CommitmentTypeIdentifier ::= OBJECT IDENTIFIER

CommitmentTypeQualifier ::= SEQUENCE {
    commitmentTypeIdentifier   CommitmentTypeIdentifier,
    qualifier                  ANY DEFINED BY 
                               commitmentTypeIdentifier
}

The use of electronic 
signature identified above any qualifiers to the commitment type is carried as unsigned attributes associated 
with an individual signature by being placed in outside the unsignedAttrs field scope 
of SignerInfo (see clause 6????). Thus all the attributes this document.

The following generic commitment types are defined in 
clause 9?? are unsigned attributes. this document:

       id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-
       body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
       cti(6) 1}

       id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-
       body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
       cti(6) 2}

ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 28] 26]
Internet Draft                             Electronic Signature Formats

NOTE:	Where multiple signatures are to be supported, as described in 
clause 3.13, each signature has a separate SignerInfo. Thus, each 
signature requires its own unsigned attribute values to create ES-T, 
ES-C etc.

4.1	Electronic Signature Timestamp 

An Electronic Signature with Timestamp is an Electronic Signature for 
which part, but not all, of the additional data required for validation 
is available (i.e. some certificates and revocation information is 
available but not all). The minimum structure Timestamp validation data 
is:
     * The Signature Timestamp Attribute as defined in clause 4.1.1 
       over the ES signature value.



4.1.1	Signature Timestamp Attribute Definition

The Signature Timestamp attribute is timestamp of the signature value. 
It is an unsigned attribute.  Several instances of this attribute may  
occur with an electronic signature, from different TSAs.

The Signature Validation Policy specifies, in the 
signatureTimestampDelay field of TimestampTrustConditions, an maximum 
acceptable time difference which is allowed between the time indicated 
in the signing time attribute and the time indicated by the Signature 
Timestamp attribute. If this delay is exceeded then the electronic 
signature must be considered as invalid.

The following object identifier identifies the Signature Timestamp 
attribute:


     id-aa-signatureTimeStampToken

       id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1)
       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
       smime(16)
     id-aa(2) 14}


The Signature timestamp attribute value has ASN.1 type 
SignatureTimeStampToken:

SignatureTimeStampToken cti(6) 3}

       id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= TimeStampToken

The value of messageImprint field within TimeStampToken must be a hash 
of { iso(1) member-
       body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
       cti(6) 4}

       id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1)
       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
       smime(16) cti(6) 5}

       id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1)
       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
       smime(16) cti(6) 6}

These generic commitment types have the value following meaning: 

Proof of signature field within SignerInfo origin indicates that the signer recognizes to have created, 
approved and sent the message.

Proof of receipt indicates that signer recognizes to have received the 
content of the message.

Proof of delivery indicates that the TSP providing that indication has 
delivered a message in a local store accessible to the recipient of the 
message.

Proof of sender indicates that the entity providing that indication has 
sent the message (but not necessarily created it).

Proof of approval indicates that the signer has approved the content of 
the message.

Proof of creation indicates that the signer has created the message 
(but not necessarily approved, nor sent it).

3.12.2  Signer Location attribute

The signer-location attribute is an attribute which specifies a 
mnemonic for an address associated with the signedData 
being timestamped.

For further information signer at a particular 
geographical (e.g. city) location. The mnemonic is registered in the 
country in which the signer is located and definition is used in the provision of TimeStampToken see [TSP]
Temp note ;ref 
the Public Telegram Service (according to timestamping doc required ITU-T Recommendation F.1
[PTS]).

The signer-location attribute must be a signed attribute.

The following object identifier identifies the signer-location 
attribute:

id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17}


ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 29] 27]
Internet Draft                             Electronic Signature Formats

4.2	Complete Validation Data 

An electronic signature with complete validation data is an Electronic 
Signature for which all

Signer-location attribute values have ASN.1 type SignerLocation.

   SignerLocation ::= SEQUENCE { 
        -- at least one of the additional data required for validation 
(i.e. all certificates and revocation information) is available.  
Complete validation data (ES-C) build on the electronic signature 
Timestamp following must be present
      countryName          [0] DirectoryString      OPTIONAL,
        -- as defined above.

The minimum structure of used to name a  Complete validation data is:
     * the Signature Timestamp Attribute, as defined in clause 4.1.1;
     * Complete Certificate Refs, as defined Country in clause 4.2.1;
     * Complete Revocation Refs, X.500
      localityName         [1] DirectoryString      OPTIONAL,
         -- as defined in clause 4.2.2.

The Complete validation data MAY also include the following additional 
information, forming a X-Long validation data, for use if later 
validation processes may not have access used to this information:

     * Complete Certificate Values, as defined in clause 4.2.3;

     * Complete Revocation Values, as defined name a locality in clause 4.2.4. X.500
      postalAdddress       [2] PostalAddress        OPTIONAL
}

   PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString

3.12.3  Signer Attributes attribute

The  Complete validation data MAY also include one of the following 
additional attributes, forming a X-Timestamp validation data, to 
provide signer-attributes attribute is an attribute which specifies 
additional protection against later CA compromise and provide 
integrity attributes of the validation data used: signer (e.g. role). 

It may be either:

     * ES-C Timestamp, as defined in clause 4.2.5; claimed attributes of the signer; or
     * Time-Stamped Certificates and CRLs references, as defined in 
       clause 4.2.6.

NOTE 1:	As long as certified attributes of the CA's are trusted such that these keys cannot signer;

The signer-attributes attribute must be compromised or the cryptography used broken, the ES-C provides long 
term proof of a valid electronic signature.

A valid electronic signature is an electronic signature which passes 
validation according to a signature validation policy.

NOTE 2: signed attribute.

The ES-C provides the following important property for long 
standing signatures; that is having been found once to be valid, must 
continue to be so months or years later. Long after the validity period 
of object identifier identifies the certificates signer-attribute 
attribute:

id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18}

signer-attribute attribute values have expired, or after the user key has been 
compromised.

4.2.1	Complete Certificate Refs ASN.1 type SignerAttribute.

   SignerAttribute ::= SEQUENCE OF CHOICE {
      claimedAttributes      [0]  ClaimedAttributes,
      certifiedAttributes    [1]  CertifiedAttributes
}

ClaimedAttributes ::= SEQUENCE OF Attribute Definition 

CertifiedAttributes ::= AttributeCertificate  
         -- as defined in X.509 : see section 10.3

NOTE:  The Complete claimed and certified attribute are imported from ITU-T 
Recommendations X.501 [16] and ITU-T Recommendation X.509 : Draft 
Amendment on Certificate Refs Extensions, October 1999.

3.12.4  Content Timestamp attribute

The content timestamp attribute is an unsigned attribute. It 
references attribute which is the full set timestamp 
of CA certificates that have been used to 
validate a ES with Complete validation data (ES-C) up to (but not 
including) the signer's certificate. Only a single instance of this signed data content before it is signed.

The content timestamp attribute must occur with an electronic signature. be a signed attribute.


ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 31] 28]
Internet Draft                             Electronic Signature Formats

Note:


The signer's certified is referenced in following object identifier identifies the signing certificate 
attribute (see clause 3.1).

id-aa-ets-certificateRefs signer-attribute 
attribute:

     id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) 
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
     smime(16) id-aa(2) 21}


The complete certificate refs 20}

Content timestamp attribute value has the values have ASN.1 syntax 
CompleteCertificateRefs.

CompleteCertificateRefs ::=  SEQUENCE OF ETSICertID


ETSICertID is defined in clause 3.8.2. type ContentTimestamp:
ContentTimestamp::= TimeStampToken

The IssuerSerial that value of messageImprint field within TimeStampToken must be present in ETSICertID. The certHash 
must match the a hash 
of the certificate referenced.

NOTE:	Copies value of eContent field within encapContentInfo within the certificate values may 
signedData.

For further information and definition of TimeStampToken see [TSP].

3.13  Support for Multiple Signatures

3.13.1  Independent Signatures

Multiple independent signatures are supported by independent SignerInfo 
from each signer.

Each SignerInfo must include all the attributes required under this 
document and must be held processed independently by the verifier.

3.13.2  Embedded Signatures

Multiple embedded signatures are supported using the 
Certificate Values counter-signature 
unsigned attribute defined in (see clause 4.3.1.

4.2.2	Complete Revocation Refs Attribute Definition

The Complete Revocation Refs attribute 3.10.1). Each counter signature is 
carried in Countersignature held as an unsigned attribute. Only a 
single instance of this attribute must occur with an electronic 
signature. It references to the full set of 
SignerInfo to which the CRL or OCSP responses that 
have been used counter-signature is applied.

4.  Validation Data

This clause specifies the validation data structures which builds on 
the electronic signature specified in clause 3. This includes:

    * Timestamp applied to the electronic signature value.

    * Complete validation data which comprises the timestamp of the signer and CA 
      signature value, plus references to all the certificates and 
      revocation information used for full validation of the electronic 
      signature.

The following optional eXtended forms of validation data are also 
defined:

     * X-timestamp: There are two types of timestamp used in extended 
       validation data defined by this document.




ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 29]
Internet Draft                             Electronic Signature Formats

        - Type 1 -Timestamp which comprises a timestamp over the ES
          with Complete validation data.

The following object identifier identifies data (ES-C).

        - Type 2 X-Timestamp which comprises of a timestamp over the CompleteRevocationRefs 
attribute:

id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22}

The complete revocation refs attribute value has 
          certification path references and the ASN.1 syntax 
CompleteRevocationRefs
CompleteRevocationRefs ::=  SEQUENCE OF CrlOcspRef

CrlOcspRef ::= SEQUENCE {
    crlids           [0] CRLListID   OPTIONAL,
    ocspids          [1] OcspListID  OPTIONAL,
    otherRev	     [2] OtherRevRefs OPTIONAL
                                                   }











ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 32]

Internet Draft                                   Electronic Signature Formats

CompleteRevocationRefs must contain one CrlOcspRef for revocation information 
          references used to support the signing 
certificate, followed by one for each ETSICertID in ES-C.

               * X-Long : This comprises a  Complete validation data 
                 plus the 
CompleteCertificateRefs attribute. actual values of all the second certificates and subsequent CrlOcspRef 
fields must be 
                 revocation information used in the same order as the ETSICertID to which they 
relate. At least one of CRLListID or OcspListID ES-C.

               * X-Long-Timestamp: This comprises a Type 1 or OtherRevRefs should 
be present for all but Type 2 
                 X-Timestamp plus the "trusted" CA actual values of all the certificate path.

CRLListID ::=  SEQUENCE {
    crls        SEQUENCE OF CrlValidatedID}

CrlValidatedID ::=  SEQUENCE {
     crlHash                   ETSIHash, 
     crlIdentifier             CrlIdentifier OPTIONAL}

CrlIdentifier ::= SEQUENCE {
    crlissuer                 Name,
    crlIssuedTime             UTCTime,
    crlNumber                 INTEGER OPTIONAL
                                            }

OcspListID ::=  SEQUENCE {
    ocspResponses        SEQUENCE OF OcspResponsesID}

OcspResponsesID ::=  SEQUENCE {
    ocspIdentifier              OcspIdentifier,
    ocspRepHash                 ETSIHash    OPTIONAL
                                            }

OcspIdentifier ::= SEQUENCE {
     ocspResponderID		ResponderID,	
                       -- As 
                 certificates and revocation information used in OCSP response the
                 ES-C.

This clause also specifies the data
     producedAt			GeneralizedTime 
                       -- As structures used in OCSP response Archive 
validation data: 

      * Archive validation data
                                             }

When creating an crlValidatedID, the crlHash is computed over the 
entire DER encoded CRL including comprises a  Complete validation data,
        the signature. The crlIdentifier would 
normally be present unless certificate and revocation values (as in a X-Long 
        validation data), any other existing X-timestamps, plus the CRL can
        Signed User data and an additional archive timestamp over all 
        that data. An archive timestamp may be inferred from other 
information. repeatedly applied 
        after long periods to maintain validity when electronic 
        signature and timestamping algorithms weaken.

The crlIdentifier is additional data required to identify create the CRL using forms of electronic 
signature identified above is carried as unsigned attributes 
associated with an individual signature by being placed in the issuer name and 
unsignedAttrs field of SignerInfo. Thus all the 
CRL issued time which must correspond attributes defined 
in clause 4 are unsigned attributes.

NOTE:  Where multiple signatures are to the time "thisUpdate" 
contained be supported, as described in the issued CRL. The crlListID 
clause 3.13, each signature has a separate SignerInfo. Thus, each 
signature requires its own unsigned attribute values to create ES-T, 
ES-C etc.

4.1  Electronic Signature Timestamp 

An Electronic Signature with Timestamp is an unsigned 
attribute.   In the case that Electronic Signature for 
which part, but not all, of the identified CRL additional data required for validation 
is a Delta CRL then 
references to the set of CRLs to provide a complete available (e.g. some certificates and revocation list 
must be included. information is 
available but not all). 

The OcspIdentifier minimum structure Timestamp validation data is to identify the OSCP response using the issuer 
name and Signature 
Timestamp Attribute as defined in clause 4.1.1 over the time of issue ES signature 
value.

4.1.1  Signature Timestamp Attribute Definition

The Signature Timestamp attribute is timestamp of the OCSP response which must correspond 
to the time "producedAt" contained in the issued OCSP response. Since 
it may be needed to make the difference between two OCSP responses 
received within the same second, then the hash signature value. 
It is an unsigned attribute. Several instances of the response contained 
in the OcspResponsesID this attribute from 
different TSAs may be needed to solve the ambiguity. occur with an electronic signature.

ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 33] 30]
Internet Draft                             Electronic Signature Formats


NOTE:	Copies of the CRL and OCSP responses values may be held using the 
Revocation Values attribute defined in clause 4.3.2.

OtherRevRefs ::= SEQUENCE {
 	otherRevRefType	OtherRevRefType,
	otherRevRefs	ANY DEFINED BY otherRevRefType
                                                  }

OtherRevRefType ::= OBJECT IDENTIFIER

The syntax and semantics of other revocation references is outside Signature Validation Policy specifies, in the 
scope of this document.  The definition 
signatureTimestampDelay field of TimestampTrustConditions, a maximum 
acceptable time difference which is allowed between the syntax of time indicated 
in the other form 
of revocation information is as identified by OtherRevRefType.

4.3	Extended Validation Data

4.3.1	Certificate Values Attribute Definition

The Certificate Values attribute is an unsigned attribute. Only a 
single instance of this signing time attribute must occur with an electronic 
signature. It holds and the values of certificates referenced in time indicated by the 
CompleteCertificateRefs Signature 
Timestamp attribute.

Note: If an Attribute Certificate is used, it is not provided in this 
structure but delay is exceeded then the electronic 
signature must be provided by the signer considered as a signer-attributes 
attribute (see clause 12.3). invalid.

The following object identifier identifies the CertificateValues Signature Timestamp 
attribute:

id-aa-ets-certValues

     id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
     id-aa(2) 23} 14}

The certificate values Signature timestamp attribute value has the ASN.1 syntax 
CertificateValues
CertificateValues type 
SignatureTimeStampToken.

SignatureTimeStampToken ::=  SEQUENCE OF Certificate

Certificate is defined in clause 10.1 (which is as defined in ITU-T 
Recommendation X.509 [1])














ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 34]

Internet Draft                                   Electronic Signature Formats

4.3.2	Revocation Values Attribute Definition TimeStampToken

The Revocation Values attribute is an unsigned attribute. Only a single 
instance value of this attribute messageImprint field within TimeStampToken must occur with an electronic signature.  
It holds the values be a hash 
of CRLs and OCSP referenced in the
 CompleteRevocationRefs attribute.

The following object identifier identifies the CertificateValues 
attribute:

id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-
body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 24}


The revocation values attribute value has of signature field within SignerInfo for the ASN.1 syntax 
RevocationValues
RevocationValues ::=  SEQUENCE {
   crlVals          [0] SEQUENCE OF CertificateList OPTIONAL,
   ocspVals         [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,
   otherRevVals	    [2] OtherRevVals }

OtherRevVals ::= SEQUENCE {
 	otherRevValType	OtherRevValType,
	otherRevVals	ANY DEFINED BY otherRevValType
                                     }

OtherRevValType ::= OBJECT IDENTIFIER


The syntax signedData 
being timestamped.

For further information and semantics definition of TimeStampToken see [TSP]

4.2  Complete Validation Data 

An electronic signature with complete validation data is an Electronic 
Signature for which all the other additional data required for validation 
(i.e. all certificates and revocation values information) is outside available.  
Complete validation data (ES-C) build on the 
scope of this document. electronic signature 
Timestamp as defined above.

The definition of the syntax minimum structure of a Complete validation data is:

     * the other form 
of revocation information is Signature Timestamp Attribute, as identified by OtherRevRefType.

CertificateList is defined in clause 10.2 (which 4.1.1;
     * Complete Certificate Refs, as defined in ITU-T 
Recommendation X.509 [1]).

BasicOCSPResponse is defined in clause 10.3 (which 4.2.1;
     * Complete Revocation Refs, as defined in ??? RFC 
2560 [8] ???).

4.3.3	ES-C Timestamp Attribute Definition

This attribute is used for the Type 1 X-Timestamped validation data. clause 4.2.2.

The ES-C Timestamp attribute is an unsigned attribute. It is timestamp 
of a hash of the electronic signature and the complete Complete validation data 
(ES-C). It is a special purpose TimeStampToken Attribute which 
timestamps MAY also include the ES-C. Several instances instance of this attribute following additional 
information, forming a X-Long validation data, for use if later 
validation processes may 
occur with an electronic signature from different TSAs. not have access to this information:

     * Complete Certificate Values, as defined in clause 4.2.3;
     * Complete Revocation Values, as defined in clause 4.2.4.

The  Complete validation data MAY also include one of the following object identifier identifies 
additional attributes, forming a X-Timestamp validation data, to 
provide additional protection against later CA compromise and provide 
integrity of the validation data used:

     * ES-C Timestamp 
attribute:

id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25} Timestamp, as defined in clause 4.2.5; or
     * Time-Stamped Certificates and CRLs references, as defined in 
       clause 4.2.6.

ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 35] 31]
Internet Draft                             Electronic Signature Formats


The ES-C timestamp attribute value has

NOTE 1: As long as the ASN.1 syntax 
ESCTimeStampToken.

ESCTimeStampToken ::= TimeStampToken

The value of messageImprint field within TimeStampToken must CA's are trusted such that these keys cannot 
be a hash 
of the concatenated values (without the type compromised or length encoding for 
that value) of the following data objects as present in cryptography used broken, the ES with 
Complete ES-C provides long 
term proof of a valid electronic signature.

A valid electronic signature is an electronic signature which passes 
validation data (ES-C):

     * according to a signature field within SignerInfo;

     * SignatureTimeStampToken attribute;

     * CompleteCertificateRefs attribute;

     * CompleteRevocationRefs attribute.

For further information and definition of validation policy.

NOTE 2: The ES-C provides the Time Stamp Token see 
clause [TSP].
Temp note ;ref following important property for long 
standing signatures; that is having been found once to timestamping doc required.


4.3.4	Time-Stamped Certificates and CRLs be valid, must 
continue to be so months or years later. Long after the validity period 
of the certificates have expired, or after the user key has been 
compromised.

4.2.1  Complete Certificate Refs Attribute Definition

This attribute is used for the Type 2 X-Timestamp validation data. A 
TimestampedCertsCRLsRef

The Complete Certificate Refs attribute is an unsigned attribute. It is a 
list 
references the full set of referenced CA certificates and OCSP responses/CRLs which are that have been 
timestamped used to protect against certain CA compromises. Its syntax is as 
follows: 
validate a ES with Complete validation data (ES-C) up to (but not 
including) the signer's certificate. Only a single instance of this 
attribute must occur with an electronic signature.

Note: The following object identifier identifies signer's certified is referenced in the TimestampedCertsCRLsRef 
attribute:

id-aa-ets-certCRLTimestamp signing certificate 
attribute (see clause 3.1).

id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-
body(2) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26} 21}

The complete certificate refs attribute value has the ASN.1 syntax TimestampedCertsCRLs.

TimestampedCertsCRLs 
CompleteCertificateRefs.

CompleteCertificateRefs ::= TimeStampToken  SEQUENCE OF OTHERCertID

OTHERCertID is defined in clause 3.8.2. 

The value of messageImprint field within TimeStampToken IssuerSerial that must be a present in OTHERCertID. The certHash 
must match the hash of the concatenated values (without the type or length encoding for 
that value) certificate referenced.

NOTE:  Copies of the following data objects as present in certificate values may be held using the ES with 
Certificate Values attribute defined in clause 4.3.1.

4.2.2  Complete validation data (ES-C):

* CompleteCertificateRefs attribute;
* CompleteRevocationRefs attribute.



ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 36]

Internet Draft                                   Electronic Signature Formats


4.4	Archive Validation Data

Where an electronic signature is required to last for a very long time, 
and a the timestamp on an electronic signature is in danger of being 
invalidated due to algorithm weakness or limits in the validity period 
of the TSA certificate, then it may be required to timestamp the 
electronic signature several times. When this is required an archive 
timestamp attribute may be required. This timestamp may be repeatedly 
applied over a period of time.


4.4.1	Archive Timestamp Revocation Refs Attribute Definition

The Archive Timestamp attribute is timestamp of the user data and the 
entire electronic signature. If the Certificate values and Complete Revocation 
Values attributes are not present these attributes must be added to 
the electronic signature prior to the timestamp. The Archive Timestamp Refs attribute is an unsigned attribute. Several instances Only a 
single instance of this attribute 
may must occur with on an electronic signature both over time 
signature. It references the full set of the CRL or OCSP responses that 
have been used in the validation of the signer and from 
different TSAs. CA certificates 
used in ES with Complete validation data.

The following object identifier identifies the Nested Archive Timestamp CompleteRevocationRefs 
attribute:

id-aa-ets-archiveTimestamp

id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-
body(2) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27}

Archive timestamp 22}


ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 32]
Internet Draft                             Electronic Signature Formats


The complete revocation refs attribute values have value has the ASN.1 syntax 
ArchiveTimeStampToken

ArchiveTimeStampToken 
CompleteRevocationRefs.

CompleteRevocationRefs ::= TimeStampToken

The value of messageImprint field within TimeStampToken  SEQUENCE OF CrlOcspRef

CrlOcspRef ::= SEQUENCE {
    crlids           [0] CRLListID        OPTIONAL,
    ocspids          [1] OcspListID       OPTIONAL,
    otherRev         [2] OtherRevRefs     OPTIONAL
}

CompleteRevocationRefs must be a hash 
of the concatenated values (without the type or length encoding contain one CrlOcspRef for 
that value) of the following data objects as present signing 
certificate, followed by one for each OTHERCertID in the electronic 
signature:

     * encapContentInfo eContent OCTET STRING;
     * signedAttributes;
     * signature field within SignerInfo;
     * SignatureTimeStampToken attribute;
     * 
CompleteCertificateRefs attribute;
     * CompleteRevocationData attribute;
     *  CertificateValues attribute 
(If not already present this information attribute. The second and subsequent CrlOcspRef 
fields must be included in the 
ES-A);
     * RevocationValues attribute 
(If not already present this information must same order as the OTHERCertID to which they 
relate. At least one of CRLListID or OcspListID or OtherRevRefs should 
be included present for all but the "trusted" CA of the certificate path.

CRLListID ::=  SEQUENCE {
    crls        SEQUENCE OF CrlValidatedID}

CrlValidatedID ::=  SEQUENCE {
     crlHash                   ETSIHash, 
     crlIdentifier             CrlIdentifier OPTIONAL}

CrlIdentifier ::= SEQUENCE {
    crlissuer                 Name,
    crlIssuedTime             UTCTime,
    crlNumber                 INTEGER OPTIONAL
                                            }

OcspListID ::=  SEQUENCE {
    ocspResponses        SEQUENCE OF OcspResponsesID}

OcspResponsesID ::=  SEQUENCE {
    ocspIdentifier              OcspIdentifier,
    ocspRepHash                 ETSIHash    OPTIONAL
                                            }

OcspIdentifier ::= SEQUENCE {
     ocspResponderID    ResponderID,  
                       -- As in OCSP response data
     producedAt      GeneralizedTime 
                       -- As in OCSP response data
                                             }

When creating an crlValidatedID, the 
ES-A);
     * ESCTimeStampToken attribute if present;
     * TimestampedCertsCRLs attribute if present;
     * any previous ArchiveTimeStampToken attributes. crlHash is computed over the 
entire DER encoded CRL including the signature. The crlIdentifier would 
normally be present unless the CRL can be inferred from other 
information.




ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 37] 33]
Internet Draft                             Electronic Signature Formats


For further information and definition of TimeStampToken see see [TSP]
Temp note ;ref to timestamping doc required

The timestamp should be created crlIdentifier is to identify the CRL using stronger algorithms (or longer 
key lengths) than in the original electronic signatures issuer name and weak 
algorithm (key length) timestamps .


5.	Signature Policy Specification

This document mandates that:
     * an electronic signature the 
CRL issued time which must be processed by correspond to the signer and 
       verifier time "thisUpdate" 
contained in accordance with the signature policy as identified
       by the signature policy issued CRL. The crlListID attribute (see clause 4.1);
     * the signature policy must be identifiable by is an Object 
       Identifier;
     * there must exist unsigned 
attribute. In the case that the identified CRL is a specification of Delta CRL then 
references to the signature policy;
     * for set of CRLs to provide a given signature policy there complete revocation list 
must be one definitive form 
       of included.

The OcspIdentifier is to identify the specification which has a unique binary encoding;
     * a hash OSCP response using the issuer 
name and the time of issue of the definitive specification, using an agreed 
       algorithm, OCSP response which must be provided by correspond 
to the signer and checked by time "producedAt" contained in the
       verifier (see clause 4.1).

A signature policy specification includes general information about issued OCSP response. Since 
it may be needed to make the 
policy, difference between two OCSP responses 
received within the validation policy rules and other signature policy 
information. 

Clause 6 describes same second, then the kind hash of information to be included the response 
contained in a 
signature policy.

The current document does not mandate the form OcspResponsesID may be needed to solve the ambiguity.

NOTE: Copies of the signature policy 
specification. The signature policy CRL and OCSP responses values may be specified either:

     * in a free form document for human interpretation; or 
     * in a structured form held using an agreed syntax and encoding.

This document defines an ASN.1 based 
the Revocation Values attribute defined in clause 4.3.2.

OtherRevRefs ::= SEQUENCE {
   otherRevRefType      OtherRevRefType,
   otherRevRefs         ANY DEFINED BY otherRevRefType
}

OtherRevRefType ::= OBJECT IDENTIFIER

The syntax that may be used to define 
a structured signature policy.


5.1	Overall ASN.1 Structure and semantics of other revocation references is outside the 
scope of this document.  The overall structure definition of a signature policy defined using ASN.1 the syntax of the other form 
of revocation information is 
given in as identified by OtherRevRefType.

4.3  Extended Validation Data

4.3.1  Certificate Values Attribute Definition

The Certificate Values attribute is an unsigned attribute. Only a 
single instance of this clause. Use attribute must occur with an electronic 
signature. It holds the values of certificates referenced in the 
CompleteCertificateRefs attribute.

Note: If an Attribute Certificate is used, it is not provided in this ASN.1 
structure is optional.

This but must be provided by the signer as a signer-attributes 
attribute (see clause 12.3).

The following object identifier identifies the CertificateValues 
attribute:

id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23}

The certificate values attribute value has the ASN.1 syntax 
CertificateValues.

CertificateValues ::=  SEQUENCE OF Certificate

Certificate is encoded using the Distinguished Encoding Rules 
(DER). defined in RFC2459 and ITU-T Recommendation X.509 [1])


ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 38] 34]
Internet Draft                             Electronic Signature Formats


In this structure the policy information

4.3.2  Revocation Values Attribute Definition

The Revocation Values attribute is preceded by an identifier 
for the hashing algorithm used to protect the signature policy and 
followed by the hash value which unsigned attribute. Only a single 
instance of this attribute must be re-calculated occur with an electronic signature. It 
holds the values of CRLs and checked 
whenever OCSP referenced in the policy is passed between 
CompleteRevocationRefs attribute.

The following object identifier identifies the issuer and signer/verifier. Revocation Values 
attribute:

    id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
    id-aa(2) 24}

The hash is calculated without revocation values attribute value has the outer type and length fields.

SignaturePolicy ASN.1 syntax 
RevocationValues.

RevocationValues ::=  SEQUENCE {
	signPolicyHashAlg      AlgorithmIdentifier, 
	signPolicyInfo         SignPolicyInfo, 
	signPolicyHash         SignPolicyHash     OPTIONAL
   crlVals           [0] SEQUENCE OF CertificateList     OPTIONAL,
   ocspVals          [1] SEQUENCE OF BasicOCSPResponse   OPTIONAL,
   otherRevVals      [2] OtherRevVals
}

SignPolicyHash ::= OCTET STRING



SignPolicyInfo

OtherRevVals ::= SEQUENCE {
	signPolicyIdentifier            SignPolicyId,
	dateOfIssue                     GeneralizedTime,
	policyIssuerName                PolicyIssuerName,
	fieldOfApplication              FieldOfApplication,
	signatureValidationPolicy       SignatureValidationPolicy,
	signPolExtensions	        SignPolExtensions	
	                                           OPTIONAL
   otherRevValType       OtherRevValType,
   otherRevVals          ANY DEFINED BY otherRevValType
}

SignPolicyId

OtherRevValType ::= OBJECT IDENTIFIER

The policyIssuerName field identifies the policy issuer in one or more syntax and semantics of the general name forms.

PolicyIssuerName ::= GeneralNames


The fieldofApplication other revocation values is a description of outside the expected application 
scope of this policy.

FieldOfApplication ::= DirectoryString document. The signature validation policy rules are fully processable to allow definition of the validation syntax of electronic signatures issued under that signature 
policy. They are described in the rest other form 
of this clause.


5.2	Signature Validation Policy

The signature validation policy defines revocation information is as identified by OtherRevRefType.

CertificateList is defined in RFC 2459 [RFC2459] and in ITU-T 
Recommendation X.509 [X509]).

BasicOCSPResponse is defined in RFC 2560 [OCSP].

4.3.3  ES-C Timestamp Attribute Definition

This attribute is used for the signer which data 
elements must be present in Type 1 X-Timestamped validation data. 
The ES-C Timestamp attribute is an unsigned attribute. It is timestamp 
of a hash of the electronic signature he provides and 
for the verifier which complete validation data elements must be present under that 
signature policy for 
(ES-C). It is a special purpose TimeStampToken Attribute which 
timestamps the ES-C. Several instances instance of this attribute may 
occur with an electronic signature to be potentially valid.



ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 39]

Internet Draft                                   Electronic Signature Formats


The signature validation policy is described as follows:

SignatureValidationPolicy ::= SEQUENCE {
	signingPeriod          SigningPeriod,
	commonRules            CommonRules,
	commitmentRules        CommitmentRules,
	signPolExtensions      SignPolExtensions	OPTIONAL
                                                } from different TSAs.

The signingPeriod following object identifier identifies the date and time before which the 
signature policy should not be used for creating signatures, and an 
optional date after which it should not be used for creating 
signatures.

SigningPeriod ::= SEQUENCE {
	notBefore	GeneralizedTime,
	notAfter	GeneralizedTime OPTIONAL }



5.3	Common Rules

The CommonRules define rules that are common to all commitment types. 
These rules are defined in terms of trust conditions for certificates, 
timestamps and attributes, along with any constraints on attributes 
that may be included in the electronic signature.

CommonRules ES-C Timestamp 
attribute:

    id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= SEQUENCE {
	signerAndVeriferRules          [0]  SignerAndVerifierRules     
                                                        OPTIONAL,
	signingCertTrustCondition      [1]  SigningCertTrustCondition   
                                                        OPTIONAL,
	timeStampTrustCondition        [2]  TimestampTrustCondition     
                                                        OPTIONAL,
	attributeTrustCondition        [3]  AttributeTrustCondition     
                                                        OPTIONAL,
	algorithmConstraintSet         [4]  AlgorithmConstraintSet      
                                                        OPTIONAL, 
	signPolExtensions	       [5]  SignPolExtensions		    
                                                         OPTIONAL
                                                       }

If a field is present in CommonRules then the equivalent field must 
not be present in any of the CommitmentRules (see below). If any of the 
following fields are not present in CommonRules then it must be 
present in each CommitmentRule:

* signerAndVeriferRules;
* signingCertTrustCondition;
* timeStampTrustCondition. iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
    id-aa(2) 25}

ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 40] 35]
Internet Draft                             Electronic Signature Formats


5.4	Commitment Rules

The CommitmentRules consists of ES-C timestamp attribute value has the validation rules which apply to 
given commitment types:

CommitmentRules ASN.1 syntax 
ESCTimeStampToken.

ESCTimeStampToken ::= SEQUENCE OF CommitmentRule TimeStampToken

The CommitmentRule for given commitment types are defined in terms value of 
trust conditions for certificates, timestamps and attributes, along 
with any constraints on attributes that may messageImprint field within TimeStampToken must be included in the 
electronic signature.



CommitmentRule  ::= SEQUENCE {
	selCommitmentTypes                  SelectedCommitmentTypes,
	signerAndVeriferRules          [0]  SignerAndVerifierRules      
                                                          OPTIONAL,
	signingCertTrustCondition      [1]  SigningCertTrustCondition   
                                                          OPTIONAL,
	timeStampTrustCondition        [2]  TimestampTrustCondition     
                                                          OPTIONAL,
	attributeTrustCondition        [3]  AttributeTrustCondition     
                                                          OPTIONAL,
	algorithmConstraintSet         [4]  AlgorithmConstraintSet      
                                                          OPTIONAL, 
	signPolExtensions	       [5]  SignPolExtensions		    
                                                          OPTIONAL
                                                       }

SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
	empty                        NULL,
	recognizedCommitmentType     CommitmentType }


If the SelectedCommitmentTypes indicates "empty" then this rule applied 
when a commitment type is not present  (i.e.the type hash 
of commitment is 
indicated in the semantics of the message). Otherwise, concatenated values (without the electronic 
signature must contain a commitment type indication or length encoding for 
that must fit one value) of the commitments types that are mentioned in CommitmentType.

A specific commitment type identifier must not appear following data objects as present in more than one 
commitment rule.

CommitmentType ::= SEQUENCE {
	identifier			CommitmentTypeIdentifier,
	fieldOfApplication	[0] FieldOfApplication OPTIONAL,
	semantics		[1] DirectoryString OPTIONAL }


The fieldOfApplication and semantics fields define the specific use ES with 
Complete validation data (ES-C):

     * signature field within SignerInfo;

     * SignatureTimeStampToken attribute;

     * CompleteCertificateRefs attribute;

     * CompleteRevocationRefs attribute.

For further information and 
meaning definition of the commitment within the overall field of application 
defined Time Stamp Token see 
[TSP].

4.3.4  Time-Stamped Certificates and CRLs Attribute Definition

This attribute is used for the policy.

ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 41]

Internet Draft                                   Electronic Signature Formats

5.5	Signer and Verifier Rules

The SignerAndVerifierRules consists Type 2 X-Timestamp validation data. A 
TimestampedCertsCRLsRef attribute is an unsigned attribute. It is a 
list of signer rule referenced certificates and verification 
rules OCSP responses/CRLs which are been 
timestamped to protect against certain CA compromises. Its syntax is as defined below:
SignerAndVerifierRules 
follows:

The following object identifier identifies the TimestampedCertsCRLsRef 
attribute:

    id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= SEQUENCE {
	signerRules      SignerRules,
	verifierRules    VerifierRules }


5.5.1	Signer Rules iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
    id-aa(2) 26}

The signer rules identify:

     * if the eContent is empty and attribute value has the signature is calculated using
       a hash ASN.1 syntax TimestampedCertsCRLs.

TimestampedCertsCRLs ::= TimeStampToken

The value of signed data external to CMS structure.

     * the CMS signed attributes that messageImprint field within TimeStampToken must be provided by a hash 
of the signer
        under this policy;

     * concatenated values (without the CMS unsigned attribute type or length encoding for 
that must be provided by the signer
        under this policy;

     * whether the certificate identifiers from the full certification 
       path up to the trust point must be provided by value) of the signer following data objects as present in the SigningCertificate ES with 
Complete validation data (ES-C):

* CompleteCertificateRefs attribute;
* whether a signer's certificate, or all certificates in the 
       certification path CompleteRevocationRefs attribute.

4.4  Archive Validation Data

Where an electronic signature is required to last for a very long time, 
and a the trust point must be provided by the
       signer timestamp on an electronic signature is in the certificates field danger of SignedData.

SignerRules ::= SEQUENCE {
	externalSignedData         BOOLEAN	OPTIONAL,
		    -- True if signed data is external being 
invalidated due to CMS structure 
			-- False if signed data part algorithm weakness or limits in the validity period 
of CMS structure
			-- not present if either allowed
	mandatedSignedAttr         CMSAttrs,
                                 -- Mandated CMS signed attributes
	mandatedUnsignedAttr       CMSAttrs,
                                 -- Mandated CMS unsigned attributed
	mandatedCertificateRef     [0] CertRefReq DEFAULT signerOnly, 
				 -- Mandated Certificate Reference
	mandatedCertificateInfo    [1] CertInfoReq DEFAULT none,
				 -- Mandated Certificate Info
	signPolExtensions	   [2] SignPolExtensions	OPTIONAL
                                                }

CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER


The mandatedSignedAttr field must include the object identifier for 
all those signed attributes required by this document as well as 
additional attributes TSA certificate, then it may be required by this policy. to timestamp the 

ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 42] 36]
Internet Draft                             Electronic Signature Formats



The mandatedUnsignedAttr field must include the object identifier for 
all those unsigned attributes required by this document as well as 
additional attributes required this policy. For example, if a


electronic signature 
timestamp (see clause 1.1) several times. When this is required by the signer the object 
identifier for this an archive 
timestamp attribute must may be included.

The mandatedCertificateRef identifies whether just the signer's 
certificate, or all the full certificate path must required. This timestamp may be provided by the 
signer.



CertRefReq ::= ENUMERATED {
				signerOnly (1),		
           -- Only reference to signer cert mandated
				fullPath (2)	
						
           -- References for full cert path up to repeatedly 
applied over a trust point required
					} period of time.

4.4.1  Archive Timestamp Attribute Definition

The mandatedCertificateInfo field identifies whether a signer's 
certificate, or all certificates in Archive Timestamp attribute is timestamp of the certification path to user data and the trust 
point 
entire electronic signature. If the Certificate values and Revocation 
Values attributes are not present these attributes must be provided by the signer in the certificates field of 
SignedData.

CertInfoReq ::= ENUMERATED {
				none (0)	,			
                        -- No mandatory requirements
				signerOnly (1)	,		
                        -- Only reference added to signer cert mandated
				fullPath (2)		
                        -- References for full cert path up 
the electronic signature prior to a 
                        -- trust point mandated
		                                   }


5.5.2	Verifier Rules

The verifier rules identify:
* the timestamp. The CMS Archive Timestamp 
attribute is an unsigned attributes that must be present under attribute. Several instances of this policy attribute 
may occur with on electronic signature both over time and must be added by the verifier if not added by from 
different TSAs.

The following object identifier identifies the signer.

VerifierRules Nested Archive Timestamp 
attribute:

    id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= SEQUENCE {
		mandatedUnsignedAttr	MandatedUnsignedAttr,
		signPolExtensions		SignPolExtensions  OPTIONAL
		                                                   }

MandatedUnsignedAttr iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
    id-aa(2) 27}

Archive timestamp attribute values have the ASN.1 syntax 
ArchiveTimeStampToken

ArchiveTimeStampToken ::=  CMSAttrs    
                                   -- Mandated CMS unsigned attributed



ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 43]

Internet Draft                                   Electronic Signature Formats



5.6	Certificate and Revocation Requirement TimeStampToken

The SigningCertTrustCondition, TimestampTrustCondition and 
AttributeTrustCondition (defined in subsequent sub-clauses) make use value of 
two ASN1 structures which are defined below: CertificateTrustTrees and 
CertRevReq.


5.6.1	Certificate Requirements

The certificateTrustTrees identifies messageImprint field within TimeStampToken must be a set hash 
of self signed certificates 
for the trust points used to start (or end) certificate path processing 
and concatenated values (without the initial conditions for certificate path validation as defined 
RFC 2459 [7] section 5. This ASN1 structure is used to define policy type or length encoding for validating 
that value) of the signing certificate, following data objects as present in the TSA's certificate and electronic 
signature:

     * encapContentInfo eContent OCTET STRING;
     * signedAttributes;
     * signature field within SignerInfo;
     * SignatureTimeStampToken attribute;
     * CompleteCertificateRefs attribute;
     * CompleteRevocationData attribute;
     * CertificateValues attribute certificates.



CertificateTrustTrees ::=   SEQUENCE OF CertificateTrustPoint

CertificateTrustPoint ::= SEQUENCE {
	trustpoint				Certificate,
                               -- self-signed certificate
	pathLenConstraint	[0] PathLenConstraint   OPTIONAL,
	acceptablePolicySet	[1] AcceptablePolicySet OPTIONAL,
                                -- If 
       (If not already present "any policy"
	nameConstraints		[2] NameConstraints     OPTIONAL, 
	policyConstraints	[3] PolicyConstraints   OPTIONAL }


The trustPoint field gives the self signed certificate for the CA that 
is used as the trust point for the start of certificate path 
processing.

The pathLenConstraint field gives the maximum number of CA certificates 
that may this information must be included in a certification path following the trustpoint. A value 
of zero indicates that only the given trustpoint certificate and an 
end-entity certificate may be used. If present, 
       the pathLenConstraint 
field ES-A);
     * RevocationValues attribute 
       (If not already present this information must be greater than or equal to zero. Where pathLenConstraint 
is not present, there is no limit to the allowed length of the 
certification path.

PathLenConstraint    ::=   INTEGER (0..MAX) 


The acceptablePolicySet field identifies included in 
       the initial set of certificate 
policies, ES-A);
     * ESCTimeStampToken attribute if present;
     * TimestampedCertsCRLs attribute if present;
     * any previous ArchiveTimeStampToken attributes.

For further information and definition of which are acceptable under TimeStampToken see [TSP]

The timestamp should be created using stronger algorithms (or longer 
key lengths) than in the signature policy.
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId

CertPolicyId ::= OBJECT IDENTIFIER original electronic signatures.



ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 44] 37]
Internet Draft                             Electronic Signature Formats


5.  Security considerations

5.1  Protection of Private Key

The nameConstraints field indicates a name space within which all 
subject names in subsequent certificates in a certification path must 
be located. Restrictions may apply to the subject distinguished name or 
subject alternative names. Restrictions apply only when the specified 
name form is present. If no name security of the type is in the certificate, the 
certificate is acceptable.

Restrictions are electronic signature mechanism defined in terms of permitted or excluded name 
subtrees. Any name matching a restriction in this 
document depends on the excludedSubtrees field 
is invalid regardless privacy of information appearing in the ermittedSubtrees.

 NameConstraints ::= SEQUENCE {
           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

      GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

      GeneralSubtree ::= SEQUENCE {
           base                    GeneralName,
           minimum         [0]     BaseDistance DEFAULT 0,
           maximum         [1]     BaseDistance OPTIONAL }

      BaseDistance ::= INTEGER (0..MAX)

The policyConstraints extension constrains path processing in two ways. 
It can be used signer's private key.  
Implementations must take steps to prohibit policy mapping or require ensure that each 
certificate in a path contain an acceptable policy identifier.

The policyConstraints field, if present specifies requirement for 
explicit indication of the certificate policy and/or the constraints on 
policy mapping.

PolicyConstraints ::= SEQUENCE {
        requireExplicitPolicy           [0] SkipCerts OPTIONAL,
        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

If the inhibitPolicyMapping field is present, the value indicates the 
number private keys cannot be 
compromised.

5.2  Choice of additional certificates Algorithms

Implementers should be aware that may appear in the path 
(including cryptographic algorithms become 
weaker with time. As new cryptoanalysis techniques are developed and 
computing performance improves, the trustpoint's self certificate) before policy mapping is 
no longer permitted. For example, work factor to break a value of one indicates that policy 
mapping may particular 
cryptographic algorithm will reduce. Therefore, cryptographic algorithm 
implementations should be processed in certificates issued by modular allowing new algorithms to be readily 
inserted. That is, implementers should be prepared for the subject set of this 
certificate, but not in additional certificates in the path.

If the requireExplicitPolicy field is present, subsequent certificates 
must include an acceptable policy identifier. The value 
mandatory to implement algorithms to change over time.

6.  Conformance Requirements

This document only defines conformance requirements up to a ES with 
Complete validation data (ES-C). This means that none of 
requireExplicitPolicy indicates the number extended 
and archive forms of additional certificates 
that may appear in the path (including the trustpoint's self 
certificate) before an explicit policy is required. An acceptable 
policy identifier is the identifier Electronic Signature (ES-X, ES-A) need to be 
implemented to get conformance to this standard.

This document mandates support for elements of a policy required by the user signature policy.

6.1  Signer

A system supporting signers according to this document must, at a 
minimum, support generation of 
the certification path or the identifier an electronic signature consisting of a policy which has been 
declared equivalent through policy mapping. 
the following components:

      * The general CMS syntax and content type as defined in RFC 2630 
        (see clauses 4.1 and 4.2).

      * CMS SignedData as defined in RFC 2630 with version set to 3 
        and at least one SignerInfo must be present 
        (see clauses 4.3, 4.4, 4.5, 4.6).

      * The following CMS Attributes as defined in RFC 2630 :

             - ContentType; This must always be present 
               (see clause 3.7.1);

             - MessageDigest; This must always be present 
               (see clause 3.7.2);

             - SigningTime; This must always be present 
               (see clause 3.7.3).



ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 45] 38]
Internet Draft                             Electronic Signature Formats

5.6.2	Revocation Requirements

      * The RevocRequirements field specifies minimum requirements for 
revocation information, obtained through CRLs and/or OCSP responses, to 
be used following ESS Attributes as defined in checking the revocation status of certificates. RFC 2634 :

              - SigningCertificate: This ASN1 
structure is used to define policy for validating the signing 
certificate, the TSA's certificate and attribute certificates. 

CertRevReq ::= SEQUENCE {
	endCertRevReq	RevReq,
	caCerts	    [0] RevReq
                                            }


Certificate revocation requirements are specified must be set as defined 
                in terms of checks 
required on: clauses 3.8.1 and 3.8.2.

      * endCertRevReq: end certificates (i.e. the signers certificate,
     the attribute certificate or the timestamping authority 
     certificate). The following Attributes as defined in clause 3.9:
             - SignaturePolicyIdentifier; This must always be present.

      * caCerts: CA certificates.

        RevReq ::= SEQUENCE  { 
         enuRevReq  EnuRevReq,
         exRevReq    SignPolExtensions OPTIONAL}


An authority certificate is certificate issued to an authority (e.g. 
either to a certification authority or to an attribute authority (AA)).

A TimeStamping Authority (TSA) is a trusted third party that creates 
time stamp tokens Public Key Certificates as defined in order ITU-T Recommendation 
        X.509 [1] and profiled in RFC 2459 [7] (see clause 9.1).

6.2  Verifier

A system supporting verifiers according to indicate that a datum existed this document must, at a 
particular point 
minimum, support:

       * Verification of the mandated components of an electronic 
         signature, as defined in time (RFC??: "Internet X.509 clause 14.1.

       * Signature Timestamp attribute, as defined in clause 4.1.1.

       * Complete Certificate Refs attribute, as defined in 
         clause 4.2.1.

       * Complete Revocation Refs Attribute, as defined in 
         clause  4.2.2.

       * Public Key 
Infrastructure Certificates, as defined in ITU-T 
         Recommendation X.509 and profiled in RFC 2459.

       * Either of:

             - Time Stamp Protocol").

EnuRevReq  ::= ENUMERATED {
	clrCheck	(0), 
                   --Checks must be made against current CRLs
		   -- (or authority revocation lists (ARL))
	ocspCheck	(1), -- The revocation status must be checked
                  -- using the Online Certificate Revocation Lists. as defined in ITU-T 
               Recommendation X.509 [1] and profiled in RFC 2459 [7]; 
               or

             - On-line Certificate Status Protocol 
                  -- (OCSP),RFC 2450.
	bothCheck	(2),	
                  -- Both CRL and OCSP checks must be carried out
	eitherCheck	(3),	
                  -- At least one of CRL or OCSP checks must be
                  -- carried out
	noCheck		(4),	
                  -- no check is mandated
	other		(5)		
                  -- Other mechanism responses, as 
               defined by signature poilicy 
                  -- extension
	  } in RFC 2560.

















ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 46] 39]
Internet Draft                             Electronic Signature Formats

Revocation requirements are specified

7. References

[RFC2119] Bradner, S., "Key words for use in terms of: 
     * clrCheck: Checks must be made against current CRLs (or
       authority revocation lists);
     * ocspCheck: The revocation status must be checked using the
       Online Certificate RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[ESS] P. Hoffman, "Enhanced Security Services for S/MIME", 
RFC 2634, June 1999 

[CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, 
June 1999.

[OCSP] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams.
On-line Status Certificate Protocol, RFC 2560. 

[TSP] C. Adams, P. Cain, D. Pinkas, R. Zuccherato. Time Stamp Protocol (RFC 2450);
     * bothCheck: Both OCSP and CRL checks must be carried out;
     * eitherCheck: Either OCSP or CRL checks must be carried out;
     * noCheck: No check is mandated.

5.7	Signing 
(TSP), (under progress). June 2000.

[PTS] Public Telegram Service. ITU-T Recommendation F1. XXXX

[RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public 
Key Infrastructure, Certificate Trust Conditions

The SigningCertTrustCondition field identifies trust conditions for 
certificate path processing used to validate the signing certificate.

SigningCertTrustCondition ::=   SEQUENCE {
     signerTrustTrees              CertificateTrustTrees,
     signerRevReq                  CertRevReq
                                             }


5.8	TimeStamp Trust Conditions

The TimeStampTrustCondition field identifies trust conditions for 
certificate path processing used to authenticate the timstamping 
authority and constraints on the name CRL Profile," RFC 2459, January 
1999.

[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data Security Inc., Redwood City, California, November
1993 Release.

[ISONR] ISO/IEC 10181-5:  Security Frameworks in Open Systems.  
Non-Repudiation Framework. April 1997.

[ES201733] ETSI Standard ES 201 733 V1.1.3 (2000-05) Electronic
Signature Formats. Note: copies of ETSI ES 210 733 can be freely
downloaded from the timestamping authority. ETSI web site www.etsi.org.

8. Authors' Addresses

This applies to the timestamp that must be present in every ES-T.


TimestampTrustCondition ::= SEQUENCE {
    ttsCertificateTrustTrees	[0]	CertificateTrustTrees    
                                           OPTIONAL,
    ttsRevReq			[1]		CertRevReq              
                                           OPTIONAL,
    ttsNameConstraints  	[2]		NameConstraints         
                                           OPTIONAL,
    cautionPeriod		[3]		DeltaTime               
                                           OPTIONAL,
    signatureTimestampDelay	[4]		DeltaTime               
                                           OPTIONAL }

DeltaTime ::= SEQUENCE {
	deltaSeconds	INTEGER,
	deltaMinutes	INTEGER,
	deltaHours	INTEGER,
	deltaDays	INTEGER }


If ttsCertificateTrustTrees is not present then the same rule as 
defined Informational RFC has been produced in certificateTrustCondition applies to certification of the 
timestamping authorities public key. ETSI TC-SEC.

ETSI
F-06921 Sophia Antipolis, Cedex - FRANCE
650 Route des Lucioles - Sophia Antipolis
Valbonne - France
Tel: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16
secretariat@etsi.fr
http://www.etsi.org









ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 47] 40]
Internet Draft                             Electronic Signature Formats

Contact Point

Harri Rasilainen
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis, Cedex
FRANCE
harri.rasilainen@etsi.fr

Denis Pinkas
Bull S.A.
12, rue de Paris
B.P. 59
78231 Le Pecq
FRANCE
Denis.Pinkas @bull.net

John Ross
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom 
ross@secstan.com

Nick Pope
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom
pope@secstan.com


9. Full Copyright Statement 

Copyright (C) The tstrRevReq specifies minimum requirements for revocation 
information, obtained through CRLs and/or OCSP responses, Internet Society (2000). All Rights Reserved. 
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 used prepared, copied, published and 
distributed, in 
checking the revocation status whole or in part, without restriction of the time stamp any kind, 
provided that must be present 
in the ES-T.

If ttsNameConstraints is not present then there above copyright notice and this paragraph are no additional 
naming constraints 
included on the trusted timestamping authority other than 
those implied by the ttsCertificateTrustTrees.

The cautionPeriod field specifies a caution period after the signing 
time that it is mandated the verifier must wait to get high assurance 
of the validity of the signer's key all such copies and that any relevant revocation 
has been notified. The revocation status information forming the ES 
with Complete validation data must derivative works. However, this 
document itself may not be collected and used to 
validate the electronic signature until after this caution period.

The signatureTimestampDelay field specifies a maximum acceptable time 
between the signing time and the time at which the signature timestamp, modified in any way, such as used by removing 
the copyright notice or references to form the ES Timestamped, is created Internet Society or other 
Internet organizations, except as needed for the verifier. If the 
signature timestamp is later that the time purpose of developing 
Internet standards in which case the signing-time 
attribute by more than the value given procedures for copyrights defined 
in signatureTimestampDelay, the 
signature Internet Standards process must be considered invalid.


5.9	Attribute Trust Conditions

If the attributeTrustCondition field is not present then any certified 
attributes may not considered followed, or as required to be valid under this validation policy. 
translate it into languages other than English. 






ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 41]
Internet Draft                             Electronic Signature Formats


The AttributeTrustCondition field is defined as follows:


AttributeTrustCondition ::= SEQUENCE {
	attributeMandated            BOOLEAN, 
                                     -- Attribute must limited permissions granted above are perpetual and will not be present
	howCertAttribute             HowCertAttribute,
	attrCertificateTrustTrees   [0] CertificateTrustTrees  OPTIONAL, 
	attrRevReq                  [1] CertRevReq             OPTIONAL,
	attributeConstraints        [2] AttributeConstraints   OPTIONAL }


If attributeMandated is true then an attribute, certified within 
revoked by the 
following constraints, must be present. If false, then Internet Society or its successors or assigns. 

This document and the signature information contained herein is still valid if no attribute is specified.

The howCertAttribute field specifies whether attributes uncertified 
attributes "claimed" by the signer, or certified in provided on an attribute 
certificate or either  using the signer attributes attribute defined 
in 4.12.3.

HowCertAttribute ::= ENUMERATED {
	claimedAttribute       (0),
	certifiedAttribtes     (1),
	either                 (2) } 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS 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.













































ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 48] 42]
Internet Draft                             Electronic Signature Formats


The attrCertificateTrustTrees specifies certificate path conditions for 
any attribute certificate. If not present


Annex A (normative): ASN.1 Definitions

This annex provides a summary of all the same rules apply as ASN.1 syntax definitions for 
new syntax defined in 
certificateTrustCondition. this document.

A.1  Definitions Using X.208 (1988) ASN.1 Syntax

NOTE:  The attrRevReq specifies minimum requirements for revocation 
information, obtained through CRLs and/or OCSP responses, to be used ASN.1 module defined in clause A.1 has precedence over that 
defined in Annex A-2 in 
checking the revocation status case of Attribute Certificates, if any are 
present.

If the attributeConstraints field is not present then there are no 
constraints on the attributes that may be validated under this policy. 
The attributeConstraints field is defined as follows:

AttributeConstraints ::= SEQUENCE conflict.

    ETS-ElectronicSignatureFormats-88syntax {
	attributeTypeConstarints	[0] AttributeTypeConstraints  
                                                 OPTIONAL,
	attributeValueConstarints	[1] AttributeValueConstraints 
                                                 OPTIONAL }


If present, the attributeTypeConstarints field specifies the attribute 
types which are considered valid under the signature policy. Any value 
for that attribute is considered valid.

AttributeTypeConstraints iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 5}

DEFINITIONS EXPLICIT TAGS ::= SEQUENCE OF AttributeType 


If present, the attributeTypeConstraints field specifies the specific 
attribute values which are considered valid under the signature policy.

AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue

5.10	Algorithm Constraints

The algorithmConstrains fields, if present, identifies the signing 
algorithms (hash, public key cryptography, combined hash and public key 
cryptography) that may be used for specific purposes and any minimum 
length. If this field is not present then the policy applies no 
constraints.

AlgorithmConstraintSet ::= SEQUENCE {

BEGIN

-- Algorithm constrains on:
signerAlgorithmConstraints	[0] 	AlgorithmConstraints OPTIONAL, EXPORTS All -

IMPORTS

-- signer
eeCertAlgorithmConstraints	[1] 	AlgorithmConstraints OPTIONAL, Crypographic Message Syntax (CMS): RFC 2630

  ContentInfo, ContentType, id-data, id-signedData, SignedData, 
  EncapsulatedContentInfo, SignerInfo, id-contentType, 
  id-messageDigest, MessageDigest, id-signingTime, SigningTime,
  id-countersignature, Countersignature

  FROM CryptographicMessageSyntax
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
      smime(16) modules(0) cms(1) }

-- issuer of end entity certs.
caCertAlgorithmConstraints	[2] 	AlgorithmConstraints OPTIONAL, ESS Defined attributes: RFC 2634 
-- issuer of CA certificates
aaCertAlgorithmConstraints	[3] 	AlgorithmConstraints OPTIONAL, (Enhanced Security Services for S/MIME)

  id-aa-signingCertificate, SigningCertificate, IssuerSerial,
  id-aa-contentReference, ContentReference, 
  id-aa-contentIdentifier, ContentIdentifier

  FROM ExtendedSecurityServices
     { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }

-- Attribute Authority 
tsaCertAlgorithmConstraints	[4] 	AlgorithmConstraints OPTIONAL Internet X.509 Public Key Infrastructure 
-- TimeStamping Authority
			                                    } Certificate and CRL Profile: RFC 2459

  Certificate, AlgorithmIdentifier, CertificateList, Name, 
  GeneralNames, GeneralName, DirectoryString,Attribute, 
  AttributeTypeAndValue, AttributeType, AttributeValue,
  PolicyInformation, BMPString, UTF8String




ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 49] 43]
Internet Draft                             Electronic Signature Formats


AlgorithmConstraints ::= SEQUENCE OF AlgAndLength

AlgAndLength ::= SEQUENCE {
	algID			OBJECT IDENTIFIER,
	minKeyLength	INTEGER 	OPTIONAL,


  FROM PKIX1Explicit88 
  {iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-
   88(1)}

-- Minimum key length in bits
	other 		SignPolExtensions OPTIONAL
		 }

An Attribute Authority (AA)is authority which assigns privileges by 
issuing attribute certificates 

5.11	Signature Policy Extensions

Additional signature policy rules may be added to:

     * the overall signature policy structure, as defined in 
       clause 5.1;
     * the signature validation policy structure, as defined in 
       clause 5.2;
     * the common rules, as X.509 '97 Authentication Framework

AttributeCertificate

  FROM AuthenticationFramework 
  {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3}

-- The imported AttributeCertificate is defined in clause 5.3;
     * using the commitment rules, as defined in clause 5.4;
     * the signer rules, as defined in clause 5.5.1;
     * the verifier rules, as defined in clause 5.5.2;
     * the revocation requirements in clause 5.6.2;
     * the algorithm constraints in clause 5.10.


These extensions to the signature policy rules must be defined using X.680 1997 
-- ASN.1 Syntax,
-- an equivalent using the 88 ASN.1 syntax with an associated object identifier carried may be used.


-- OCSP 2560

BasicOCSPResponse, ResponderID

  FROM OCSP {-- OID not assigned -- }


-- Time Stamp Protocol Internet Draft

TimeStampToken

  FROM PKIXTSP 
  {iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}

-- S/MIME Object Identifier arcs used in the 
SignPolExtn as defined below:

SignPolExtensions this document
-- ===================================================

-- S/MIME  OID arc used in this document
-- id-smime OBJECT IDENTIFIER ::= SEQUENCE OF SignPolExtn

SignPolExtn { iso(1) member-body(2) 
--             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

-- S/MIME Arcs
-- id-mod  OBJECT IDENTIFIER ::= SEQUENCE {
                extnID id-smime 0 }   
-- modules
-- id-ct   OBJECT IDENTIFIER,
		extnValue   OCTET STRING IDENTIFIER ::= { id-smime 1 }


The extnID field must contain the object   
-- content types
-- id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }   
-- attributes
-- id-spq  OBJECT IDENTIFIER ::= { id-smime 5 }   
-- signature policy qualifier
-- id-cti  OBJECT IDENTIFIER ::= { id-smime 6 }   
-- commitment type identifier for the extension. 
The extnValue field must contain the DER (see ITU-T Recommendation 
X.690 [4]) encoded value




ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 44]
Internet Draft                             Electronic Signature Formats


-- Definitions of the extension. Object Identifier arcs used in this document
-- ===========================================================

-- The definition of an 
extension, as identified by extnID must include a definition allocation of OIDs to specific objects are given below with the 
-- associated ASN.1 syntax and semantics of the extension.

6.	Security considerations

6.1	Protection of Private Key

The security of the definition

-- OID used referencing electronic signature mechanism defined mechanisms based on this 
-- standard for use with the IDUP API (see annex D)

id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::=
  { itu-t(0) identified-organization(4) etsi(0) 
     electronic-signature-standard (1733) part1 (1) 
         idupMechanism (4)etsiESv1(1) }

-- CMS Attributes Defined in this document depends on the privacy of the signer's private key.  
Implementations must take steps to ensure that private keys cannot be 
compromised.
-- =======================================

-- Mandatory Electronic Signature Attributes

-- OtherSigningCertificate

    id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-aa(2) 19 }

OtherSigningCertificate ::=  SEQUENCE {
    certs        SEQUENCE OF OtherCertID,
    policies     SEQUENCE OF PolicyInformation OPTIONAL
                 -- NOT USED IN THIS DOCUMENT
}

OtherCertID ::= SEQUENCE {
     otherCertHash            OtherHash,
     issuerSerial             IssuerSerial OPTIONAL
}

OtherHash ::= CHOICE {
    sha1Hash     OtherHashValue,  -- This contains a SHA-1 hash
    otherHash    OtherHashAlgAndValue
}

OtherHashValue ::= OCTET STRING

OtherHashAlgAndValue ::= SEQUENCE {
  hashAlgorithm    AlgorithmIdentifier,
  hashValue        OtherHashValue
}

-- Signature Policy Identifier

    id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-aa(2) 15 }

ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 50] 45]
Internet Draft                             Electronic Signature Formats


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

7.	Conformance Requirements

This document only defines conformance requirements up to a ES with 
Complete validation data (ES-C). This means that none of the extended 
and archive forms of



SignaturePolicyIdentifier ::= SEQUENCE {
        sigPolicyIdentifier   SigPolicyId,
        sigPolicyHash         SigPolicyHash,
        sigPolicyQualifiers   SEQUENCE SIZE (1..MAX) OF
                              SigPolicyQualifierInfo OPTIONAL
}

SigPolicyId ::= OBJECT IDENTIFIER

SigPolicyHash ::= ETSIHashAlgAndValue

SigPolicyQualifierInfo ::= SEQUENCE {
        sigPolicyQualifierId  SigPolicyQualifierId,
        sigQualifier          ANY DEFINED BY sigPolicyQualifierId
}

SigPolicyQualifierId ::=
        OBJECT IDENTIFIER 

    id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-spq(5) 1 }


   SPuri ::= IA5String

    id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-spq(5) 2 }

   SPUserNotice ::= SEQUENCE {
        noticeRef        NoticeReference   OPTIONAL,
        explicitText     DisplayText       OPTIONAL
}

   NoticeReference ::= SEQUENCE {
        organization     DisplayText,
        noticeNumbers    SEQUENCE OF INTEGER
}

   DisplayText ::= CHOICE {
        visibleString    VisibleString  (SIZE (1..200)),
        bmpString        BMPString      (SIZE (1..200)),
        utf8String       UTF8String     (SIZE (1..200))
}








ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 46]
Internet Draft                             Electronic Signature Formats


-- Optional Electronic Signature (ES-X, ES-A) need to be 
implemented to get conformance to this standard.

This document mandates support for elements of the signature policy.

7.1	Signer

A system supporting signers according to this document must, at a 
minimum, support generation of an electronic signature consisting of 
the following components:

      * The general CMS syntax and content type as defined in RFC 2630 
        (see clauses 4.1 and 4.2).

      * CMS SignedData as defined in RFC 2630 with version set to 3 
        and at least one SignerInfo must be present 
        (see clauses 4.3, 4.4, 4.5, 4.6).

      * The following CMS Attributes as defined in RFC 2630 :
             - ContentType; This must always be present 
               (see clause 3.7.1);

             - MessageDigest; This must always be present 
               (see clause 3.7.2);

             - SigningTime; This must always be present 
               (see clause 3.7.3).

      * The following ESS Attributes as defined in RFC 2634 :
              - SigningCertificate: This must be set as defined 
                in clauses 3.8.1 and 3.8.2.

      * The following Attributes as defined in clause 3.9:
             - SignaturePolicyIdentifier; This must always be present.

      * Public Key Certificates as defined in ITU-T Recommendation 
        X.509 [1] and profiled in RFC 2459 [7] (see clause 9.1).

-- Commitment Type

id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16}


CommitmentTypeIndication ::= SEQUENCE {
  commitmentTypeId                 CommitmentTypeIdentifier,
  commitmentTypeQualifier          SEQUENCE SIZE (1..MAX) OF 
                                   CommitmentTypeQualifier   OPTIONAL
}

CommitmentTypeIdentifier ::= OBJECT IDENTIFIER

CommitmentTypeQualifier ::= SEQUENCE {
    commitmentTypeIdentifier   CommitmentTypeIdentifier,
    qualifier                  ANY DEFINED BY commitmentTypeIdentifier
}


    id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
    cti(6) 1}


    id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
    cti(6) 2}


    id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member-
    body(2)  us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
    cti(6) 3}


    id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
   cti(6) 4}


    id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
    cti(6) 5}


    id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
    cti(6) 6}




ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 51] 47]
Internet Draft                             Electronic Signature Formats


7.2	Verifier

A system supporting verifiers according to this document must,


-- Signer Location

   id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-
   body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
   id-aa(2) 17}

SignerLocation ::= SEQUENCE { 
       -- at a 
minimum, support:

       * Verification least one of the mandated components of an electronic 
          signature, as defined in clause 14.1.

       * Signature Timestamp attribute, as defined in clause 5.1.1.

       * Complete Certificate Refs attribute, following must be present
      countryName      [0]  DirectoryString    OPTIONAL,
       -- as defined used to name a Country in 
         clause 5.2.1.

       * Complete Revocation Refs Attribute, X.500
      localityName     [1]  DirectoryString    OPTIONAL,
       -- as defined used to name a locality in 
         clause  5.2.2.

       * Public Key Certificates, X.500
      postalAdddress   [2]  PostalAddress      OPTIONAL
}

  PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString

-- Signer Attributes

    id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18}

SignerAttribute ::= SEQUENCE OF CHOICE {
      claimedAttributes     [0] ClaimedAttributes,
      certifiedAttributes   [1] CertifiedAttributes
}

ClaimedAttributes ::= SEQUENCE OF Attribute 

CertifiedAttributes ::= AttributeCertificate  -- as defined in ITU-T 
         Recommendation X.509 and profiled in : 
see section 10.3

-- Content Timestamp

    id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
    id-aa(2) 20}

ContentTimestamp::= TimeStampToken

-- Validation Data

-- Signature Timestamp

    id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) 
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
    id-aa(2) 14}

SignatureTimeStampToken ::= TimeStampToken





ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC 2459 
         (see clause 10.1)

       * Either of:
             -       [Page 48]
Internet Draft                             Electronic Signature Formats



-- Complete Certificate Refs.

id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21}

CompleteCertificateRefs ::=  SEQUENCE OF OTHERCertID

-- Complete Revocation Lists. as defined in ITU-T 
               Recommendation X.509 Refs

   id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-
   body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
   id-aa(2) 22}

CompleteRevocationRefs ::=  SEQUENCE OF CrlOcspRef

CrlOcspRef ::= SEQUENCE {
    crlids           [0] CRLListID      OPTIONAL,
    ocspids          [1] and profiled in RFC 2459 [7] 
               (see clause 10.2); Or
             - On-line Certificate Status Protocol, OcspListID     OPTIONAL,
    otherRev         [2] OtherRevRefs   OPTIONAL
}

CRLListID ::=  SEQUENCE {
    crls        SEQUENCE OF CrlValidatedID}

CrlValidatedID ::=  SEQUENCE {
     crlHash                   ETSIHash, 
     crlIdentifier             CrlIdentifier OPTIONAL
}

CrlIdentifier ::= SEQUENCE {
    crlissuer                 Name,
    crlIssuedTime             UTCTime,
    crlNumber                 INTEGER OPTIONAL
}

OcspListID ::=  SEQUENCE {
    ocspResponses        SEQUENCE OF OcspResponsesID}

OcspResponsesID ::=  SEQUENCE {
    ocspIdentifier              OcspIdentifier,
    ocspRepHash                 ETSIHash    OPTIONAL
}

OcspIdentifier ::= SEQUENCE {
  ocspResponderID    ResponderID,  
                    -- as defined in 
               RFC 2560 (see clause 10.3).


7.3	Signature Policy

Both signer and verifier systems must be able to process an electronic 
signature in accordance with the specification of at least one 
signature policy, OCSP response data
  producedAt      GeneralizedTime 
                    -- as identified by the signature policy attribute 
(see clause 4.9.1).



8. References

[RFC2510] C. Adams, S. Farrell, "Internet X.509 Public Key 
Infrastructure, Certificate Management Protocols," RFC 2510, March 1999.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2246] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0," RFC 
2246, January 1999.

[RFC 2634] P. Hoffman, "Enhanced Security Services for S/MIME", 

[RFC 2630] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 
1999. OCSP response data
}




ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 52] 49]
Internet Draft                             Electronic Signature Formats

[RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public 
Key Infrastructure,


OtherRevRefs ::= SEQUENCE {
   otherRevRefType         OtherRevRefType,
   otherRevRefs            ANY DEFINED BY otherRevRefType
}

OtherRevRefType ::= OBJECT IDENTIFIER

-- Certificate and CRL Profile," RFC 2459, January 
1999.

[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data Security Inc., Redwood City, California, November
1993 Release.

[ISONR] ISO/IEC 10181-5:  Security Frameworks in Open Systems.  
Non-Repudiation Framework. April 1997.

9. Authors' Addresses

This Informational RFC has been produced in ETSI TC-SEC.

ETSI
F-06921 Sophia Antipolis, Cedex - FRANCE
650 Route des Lucioles - Sophia Antipolis
Valbonne - France
Tel: +33 4 92 94 42 00	Fax: +33 4 93 65 47 16
secretariat@etsi.fr
http://www.etsi.org

ETSI Contact Point

Harri Rasilainen Values

id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23}

CertificateValues ::=  SEQUENCE OF Certificate

-- Certificate Revocation Values

id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
    id-aa(2) 24}

RevocationValues ::=  SEQUENCE {
   crlVals          [0] SEQUENCE OF CertificateList     OPTIONAL,
   ocspVals         [1] SEQUENCE OF BasicOCSPResponse   OPTIONAL,
   otherRevVals     [2] OtherRevVals
}

OtherRevVals ::= SEQUENCE {
   otherRevValType  OtherRevValType,
  otherRevVals      ANY DEFINED BY otherRevValType
}

OtherRevValType ::= OBJECT IDENTIFIER


-- ES-C Timestamp

id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 25}

ESCTimeStampToken ::= TimeStampToken


-- Time-Stamped Certificates and CRLs

id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
    id-aa(2) 26}

TimestampedCertsCRLs ::= TimeStampToken





ETSI
F-06921 Sophie Antipolis
650 Route des Lucioles
Sophia Antipolis, Valbonne
FRANCE
harri.rasilainen@etsi.fr


Additional Contact Points

John Ross
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom 
ross@secstan.com

Denis Pinkas                          Nick TC-SEC, Pinkas, Ross, Pope
Bull S.A.                             Security & Standards
12, rue de Paris                      192 Moulsham Street
B.P. 59                               Chelmsford, Essex
78231 Le Pecq                         CM2 0LG
FRANCE                                United Kingdom
pinkas.denis@bull.net                 pope@secstan.com       Informational RFC       [Page 50]
Internet Draft                             Electronic Signature Formats


-- Archive Timestamp

id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
    body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
    id-aa(2) 27}

ArchiveTimeStampToken ::= TimeStampToken




END -- ETS-ElectronicSignatureFormats-88syntax --










































ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 53] 51]
Internet Draft                             Electronic Signature Formats


10. Full Copyright Statement 

Copyright (C)


A.2  Definitions Using X.680 1997 ASN.1 Syntax

NOTE:  The Internet Society (2000). All Rights Reserved. 
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 ASN.1 module defined in part, without restriction of any kind, provided clause A.1 has precedence over 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 
defined in any 
way, such as by removing the copyright notice or references to the Internet 
Society or other Internet organizations, except as needed for the purpose of
developing Internet standards clause A.2 in which case the procedures case of any conflict.

    ETS-ElectronicSignatureFormats-97Syntax { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 6}

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

-- EXPORTS All -

IMPORTS

-- Cryptographic Message Syntax (CMS): RFC 2630

  ContentInfo, ContentType, id-data, id-signedData, SignedData,
  EncapsulatedContentInfo, SignerInfo, id-contentType, 
  id-messageDigest, MessageDigest, id-signingTime, 
  SigningTime, id-countersignature, Countersignature

   FROM CryptographicMessageSyntax
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
    smime(16) modules(0) cms(1) }
     

-- ESS Defined attributes: RFC 2634 (Enhanced Security Services
-- for copyrights 
defined in the S/MIME)

   id-aa-signingCertificate, SigningCertificate, IssuerSerial,
   id-aa-contentReference, ContentReference, 
   id-aa-contentIdentifier, ContentIdentifier

  FROM ExtendedSecurityServices
    { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }

-- Internet Standards process must be followed, or as required to 
translate it into languages other than English. 

The limited permissions granted above are perpetual X.509 Public Key Infrastructure 
- - Certificate and will not be revoked 
by the Internet Society or its successors or assigns. 

This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS 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.




11.Temportary Issues
It might be interesting to split this document into two RFCs, one RFC 
dealing only with ES formats, the other one only with Signature 
Policies. In such a case, the basis of this split will be, sections 6 
and annex C will be removed from this document and placed in the another 
RFC dealing with Signature policies.  The signature policy ASN.1 will be 
removed the current ASN.1 modules in annex A and placed in a new ASN.1 
module in the other RFC dealing with Signature Policies. Opinions are 
requested on this issue. CRL Profile:RFC 2459

   Certificate, AlgorithmIdentifier, CertificateList, Name, 
   GeneralNames, GeneralName, DirectoryString, Attribute,
   AttributeTypeAndValue, AttributeType, AttributeValue,
   PolicyInformation.


  FROM PKIX1Explicit93 
    {iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) id-mod(0) 
     id-pkix1-explicit-88(1)}


ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 54] 52]
Internet Draft                             Electronic Signature Formats

Note: If there is a request to split


-- X.509 '97 Authentication Framework

        AttributeCertificate

        FROM AuthenticationFramework 
        {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3}

-- OCSP 2560

      BasicOCSPResponse, ResponderID

  FROM OCSP 

--  { OID not assigned }


-- Time Stamp Protocol Internet Draft TimeStampToken

  FROM PKIXTSP 
  {iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}

-- S/MIME Object Identifier arcs used in this document into two RFCs, one 
RFC dealing with ES formats, the other with Signature policies, then the 
signature policy ASN.1 will be removed the current ASN.1 modules in 
annex A and placed in a new ASN.1 module in the other RFC dealing with 
Signature policies.

Annex A (normative):

ASN.1 Definitions

This annex provides a summary of all the ASN.1 syntax definitions for 
new syntax defined 
-- ===================================================

-- S/MIME  OID arc used in this document.

A.1	Definitions Using X.208 (1988) ASN.1 Syntax

NOTE:	The ASN.1 module defined in clause A.1 has precedence over that 
defined in Annex A-2 in the case of any conflict.

ETS-ElectronicSignature-88syntax document
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 
--             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 5}


DEFINITIONS EXPLICIT TAGS 16 }

-- S/MIME Arcs
-- id-mod  OBJECT IDENTIFIER ::=
BEGIN { id-smime 0 }   
-- EXPORTS All -

IMPORTS modules
-- Crypographic Message Syntax (CMS): RFC 2630
	ContentInfo, ContentType, id-data, id-signedData, SignedData, 
        EncapsulatedContentInfo,
	SignerInfo, id-contentType, id-messageDigest, MessageDigest,
        id-signingTime, SigningTime,
	id-countersignature, Countersignature
	FROM CryptographicMessageSyntax id-ct   OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
      smime(16) modules(0) cms(1) id-smime 1 }   
-- ESS Defined attributes: RFC 2634 content types
-- (Enhanced Security Services for S/MIME)
   id-aa-signingCertificate, SigningCertificate, IssuerSerial,
	id-aa-contentReference, ContentReference, 
        id-aa-contentIdentifier, ContentIdentifier
	FROM ExtendedSecurityServices id-aa   OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) id-smime 2 }   
-- attributes
-- id-spq  OBJECT IDENTIFIER ::= { id-smime 5 }   
-- signature policy qualifier
-- id-cti  OBJECT IDENTIFIER ::= { id-smime 6 }   
-- commitment type identifier


-- Definitions of Object Identifier arcs used in this document
-- ===========================================================

-- The allocation of OIDs to specific objects are given below with the 
-- associated ASN.1 syntax definition

-- OID used referencing electronic signature mechanisms based on this
-- standard for use with the IDUP API (see annex D)




ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 55] 53]
Internet Draft                             Electronic Signature Formats


-- Internet X.509 Public Key Infrastructure 
- - Certificate and CRL Profile: RFC 2459

	Certificate, AlgorithmIdentifier, CertificateList, Name, 
        GeneralNames, GeneralName,
	DirectoryString,Attribute, AttributeTypeAndValue, AttributeType, 
        AttributeValue,
	PolicyInformation, BMPString, UTF8String
  FROM PKIX1Explicit88 
	{iso(1) identified-organization(3) dod(6) internet(1)
  	security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-
        88(1)}

-- X.509 '97 Authentication Framework
AttributeCertificate
	FROM AuthenticationFramework 
	{joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3}
-- The imported AttributeCertificate is defined using the X.680 1997 
-- ASN.1 Syntax,
-- an equivalent using the 88 ASN.1 syntax may be used.


-- OCSP 2560
BasicOCSPResponse, ResponderID
	FROM OCSP {-- OID not assigned --


id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::=
  { itu-t(0) identified-organization(4) etsi(0) 
   electronic-signature-standard (1733) part1 (1) 
   idupMechanism (4)etsiESv1(1) }


-- Time Stamp Protocol Internet Draft
-- TimeStampToken
	FROM TSP {-- OID not assigned -- };


-- S/MIME Object Identifier arcs used CMS Attributes Defined in this document
-- ================================================================== =======================================

-- S/MIME  OID arc used in this document Mandatory Electronic Signature Attributes
-- id-smime OtherSigningCertificate

id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) 
-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 pkcs9(9)
    smime(16) id-aa(2) 19 }

-- S/MIME Arcs
-- id-mod  OBJECT IDENTIFIER

OtherSigningCertificate ::=  SEQUENCE { id-smime 0 }   
-- modules
    certs        SEQUENCE OF OtherCertID,
    policies     SEQUENCE OF PolicyInformation OPTIONAL
                 -- id-ct   OBJECT IDENTIFIER NOT USED IN THIS DOCUMENT
}

OtherCertID ::= SEQUENCE { id-smime 1
     otherCertHash            OtherHash,
     issuerSerial             IssuerSerial OPTIONAL
}   
-- content types
-- id-aa   OBJECT IDENTIFIER

OtherHash ::= CHOICE { id-smime 2 }   
-- attributes
    sha1Hash OtherHashValue,  -- id-spq  OBJECT IDENTIFIER This contains a SHA-1 hash
    otherHash OtherHashAlgAndValue
}

OtherHashValue ::= OCTET STRING

OtherHashAlgAndValue ::= SEQUENCE { id-smime 5
  hashAlgorithm  AlgorithmIdentifier,
  hashValue    OtherHashValue
}

-- signature policy qualifier
-- id-cti Signature Policy Identifier

id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { id-smime 6 iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-aa(2) 15 }   
-- commitment type identifier




ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 56]

Internet Draft                                   Electronic Signature Formats




-- Definitions of Object Identifier arcs used in this document
-- ==================================================================

-- The allocation of OIDs to specific objects are given below with the 
-- associated ASN.1 syntax definition

-- OID used referencing electronic signature mechanisms based on this 
-- standard for use with the IDUP API (see annex D)

id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::=
	{ itu-t(0) identified-organization(4) etsi(0) 
	   electronic-signature-standard (1733) part1 (1) 
         idupMechanism (4)etsiESv1(1) }


-- CMS Attributes Defined in this document
-- ==============================================

-- Mandatory Electronic Signature Attributes

-- OtherSigningCertificate

id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-aa(2) 19 }

OtherSigningCertificate

SignaturePolicyIdentifier ::= SEQUENCE {
    certs        SEQUENCE OF OtherCertID,
    policies
        sigPolicyIdentifier   SigPolicyId,
        sigPolicyHash         SigPolicyHash,
        sigPolicyQualifiers   SEQUENCE SIZE (1..MAX) OF PolicyInformation OPTIONAL
                 -- NOT USED IN THIS DOCUMENT
                                            }

OtherCertID ::= SEQUENCE {
     otherCertHash            OtherHash,
     issuerSerial             IssuerSerial
                                SigPolicyQualifierInfo OPTIONAL
}

OtherHash ::= CHOICE {
    sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
    otherHash OtherHashAlgAndValue}

OtherHashValue ::= OCTET STRING

OtherHashAlgAndValue

SigPolicyId ::= SEQUENCE {
	hashAlgorithm	AlgorithmIdentifier,
	hashValue		OtherHashValue }

-- Signature Policy Identifier

id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-aa(2) 15 }

ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 57] 54]
Internet Draft                             Electronic Signature Formats



SignaturePolicyIdentifier ::= SEQUENCE {
        sigPolicyIdentifier   SigPolicyId,
		sigPolicyHash         SigPolicyHash,
        sigPolicyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                SigPolicyQualifierInfo OPTIONAL}

SigPolicyId ::= OBJECT IDENTIFIER

SigPolicyHash ::= ETSIHashAlgAndValue 


SigPolicyQualifierInfo ::= SEQUENCE {
        sigPolicyQualifierId  SigPolicyQualifierId,
        sigQualifier          ANY DEFINED BY sigPolicyQualifierId    SIG-POLICY-QUALIFIER.&id
                                 ({SupportedSigPolicyQualifiers}),
        qualifier               SIG-POLICY-QUALIFIER.&Qualifier
                                ({SupportedSigPolicyQualifiers}
                                 {@sigPolicyQualifierId})OPTIONAL }

SigPolicyQualifierId

SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::= 
                           { noticeToUser | pointerToSigPolSpec }

SIG-POLICY-QUALIFIER ::= CLASS {
        &id             OBJECT IDENTIFIER UNIQUE,
        &Qualifier      OPTIONAL }

WITH SYNTAX {
        SIG-POLICY-QUALIFIER-ID     &id
        [SIG-QUALIFIER-TYPE &Qualifier] }

noticeToUser SIG-POLICY-QUALIFIER ::= {
      SIG-POLICY-QUALIFIER-ID id-sqt-unotice SIG-QUALIFIER-TYPE 
                                            SPUserNotice 
                                                        }

pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= {
      SIG-POLICY-QUALIFIER-ID id-sqt-uri SIG-QUALIFIER-TYPE SPuri }

    id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-spq(5) 1 }

   SPuri ::= IA5String

  id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-spq(5) 2 }

   SPUserNotice ::= SEQUENCE {
        noticeRef        NoticeReference OPTIONAL,
        explicitText     DisplayText OPTIONAL} OPTIONAL
}

   NoticeReference ::= SEQUENCE {
        organization     DisplayText,
        noticeNumbers    SEQUENCE OF INTEGER
}

   DisplayText ::= CHOICE {
        visibleString    VisibleString  (SIZE (1..200)),
        bmpString        BMPString      (SIZE (1..200)),
        utf8String       UTF8String     (SIZE (1..200))
}

ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 58] 55]
Internet Draft                             Electronic Signature Formats



-- Optional Electronic Signature Attributes

-- Commitment Type

id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16}

CommitmentTypeIndication ::= SEQUENCE {
  commitmentTypeId CommitmentTypeIdentifier,
  commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 
                                           CommitmentTypeQualifier 
                                           OPTIONAL}

CommitmentTypeIdentifier ::= OBJECT IDENTIFIER

CommitmentTypeQualifier ::= SEQUENCE {
		commitmentTypeIdentifier CommitmentTypeIdentifier,
        commitmentQualifierId       COMMITMENT-QUALIFIER.&id,
        qualifier	ANY DEFINED BY commitmentTypeIdentifier                   COMMITMENT-QUALIFIER.&Qualifier 
                                                  OPTIONAL }

COMMITMENT-QUALIFIER ::= CLASS {
                    &id             OBJECT IDENTIFIER UNIQUE,
                    &Qualifier      OPTIONAL }
WITH SYNTAX {
         COMMITMENT-QUALIFIER-ID     &id
                        [COMMITMENT-TYPE &Qualifier] }

  id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) member-
       body(2) 
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
      smime(16) cti(6) 1}

  id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1) member-
      body(2)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) cti(6) 2}

  id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1) member-
      body(2)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) cti(6) 3}

  id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1) member-
      body(2)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) cti(6) 4}

  id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1) member-
      body(2)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
      smime(16) cti(6) 5}

  id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1) member-
      body(2)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) cti(6) 6}



ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 59] 56]
Internet Draft                             Electronic Signature Formats


-- Signer Location

id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17}

SignerLocation ::= SEQUENCE {
                       -- At at least one of the following must be present
      countryName [0] DirectoryString OPTIONAL, 
        -- As used to name a Country in X.500
      localityName [1] DirectoryString OPTIONAL, 
         -- As used to name a locality in X.500
      postalAdddress [2] PostalAddress OPTIONAL }
  
  PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString


-- Signer Attributes

id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18}

SignerAttribute ::= SEQUENCE OF CHOICE {
      claimedAttributes  [0] ClaimedAttributes,
      certifiedAttributes [1] CertifiedAttributes }



ClaimedAttributes ::= SEQUENCE OF Attribute 

CertifiedAttributes ::= AttributeCertificate  
-- As defined in X.509 : see section 10.3


-- Content Timestamp

id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
    body(2)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
      smime(16) id-aa(2) 20}

ContentTimestamp::= TimeStampToken


-- Validation Data

-- Signature Timestamp

id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1) member-
    body(2)
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
     smime(16) id-aa(2) 14}

SignatureTimeStampToken ::= TimeStampToken



ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 60] 57]
Internet Draft                             Electronic Signature Formats


-- Complete Certificate Refs.

id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21}

CompleteCertificateRefs ::=  SEQUENCE OF ETSICertID OTHERCertID


-- Complete Revocation Refs

id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22}

CompleteRevocationRefs ::=  SEQUENCE OF CrlOcspRef

CrlOcspRef ::= SEQUENCE {
    crlids           [0] CRLListID   OPTIONAL,
    ocspids          [1] OcspListID  OPTIONAL,
  otherRev     [2] OtherRevRefs OPTIONAL
                                          }

CRLListID ::=  SEQUENCE {
    crls        SEQUENCE OF CrlValidatedID}

CrlValidatedID ::=  SEQUENCE {
     crlHash                   ETSIHash, 
     crlIdentifier             CrlIdentifier OPTIONAL}

CrlIdentifier ::= SEQUENCE {
    crlissuer                 Name,
    crlIssuedTime             UTCTime,
    crlNumber                 INTEGER OPTIONAL
                                            }



OcspListID ::=  SEQUENCE {
    ocspResponses        SEQUENCE OF OcspResponsesID}

OcspResponsesID ::=  SEQUENCE {
    ocspIdentifier              OcspIdentifier,
    ocspRepHash                 ETSIHash    OPTIONAL
                                            }

OcspIdentifier ::= SEQUENCE {
  ocspResponderID    ResponderID,  
                        -- As in OCSP response data
  producedAt      GeneralizedTime 
                        -- As in OCSP response data
                                             }




ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 61] 58]
Internet Draft                             Electronic Signature Formats



OtherRevRefs ::= SEQUENCE {
   otherRevRefType	OtherRevRefType,  OTHER-REVOCATION-REF.&id,
  otherRevRefs	ANY DEFINED BY otherRevRefType  OTHER-REVOCATION-REF.&Type
                                              }

OtherRevRefType

OTHER-REVOCATION-REF ::= CLASS {
    &Type, 
    &id  OBJECT IDENTIFIER UNIQUE }
  WITH SYNTAX { 
    &Type ID &id }


-- Certificate Values

id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23}

CertificateValues ::=  SEQUENCE OF Certificate

-- Certificate Revocation Values

id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-
    body(2) us(840)
     member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
     smime(16) id-aa(2) 24}

RevocationValues ::=  SEQUENCE {
   crlVals          [0] SEQUENCE OF CertificateList OPTIONAL,
   ocspVals         [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,
   otherRevVals      [2] OtherRevVals }

OtherRevVals ::= SEQUENCE {
   otherRevValType	OtherRevValType,  OTHER-REVOCATION-VAL.&id,
  otherRevVals	ANY DEFINED BY otherRevValType  OTHER-REVOCATION-VAL.&Type
                                               }

OtherRevValType

OTHER-REVOCATION-VAL ::= CLASS {
    &Type, 
    &id  OBJECT IDENTIFIER UNIQUE }
  WITH SYNTAX { 
    &Type ID &id }


-- ES-C Timestamp

id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1)
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
     smime(16) id-aa(2) 25}

ESCTimeStampToken ::= TimeStampToken




ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 59]
Internet Draft                             Electronic Signature Formats


-- Time-Stamped Certificates and CRLs

id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
    body(2)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
    smime(16) id-aa(2) 26}

TimestampedCertsCRLs ::= TimeStampToken




ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 62]

Internet Draft                                   Electronic Signature Formats


-- Archive Timestamp

id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
    body(2) us(840)
   member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
   smime(16) id-aa(2) 27}

ArchiveTimeStampToken ::= TimeStampToken



END                -- Signature Policy Specification
-- ==============================

SignaturePolicy ::= SEQUENCE {
	signPolicyHashAlg      AlgorithmIdentifier, 
	signPolicyInfo         SignPolicyInfo, 
	signPolicyHash         SignPolicyHash     OPTIONAL }

SignPolicyHash ::= OCTET STRING

SignPolicyInfo ::= SEQUENCE {
	signPolicyIdentifier            SignPolicyId,
	dateOfIssue                     GeneralizedTime,
	policyIssuerName                PolicyIssuerName,
	fieldOfApplication              FieldOfApplication,
	signatureValidationPolicy 	SignatureValidationPolicy,
	signPolExtensions		SignPolExtensions	
	                                      OPTIONAL
	                                              }

SignPolicyId ::= OBJECT IDENTIFIER

PolicyIssuerName ::= GeneralNames

FieldOfApplication ::= DirectoryString 

SignatureValidationPolicy ::= SEQUENCE {
	signingPeriod          SigningPeriod,
	commonRules            CommonRules,
	commitmentRules        CommitmentRules,
	signPolExtensions	SignPolExtensions
                             		OPTIONAL
                                                }

SigningPeriod ::= SEQUENCE {
	notBefore	GeneralizedTime,
	notAfter	GeneralizedTime OPTIONAL } ETS-ElectronicSignatureFormats-97Syntax


































ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC           [Page 63]

Internet Draft                                   Electronic Signature Formats




CommonRules  ::= SEQUENCE {
   	signerAndVeriferRules          [0]  SignerAndVerifierRules     
                                                          OPTIONAL,
	signingCertTrustCondition      [1]  SigningCertTrustCondition   
                                                          OPTIONAL,
	timeStampTrustCondition        [2]  TimestampTrustCondition     
                                                        OPTIONAL,
	attributeTrustCondition        [3]  AttributeTrustCondition     
                                                        OPTIONAL,
	algorithmConstraintSet         [4]  AlgorithmConstraintSet      
                                                         OPTIONAL, 
     	signPolExtensions	       [5]  SignPolExtensions		    
                                                         OPTIONAL
                                                                 }

CommitmentRules ::= SEQUENCE OF CommitmentRule

CommitmentRule  ::= SEQUENCE {
	selCommitmentTypes                  SelectedCommitmentTypes,
	signerAndVeriferRules          [0]  SignerAndVerifierRules      
                                                           OPTIONAL,
	signingCertTrustCondition      [1]  SigningCertTrustCondition   
                                                           OPTIONAL,
	timeStampTrustCondition        [2]  TimestampTrustCondition     
                                                           OPTIONAL,
	attributeTrustCondition        [3]  AttributeTrustCondition     
                                                           OPTIONAL,
	algorithmConstraintSet         [4]  AlgorithmConstraintSet      
                                                           OPTIONAL, 
	signPolExtensions	       [5]  SignPolExtensions		    
                                                            OPTIONAL
                                                                  }

SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
	empty                        NULL,
	recognizedCommitmentType     CommitmentType }

CommitmentType ::= SEQUENCE {
	identifier			CommitmentTypeIdentifier,
	fieldOfApplication	[0] FieldOfApplication OPTIONAL,
	semantics			[1] DirectoryString OPTIONAL }

SignerAndVerifierRules ::= SEQUENCE {
	signerRules      SignerRules,
	verifierRules    VerifierRules }







ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 64]

Internet Draft                                   Electronic Signature Formats



SignerRules ::= SEQUENCE {
	externalSignedData         BOOLEAN	OPTIONAL,
		      -- True if signed data is external to CMS structure 
		      -- False if signed data part of CMS structure
		      -- not present if either allowed
	mandatedSignedAttr         CMSAttrs,   
                      -- Mandated CMS signed attributes
	mandatedUnsignedAttr       CMSAttrs,   
                      -- Mandated CMS unsigned attributed
	mandatedCertificateRef     [0] CertRefReq DEFAULT signerOnly, 
		      -- Mandated Certificate Reference
	mandatedCertificateInfo    [1] CertInfoReq DEFAULT none,
		      -- Mandated Certificate Info
	signPolExtensions		 [2] SignPolExtensions
                                                OPTIONAL}

CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER

CertRefReq ::= ENUMERATED {
				signerOnly (1),		
-- Only reference to signer cert mandated
				fullPath (2)
-- References for full cert path up to a trust point required

					          }

CertInfoReq ::= ENUMERATED {
				none (0),
-- No mandatory requirements
				signerOnly (1),		
-- Only reference to signer cert mandated
				fullPath (2)	
-- References for full cert path up to a trust point mandated
                                                  }

VerifierRules ::= SEQUENCE {
		mandatedUnsignedAttr	MandatedUnsignedAttr,
		signPolExtensions	SignPolExtensions   OPTIONAL
		                                  }

MandatedUnsignedAttr ::=  CMSAttrs    
-- Mandated CMS unsigned attributed











ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 65]

Internet Draft                                   Electronic Signature Formats



CertificateTrustTrees ::=   SEQUENCE OF CertificateTrustPoint

CertificateTrustPoint ::= SEQUENCE {
	trustpoint				Certificate,                       
                            -- self-signed certificate
	pathLenConstraint	[0] PathLenConstraint   OPTIONAL,
	acceptablePolicySet	[1] AcceptablePolicySet OPTIONAL,  
                            -- If not present "any policy"
	nameConstraints		[2] NameConstraints     OPTIONAL, 
	policyConstraints	[3] PolicyConstraints   OPTIONAL }

PathLenConstraint    ::=   INTEGER (0..MAX) 

AcceptablePolicySet ::= SEQUENCE OF CertPolicyId

CertPolicyId ::= OBJECT IDENTIFIER

NameConstraints ::= SEQUENCE {
           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

      GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

      GeneralSubtree ::= SEQUENCE {
           base                    GeneralName,
           minimum         [0]     BaseDistance DEFAULT 0,
           maximum         [1]     BaseDistance OPTIONAL }

      BaseDistance ::= INTEGER (0..MAX)

PolicyConstraints ::= SEQUENCE {
        requireExplicitPolicy           [0] SkipCerts OPTIONAL,
        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

CertRevReq ::= SEQUENCE {
	endCertRevReq	RevReq,
	caCerts	  [0] RevReq
                             }

RevReq ::= SEQUENCE  { 
    enuRevReq  EnuRevReq,
    exRevReq    SignPolExtensions OPTIONAL}





ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 66]

Internet Draft                                   Electronic Signature Formats



EnuRevReq  ::= ENUMERATED {
	clrCheck	(0), --Checks must be made against current CRLs
	-- (or authority revocation lists)
	ocspCheck	(1), -- The revocation status must be checked
	-- using the Online Certificate Status Protocol (RFC 2450)
	bothCheck	(2),	
      -- Both CRL and OCSP checks must be carried out
	eitherCheck	(3),	
      -- At least one of CRL or OCSP checks must be carried out
	noCheck		(4),	
      -- no check is mandated
	other		(5)		
      -- Other mechanism as defined by signature policy extension
	                                        }

SigningCertTrustCondition ::=   SEQUENCE {
     signerTrustTrees              CertificateTrustTrees,
     signerRevReq                  CertRevReq
                                               }


TimestampTrustCondition ::= SEQUENCE {
    ttsCertificateTrustTrees	[0]		CertificateTrustTrees    
                                                        OPTIONAL,
    ttsRevReq			[1]		CertRevReq              
                                                        OPTIONAL,
    ttsNameConstraints  	[2]		NameConstraints         
                                                        OPTIONAL,
    cautionPeriod		[3]		DeltaTime               
                                                        OPTIONAL,
    signatureTimestampDelay	[4]		DeltaTime               
                                                       OPTIONAL }

DeltaTime ::= SEQUENCE {
	deltaSeconds	INTEGER,
	deltaMinutes	INTEGER,
	deltaHours	INTEGER,
	deltaDays	INTEGER }

AttributeTrustCondition ::= SEQUENCE {
	attributeMandated            BOOLEAN,              
                                -- Attribute must be present
	howCertAttribute             HowCertAttribute,
	attrCertificateTrustTrees   [0] CertificateTrustTrees  OPTIONAL, 
	attrRevReq                  [1] CertRevReq             OPTIONAL,
	attributeConstraints        [2] AttributeConstraints   OPTIONAL }


HowCertAttribute ::= ENUMERATED {
	claimedAttribute    (0),
	certifiedAttribtes  (1),
	either		    (2) }

ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 67]

Internet Draft                                   Electronic Signature Formats



AttributeConstraints ::= SEQUENCE {
	attributeTypeConstarints	[0] AttributeTypeConstraints  
                                                        OPTIONAL,
	attributeValueConstarints	[1] AttributeValueConstraints 
                                                       OPTIONAL }


AttributeTypeConstraints ::= SEQUENCE OF AttributeType 

AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue


AlgorithmConstraintSet ::= SEQUENCE {   -- Algorithm constrains on:
signerAlgorithmConstraints	[0] 	AlgorithmConstraints OPTIONAL, 
                                 -- signer
eeCertAlgorithmConstraints	[1] 	AlgorithmConstraints OPTIONAL, 
                                 -- issuer of end entity certs.
caCertAlgorithmConstraints	[2] 	AlgorithmConstraints OPTIONAL, 
                                 -- issuer of CA certificates
aaCertAlgorithmConstraints	[3] 	AlgorithmConstraints OPTIONAL, 
                                 -- Attribute Authority 
tsaCertAlgorithmConstraints	[4] 	AlgorithmConstraints OPTIONAL  
                                 -- TimeStamping Authority
			                            }

AlgorithmConstraints ::= SEQUENCE OF AlgAndLength

AlgAndLength ::= SEQUENCE {
	algID			OBJECT IDENTIFIER,
	minKeyLength	INTEGER 	OPTIONAL, 
                             -- Minimum key length in bits other
 		SignPolExtensions OPTIONAL
		 }

SignPolExtensions ::= SEQUENCE OF SignPolExtn

SignPolExtn ::= SEQUENCE {
        extnID      OBJECT IDENTIFIER,
		extnValue   OCTET STRING  }


END -- ETS-ElectronicSignature-88syntax --











ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 68]

Internet Draft                                   Electronic Signature Formats



A.2	Definitions Using X.680 1997 ASN.1 Syntax

NOTE:	The ASN.1 module defined in clause A.1 has precedence over that 
defined in clause A.2 in the case of any conflict.

ETS-ElectronicSignature-97Syntax { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 6}

DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS All -

IMPORTS

-- Crypographic Message Syntax (CMS): RFC 2630
	ContentInfo, ContentType, id-data, id-signedData, SignedData,
	EncapsulatedContentInfo, SignerInfo,
	id-contentType, id-messageDigest, MessageDigest, id-signingTime, 
      SigningTime, id-countersignature, Countersignature

   FROM CryptographicMessageSyntax
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
    smime(16) modules(0) cms(1) }
     

-- ESS Defined attributes: RFC 2634 (Enhanced Security Services
-- for S/MIME)
   id-aa-signingCertificate, SigningCertificate, IssuerSerial,
   id-aa-contentReference, ContentReference, 
   id-aa-contentIdentifier, ContentIdentifier
	FROM ExtendedSecurityServices
    { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }


-- Internet X.509 Public Key Infrastructure 
- - Certificate and CRL Profile:RFC 2459
      Certificate, AlgorithmIdentifier, CertificateList, Name, 
      GeneralNames, GeneralName, DirectoryString, Attribute,
      AttributeTypeAndValue, AttributeType, AttributeValue,
	PolicyInformation.

  FROM PKIX1Explicit93 
  	{iso(1) identified-organization(3) dod(6) internet(1)
   	security(5) mechanisms(5) pkix(7) id-mod(0) 
        id-pkix1-explicit-88(1)}

-- X.509 '97 Authentication Framework
        AttributeCertificate
        FROM AuthenticationFramework 
        {joint-iso-ccitt ds(5) module(1) authenticationFramework(7) 3}

ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 69]


Internet Draft                                   Electronic Signature Formats



-- OCSP 2560
      BasicOCSPResponse, ResponderID
	FROM OCSP 
--  { OID not assigned }




-- Time Stamp Protocol Internet Draft TimeStampToken
	FROM TSP 
-- { OID not assigned };


-- S/MIME Object Identifier arcs used in this document 
-- ==================================================================

-- S/MIME  OID arc used in this document
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 
--             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

-- S/MIME Arcs
-- id-mod  OBJECT IDENTIFIER ::= { id-smime 0 }   
-- modules
-- id-ct   OBJECT IDENTIFIER ::= { id-smime 1 }   
-- content types
-- id-aa   OBJECT IDENTIFIER ::= { id-smime 2 }   
-- attributes
-- id-spq  OBJECT IDENTIFIER ::= { id-smime 5 }   
-- signature policy qualifier
-- id-cti  OBJECT IDENTIFIER ::= { id-smime 6 }   
-- commitment type identifier


-- Definitions of Object Identifier arcs used in this document
-- ==================================================================


-- The allocation of OIDs to specific objects are given below with the 
-- associated ASN.1 syntax definition

-- OID used referencing electronic signature mechanisms based on this
-- standard for use with the IDUP API (see annex D)

id-etsi-es-IDUP-Mechanism-v1 OBJECT IDENTIFIER ::=
	{ itu-t(0) identified-organization(4) etsi(0) 
	   electronic-signature-standard (1733) part1 (1) 
         idupMechanism (4)etsiESv1(1) }






ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 70]

Internet Draft                                   Electronic Signature Formats




-- CMS Attributes Defined in this document
-- ==============================================

-- Mandatory Electronic Signature Attributes
-- OtherSigningCertificate

id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-aa(2) 19 }



OtherSigningCertificate ::=  SEQUENCE {
    certs        SEQUENCE OF OtherCertID,
    policies     SEQUENCE OF PolicyInformation OPTIONAL
                 -- NOT USED IN THIS DOCUMENT
    }

OtherCertID ::= SEQUENCE {
     otherCertHash            OtherHash,
     issuerSerial             IssuerSerial OPTIONAL }

OtherHash ::= CHOICE {
    sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
    otherHash OtherHashAlgAndValue}

OtherHashValue ::= OCTET STRING

OtherHashAlgAndValue ::= SEQUENCE {
	hashAlgorithm	AlgorithmIdentifier,
	hashValue		OtherHashValue }


-- Signature Policy Identifier

id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-aa(2) 15 }

SignaturePolicyIdentifier ::= SEQUENCE {
        sigPolicyIdentifier   SigPolicyId,
		sigPolicyHash         SigPolicyHash,
        sigPolicyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                SigPolicyQualifierInfo OPTIONAL}








ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 71]

Internet Draft                                   Electronic Signature Formats


SigPolicyId ::= OBJECT IDENTIFIER

SigPolicyHash ::= ETSIHashAlgAndValue

SigPolicyQualifierInfo ::= SEQUENCE {
        sigPolicyQualifierId       SIG-POLICY-QUALIFIER.&id
                                 ({SupportedSigPolicyQualifiers}),
        qualifier               SIG-POLICY-QUALIFIER.&Qualifier
                                ({SupportedSigPolicyQualifiers}
                                 {@sigPolicyQualifierId})OPTIONAL }

SupportedSigPolicyQualifiers SIG-POLICY-QUALIFIER ::= 
                           { noticeToUser | pointerToSigPolSpec }

SIG-POLICY-QUALIFIER ::= CLASS {
        &id             OBJECT IDENTIFIER UNIQUE,
        &Qualifier      OPTIONAL }

WITH SYNTAX {
        SIG-POLICY-QUALIFIER-ID     &id
        [SIG-QUALIFIER-TYPE &Qualifier] }

noticeToUser SIG-POLICY-QUALIFIER ::= {
      SIG-POLICY-QUALIFIER-ID id-sqt-unotice SIG-QUALIFIER-TYPE 
                   SPUserNotice 
                                  }

pointerToSigPolSpec SIG-POLICY-QUALIFIER ::= {
      SIG-POLICY-QUALIFIER-ID id-sqt-uri SIG-QUALIFIER-TYPE SPuri }


    id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-spq(5) 1 }

   SPuri ::= IA5String

	id-spq-ets-unotice OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
    smime(16) id-spq(5) 2 }

   SPUserNotice ::= SEQUENCE {
        noticeRef        NoticeReference OPTIONAL,
        explicitText     DisplayText OPTIONAL}

   NoticeReference ::= SEQUENCE {
        organization     DisplayText,
        noticeNumbers    SEQUENCE OF INTEGER }

   DisplayText ::= CHOICE {
        visibleString    VisibleString  (SIZE (1..200)),
        bmpString        BMPString      (SIZE (1..200)),
        utf8String       UTF8String     (SIZE (1..200)) }

ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 72]

Internet Draft                                   Electronic Signature Formats



-- Optional Electronic Signature Attributes

-- Commitment Type

id-aa-ets-commitmentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 16}

CommitmentTypeIndication ::= SEQUENCE {
  commitmentTypeId CommitmentTypeIdentifier,
  commitmentTypeQualifier SEQUENCE SIZE (1..MAX) OF 
                                           CommitmentTypeQualifier 
                                           OPTIONAL}

CommitmentTypeIdentifier ::= OBJECT IDENTIFIER

CommitmentTypeQualifier ::= SEQUENCE {
        commitmentQualifierId       COMMITMENT-QUALIFIER.&id,
        qualifier                   COMMITMENT-QUALIFIER.&Qualifier 
                                                  OPTIONAL }

COMMITMENT-QUALIFIER ::= CLASS {
                    &id             OBJECT IDENTIFIER UNIQUE,
                    &Qualifier      OPTIONAL }
WITH SYNTAX {
         COMMITMENT-QUALIFIER-ID     &id
                        [COMMITMENT-TYPE &Qualifier] }

	id-cti-ets-proofOfOrigin OBJECT IDENTIFIER ::= { iso(1) 
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
      smime(16) cti(6) 1}

	id-cti-ets-proofOfReceipt OBJECT IDENTIFIER ::= { iso(1)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) cti(6) 2}

	id-cti-ets-proofOfDelivery OBJECT IDENTIFIER ::= { iso(1)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) cti(6) 3}

	id-cti-ets-proofOfSender OBJECT IDENTIFIER ::= { iso(1)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) cti(6) 4}

	id-cti-ets-proofOfApproval OBJECT IDENTIFIER ::= { iso(1)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
      smime(16) cti(6) 5}

	id-cti-ets-proofOfCreation OBJECT IDENTIFIER ::= { iso(1)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) cti(6) 6}



ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 73]

Internet Draft                                   Electronic Signature Formats


-- Signer Location

id-aa-ets-signerLocation OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 17}

SignerLocation ::= SEQUENCE {
                       -- at least one of the following must be present
			countryName [0] DirectoryString OPTIONAL, 
				-- As used to name a Country in X.500
		localityName [1] DirectoryString OPTIONAL, 
 				-- As used to name a locality in X.500
			postalAdddress [2] PostalAddress OPTIONAL }
	
	PostalAddress ::= SEQUENCE SIZE(1..6) OF DirectoryString


-- Signer Attributes

id-aa-ets-signerAttr OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 18}

SignerAttribute ::= SEQUENCE OF CHOICE {
			claimedAttributes	[0] ClaimedAttributes,
			certifiedAttributes [1] CertifiedAttributes }



ClaimedAttributes ::= SEQUENCE OF Attribute 

CertifiedAttributes ::= AttributeCertificate  
-- As defined in X.509 : see section 10.3


-- Content Timestamp

id-aa-ets-contentTimestamp OBJECT IDENTIFIER ::= { iso(1)
      member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
      smime(16) id-aa(2) 20}

ContentTimestamp::= TimeStampToken


-- Validation Data

-- Signature Timestamp

id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= { iso(1)
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
     smime(16) id-aa(2) 14}

SignatureTimeStampToken ::= TimeStampToken



ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 74]

Internet Draft                                   Electronic Signature Formats


-- Complete Certificate Refs.

id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21}

CompleteCertificateRefs ::=  SEQUENCE OF ETSICertID


-- Complete Revocation Refs

id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22}

CompleteRevocationRefs ::=  SEQUENCE OF CrlOcspRef

CrlOcspRef ::= SEQUENCE {
    crlids           [0] CRLListID   OPTIONAL,
    ocspids          [1] OcspListID  OPTIONAL,
	otherRev	   [2] OtherRevRefs OPTIONAL
                                          }

CRLListID ::=  SEQUENCE {
    crls        SEQUENCE OF CrlValidatedID}

CrlValidatedID ::=  SEQUENCE {
     crlHash                   ETSIHash, 
     crlIdentifier             CrlIdentifier OPTIONAL}

CrlIdentifier ::= SEQUENCE {
    crlissuer                 Name,
    crlIssuedTime             UTCTime,
    crlNumber                 INTEGER OPTIONAL
                                            }



OcspListID ::=  SEQUENCE {
    ocspResponses        SEQUENCE OF OcspResponsesID}

OcspResponsesID ::=  SEQUENCE {
    ocspIdentifier              OcspIdentifier,
    ocspRepHash                 ETSIHash    OPTIONAL
                                            }

OcspIdentifier ::= SEQUENCE {
	ocspResponderID		ResponderID,	
                        -- As in OCSP response data
	producedAt			GeneralizedTime 
                        -- As in OCSP response data
                                             }




ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 75]

Internet Draft                                   Electronic Signature Formats



OtherRevRefs ::= SEQUENCE {
 	otherRevRefType	OTHER-REVOCATION-REF.&id,
	otherRevRefs	OTHER-REVOCATION-REF.&Type
                                              }

OTHER-REVOCATION-REF ::= CLASS {
		&Type, 
		&id	OBJECT IDENTIFIER UNIQUE }
	WITH SYNTAX { 
		&Type ID &id }


-- Certificate Values

id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23}

CertificateValues ::=  SEQUENCE OF Certificate

-- Certificate Revocation Values

id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1)
     member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
     smime(16) id-aa(2) 24}

RevocationValues ::=  SEQUENCE {
   crlVals          [0] SEQUENCE OF CertificateList OPTIONAL,
   ocspVals         [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,
   otherRevVals	    [2] OtherRevVals }

OtherRevVals ::= SEQUENCE {
 	otherRevValType	OTHER-REVOCATION-VAL.&id,
	otherRevVals	OTHER-REVOCATION-VAL.&Type
                                               }

OTHER-REVOCATION-VAL ::= CLASS {
		&Type, 
		&id	OBJECT IDENTIFIER UNIQUE }
	WITH SYNTAX { 
		&Type ID &id }


-- ES-C Timestamp

id-aa-ets-escTimeStamp OBJECT IDENTIFIER ::= { iso(1)
     member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
     smime(16) id-aa(2) 25}

ESCTimeStampToken ::= TimeStampToken




ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 76]

Internet Draft                                   Electronic Signature Formats


-- Time-Stamped Certificates and CRLs

id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1)
    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
    smime(16) id-aa(2) 26}

TimestampedCertsCRLs ::= TimeStampToken


-- Archive Timestamp

id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1)
   member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
   smime(16) id-aa(2) 27}

ArchiveTimeStampToken ::= TimeStampToken


-- Signature Policy Specification
-- ==============================

SignaturePolicy ::= SEQUENCE {
	signPolicyHashAlg      AlgorithmIdentifier, 
	signPolicyInfo         SignPolicyInfo, 
	signPolicyHash         SignPolicyHash     OPTIONAL }

SignPolicyHash ::= OCTET STRING

SignPolicyInfo ::= SEQUENCE {
	signPolicyIdentifier            SignPolicyId,
	dateOfIssue                     GeneralizedTime,
	policyIssuerName                PolicyIssuerName,
	fieldOfApplication              FieldOfApplication,
	signatureValidationPolicy 	SignatureValidationPolicy,
	signPolExtensions		SignPolExtensions	
	                                                OPTIONAL
	                                                       }

SignPolicyId ::= OBJECT IDENTIFIER

PolicyIssuerName ::= GeneralNames

FieldOfApplication ::= DirectoryString 



SignatureValidationPolicy ::= SEQUENCE {
	signingPeriod          SigningPeriod,
	commonRules            CommonRules,
	commitmentRules        CommitmentRules,
	signPolExtensions      SignPolExtensions   OPTIONAL
                                                       }


ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 77]

Internet Draft                                   Electronic Signature Formats


SigningPeriod ::= SEQUENCE {
	notBefore	GeneralizedTime,
	notAfter	GeneralizedTime OPTIONAL }

CommonRules  ::= SEQUENCE {
	signerAndVeriferRules          [0]  SignerAndVerifierRules     
                                                         OPTIONAL,
	signingCertTrustCondition      [1]  SigningCertTrustCondition   
                                                         OPTIONAL,
	timeStampTrustCondition        [2]  TimestampTrustCondition     
                                                         OPTIONAL,
	attributeTrustCondition        [3]  AttributeTrustCondition     
                                                         OPTIONAL,
	algorithmConstraintSet         [4]  AlgorithmConstraintSet      
                                                         OPTIONAL, 
	signPolExtensions	       [5]  SignPolExtensions		    
                                                         OPTIONAL
                                                        }

CommitmentRules ::= SEQUENCE OF CommitmentRule

CommitmentRule  ::= SEQUENCE {
	selCommitmentTypes                  SelectedCommitmentTypes,
	signerAndVeriferRules          [0]  SignerAndVerifierRules      
                                                         OPTIONAL,
	signingCertTrustCondition      [1]  SigningCertTrustCondition   
                                                         OPTIONAL,
	timeStampTrustCondition        [2]  TimestampTrustCondition     
                                                         OPTIONAL,
	attributeTrustCondition        [3]  AttributeTrustCondition     
                                                         OPTIONAL,
	algorithmConstraintSet         [4]  AlgorithmConstraintSet      
                                                         OPTIONAL, 
	signPolExtensions	       [5]  SignPolExtensions		    
                                                         OPTIONAL
                                                              }

SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
	empty                        NULL,
	recognizedCommitmentType     CommitmentType }

CommitmentType ::= SEQUENCE {
	identifier			CommitmentTypeIdentifier,
	fieldOfApplication	[0] FieldOfApplication OPTIONAL,
	semantics		[1] DirectoryString OPTIONAL }

SignerAndVerifierRules ::= SEQUENCE {
	signerRules      SignerRules,
	verifierRules    VerifierRules }





ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 78]

Internet Draft                                   Electronic Signature Formats




SignerRules ::= SEQUENCE {
	externalSignedData         BOOLEAN	OPTIONAL,
		      -- True if signed data is external to CMS structure 
			-- False if signed data part of CMS structure
			-- not present if either allowed
	mandatedSignedAttr         CMSAttrs,    
                  -- Mandated CMS signed attributes
	mandatedUnsignedAttr       CMSAttrs,    
                  -- Mandated CMS unsigned attributed
	mandatedCertificateRef     [0] CertRefReq DEFAULT signerOnly, 
			-- Mandated Certificate Reference
	mandatedCertificateInfo    [1] CertInfoReq DEFAULT none,
			-- Mandated Certificate Info
	signPolExtensions		 [2] SignPolExtensions	OPTIONAL
                                                      }

CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER

CertRefReq ::= ENUMERATED {
				signerOnly (1),		
                   -- Only reference to signer cert mandated
				fullPath (2)	
                   -- References for full cert path up to a trust
                   -- point required
									}

CertInfoReq ::= ENUMERATED {
				none (0)	,			
                   -- No mandatory requirements
				signerOnly (1)	,		
                   -- Only reference to signer cert mandated
				fullPath (2)	
			 -- References for full cert path up to a
                   -- trust point mandated
		                                          }

VerifierRules ::= SEQUENCE {
		mandatedUnsignedAttr	MandatedUnsignedAttr,
		signPolExtensions		SignPolExtensions		OPTIONAL
		}

MandatedUnsignedAttr ::=  CMSAttrs    
                          -- Mandated CMS unsigned attributed









ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 79]

Internet Draft                                   Electronic Signature Formats




CertificateTrustTrees ::=   SEQUENCE OF CertificateTrustPoint

CertificateTrustPoint ::= SEQUENCE {
	trustpoint				Certificate,                       
                          -- self-signed certificate
	pathLenConstraint	[0] PathLenConstraint   OPTIONAL,
	acceptablePolicySet	[1] AcceptablePolicySet OPTIONAL,  
                          -- If not present "any policy"
	nameConstraints		[2] NameConstraints     OPTIONAL, 
	policyConstraints	[3] PolicyConstraints   OPTIONAL }

PathLenConstraint    ::=   INTEGER (0..MAX) 


AcceptablePolicySet ::= SEQUENCE OF CertPolicyId

CertPolicyId ::= OBJECT IDENTIFIER

NameConstraints ::= SEQUENCE {
           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

      GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

      GeneralSubtree ::= SEQUENCE {
           base                    GeneralName,
           minimum         [0]     BaseDistance DEFAULT 0,
           maximum         [1]     BaseDistance OPTIONAL }

      BaseDistance ::= INTEGER (0..MAX)

PolicyConstraints ::= SEQUENCE {
        requireExplicitPolicy           [0] SkipCerts OPTIONAL,
        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

CertRevReq ::= SEQUENCE {
	endCertRevReq	RevReq,
	caCerts	     [0] RevReq
                                          }

RevReq ::= SEQUENCE  { 
    enuRevReq  EnuRevReq,
    exRevReq    SignPolExtensions OPTIONAL}







ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 80]

Internet Draft                                   Electronic Signature Formats



EnuRevReq  ::= ENUMERATED {
	clrCheck	(0), 
                   -- Checks must be made against current CRLs
                   -- (or authority revocation lists)
	ocspCheck	(1), 
                   -- The revocation status must be checked using
                   -- the Online Certificate Status Protocol (RFC 2450)
	bothCheck	(2),	
                   -- Both CRL and OCSP checks must be carried out
	eitherCheck	(3),	
                   -- At least one of CRL or OCSP checks must be carried out
	noCheck		(4),	
                   -- no check is mandated
	other		(5)		
                   -- Other mechanism as defined by signature poilicy
                   -- extension
	                                      }

SigningCertTrustCondition ::=   SEQUENCE {
     signerTrustTrees              CertificateTrustTrees,
     signerRevReq                  CertRevReq
                                              }


TimestampTrustCondition ::= SEQUENCE {
    ttsCertificateTrustTrees	[0]		CertificateTrustTrees    
                                                       OPTIONAL,
    ttsRevReq			[1]		CertRevReq              
                                                       OPTIONAL,
    ttsNameConstraints  	[2]		NameConstraints         
                                                       OPTIONAL,
    cautionPeriod		[3]		DeltaTime               
                                                       OPTIONAL,
    signatureTimestampDelay	[4]		DeltaTime               
                                                      OPTIONAL }

DeltaTime ::= SEQUENCE {
	deltaSeconds	INTEGER,
	deltaMinutes	INTEGER,
	deltaHours	INTEGER,
	deltaDays	INTEGER }

AttributeTrustCondition ::= SEQUENCE {
	attributeMandated            BOOLEAN,              
                               -- Attribute must be present
	howCertAttribute             HowCertAttribute,
	attrCertificateTrustTrees   [0] CertificateTrustTrees  OPTIONAL, 
	attrRevReq                  [1] CertRevReq             OPTIONAL,
	attributeConstraints        [2] AttributeConstraints   OPTIONAL }




ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 81]

Internet Draft                                   Electronic Signature Formats



HowCertAttribute ::= ENUMERATED {
	claimedAttribute	(0),
	certifiedAttribtes	(1),
	either			(2) }

AttributeConstraints ::= SEQUENCE {
	attributeTypeConstarints	[0] AttributeTypeConstraints  
                                                       OPTIONAL,
	attributeValueConstarints	[1] AttributeValueConstraints 
                                                       OPTIONAL }


AttributeTypeConstraints ::= SEQUENCE OF AttributeType 

AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue


AlgorithmConstraintSet ::= SEQUENCE {  
                               -- Algorithm constrains on:
signerAlgorithmConstraints	[0] 	AlgorithmConstraints OPTIONAL, 
                                -- signer
eeCertAlgorithmConstraints	[1] 	AlgorithmConstraints OPTIONAL, 
                                -- issuer of end entity certs.
caCertAlgorithmConstraints	[2] 	AlgorithmConstraints OPTIONAL, 
                                -- issuer of CA certificates
aaCertAlgorithmConstraints	[3] 	AlgorithmConstraints OPTIONAL, 
                                -- Attribute Authority 
tsaCertAlgorithmConstraints	[4] 	AlgorithmConstraints OPTIONAL  
                                -- TimeStamping Authority
	                                     		 }


AlgorithmConstraints ::= SEQUENCE OF AlgAndLength

AlgAndLength ::= SEQUENCE {
	algID		OBJECT IDENTIFIER,
	minKeyLength	INTEGER 	OPTIONAL, 
                               -- Minimum key length in bits
	other 		SignPolExtensions OPTIONAL
                                        		 }

SignPolExtensions ::= SEQUENCE OF SignPolExtn

SignPolExtn ::= SEQUENCE {
        extnID      OBJECT IDENTIFIER,
	extnValue   OCTET STRING  }

END                           -- ETS-ElectronicSignature-97Syntax





ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 82]

Internet Draft                                   Electronic Signature Formats

Annex B (informative):

General Description

This annex captures the concepts that apply to this document and the 
rational for the elements of the specification defined using ASN.1 in 
the main text of this document.

The specification below includes a description why the component is 
needed, with a brief description of the vulnerabilities and threats and 
the manner by which they are countered. 

B.1	The Signature Policy

The signature policy is a set of rules for the creation and validation 
of an electronic signature, under which the signature can be determined 
to be valid. A given legal/contractual context may recognize a 
particular signature policy as meeting its requirements. A signature 
policy may be issued, for example, by a party relying on the electronic 
signatures and selected by the signer for use with that relying party. 
Alternatively, a signature policy may be established through an 
electronic trading association for use amongst its members. Both the 
signer and verifier use the same signature policy. 

A signature policy has a globally unique reference, which is bound to 
an electronic signature by the signer as part of the signature 
calculation.

The signature policy needs to be available in human readable form so 
that it can be assessed to meet the requirements of the legal and 
contractual context in which it is being applied. To facilitate the 
automatic processing of an electronic signature the parts of the 
signature policy which specify the electronic rules for the creation 
and validation of the electronic signature also needs to be in a 
computer processable form.

The signature policy thus includes the following:

     * Rules, which apply to functionality, covered by this document 
       (referred to as the Signature Validation Policy).
     * Rules which may be implied through adoption of Certificate 
       Policies that apply to the electronic signature (e.g. rules for
       ensuring the secrecy of the private signing key).
     * Rules, which relate to the environment used by the signer,
       e.g. the use of an agreed CAD (Card Accepting Device) used 
       in conjunction with a smart card.

The Signature Validation Policy may be structured so that it can be 
computer processable. The current document includes, as an option, a 
formal structure for the signature validation policy based on the used 
of Abstract Syntax Notation 1 (ASN.1). Other formats of the signature 
validation policy are allowed by this document. However, for a given 
signature policy there must be one definitive form that has a unique 
binary encoded value.

ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 83]

Internet Draft                                   Electronic Signature Formats

The Signature Validation Policy includes rules regarding use of TSPs 
(CA, Attribute Authorities, Time Stamping Authorities) as well as rules 
defining the components of the electronic signature that must be 
provided by the signer with data required by the verifier to provide 
long term proof. 


B.2	Signed Information

The information being signed may be defined as a MIME-encapsulated 
message which can be used to signal the format of the content in order 
to select the right display or application. It can be composed of 
formatted text (e.g. EDIFACT), free text or of fields from an 
electronic form (e-form). For example, the Adobe(tm) format "pdf" may 
be used or the eXtensible Mark up Language (XML). 


B.3	Components of an Electronic Signature 

B.3.1	Reference to the Signature Policy

The definition of electronic signature includes: "a 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". 

When two independent parties want to evaluate an electronic signature, 
it is fundamental that they get the same result. To meet this 
requirement the technical components and technical aspects used in 
creating the signature must be referenced, this is provided by a 
reference to the "Signature Validation Policy". The "Signature 
Validation Policy" defines:

    * the components of an electronic signature to be provided by the 
       signer;
    * any additional components (i.e. verifier components) used to 
      validate an electronic signature at the time of receipt by a
      verifier and later by an arbitrator, auditor or other 
      independent parties. 

By signing over the signature policy identifier, the algorithm 
identifier and the hash of the signature policy, the signer explicitly 
indicates that he or she has applied the signature policy in creating 
the signature. Thus, undertakes any commitments implied by the 
signature policy, any indication of commitment type included in the 
electronic signature, and the user data that is signed. 

The hash algorithm identifier and value is included to ensure that both 
the signer and verifier use exactly the same signature policy. This 
unambiguously binds the signer and verifier to same definitive form of 
the signature policy has a unique binary encoding.




ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 84]

Internet Draft                                   Electronic Signature Formats



In order to identify unambiguously the "Signature Validation Policy" to 
be used to verify the signature an identifier and hash of the 
"Signature policy" must be part of the signed data. Additional 
information about the policy (e.g. web reference to the document) may 
be carried as "qualifiers" to the signature policy identifier


B.3.2	Commitment Type Indication

The definition of electronic signature includes: "a 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 commitment type can be indicated in the electronic signature 
either:

      * explicitly using a "commitment type indication" in the
        electronic signature;

      * implicitly or explicitly from the semantics of the signed data.

If the indicated commitment type is explicit using a "commitment type 
indication" in the electronic signature , acceptance of a verified 
signature implies acceptance of the semantics of that commitment type. 
The semantics of explicit commitment types indications must be 
specified either as part of the signature policy or may be registered 
for generic use across multiple policies.

If a signature includes a commitment type indication other than one of 
those recognized under the signature policy the signature must be 
treated as invalid.

How commitment is indicated using the semantics of the data being 
signed is outside the scope of this document.

NOTE:	Examples of commitment indicated through the semantics of the 
data being signed, are:

     * An explicit commitment made by the signer indicated by the type 
       of data being signed over.  Thus, the data structure being 
       signed can have an explicit commitment within the context of the 
       application (e.g. EDIFACT purchase order).

     * An implicit commitment which is a commitment made by the signer 
       because the data being signed over has specific semantics
      (meaning) which is only interpretable by humans, 
      (i.e. free text).




ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 85]

Internet Draft                                   Electronic Signature Formats


B.3.4	Certificate Identifier from the Signer

The definition of the ETSI electronic signature includes: "a 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."

In many real life environments users will be able to get from different 
CAs or even from the same CA, different certificates containing the 
same public key for different names. The prime advantage is that a user 
can use the same private key for different purposes. Multiple use of 
the private key is an advantage when a smart card is used to protect 
the private key, since the storage of a smart card is always limited. 
When several CAs are involved, each different certificate may contain a 
different identity, e.g. as a national or as an employee from a 
company. Thus when a private key is used for various purposes, the 
certificate is needed to clarify the context in which the private key 
was used when generating the signature. Where there is the possibility 
of multiple use of private keys it is necessary for the 
signer to indicate to the verifier the precise certificate to be used.

Many current schemes simply add the certificate after the signed data 
and thus are subject to various substitution attacks. An example of a 
substitution attack is a "bad" CA that would issue a certificate to 
someone with the public key of someone else. If the certificate from 
the signer was simply appended to the signature and thus not protected 
by the signature, any one could substitute one certificate by another 
and the message would appear to be signed by some one else. 

In order to counter this kind of attack, the identifier of the signer 
has to be protected by the digital signature from the signer.

Although it does not provide the same advantages as the previous 
technique, another technique to counter that threat has been 
identified. It requires all CAs to perform a Proof Of Possession of the 
private key at the time of registration. The problem with that 
technique is that it does not provide any guarantee at the time of 
verification and only some proof "after the event" may be obtained, if 
and only if the CA keeps the Proof Of Possession in audit trail.

In order to identify unambiguously the certificate to be used for the 
verification of the signature an identifier of the certificate from the 
signer must be part of the signed data.

B.3.5	Role Attributes

The definition of electronic signature includes: "a commitment has been 
explicitly endorsed under a non repudiation security policy, at a given 
time, by a signer under an identifier, e.g. a name or a pseudonym, and 
optionally a role. "


ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 86]

Internet Draft                                   Electronic Signature Formats



While the name of the signer is important, the position of the signer 
within a company or an organization can be even more important. Some 
contracts may only be valid if signed by a user in a particular role, 
e.g. a Sales Director. In many cases whom the sales Director really is, 
is not that important but being sure that the signer is empowered by 
his company to be the Sales Director is fundamental.

This document defines two different ways for providing this feature:

      * by placing a claimed role name in the CMS signed 
        attributes field;
     * by placing a attribute certificate containing a certified 
       role name in the CMS signed attributes field.

NOTE:	Another possible approach would have been to use additional 
attributes containing the roles name(s) in the signer's certificate. 
However, it was decided not to follow this approach as it breaks the 
basic philosophy of the certificate being issued for one primary 
purpose. Also, by using separate certificates for management of the 
signer's identity certificate and management of additional roles can 
simplify the management, as new identity keys need not be issued if a 
use of role is to be changed.

B.3.5.1	Claimed Role

The signer may be trusted to state his own role without any certificate 
to corroborate this claim. In which case the claimed role can be added 
to the signature as a signed attribute.

B.3.5.2	Certified Role

Unlike public key certificates that bind an identifier to a public key, 
Attribute Certificates bind the identifier of a certificate to some 
attributes, like a role. An Attribute Certificate is NOT issued by a CA 
but by an Attribute Authority (AA). The Attribute Authority will be 
most of the time under the control of an organization or a company that 
is best placed to know which attributes are relevant for which 
individual. The Attribute Authority may use or point to public key 
certificates issued by any CA, provided that the appropriate trust may 
be placed in that CA. Attribute Certificates may have various periods 
of validity. That period may be quite short, e.g. one day. While this 
requires that a new Attribute Certificate is obtained every day, valid 
for that day, this can be advantageous since revocation of such 
certificates may not be needed. When signing, the signer will have to 
specify which Attribute Certificate it selects. In order to do 
so, the Attribute Certificate will have to be included in the signed 
data in order to be protected by the digital signature from the signer.






ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 87]

Internet Draft                                   Electronic Signature Formats

In order to identify unambiguously the attribute certificate(s) to be 
used for the verification of the signature an identifier of the 
attribute certificate(s) from the signer must be part of the signed 
data.

B.3.6	Signer Location

In some transactions the purported location of the signer at the time 
he or she applies his signature may need to be indicated. For this 
reason an optional location indicator must be able to be included.

In order to provide indication of the location of the signer at the 
time he or she applied his signature a  location attribute may be 
included in the signature.

B.3.7	Signing Time

The definition of electronic signature includes: "a 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. "

There are several ways to address this problem. The solution adopted in 
this document is to sign over a time which the signer claims is the 
signing time (i.e. claimed signing time) and to require  a trusted time 
stamp to be obtained when building a ES with Timestamp. When a verifier 
accepts a signature, the two times must be within acceptable limits. 

The solution that is adopted in this document offers the major 
advantage that electronic signatures can be generated without any on-
line connection to a trusted time source (i.e. they may be generated 
off-line).

Thus two dates and two signatures are required: 
     * a signing time indicated by the signer and which is part of 
       the data signed by the signer (i.e. part of the basic electronic 
       signature);
     * a time indicated by a TimeStamping Authority (TSA) which is 
       signed over the digital signature value of the basic electronic
       signature. The signer, verifier or both may obtain the TSA
       timestamp.

In order for an electronic signature to be valid under a signature 
policy, it must be timestamped by a TSA where the signing time as 
indicated by the signer and the time of time stamping as indicated by a 
TSA must be "close enough" to meet the requirements of the signature 
validation policy. 

"Close enough" means a few minutes, hours or even days according to the 
"Signature Validation Policy". 





ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 88]

Internet Draft                                   Electronic Signature Formats


NOTE:	The need for Timestamping is further explained in clause B.4.5.
A further optional attribute is defined in this document to timestamp 
the content, to provide proof of the existence of the content, at the 
time indicated by the timestamp.

Using this optional attribute a trusted secure time may be obtained 
before the document is signed and included under the digital signature. 
This solution requires an on-line connection to a trusted timestamping 
service before generating the signature and may not represent the 
precise signing time, since it can be obtained in advance.  However, 
this optional attribute may be used by the signer to prove that the 
signed object existed before the  date included in the timestamp (see 
4.12.3, Content Timestamp).

Also, the signing time should be between the time indicated by this 
timestamp and time indicated by the ES-T timestamp.

B.4	Components of Validation Data

B.4.1	Revocation Status Information

A verifier will have to prove that the certificate of the signer was 
valid at the time of the signature. This can be done by either:
     * using Certificate Revocation Lists (CRLs);
     * using responses from an on-line certificate status server 
       (for example; obtained through the OCSP protocol).

B.4.2	CRL Information

When using CRLs to get revocation information, a verifier will have to 
make sure that he or she gets at the time of the first verification the 
appropriate certificate revocation information from the signer's CA. 
This should be done as soon as possible to minimize the time delay 
between the generation and verification of the signature. This involves 
checking that the signer certificate serial number is not included in 
the CRL. The signer, the verifier or any other third party may obtain 
either this CRL. If obtained by the signer, then it must be conveyed 
to the verifier. It may be convenient to archive the CRL for ease of 
subsequent verification or arbitration. 


Alternatively, provided the CRL is archived elsewhere which is 
accessible for the purpose of arbitration, then the serial number of 
the CRL used may be archived together with the verified electronic 
signature.









ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 89]

Internet Draft                                   Electronic Signature Formats

It may happen that the certificate serial number appears in the CRL but 
with the status "suspended" (i.e. on hold). In such a case, the 
electronic signature is not yet valid, since it is not possible to know 
whether the certificate will or will not be revoked at the end of the 
suspension period. If a decision has to be taken immediately then the 
signature has to be considered as invalid. If a decision can wait until 
the end of the suspension period, then two cases are possible:

     * the certificate serial number has disappeared from the list 
       and thus the certificate can be considered as valid and that CRL 
       must be captured and archived either by the verifier or 
       elsewhere and be kept accessible for the purpose of arbitration.

     * the certificate serial number has been maintained on the list 
       with the status definitively revoked and thus the electronic 
       signature must be considered as invalid and discarded.

At this point the verifier may be convinced that he or she got a valid 
signature, but is not yet in a position to prove at a later time that 
the signature was verified as valid. Before addressing this point, an 
alternative to CRL is to use OCSP responses.


B.4.3	OCSP Information

When using OCSP to get revocation information , a verifier will have to 
make sure that he or she gets at the time of the first verification an 
OCSP response that contains the status "valid". This should be done as 
soon as possible after the generation of the signature. The signer, the 
verifier or any other third party may fetch this OCSP response. Since 
OSCP responses are transient and thus are not archived by any TSP 
including CA, it is RFC       [Page 60]
Internet Draft                             Electronic Signature Formats

Annex B (informative): General Description

This annex captures the responsibility of every verifier to make sure concepts that it is stored in a safe place. The simplest way is to store them 
associated with the electronic signature. An alternative would be apply to 
store them in some storage so that they can then be easily retrieved. 

In this document and the same way as 
rational for the case elements of the CRL, it may happen that the 
certificate is declared as invalid but with specification defined using ASN.1 in 
the secondary status 
"suspended". 

In such main text of this document.

The specification below includes a case, description why the electronic signature is not yet valid, since it component is 
not possible to know whether the certificate will or will not be 
revoked at the end 
needed, with a brief description of the suspension period. If a decision has to be 
taken immediately then vulnerabilities and threats 
and the electronic manner by which they are countered. 

B.1  The Signature Policy

The signature has to be considered as 
invalid. If policy is a decision can wait until the end set of rules for the suspension period, 
then two cases are possible:

     * An OCSP response with a valid status is obtained at a later date creation and thus validation 
of an electronic signature, under which the certificate signature can be considered 
determined to be valid. A given legal/contractual context may 
recognize a particular signature policy as valid and that
       OCSP response must meeting its requirements. 
A signature policy may be captured.

     * An OCSP response with an invalid status is obtained with issued, for example, by a 
       secondary status indicating that party relying on 
the certificate is definitively 
       revoked electronic signatures and thus selected by the electronic signer for use with that 
relying party. Alternatively, a signature must policy may be considered as 
       invalid and discarded.

ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 90]

Internet Draft                                   Electronic Signature Formats


As in the CRL case, at this point, established 
through an electronic trading association for use amongst its members. 
Both the signer and verifier may be convinced that 
he or she got a valid signature, but is not yet in a position to prove 
at a later time that use the same signature was verified as valid. 

B.4.4	Certification Path policy. 

A verifier will have signature policy has a globally unique reference, which is bound to prove that the certification path was valid, at 
an electronic signature by the time signer as part of the signature, up signature 
calculation.

The signature policy needs to a trust point according be available in human readable form so 
that it can be assessed to meet the naming 
constraints requirements of the legal and 
contractual context in which it is being applied. To facilitate the certificate policy constraints from 
automatic processing of an electronic signature the "Signature 
Validation Policy". It will be necessary to capture all parts of the 
certificates from 
signature policy which specify the certification path, starting with those from electronic rules for the 
signer creation 
and ending up with those validation of the self-signed certificate from one 
trusted root of electronic signature also needs to be in a 
computer processable form.

The signature policy thus includes the "Signature Validation Policy". In addition, it will following:

     * Information about the signature policy that can be necessary displayed 
       to capture the Authority Revocation Lists (ARLs) signer or the verifiers.
     * Rules, which apply to prove 
than none of functionality, covered by this document 
       (referred to as the CAs from Signature Validation Policy).
     * Rules which may be implied through adoption of Certificate 
       Policies that apply to the chain was revoked at electronic signature (e.g. rules for
       ensuring the time secrecy of the 
signature.

As in private signing key).
     * Rules, which relate to the OCSP case, at this point, environment used by the verifier may be convinced that 
he or she got a valid signature, but is not yet signer,
       e.g. the use of an agreed CAD (Card Accepting Device) used 
       in conjunction with a position to prove 
at a later time smart card.

The Signature Validation Policy may be structured so that it can be 
computer processable. Any format of the signature was verified as valid. 

B.4.5	Timestamping for Long Life of Signature

An important property for long standing signatures validation policy 
is that allowed by this document. However, for a signature, 
having been found once to be valid, given signature policy 
there must continue to be so months or 
years later. 

A signer, verifier or both may be required to provide on request, proof one definitive form that has a digital signature was created or verified during the validity 
period unique binary encoded 
value.



ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 61]
Internet Draft                             Electronic Signature Formats


The Signature Validation Policy includes rules regarding use of TSPs 
(CA, Attribute Authorities, Time Stamping Authorities) as well as 
rules defining the all the certificates that make up the certificate path. 
In this case, components of the signer, verifier or both will also electronic signature that must be 
provided by the signer with data required by the verifier to provide proof that all the user and CA certificates used were not 
revoked when the signature was created or verified. 

It would 
long term proof. 

B.2  Signed Information

The information being signed may be quite unacceptable, to consider a signature defined as invalid even 
if the keys or certificates were later compromised. Thus there is a 
need to MIME-encapsulated 
message which can be able used to demonstrate that the signature keys was valid around signal the time that format of the signature was created content in order 
to provide long term evidence 
of select the validity of a signature. right display or application. It could can be the case that a certificate was valid at the time composed of 
formatted text (e.g. EDIFACT), free text or of fields from an 
electronic form (e-form). For example, the 
signature but revoked some time later. In this event, evidence must Adobe(tm) format "pdf" may 
be 
provided that the document was signed before the signing key was 
revoked. 

Timestamping by a Time Stamping Authority (TSA) can provide such 
evidence. A time stamp is obtained by sending used or the hash value eXtensible Mark up Language (XML). 

B.3  Components of the 
given data an Electronic Signature 

B.3.1  Reference to the TSA. Signature Policy

The returned "timestamp" definition of electronic signature includes: "a 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". 

When two independent parties want to evaluate an electronic signature, 
it is a signed document fundamental that contains the hash value, they get the identity of same result. To meet this 
requirement the TSA, technical components and technical aspects used in 
creating the time of 
stamping. This proves that the given data existed before the time of 
stamping. Timestamping a digital signature (by sending must be referenced, this is provided by a hash of the 
signature 
reference to the TSA) before "Signature Validation Policy". The "Signature 
Validation Policy" defines:

    * the revocation components of the signer's private 
key, provides evidence that the signature has been created before the 
key was revoked.

ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 91]

Internet Draft                                   Electronic Signature Formats


If a recipient wants to hold a valid an electronic signature he will have to ensure that he has obtained a valid time stamp for it, before that 
key (and any key involved in the validation) is revoked. The sooner the 
timestamp is obtained after the signing time, be provided by the better.


It is important 
      signer;

    * any additional components (i.e. verifier components) used to note that signatures may be generated "off-line" and 
time-stamped 
      validate an electronic signature at a later the time of receipt by anyone, for example a
      verifier and later by the signer an arbitrator, auditor or 
any recipient interested in other 
      independent parties. 

By signing over the value signature policy identifier, the algorithm 
identifier and the hash of the signature. The time stamp 
can thus be provided by signature policy, the signer together with the signed document, explicitly 
indicates that he or obtained by the recipient following receipt of she has applied the signed document.

The time stamp is NOT a component of signature policy in creating 
the Electronic Signature, but signature. Thus, undertakes any commitments implied by the 
essential component 
signature policy, any indication of the ES with Timestamp.

It is required commitment type included in this document the 
electronic signature, and the user data that signer's digital signature is signed. 

The hash algorithm identifier and value is timestamped by a trusted source, known as a TimeStamping Authority.

This document requires included to ensure that 
both the signer's digital signature value is 
timestamped by a trusted source before signer and verifier use exactly the electronic same signature can 
become a ES with Complete validation data (ES-C). The acceptable TSAs 
are specified in the Signature Validation Policy.

Should both policy. 
This unambiguously binds the signer and verifier be required to timestamp same definitive 
form of the signature value policy has a unique binary encoding.




ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 62]
Internet Draft                             Electronic Signature Formats


In order to meet identify unambiguously the requirements of "Signature Validation Policy" 
to be used to verify the signature policy, an identifier and hash of the 
"Signature policy" must be part of the signed data. Additional 
information about the 
signature policy MAY specify a permitted time delay between (e.g. web reference to the two 
time stamps.


B.4.6	Timestamping for Long Life document) may 
be carried as "qualifiers" to the signature policy identifier.

B.3.2  Commitment Type Indication

The definition of Signature before CA Key Compromises

Timestamped extended electronic signatures are needed when there is signature includes: "a commitment has 
been explicitly endorsed under a 
requirement to safeguard against signature policy, at a given time, 
by a signer under an identifier, e.g. a name or a pseudonym, and 
optionally a role". 

The commitment type can be indicated in the possibility of electronic signature 
either:

      * explicitly using a CA key "commitment type indication" in the 
certificate chain ever being compromised. A verifier may be required to 
provide on request, proof that
        electronic signature;

      * implicitly or explicitly from the certification path and semantics of the 
revocation information used signed data.

If the indicated commitment type is explicit using a "commitment type 
indication" in the time electronic signature, acceptance of the a verified 
signature were valid, 
even in implies acceptance of the case where one semantics of that commitment type. 
The semantics of explicit commitment types indications must be 
specified either as part of the issuing keys signature policy or OCSP responder keys 
is later compromised.

The current document defines two ways may be registered 
for generic use across multiple policies.

If a signature includes a commitment type indication other than one of 
those recognized under the signature policy the signature must be 
treated as invalid.

How commitment is indicated using timestamps to protect 
against this compromise:

    * Timestamp the ES with Complete validation data, when an OCSP 
      response semantics of the data being 
signed is used to get outside the status scope of this document.

NOTE:  Examples of commitment indicated through the certificate from semantics of the
      signer. 
data being signed, are:

     * Timestamp only An explicit commitment made by the certification path and revocation information 
      references when a CRL is used to get signer indicated by the status type 
       of data being signed over. Thus, the 
      certificate from data structure being 
       signed can have an explicit commitment within the signer.

NOTE: context of 
       the application (e.g. EDIFACT purchase order).

     * An implicit commitment which is a commitment made by the signer, verifier or both may obtain signer 
       because the timestamp. data being signed over has specific semantics
       (meaning) which is only interpretable by humans, (i.e. free 
       text).







ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 92] 63]
Internet Draft                             Electronic Signature Formats



B.4.6.1	Timestamping

B.3.3  Certificate Identifier from the ES with Complete validation data

When Signer

The definition of the ETSI electronic signature includes: "a 
commitment has been explicitly endorsed under a signature policy, 
at a given time, by a signer under an OCSP response is used, it is necessary identifier, e.g. a name or a 
pseudonym, and optionally a role."

In many real life environments users will be able to time stamp in 
particular that response in get from 
different CAs or even from the case same CA, different certificates 
containing the same public key from for different names. The prime 
advantage is that a user can use the responder would 
be compromised. Since same private key for different 
purposes. Multiple use of the information contained in private key is an advantage when a smart 
card is used to protect the OCSP response private key, since the storage of a smart 
card is 
user specific and time specific, always limited. When several CAs are involved, each different 
certificate may contain a different identity, e.g. as a national or as 
an individual time stamp employee from a company. Thus when a private key is needed used for 
every signature received. Instead of placing 
various purposes, the time stamp only over certificate is needed to clarify the certification path references and context in 
which the private key was used when generating the signature. Where 
there is the possibility of multiple use of private keys it is 
necessary for the revocation information 
references, which include signer to indicate to the OCSP response, verifier the time stamp is placed 
on precise 
certificate to be used.

Many current schemes simply add the ES-C. Since certificate after the certification path signed data 
and revocation information 
references thus are included in the ES subject to various substitution attacks. An example of a 
substitution attack is a "bad" CA that would issue a certificate to 
someone with Complete validation data they 
are also protected. For the same cryptographic price, this provides an 
integrity mechanism over the ES with Complete validation data. Any 
modification can be immediately detected. It should be noticed that 
other means public key of protecting/detecting someone else. If the integrity of certificate from 
the ES with 
Complete Validation Data exist signer was simply appended to the signature and could be used. 

Although thus not protected 
by the technique requires a time stamp for every signature, it is 
well suited for individual users wishing any one could substitute one certificate by another 
and the message would appear to have an integrity protected 
copy be signed by some one else. 

In order to counter this kind of all attack, the validated signatures they have received.

By timestamping identifier of the complete electronic signature, including signer 
has to be protected by the digital signature as well from the signer.

Although it does not provide the same advantages as the references previous 
technique, another technique to the certificates and 
revocation status information used counter that threat has been 
identified. It requires all CAs to support validation perform a Proof Of Possession of that 
signature, 
the timestamp ensures that there is no ambiguity in private key at the 
means time of validating registration. The problem with that signature.

This 
technique is referred to as ES with eXtended validation data (ES-
X), type 1 Timestamped in this document. 

NOTE:	Trust is achieved in the references by including a hash of the 
data being referenced. 

If that it is desired for does not provide any reason to keep a copy of guarantee at the additional data 
being referenced, time of 
verification and only some proof "after the additional data event" may be attached to obtained, if 
and only if the electronic 
signature, CA keeps the Proof Of Possession in which case audit trail.

In order to identify unambiguously the electronic signature becomes a ES-X Long 
as defined by this document.

A ES-X Long Timestamped  is simply certificate to be used for the concatenation of a ES-X 
Timestamped  with a copy 
verification of the additional data being referenced.

B.4.6.2	Timestamping Certificates and Revocation Information 

References Timestamping each ES with Complete validation data as 
defined above may not be efficient, particularly when the same set signature an identifier of 
CA certificates and CRL information is used to validate many 
signatures.






ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 93]

Internet Draft                                   Electronic Signature Formats


Timestamping CA certificates will stop any attacker the certificate from issuing bogus 
CA certificates that could be claimed to existing before 
the CA key was 
compromised. Any bogus timestamped CA certificates will show that signer must be part of the 
certificate was created after signed data.

B.3.4  Role Attributes

The definition of electronic signature includes: "a commitment has 
been explicitly endorsed under a non repudiation security policy, 
at a given time, by a signer under an identifier, e.g. a name or a 
pseudonym, and optionally a role. "




ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 64]
Internet Draft                             Electronic Signature Formats


While the legitimate CA key was compromised. In name of the same way, timestamping CA CRLs, will stop any attacker from issuing 
bogus CA CRLs which could be claimed to existing before signer is important, the CA key was 
compromised.

Timestamping position of commonly used certificates and CRLs can be done 
centrally, e.g. inside the signer 
within a company or an organization can be even more important. Some 
contracts may only be valid if signed by a service provider. This method 
reduces user in a particular role, 
e.g. a Sales Director. In many cases whom the amount of data sales Director really 
is, is not that important but being sure that the verifier has signer is empowered 
by his company to timestamp, be the Sales Director is fundamental.

This document defines two different ways for example 
it could reduce to just one time stamp per day (i.e. providing this feature:

      * by placing a claimed role name in the case were 
all CMS signed 
        attributes field;

     * by placing a attribute certificate containing a certified 
       role name in the signers CMS signed attributes field.

NOTE:  Another possible approach would have been to use additional 
attributes containing the same CA and the CRL applies for roles name(s) in the whole day). 
The information that needs to be time stamped is signer's certificate. 
However, it was decided not the actual 
certificates and CRLs but the unambiguous references to those 
certificates and CRLs.

To comply with extended validation data, type 2 Timestamped, follow this 
document requires the following: 
     * All approach as it breaks the CA certificates references and revocation information 
       references (i.e. CRLs) used in validating 
basic philosophy of the ES-C are covered
       by certificate being issued for one or more timestamp. 

Thus a ES-C with a timestamp signature value at time T1, can be proved 
valid if all primary 
purpose. Also, by using separate certificates for management of the CA 
signer's identity certificate and CRL references are timestamped at time T1+.


B.4.7	Timestamping for Long Life management of Signature 

Advances in computing increase additional roles can 
simplify the probability management, as new identity keys need not be issued if a 
use of being able to break 
algorithms and compromise keys. There role is therefore a requirement to be 
able changed.

B.3.5.1  Claimed Role

The signer may be trusted to protect electronic signatures against state his own role without any 
certificate to corroborate this probability.

Over a period of time weaknesses may occur in claim. In which case the cryptographic 
algorithms used claimed role 
can be added to create an electronic the signature (e.g. due as a signed attribute.

B.3.5.2  Certified Role

Unlike public key certificates that bind an identifier to a public 
key, Attribute Certificates bind the identifier of a certificate to 
some attributes, like a role. An Attribute Certificate is NOT issued 
by a CA but by an Attribute Authority (AA). The Attribute Authority 
will be most of the time 
available for cryptoanalysis, under the control of an organization or improvements in cryptoanalytical 
techniques). Before this such weaknesses become likely, a verifier 
should take extra measures 
company that is best placed to know which attributes are relevant for 
which individual. 

The Attribute Authority may use or point to maintain public key certificates 
issued by any CA, provided that the validity appropriate trust may be placed 
in that CA. Attribute Certificates may have various periods of the electronic 
signature. Several techniques could 
validity. That period may be used to achieve quite short, e.g. one day. While this goal 
depending on the nature 
requires that a new Attribute Certificate is obtained every day, valid 
for that day, this can be advantageous since revocation of such 
certificates may not be needed. When signing, the weakened cryptography. signer will have to 
specify which Attribute Certificate it selects. In order to 
simplify, a single technique, called Archive validation data, covering 
all do 
so, the cases is being used Attribute Certificate will have to be included in this document.

Archive validation data consists of the Complete validation data and 
the complete certificate and revocation data, time stamped together 
with the electronic signature. The Archive validation signed 
data  is 
necessary if the hash function and the crypto algorithms that were used in order to create the signature are no longer secure. Also, if it cannot be 
assumed that the hash function used protected by the Time Stamping Authority is 
secure, then nested timestamps of Archived Electronic Signature are 
required. digital signature from the signer.




ETSI TC-SEC, Ross, Pinkas, Ross, Pope         Informational RFC           [Page 94]

Internet Draft                                   Electronic Signature Formats

The potential for Trusted Service Provider (TSP) key compromise should 
be significantly lower than user keys, because TSP(s) are expected to 
use stronger cryptography and better key protection. It can be expected 
that new algorithms (or old ones with greater key lengths) will be 
used.       Informational RFC       [Page 65]
Internet Draft                             Electronic Signature Formats


In such a case, a sequence of timestamps will protect against 
forgery. Each timestamp needs order to identify unambiguously the attribute certificate(s) to be affixed before either 
used for the 
compromise verification of the signing key or signature an identifier of the cracking of 
attribute certificate(s) from the algorithms used 
by signer must be part of the TSA. TSAs (TimeStamping Authorities) should have long keys (e.g. 
which at signed 
data.

B.3.5  Signer Location

In some transactions the time purported location of drafting this document was 2048 bits for the 
signing RSA algorithm) and/or a "good" or different algorithm.

Nested timestamps will also protect signer at the verifier against key compromise time 
he or cracking the algorithm on the old electronic signatures.

The process will she applies his signature may need to be performed and iterated before indicated. For this 
reason an optional location indicator must be able to be included.

In order to provide indication of the 
cryptographic algorithms used for generating location of the signer at the previous time stamp 
are no longer secure. Archive validation data may thus bear multiple 
embedded 
time stamps.

B.4.8	Reference to Additional Data

Using type 1 he or 2 of Timestamped extended validation data verifiers 
still needs to keep track of all she applied his signature a  location attribute may be 
included in the components that were used signature.

B.3.6  Signing Time

The definition of electronic signature includes: "a 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. "

There are several ways to 
validate the signature, address this problem. The solution adopted 
in order to be able this document is to retrieve them again 
later on. These components may be archived by an external source like sign over a 
trusted service provider, in time which case referenced information that the signer claims is 
provided as part of the 
signing time (i.e. claimed signing time) and to require a trusted 
time stamp to be obtained when building a ES with Complete validation data (ES-C) is 
adequate. Timestamp. When a 
verifier accepts a signature, the two times must be within acceptable 
limits. 

The actual certificates and CRL information reference solution that is adopted in this document offers the 
ES-C major 
advantage that electronic signatures can be gathered when needed for arbitration. 

B.4.9	Timestamping for Mutual Recognition

In some business scenarios both the signer and the verifier need generated without any on-
line connection to 
timestamp their own copy of the signature value. Ideally the two 
timestamps should a trusted time source (i.e. they may be as close as possible to each other.

Example: A contract is signed by generated 
off-line).

Thus two parties A dates and B representing their 
respective organizations, to timestamp two signatures are required: 

     * a signing time indicated by the signer and verifier which is part of 
       the data two 
approaches are possible:

      * under signed by the terms signer (i.e. part of the contract pre-defined common "trusted"
        TSA may be used; basic 
       electronic signature);

     * if both organizations run their own timestamping services, A 
        and B can have the transaction timestamped a time indicated by these two
        timestamping services.In a TimeStamping Authority (TSA) which is 
       signed over the latter case, digital signature value of the basic electronic
       signature. The signer, verifier or both may obtain the TSA
       timestamp.

In order for an electronic signature will only to be considered as valid, if both timestamps 
        were obtained in due time (i.e. there should not valid under a signature 
policy, it must be timestamped by a long 
        delay between obtaining the two timestamps). Thus, neither A 
        nor B can repudiate TSA where the signing time as 
indicated by their own 
        timestamping service. 

Therefore, A the signer and B do not need to agree on the time of time stamping as indicated by 
a common "trusted" TSA must be "close enough" to 
get a valid transaction. meet the requirements of the signature 
validation policy. 



ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 95] 66]
Internet Draft                             Electronic Signature Formats

It is important to note that signatures may be generated "off-line" and 
timestamped at


"Close enough" means a later time by anyone, e.g. by the signer few minutes, hours or any 
recipient interested in validating even days according to 
the signature. "Signature Validation Policy". 

NOTE:  The need for Timestamping is further explained in clause B.4.5.
A further optional attribute is defined in this document to timestamp over 
the signature from content, to provide proof of the signer can thus be provided by existence of the signer 
together with content, at the signed document, and /or obtained 
time indicated by the verifier 
following receipt of the signed document.

The business scenarios timestamp.

Using this optional attribute a trusted secure time may thus dictate that one or more of the long-
term signature timestamping methods describe above be used. This will 
need to be part of a mutually agreed obtained 
before the Signature Validation Policy 
with document is part of the overall signature policy signed and included under which the digital signature.
This solution requires an on-line connection to a trusted timestamping 
service before generating the signature and may not represent the 
precise signing time, since it can be obtained in advance.  However, 
this optional attribute may be used by the signer to support prove that the business relationship between 
signed object existed before the 
two parties. 

B.4.10	TSA Key Compromise

TSA servers should be built date included in such a way that once the private 
signature key is installed, that there is minimal likelihood of 
compromise over as long as possible period. Thus the validity period 
for timestamp (see 
3.12.3, Content Timestamp).

Also, the TSA's keys signing time should be as long as possible.

Both between the ES-T time indicated by this 
timestamp and the ES-C contain at least one time stamp over indicated by the 
signer's signature. In order ES-T timestamp.

B.4  Components of Validation Data

B.4.1  Revocation Status Information

A verifier will have to protect against prove that the compromise certificate of the 
private signature key used to produce that timestamp, signer was 
valid at the Archive 
validation data time of the signature. This can be used when done by either:

     * using Certificate Revocation Lists (CRLs);

     * using responses from an on-line certificate status server 
       (for example; obtained through the OCSP protocol).

B.4.2  CRL Information

When using CRLs to get revocation information, a different TimeStamping Authority key 
is involved verifier will have to produce the additional timestamp. If it is believed 
make sure that he or she gets at the TSA key used in providing an earlier timestamp may ever be 
compromised (e.g. outside its validity period), then time of the ES-A first verification the
appropriate certificate revocation information from the signer's CA. 
This should be 
used. For extremely long periods this may be applied repeatedly using 
new TSA keys.

B.5	Multiple Signatures

Some electronic signatures may only be valid if they bear more than one done as soon as possible to minimize the time delay 
between the generation and verification of the signature. This is involves
checking that the case generally when a contract signer certificate serial number is signed between 
two parties. not included in 
the CRL. The ordering of signer, the signatures may verifier or any other third party may not obtain 
either this CRL. If obtained by the signer, then it must be 
important, i.e. one may or may not need conveyed 
to be applied before the other. 

Several forms of multiple and counter signatures need to verifier. It may be supported, 
which fall into two basic categories:
     * independent signatures;
     * embedded signatures.
Independent signatures are parallel signatures where convenient to archive the ordering CRL for ease of 
subsequent verification or arbitration. 

Alternatively, provided the signatures CRL is not important. The capability to have more than one 
independent signature over the same data must be provided.

Embedded signatures are applied one after archived elsewhere which is 
accessible for the other and are used where purpose of arbitration, then the order serial number of 
the signatures are applied is important. The capability to 
sign over signed data must CRL used may be provided.

These forms are described in clause 4.13. All other multiple signature 
schemes, e.g. a signed document archived together with a countersignature, double 
countersignatures or multiple signatures, can be reduced to one or more 
occurrence of the above two cases. verified electronic 
signature.





ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 96] 67]
Internet Draft                             Electronic Signature Formats


Annex C (informative):

C.1	Signature Policy and Signature Validation Policy

The definition of


It may happen that the certificate serial number appears in the CRL 
but with the status "suspended" (i.e. on hold). In such a case, the 
electronic signature mentions: "a commitment has been 
explicitly endorsed under a "Signature Policy", is not yet valid, since it is not possible to 
know whether the certificate will or will not be revoked at the end 
of the suspension period. If a given time, by a 
signer under an identifier, e.g. decision has to be taken immediately 
then the signature has to be considered as invalid. If a name decision can 
wait until the end of the suspension period, then two cases are 
possible:

     * the certificate serial number has disappeared from the list 
       and thus the certificate can be considered as valid and that 
       CRL must be captured and archived either by the verifier or a pseudonym, 
       elsewhere and optionally 
a role. "

Electronic signatures are commonly applied within be kept accessible for the context purpose of a 
legal or contractual framework. This establishes arbitration.

     * the requirements certificate serial number has been maintained on the list 
       with the status definitively revoked and thus the electronic signatures 
       signature must be considered as invalid and any special semantics (e.g. agreement, 
intent). These requirements discarded.

At this point the verifier may be defined in very general abstract 
terms convinced that he or she got a valid 
signature, but is not yet in terms of detailed rules. The specific semantics associated 
with an electronic a position to prove at a later time that 
the signature implied by was verified as valid. Before addressing this point, an 
alternative to CRL is to use OCSP responses.

B.4.3  OCSP Information

When using OCSP to get revocation information , a legal verifier will have 
to make sure that he or contractual 
framework are outside she gets at the scope time of this document.

If the signature policy is recognized, within first verification 
an OCSP response that contains the legal/contractual 
context, status "valid". This should be done 
as providing commitment, then soon as possible after the signer explicitly agrees 
with terms generation of the signature. The signer, 
the verifier or any other third party may fetch this OCSP response. 
Since OSCP responses are transient and conditions which thus are implicitly or explicitly part of not archived by any 
TSP including CA, it is the signed data.

When two independent parties want responsibility of every verifier to evaluate an electronic signature, make 
sure that it is fundamental that they get the same result. It stored in a safe place. The simplest way is therefore 
important that the conditions agreed by the signer at the time of 
signing are indicated to store 
them associated with the verifier and any arbitrator. electronic signature. An aspect 
that enables this alternative would be 
to store them in some storage so that they can then be known by all parties is easily 
retrieved. 

In the signature policy. 
The technical implications same way as for the case of the signature policy on CRL, it may happen that the electronic 
signature 
certificate is declared as invalid but with all the validation data are called secondary status 
"suspended". 

In such a case, the "Signature 
Validation Policy". The electronic signature validation policy specifies 
the rules used is not yet valid, since it is 
not possible to validate know whether the signature.

This document does certificate will or will not mandate the form and encoding of be 
revoked at the 
specification end of the signature policy. However, for suspension period. If a given signature 
policy there must decision has to be one definitive form that 
taken immediately then the electronic signature has a unique binary 
encoded value.

This document includes, to be considered 
as an option, invalid. If a formal structure for signature 
validation policy based on the use of Abstract Syntax Notation 1 
(ASN.1).

Given decision can wait until the specification end of the signature policy and its hash value an 
implementation of suspension 
period, then two cases are possible:

     * An OCSP response with a verification process must obey the rules defined 
in valid status is obtained at a later 
       date and thus the specification. 

This document places no restriction on how it should certificate can be implemented. 
Provide the implementation conforms to the conformance requirements considered as 
define in clause 14.1, 14.2 valid and 14.3 implementation options include: 
       that OCSP response must be captured.



ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 97] 68]
Internet Draft                             Electronic Signature Formats



A validation process


     * An OCSP response with an invalid status is obtained with a 
       secondary status indicating that supports the certificate is 
       definitively revoked and thus the electronic signature must be 
       considered as invalid and discarded.

As in the CRL case, at this point, the verifier may be convinced that 
he or she got a specific valid signature, but is not yet in a position to prove 
at a later time that the signature policy was verified as 
identified by valid. 

B.4.4  Certification Path

A verifier will have to prove that the certification path was valid, 
at the time of the signature, up to a trust point according to the 
naming constraints and the certificate policy constraints from the signature policy OID. Such an implementation should 
conform 
"Signature Validation Policy". It will be necessary to a human readable description provided capture all the processing 
rules 
certificates from the certification path, starting with those from the 
signer and ending up with those of the signature policy are clearly defined. However, if 
additional policies need to be supported, then such an implementation 
would need to be customized for each additional policy. This type self-signed certificate from 
one trusted root of 
implementation may be simpler to implement initially, but can the "Signature Validation Policy". In addition, it 
will be 
difficult to enhance necessary to support numerous additional signature policies.



A validation process that is dynamically programmable and able capture the Authority Revocation Lists (ARLs) to adapt 
its validation rules in accordance with a description 
prove than none of the signature 
policy provided in a computer-processable language. This present 
document defines such a policy using an ASN.1 structure (see 6.1). This 
type of implementation could support multiple signature policies 
without being modified every time, provided all CAs from the validation rules 
specified as part chain was revoked at the time of 
the signature policy are known by signature.

As in the 
implementation. (i.e. only requires modification if there are 
additional rules specified).

The precise content of OCSP case, at this point, the verifier may be convinced that 
he or she got a signature policy valid signature, but is not mandated by the 
current document. However, yet in a signature policy must be sufficiently 
definitive position to avoid any ambiguity prove 
at a later time that the signature was verified as valid. 

B.4.5  Timestamping for Long Life of Signature

An important property for long standing signatures is that a 
signature, having been found once to its implementation 
requirements. It be valid, must continue to be absolutely clear under which conditions an 
electronic signature should so 
months or years later. 

A signer, verifier or both may be accepted. For this reason, it should 
contain the following information:

     * General information about the signature policy which includes:
        - required to provide on request, 
proof that a unique identifier of the policy;
        - digital signature was created or verified during the name 
validity period of the issuer of all the policy;
        - certificates that make up the date 
certificate path. In this case, the policy was issued;
        - signer, verifier or both will 
also be required to provide proof that all the field of application of user and CA 
certificates used were not revoked when the policy.

     * The signature verification policy which includes:
       - the signing period,
       - was created 
or verified. 

It would be quite unacceptable, to consider a list of recognized commitment types;
       - rules for Use of Certification Authorities;
       - rules for Use of Revocation Status Information;
       - rules for Use of Roles;
       - rules for use of Timestamping and Timing;
       - signature verification data as invalid 
even if the keys or certificates were later compromised. Thus there 
is a need to be provided by able to demonstrate that the 
         signer/collected by verifier;
       - any constraints on signature algorithms and key lengths.
     * Other keys was valid 
around the time that the signature policy rules required was created to meet the objectives provide long term 
evidence of the validity of a signature.

Variations

It could be the case that a certificate was valid at the time of the validation policy rules may apply to different 
commitment types. 
signature but revoked some time later. In this event, evidence must be 
provided that the document was signed before the signing key was 
revoked. 




ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 98] 69]
Internet Draft                             Electronic Signature Formats



C.2	Identification of Signature Policy

When data

Timestamping by a Time Stamping Authority (TSA) can provide such 
evidence. A time stamp is signed obtained by sending the signer indicates hash value of the signature policy 
applicable 
given data to that electronic signature by including an object 
identifier for the signature policy with the signature. TSA. The signer and 
verifier must apply the rules specified by returned "timestamp" is a signed document 
that contains the identified policy. In 
addition to hash value, the identifier identity of the signature policy the signer must 
include TSA, and the hash time of the signature policy, so it can be verified that 
the policy selected by the signer is the identical to the one being 
used the verifier. 

A signature policy may be qualified by additional information. 
stamping. This can 
includes:

     * A URL where a copy of the Signature Policy may be obtained;
     * A user notice proves that should be displayed when the signature is 
       verified;

If no signature policy is identified then the signature may be assumed 
to have been generated/verified without any policy constraints, and 
hence may be given no specific legal or contractual significance 
through data existed before the context time of 
stamping. Timestamping a digital signature policy.

A "Signature Policy" will be identifiable by an OID (Object Identifier) 
and verifiable using (by sending a hash of the 
signature policy.


C.3	General Signature Policy Information

General information should be recorded about to the signature policy along 
with TSA) before the definition revocation of the rules which form signer's private 
key, provides evidence that the signature policy as 
described in subsequent subclauses. This should include:

     * Policy Object Identifier: The "Signature Policy" has been created before the 
key was revoked.


If a recipient wants to hold a valid electronic signature he will be 
       identifiable by an OID (Object Identifier) whose last component 
       (i.e. right most) is an integer that is specific have 
to ensure that he has obtained a particular 
        version issued on valid time stamp for it, before that 
key (and any key involved in the given date.
     * Date of issue: When validation) is revoked. The sooner 
the "Signature Policy" was issued.
     * Signature Policy Issuer name: An identifier for timestamp is obtained after the body 
       responsible for issuing signing time, the Signature Policy. This better.

It is important to note that signatures may be used generated "off-line" 
and time-stamped at a later time by anyone, for example by the signer 
or verifying in deciding if a policy is to be 
       trusted, any recipient interested in which case the signer/verifier must authenticate the origin value of the signature policy as coming from the identified 
       issuer.
     * Signing period: signature. The start time and date, optionally 
stamp can thus be provided by the signer together with an end 
       time and date, for the period over which signed 
document, or obtained by the signature policy 
       may be used to generate electronic signatures.
     * Field recipient following receipt of application: This defines in general terms the general 
       legal/contract/application contexts in which the signature 
       policy signed 
document.

The time stamp is to be used and NOT a component of the specific purposes for which Electronic Signature, but the 
       electronic signature 
essential component of the ES with Timestamp.

It is to be applied.


ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 99]

Internet Draft                                   Electronic Signature Formats

C.4	Recognized Commitment Types

The required in this document that signer's digital signature validation policy may recognize one or more types of 
commitment as being supported value 
is timestamped by electronic signatures produced under a trusted source, known as a TimeStamping Authority.

This document requires that the security policy.If an electronic signer's digital signature does not contain value is 
timestamped by a 
recognized commitment type then the semantics of trusted source before the electronic signature is dependent on the can 
become a ES with Complete validation data being signed and the context in 
which it is being used.

Only recognized commitment types (ES-C). The acceptable TSAs 
are allowed specified in an electronic 
signature.

The definition of a commitment type includes:
     * the object identifier for the commitment;
     * the contractual/legal/application context in which Signature Validation Policy.

Should both the signature 
        may signer and verifier be used (e.g. submission of messages);
     * a description of required to timestamp the support provided within 
signature value to meet the terms requirements of the 
       context (e.g. proof that the identified source submitted the 
       message if signature policy, the 
signature is created policy MAY specify a permitted time delay between the two 
time stamps.

B.4.6  Timestamping before CA Key Compromises

Timestamped extended electronic signatures are needed when message submission there is 
       initiated).

The definition a 
requirement to safeguard against the possibility of a commitment type can CA key in the 
certificate chain ever being compromised. A verifier may be registered:
     * as part of required 
to provide on request, proof that the validation policy;
     * as part of certification path and the application/contract/legal environment;
     * as part of generic register 
revocation information used a the time of definitions.

The legal/contractual context will determine the rules applied to signature were valid, 
even in the 
signature, as defined by case where one of the signature policy and its recognized 
commitment types, make it fit for purpose intended.


C.5	Rules for Use issuing keys or OCSP responder keys 
is later compromised.







ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 70]
Internet Draft                             Electronic Signature Formats

The current document defines two ways of Certification Authorities

The certificate using timestamps to protect 
against this compromise:

    * Timestamp the ES with Complete validation process data, when an OCSP 
      response is used to get the status of the verifier, and hence certificate from the 
certificates that may be used by
      signer.

    * Timestamp only the signer for certification path and revocation information 
      references when a valid electronic 
signature, may be constrained by CRL is used to get the combination status of the trust point and 
      certificate path constraints in from the signature validation policy.

C.5.1	Trust Points

The signature validation policy defines signer.

NOTE:  the certification authority 
trust points that are signer, verifier or both may obtain the timestamp.


B.4.6.1  Timestamping the ES with Complete validation data

When an OCSP response is used, it is necessary to time stamp in 
particular that response in the case the key from the responder would 
be used compromised. Since the information contained in the OCSP response 
is user specific and time specific, an individual time stamp is needed 
for every signature verification. Several 
trust points may be specified under one signature policy. Specific 
trust points may be specified for a particular type received. Instead of commitment 
defined under placing the time stamp only 
over the signature policy. For a signature to be valid a certification path must exists between references and the Certification Authority 
that has granted revocation information 
references, which include the certificate selected by OCSP response, the signer (i.e. time stamp is placed 
on the used 
user-certificate) ES-C. Since the certification path and one revocation information 
references are included in the ES with Complete validation data they 
are also protected. For the same cryptographic price, this provides an 
integrity mechanism over the ES with Complete validation data. Any 
modification can be immediately detected. It should be noticed that 
other means of protecting/detecting the trust point integrity of the "Signature ES with 
Complete Validation Policy".






ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 100]

Internet Draft                                   Electronic Signature Formats



C.5.2	Certification Path

There may Data exist and could be constraints on used. 

Although the use technique requires a time stamp for every signature, it 
is well suited for individual users wishing to have an integrity 
protected copy of certificates issued by one or 
more CA(s) in the certificate chain and trust points. The two prime 
constraints are certificate policy constraints and naming constraints:

     * Certificate policy constraints limit all the certification chain 
       between validated signatures they have received.

By timestamping the user certificate and complete electronic signature, including the certificate of 
digital signature as well as the trusted 
       point references to a given set of certificate policies, or equivalents 
       identified through certificate policy mapping.
     * The naming constraints limit the forms certificates and 
revocation status information used to support validation of names that 
signature, the CA timestamp ensures that there is 
       allowed to certify.

Name constraints are particularly important when a "Signature policy" 
identifies more than one trust point. In this case, a certificate no ambiguity in the 
means of a 
particular trusted point may only be used validating that signature.

This technique is referred to verify signatures from 
users as ES with names permitted under the name constraint.

Certificate Authorities may be organized eXtended validation data 
(ES-X), type 1 Timestamped in a tree structure, this tree 
structure may represent the trust relationship between various CA(s) 
and document. 

NOTE:  Trust is achieved in the users CA. Alternatively, references by including a mesh relationship may exist where hash of the 
data being referenced. 

If it is desired for any reason to keep a 
combination copy of tree and peer cross-certificates the additional data 
being referenced, the additional data may be used. The 
requirement of attached to the certificate path 
electronic signature, in which case the electronic signature becomes 
a ES-X Long as defined by this document document.

A ES-X Long Timestamped  is that it 
provides simply the trust relationship between all concatenation of a ES-X 
Timestamped  with a copy of the CAs additional data being referenced.

ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 71]
Internet Draft                             Electronic Signature Formats


B.4.6.2  Timestamping Certificates and Revocation Information 

References Timestamping each ES with Complete validation data as 
defined above may not be efficient, particularly when the signers 
user certificate. The starting point from a verification point same set of view, 
CA certificates and CRL information is used to validate many 
signatures.

Timestamping CA certificates will stop any attacker from issuing bogus 
CA certificates that could be claimed to existing before the "trust point". A trust point is usually a CA key 
was compromised. Any bogus timestamped CA certificates will show that publishes 
self-certified certificates, is 
the starting point from which certificate was created after the 
verifier verifies legitimate CA key was 
compromised. In the certificate chain. Naming constraints may 
apply same way, timestamping CA CRLs, will stop any 
attacker from the trust point, in issuing bogus CA CRLs which case they apply throughout could be claimed to existing 
before the set CA key was compromised.

Timestamping of commonly used certificates that make up the certificate path down to the signer's 
user certificate.

Policy constraints and CRLs can be easier to process but to be effective require done 
centrally, e.g. inside a company or by a service provider. This method 
reduces the presence amount of a certificate policy identifier data the verifier has to timestamp, for example 
it could reduce to just one time stamp per day (i.e. in the certificates 
used in a certification path.

Certificate path processing, thus generally starts with one of case were 
all the 
trust point from signers use the signature policy same CA and ends with the user 
certificate. The certificate path processing procedures defined in RFC 
2459 clause 6 identifies CRL applies for the following initial parameters whole day).
The information that are 
selected by needs to be time stamped is not the verifier in certificate path processing:

     * acceptable certificate policies;
     * naming constraints in terms of constrained and excluded naming 
       subtree;
     * requirements for explicit certificate policy indication actual 
certificates and 
       whether certificate policy mapping are allowed;
     * restrictions on CRLs but the certificate path length.

The signature unambiguous references to those 
certificates and CRLs.

To comply with extended validation policy identifies constraints on these 
parameters.


ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 101]

Internet Draft                                   Electronic Signature Formats


C.5	Revocation Rules

The signature policy should defines rules specifying requirements for data, type 2 Timestamped, this 
document requires the use of certificate following: 

     * All the CA certificates references and revocation lists (CRLs) and/or on-line 
certificate status check service to check information 
       references (i.e. CRLs) used in validating the validity of ES-C are covered
       by one or more timestamp. 

Thus a certificate. 
These rules specify the mandated minimum checks that must be carried 
out.

It is expected that in many cases either check may be selected ES-C with 
CRLs checks being carried out for certificate status that a timestamp signature value at time T1, can be proved 
valid if all the CA and CRL references are 
unavailable from OCSP servers. The verifier may take into account 
information timestamped at time T1+.

B.4.7  Timestamping for Long Life of Signature 

Advances in computing increase the certificate in deciding how best probability of being able to check the 
revocation status (e.g. break 
algorithms and compromise keys. There is therefore a certificate extension field about authority 
information access or requirement to be 
able to protect electronic signatures against this probability.

Over a CRL distribution point) provided that it does 
not conflict with period of time weaknesses may occur in the cryptographic 
algorithms used to create an electronic signature policy revocation rules.


C.6	Rules for (e.g. due to the Use of Roles

Roles can be supported as claimed roles 
time available for cryptoanalysis, or as certified roles using 
Attribute Certificates. 


C.6.1	Attribute Values

When signature under improvements in cryptoanalytical 
techniques). Before this such weaknesses become likely, a role is mandated by verifier 
should take extra measures to maintain the signature policy, then 
either Attribute Certificates may be used or validity of the signer may provide a 
claimed role attribute. The acceptable attribute types or values may electronic 
signature. Several techniques could be 
dependent used to achieve this goal 
depending on the type nature of commitment. For example, a user may have 
several roles that allow the user weakened cryptography. In order to sign data that imply commitments 
based on one or more of his roles.

C.6.2	Trust Points for Certified Attributes

When a signature under 
simplify, a certified role is mandated by single technique, called Archive validation data, covering 
all the signature 
policy, Attribute Authorities are cases is being used and need to be validated as part in this document.





ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 72]
Internet Draft                             Electronic Signature Formats


Archive validation data consists of the overall Complete validation of data and 
the complete certificate and revocation data, time stamped together 
with the electronic signature. The trust points 
for Attribute Authorities do not need to be Archive validation data is 
necessary if the same as hash function and the trust 
points crypto algorithms that were 
used to evaluate a certificate from the CA of the signer. Thus create the 
trust point for verifying roles need not signature are no longer secure. Also, if it cannot 
be assumed that the same as trust point hash function used to validate by the certificate path Time Stamping Authority 
is secure, then nested timestamps of the user's key. 

Naming and certification policy constraints may apply to the AA in 
similar circumstance to when they apply Archived Electronic Signature are 
required. 

The potential for Trusted Service Provider (TSP) key compromise should 
be significantly lower than user keys, because TSP(s) are expected to CA. Constraints on the AA 
use stronger cryptography and CA need not better key protection. It can be exactly the same. 

AA(s) may expected
that new algorithms (or old ones with greater key lengths) will be used when 
used. In such a signer is creating case, a signature on behalf sequence of an 
organization, they can timestamps will protect against 
forgery. Each timestamp needs to be particularly useful when affixed before either the signature 
represents an organizational role. AA(s) may or may not be 
compromise of the same 
authority as CA(s).

Thus, signing key or of the Signature Policy identifies trust points that can be used for 
Attribute Authorities, either by reference to cracking of the same trust points as algorithms used for Certification Authorities, or by an independent list.

ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 102]

Internet Draft                                   Electronic Signature Formats


C.6.3	Certification Path for Certified Attributes

Attribute Authorities may be organized in a tree structure in similar 
way to CA where
by the AAs are TSA. TSAs (TimeStamping Authorities) should have long keys (e.g.
which at the leafs time of such a tree. Naming and other 
constraints may be required on attribute certificate paths in drafting this document was 2048 bits for the 
signing RSA algorithm) and/or a similar 
manner to other electronic signature certificate paths.  

Thus, "good" or different algorithm.

Nested timestamps will also protect the Signature Policy identify constraints verifier against key compromise
or cracking the algorithm on the following 
parameters used as input old electronic signatures.

The process will need to the certificate path processing:

     * acceptable certificate policies, including requirements for 
       explicit certificate policy indication and whether certificate 
       policy mapping is allowed;
     * naming constraints in terms of constrained be performed and excluded naming 
       subtrees;
     * restrictions on iterated before the certificate path length.


C.7	Rules 
cryptographic algorithms used for generating the Use previous time stamp 
are no longer secure. Archive validation data may thus bear multiple 
embedded time stamps.

B.4.8  Reference to Additional Data

Using type 1 or 2 of Timestamping and Timing

The following rules should be used when specifying, constraints on Timestamped extended validation data verifiers 
still needs to keep track of all the 
certificate paths for timestamping authorities, constraints on components that were used to 
validate the 
timestamping authority names and general timing constraints.

C.7.1	Trust Points and Certificate Paths

Signature keys from timestamping authorities will need signature, in order to be supported able to retrieve them again 
later on. These components may be archived by an external source like 
a certification path. trusted service provider, in which case referenced information that 
is provided as part of the ES with Complete validation data (ES-C) is 
adequate. The certification path used for timestamping 
authorities requires a trustpoint actual certificates and possibly path constraints CRL information reference in the 
same way that the certificate path 
ES-C can be gathered when needed for the signer's key.

C.7.2 arbitration. 

B.4.9  Timestamping Authority Names

Restrictions may need to be placed by the validation policy on for Mutual Recognition

In some business scenarios both the 
named entities that may act a timestamping authorities.

C.7.3	Timing Constraints - Caution Period

Before an electronic signature may really be valid, signer and the verifier has need to 
be sure that the holder 
timestamp their own copy of the private key was really the only one in 
possession of key at signature value. Ideally the time of signing. However, there two 
timestamps should be as close as possible to each other.

Example: A contract is an 
inevitable delay between a compromise or loss of key being noted, signed by two parties A and a 
report of revocation being distributed. To allow greater confidence in B representing 
their respective organizations, to timestamp the validity signer and verifier 
data two approaches are possible:

      * under the terms of a signature, a "cautionary period" may be identified 
before a signature the contract pre-defined common "trusted"
        TSA may be said to be valid with high confidence. A 
verifier may revalidate a signature after this cautionary signature, or 
wait for this period before validating a signature.

The validation policy may specify such a cautionary period. used;



ETSI TC-SEC, Ross, Pinkas, Ross, Pope       Informational RFC       [Page 103] 73]
Internet Draft                             Electronic Signature Formats


C.7.4	Timing Constraints - Timestamp Delay

There will be some delay between the time that a signature is created

      * if both organizations run their own timestamping services, A 
        and B can have the time the signer's digital signature is timestamped. However, 
the longer this elapsed period the greater the risk of the signature 
being invalidated due to compromise or deliberate revocation of its 
private signing key transaction timestamped by these two
        timestamping services. In the signer. Thus latter case, the electronic 
        signature policy will only be considered as valid, if both timestamps 
        were obtained in due time (i.e. there should 
specify not be a maximum acceptable long 
        delay between obtaining the two timestamps). Thus, neither A 
        nor B can repudiate the signing time as claimed indicated by the signer their own 
        timestamping service. 

Therefore, A and the time included within the timestamp.


C.8	Rules for Verification Data B do not need to be followed

By specifying the requirements agree on a common "trusted" TSA to 
get a valid transaction. 

It is important to note that signatures may be generated "off-line" 
and timestamped at a later time by anyone, e.g. by the signer and verifier or any 
recipient interested in validating the 
responsibilities of signature. The timestamp over 
the two parties signature from the signer can thus be clearly defined to establish 
all the necessary information.

These verification data rules should include:
* requirements on provided by the signer to provide given 
together with the signed attributes;
* requirements on document, and /or obtained by the verifier to obtain additional certificates, CRLs, 
results 
following receipt of on line certificate status checks and to use timestamps (if 
no already provided by the signer).


C.9	Rules for Algorithm Constraints and Key Lengths signed document.

The signature validation policy business scenarios may identify a set of signing 
algorithms (hashing, public key, combinations) and minimum key lengths thus dictate that may be used:

     * by the signer in creating the signature;
     * in end entity public key Certificates;
     * CA Certificates;
     * attribute Certificates;
     * by one or more of the long-
term signature timestamping authority.


C.10	Other methods describe above be used. This will 
need to be part of a mutually agreed the Signature Validation Policy Rules

The 
with is part of the overall signature policy may specify additional policy rules, for example 
rules that relate under which digital 
signature may be used to support the environment used by business relationship between the signer. These 
additional rules may 
two parties. 

B.4.10  TSA Key Compromise

TSA servers should be defined built in computer processable and/or human 
readable form.

C.11	Signature Policy Protection

When signer or verifier obtains such a copy way that once the private 
signature key is installed, that there is minimal likelihood of 
compromise over as long as possible period. Thus the Signature Policy from an 
issuer, validity period 
for the source TSA's keys should be authenticated (for example by using 
electronic signatures). When the signer references a signature policy as long as possible.

Both the Object Identifier (OID) of ES-T and the policy, ES-C contain at least one time stamp over the hash value and 
signer's signature. In order to protect against the hash 
algorithm OID compromise of the 
private signature key used to produce that policy must timestamp, the Archive 
validation data can be included in used when a different TimeStamping Authority key 
is involved to produce the Electronic 
Signature. 



ETSI TC-SEC, Ross, Pinkas, Pope         Informational RFC           [Page 104]

Internet Draft                                   Electronic Signature Formats



It additional timestamp. If it is a mandatory requirement of this present document believed that 
the 
signature policy value computes to one, and TSA key used in providing an earlier timestamp may ever be 
compromised (e.g. outside its validity period), then the ES-A should be 
used. For extremely long periods this may be applied repeatedly using 
new TSA keys.

B.5  Multiple Signatures

Some electronic signatures may only be valid if they bear more than one hash value using 
the specified hash algorithm. 
signature. This means that there must be a single 
binary value of is the encoded form case generally when a contract is signed between 
two parties. The ordering of the signature policy for the unique 
hash value to signatures may or may not be calculated. For example, there 
important, i.e. one may exist a particular 
file type, length and format on which or may not need to be applied before the hash value is calculated 
which is fixed other. 






ETSI TC-SEC, Pinkas, Ross, Pope       Informational RFC       [Page 74]
Internet Draft                             Electronic Signature Formats

Several forms of multiple and definitive for a particular signature policy.

The hash value counter signatures may need to be obtained by: 
supported, which fall into two basic categories:

     * independent signatures;
     * embedded signatures.

Independent signatures are parallel signatures where the signer performing his own computation ordering of 
the hash signatures is not important. The capability to have more than one 
independent signature over the 
      signature policy using his preferred hash algorithm permitted by same data must be provided.

Embedded signatures are applied one after the signature policy, other and are used where 
the definitive binary encoded form.
      
      the signer, having verified the source of the policy, may use 
      both the hash algorithm and order the hash value included signatures are applied is important. The capability to 
sign over signed data must be provided.

These forms are described in the 
      computer processable form clause 3.13. All other multiple signature 
schemes, e.g. a signed document with a countersignature, double 
countersignatures or multiple signatures, can be reduced to one or more 
occurrence of the policy (see section 6.1). above two cases. 





































ETSI TC-SEC, Ross, Pi