Electronic Signature Policies
draft-ietf-smime-espolicies-01

The information below is for an old version of the document that is already published as an RFC
Document Type RFC Internet-Draft (smime WG)
Authors Nick Pope  , Denis Pinkas  , John Ross 
Last updated 2019-11-14 (latest revision 2001-04-08)
Stream Internet Engineering Task Force (IETF)
Formats plain text pdf htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 3125 (Experimental)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Draft                                          ETSI TC-SEC (ETSI)
S/MIME Working Group                         J Ross (Security & Standards)
expires in six months                                      D Pinkas (Bull)
Target Category: Experimental                N Pope (Security & Standards)
                                                                March 2001

                         Electronic Signature Policies
                   <draft-ietf-smime-espolicies-01.txt>

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of section 10 of RFC2026. 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 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

This RFC defines signature policies for electronic signatures. 
A signature policy is a set of rules for the creation and validation 
of an electronic signature, under which the validity of signature can 
be determined. A given legal/contractual context may recognize a 
particular signature policy as meeting its requirements. 

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 allow for the automatic processing of an electronic signature 
another part of the signature policy specifies the electronic 
rules for the creation and validation of the electronic signature in 
a computer processable form.  In the current document the format of the 
signature policy is defined using ASN.1. 

The contents of this RFC is based on the signature policy defined in
ETSI TS 101 733 V1.2.2 The ETSI TS is under the ETSI Copyright (C).
Individual copies of this ETSI deliverable can be downloaded from 
http://www.etsi.org.

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

Internet Draft                               Electronic Signature Policies

TABLE OF CONTENTS

Abstract                                                             1
Table of contents                                                    2
1.  Introduction                                                     3
2.  Major Parties                                                    3
3.  Signature Policy Specification                                   5
3.1  Overall ASN.1 Structure                                         5
3.2  Signature Validation Policy                                     6
3.3  Common Rules                                                    7
3.4  Commitment Rules                                                8
3.5  Signer and Verifier Rules                                       9
3.5.1  Signer Rules                                                  9
3.5.2  Verifier Rules                                               10
3.6  Certificate and Revocation Requirements                        11
3.6.1  Certificate Requirements                                     11
3.6.2  Revocation Requirements                                      13
3.7  Signing Certificate Trust Conditions                           14
3.8  TimeStamp Trust Conditions                                     15
3.9  Attribute Trust Conditions                                     15
3.10  Algorithm Constraints                                         16
3.11  Signature Policy Extensions                                   17
4.  Security considerations                                         18
5.  Conformance Requirements                                        18
6.  References                                                      18
7. Authors' Addresses                                               19
8. Full Copyright Statement                                         20
Annex A (normative):                                                21
A.1  Definitions Using X.208 (1988) ASN.1 Syntax                    21
A.2  Definitions Using X.680 (1997) ASN.1 Syntax                    27
Annex B (informative):                                              34
B.1  Signature Policy and Signature Validation Policy               34
B.2  Identification of Signature Policy                             36
B.3  General Signature Policy Information                           36
B.4  Recognized Commitment Types                                    37
B.5  Rules for Use of Certification Authorities                     37
B.5.1  Trust Points                                                 37
B.5.2  Certification Path                                           38
B.6  Revocation Rules                                               39
B.7  Rules for the Use of Roles                                     39
B.7.1  Attribute Values                                             39
B.7.2  Trust Points for Certified Attributes                        39
B.7.3  Certification Path for Certified Attributes                  40
B.8  Rules for the Use of Timestamping and Timing                   40
B.8.1  Trust Points and Certificate Paths                           40
B.8.2  Timestamping Authority Names                                 40
B.8.3  Timing Constraints - Caution Period                          40
B.8.4  Timing Constraints - Timestamp Delay                         41
B.9  Rules for Verification Data to be followed                     41
B.10  Rules for Algorithm Constraints and Key Lengths               41
B.11  Other Signature Policy Rules                                  41
B.12  Signature Policy Protection                                   41

ETSI TC-SEC, Pinkas, Ross, Pope          Experimental RFC      [Page 2]

Internet Draft                                A Signature Policy Format

1.  Introduction

This document is intended to cover signature policies which can be 
used with electronic signatures for various types of transactions, 
including business transactions (e.g. purchase requisition, contract, 
and invoice applications). 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.

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

2.3     Major Parties

The document uses the following terms:

     * the Signature Policy Issuer;
     * the Signer;
     * the Verifier;
     * the Arbitrator;
     * Trusted Service Providers (TSP);

The Signature Policy Issuer (which is a Trusted Service Provider (TSP)) 
issues signatures policies that define the technical and procedural 
requirements for electronic signature creation, and validation/
verification, in order to meet a particular business need.

The Signer is the entity that creates the electronic signature. When 
the signer digitally signs over an signature policy identifier, it
represents a commitment on behalf of the signing entity that the data 
being signed is signed under the rules defined by the signature policy. 

The Verifier is the entity that validates the electronic signature, it 
may be a single entity or multiple entities. The verifier MUST validate 
the electronic signature under the rules defined by the electronic signature 
policy for the signature to be valid.

An arbitrator, is an entity which arbitrates disputes between a signer 
and a verifier. It acts as verifier when it verifies the electronic 
signature after it has been previously validated.

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 3]

Internet Draft                               Electronic Signature Policies

The Trusted Service Providers (TSPs) are one or more entities that help 
to build trust relationships between the signer and verifier. Use of TSP 
specific services MAY be mandated by signature policy. TSP supporting 
services include: user certificates, cross-certificates, timestamping 
tokens,CRLs, ARLs, OCSP responses. 

A Trusted Service Providers (TSPs) MAY be a Signature Policy Issuer, as 
Such, the TSP MUST define the technical and procedural requirements for 
electronic signature creation and validation, in order to meet a 
particular business need.

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

     * Certification Authorities;
     * Registration Authorities;
     * Repository Authorities (e.g. a Directory);
     * TimeStamping Authorities;
     * One-line Certificate Status Protocol responders;
     * Attribute Authorities.

Certification Authorities provide users with public key certificates.

Registration Authorities allows the registration of 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 data was formed before a 
given trusted time. 

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

Attributes Authorities provide users with attributes linked to public 
key certificates

An Arbitrator is an entity that arbitrates disputes between a signer 
and a verifier.

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 4]

Internet Draft                               Electronic Signature Policies

3.      Signature Policy Specification

A signature policy specification includes general information about the 
policy, the validation policy rules and other signature policy 
information. 

This document mandates that:
     * an electronic signature must be processed by the signer and 
       verifier in accordance with the signature policy referenced by
       the signer;
     * the signature policy referenced by the signer must be
       identifiable by an Object Identifier;
     * there must exist a specification of the signature policy;
     * for a given signature policy there must be one definitive form 
       of the specification which has a unique binary encoding;
     * a hash of the definitive specification, using an agreed 
       algorithm, must be provided by the signer and checked by the
       verifier.

This document defines but does not mandate the form of the signature 
policy specification. The signature policy may be specified either:

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

This document defines an ASN.1 based syntax that may be used to define 
a structured signature policy. Future versions of this document may 
include structured a signature policy specification using XML.

3.1     Overall ASN.1 Structure

The overall structure of a signature policy defined using ASN.1 is 
given in this section. Use of this ASN.1 structure is optional.

This ASN.1 syntax is encoded using the Distinguished Encoding Rules 
(DER).

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 5]

Internet Draft                               Electronic Signature Policies

In this structure the policy information is preceded by an identifier 
for the hashing algorithm used to protect the signature policy and 
followed by the hash value which must be re-calculated and checked 
whenever the signature policy is passed between the issuer and 
signer/verifier. 
The hash is calculated without the outer type and length fields.

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 

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

The fieldofApplication is a description of the expected application of 
this policy.

The signature validation policy rules are fully processable to allow 
the validation of electronic signatures issued under that form of 
signature policy. They are described in the rest of this section.

The signPolExtensions is a generic way to extend the definition of any 
sub-component of a signature policy. 

3.2     Signature Validation Policy

The signature validation policy defines for the signer which data 
elements must be present in the electronic signature he provides and 
for the verifier which data elements must be present under that 
signature policy for an electronic signature to be potentially valid.

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

Internet Draft                               Electronic Signature Policies

The signature validation policy is described as follows:

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

The signingPeriod 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 }

3.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  ::= 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.

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC          [Page 7]

Internet Draft                               Electronic Signature Policies

3.4     Commitment Rules

The CommitmentRules consists of the validation rules which apply to 
given commitment types:

CommitmentRules ::= SEQUENCE OF CommitmentRule

The CommitmentRule for given commitment types 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.

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 of commitment is 
indicated in the semantics of the message). Otherwise, the electronic 
signature must contain a commitment type indication that must fit one 
of the commitments types that are mentioned in CommitmentType.

A specific commitment type identifier must not appear 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 and 
meaning of the commitment within the overall field of application 
defined for the policy.

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC          [Page 8]

Internet Draft                               Electronic Signature Policies

3.5     Signer and Verifier Rules

The following rules apply to the format of electronic signatures defined using 
[ES-FORMATS].

The SignerAndVerifierRules consists of signer rule and verification 
rules as defined below:
SignerAndVerifierRules ::= SEQUENCE {
        signerRules      SignerRules,
        verifierRules    VerifierRules }

3.5.1   Signer Rules

The signer rules identify:

     * if the eContent is empty and the signature is calculated using
       a hash of signed data external to CMS structure.

     * the CMS signed attributes that must be provided by the signer
        under this policy;

     * the CMS unsigned attribute 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 the signer in
       the SigningCertificate attribute;

     * whether a signer's certificate, or all certificates in the 
       certification path to the trust point must be provided by the
       signer in the certificates field of SignedData.

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

The mandatedSignedAttr field must include the object identifier for 
all those signed attributes required by this document as well as 
additional attributes required by this policy.

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

Internet Draft                               Electronic Signature Policies

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 signature 
timestamp is required by the signer the object identifier for this
attribute must be included.

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

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

The mandatedCertificateInfo field identifies whether a signer's 
certificate, or all certificates in the certification path to the trust 
point must be provided by the signer in the certificates field of 
SignedData.

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
                                                   }

3.5.2   Verifier Rules

The verifier rules identify:
* The CMS unsigned attributes that must be present under this policy 
and must be added by the verifier if not added by the signer.

VerifierRules ::= SEQUENCE {
                mandatedUnsignedAttr    MandatedUnsignedAttr,
                signPolExtensions               SignPolExtensions  OPTIONAL
                                                                   }

MandatedUnsignedAttr ::=  CMSAttrs    
                                   -- Mandated CMS unsigned attributed

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

Internet Draft                               Electronic Signature Policies

3.6     Certificate and Revocation Requirement

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

3.6.1   Certificate Requirements

The certificateTrustTrees identifies a set of self signed certificates 
for the trust points used to start (or end) certificate path processing 
and the initial conditions for certificate path validation as defined 
RFC 2459 [7] section 4. This ASN1 structure is used to define policy 
for validating the signing certificate, the TSA's certificate and 
attribute certificates.

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 }

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 be 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 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 the initial set of certificate 
policies, any of which are acceptable under the signature policy.
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId

CertPolicyId ::= OBJECT IDENTIFIER

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

Internet Draft                               Electronic Signature Policies

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 of the type is in the certificate, the 
certificate is acceptable.

Restrictions are defined in terms of permitted or excluded name 
subtrees. Any name matching a restriction in the excludedSubtrees field 
is invalid regardless 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 to prohibit policy mapping or require 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 of additional certificates that may appear in the path 
(including the trustpoint's self certificate) before policy mapping is 
no longer permitted. For example, a value of one indicates that policy 
mapping may be processed in certificates issued by the subject 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 of 
requireExplicitPolicy indicates the number 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 of a policy required by the user of 
the certification path or the identifier of a policy which has been 
declared equivalent through policy mapping.

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

Internet Draft                               Electronic Signature Policies

3.6.2   Revocation Requirements

The RevocRequirements field specifies minimum requirements for 
revocation information, obtained through CRLs and/or OCSP responses, to 
be used in checking the revocation status of certificates. 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 in terms of checks 
required on:
     * endCertRevReq: end certificates (i.e. the signers certificate,
     the attribute certificate or the timestamping authority 
     certificate).

     * 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 in order to indicate that a datum existed at a 
particular point in time. See [TSP]

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 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 as defined by signature policy 
                  -- extension
          }

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

Internet Draft                               Electronic Signature Policies

Revocation requirements are specified 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 Status 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.

3.7     Signing 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
                                             }

3.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 of the timestamping authority.
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 in certificateTrustCondition applies to certification of the 
timestamping authorities public key.

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 14]

Internet Draft                               Electronic Signature Policies

The tstrRevReq specifies minimum requirements for revocation 
information, obtained through CRLs and/or OCSP responses, to be used in 
checking the revocation status of the time stamp that must be present 
in the ES-T.

If ttsNameConstraints is not present then there are no additional 
naming constraints 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 and that any relevant revocation 
has been notified. The revocation status information forming the ES 
with Complete validation data must 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, 
as used to form the ES Timestamped, is created for the verifier. If the 
signature timestamp is later that the time in the signing-time 
attribute by more than the value given in signatureTimestampDelay, the 
signature must be considered invalid.

3.9     Attribute Trust Conditions

If the attributeTrustCondition field is not present then any certified 
attributes may not considered to be valid under this validation policy.
The AttributeTrustCondition field is defined as follows:

AttributeTrustCondition ::= SEQUENCE {
        attributeMandated            BOOLEAN, 
                                     -- Attribute must 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 the 
following constraints, must be present. If false, then the signature 
is still valid if no attribute is specified.

The howCertAttribute field specifies whether attributes uncertified 
attributes "claimed" by the signer, or certified attributes 
(i.e. Attribute Certificates) or either  using the signer 
attributes attribute defined in [ES-FORMATS] section 3.12.3.

HowCertAttribute ::= ENUMERATED {
        claimedAttribute       (0),
        certifiedAttribtes     (1),
        either                 (2) }

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 15]

Internet Draft                               Electronic Signature Policies

The attrCertificateTrustTrees specifies certificate path conditions for 
any attribute certificate. If not present the same rules apply as in 
certificateTrustCondition.

The attrRevReq specifies minimum requirements for revocation 
information, obtained through CRLs and/or OCSP responses, to be used in 
checking the revocation status 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 {
        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 ::= 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

3.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 {   -- 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
                                                            }

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC        [Page 16]

Internet Draft                               Electronic Signature Policies

AlgorithmConstraints ::= SEQUENCE OF AlgAndLength

AlgAndLength ::= SEQUENCE {
        algID                   OBJECT IDENTIFIER,
        minKeyLength    INTEGER         OPTIONAL,
       -- Minimum key length in bits
        other           SignPolExtensions OPTIONAL
                 }

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

3.11    Signature Policy Extensions

Additional signature policy rules may be added to:

     * the overall signature policy structure, as defined in 
       section 3.1;
     * the signature validation policy structure, as defined in 
       section 3.2;
     * the common rules, as defined in section 3.3;
     * the commitment rules, as defined in section 3.4;
     * the signer rules, as defined in section 3.5.1;
     * the verifier rules, as defined in section 3.5.2;
     * the revocation requirements in section 3.6.2;
     * the algorithm constraints in section 3.10.

These extensions to the signature policy rules must be defined using 
an ASN.1 syntax with an associated object identifier carried in the 
SignPolExtn as defined below:

SignPolExtensions ::= SEQUENCE OF SignPolExtn

SignPolExtn ::= SEQUENCE {
                extnID      OBJECT IDENTIFIER,
                extnValue   OCTET STRING  }

The extnID field must contain the object identifier for the extension. 
The extnValue field must contain the DER (see ITU-T Recommendation 
X.690 [4]) encoded value of the extension.  The definition of an 
extension, as identified by extnID must include a definition of the 
syntax and semantics of the extension.

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 17]

Internet Draft                               Electronic Signature Policies

4.      Security considerations
To be defined

5.      Conformance Requirements

To be defined

6. References

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

[ES-FORMATS] ETSI TC-SEC, D.Pinkas, J.Ross, N.Pope. Electronic Signature 
formats for long term electronic signatures <draft-ietf-smime-esformats> 
To be published as an INFORMATIONAL RFC.

[TSP] C. Adams, D. Pinkas, R. Zuccherato, P. Cain. Time Stamp Protocol <draft-
ietf-pkix-tsp>.

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

[RFC2119] Bradner, S., "Key words for use in 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, RFC 2630, 
June 1999.

[RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public 
Key Infrastructure, 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.

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

Internet Draft                               Electronic Signature Policies

7. Authors' Addresses

This Experimental RFC has been produced in ETSI TC-SEC.

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

Contact Point

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

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

Denis Pinkas                          Nick 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

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 19]

Internet Draft                               Electronic Signature Policies

8. Full Copyright Statement 

Copyright (C) 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 in part, without restriction of any kind, 
provided 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 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 ofdeveloping Internet standards in which case 
the procedures for copyrights defined in the Internet Standards process 
must be followed, or as required to translate it into languages other than 
English. 

The limited permissions granted above are perpetual 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.

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 20]

Internet Draft                               Electronic Signature Policies

Annex A (normative):
ASN.1 Definitions
This annex provides the reference definition of the ASN.1 syntax 
signature policies definitions for new syntax defined in this document.

A.1  Definitions Using X.208 (1988) ASN.1 Syntax
NOTE: The ASN.1 Module defined in section A.1 has precedence over that defined 
in 
Annex A-2 in the case of any conflict.

ETS-ElectronicSignaturePolicies-88syntax { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 7}

DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS All 

IMPORTS 

-- 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)} 
                                                ;

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

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

Internet Draft                               Electronic Signature Policies

PolicyIssuerName ::= GeneralNames

FieldOfApplication ::= DirectoryString 

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

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
                                                                  }

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

Internet Draft                               Electronic Signature Policies

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 }

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
                                                  }

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 23]

Internet Draft                               Electronic Signature Policies

VerifierRules ::= SEQUENCE {
                mandatedUnsignedAttr    MandatedUnsignedAttr,
                signPolExtensions       SignPolExtensions   OPTIONAL
                                                  }

MandatedUnsignedAttr ::=  CMSAttrs    
-- Mandated CMS unsigned attributed

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         Experimental RFC         [Page 24]

Internet Draft                               Electronic Signature Policies

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         Experimental RFC         [Page 25]

Internet Draft                               Electronic Signature Policies

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-ElectronicSignaturePolicies-88syntax --

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 26]

Internet Draft                               Electronic Signature Policies

A.2     Definitions Using X.680 1997 ASN.1 Syntax

NOTE:   The ASN.1 module defined in section A.1 has precedence over that 
defined in section A.2 in the case of any conflict.

ETS-ElectronicSignaturePolicies-97Syntax { iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 8}

DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS All -

IMPORTS 

-- 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)}
;

-- S/MIME Object Identifier arcs used in the present document 
-- ==================================================================

-- S/MIME  OID arc used in the present 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

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

Internet Draft                              Electronic Signature Policies

-- 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 }

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC        [Page 28]

Internet Draft                              Electronic Signature Policies

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         Experimental RFC         [Page 29]

Internet Draft                               Electronic Signature Policies

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         Experimental RFC         [Page 30]

Internet Draft                               Electronic Signature Policies

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         Experimental RFC         [Page 31]

Internet Draft                               Electronic Signature Policies

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 }

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

Internet Draft                              Electronic Signature Policies

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-ElectronicPolicies-97Syntax

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 33]

Internet Draft                               Electronic Signature Policies

Annex B (informative):

B.1     Signature Policy and Signature Validation Policy

The definition of electronic signature mentions: "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. "

Electronic signatures are commonly applied within the context of a 
legal or contractual framework. This establishes the requirements on 
the electronic signatures and any special semantics (e.g. agreement, 
intent). These requirements may be defined in very general abstract 
terms or in terms of detailed rules. The specific semantics associated 
with an electronic signature implied by a legal or contractual 
framework are outside the scope of this document.

If the signature policy is recognized, within the legal/contractual 
context, as providing commitment, then the signer explicitly agrees 
with terms and conditions which are implicitly or explicitly part of 
the signed data.

When two independent parties want to evaluate an electronic signature, 
it is fundamental that they get the same result. It is therefore 
important that the conditions agreed by the signer at the time of 
signing are indicated to the verifier and any arbitrator. An aspect 
that enables this to be known by all parties is the signature policy. 
The technical implications of the signature policy on the electronic 
signature with all the validation data are called the "Signature 
Validation Policy". The signature validation policy specifies 
the rules used to validate the signature.

This document does not mandate the form and encoding of the 
specification of the signature policy. However, for a given signature 
policy there must be one definitive form that has a unique binary 
encoded value.

This document includes, as an option, a formal structure for signature 
validation policy based on the use of Abstract Syntax Notation 1 
(ASN.1).

Given the specification of the signature policy and its hash value an 
implementation of a verification process must obey the rules defined 
in the specification. 

This document places no restriction on how it should be implemented. 
Provide the implementation conforms to the conformance requirements as 
define in section 5 implementation options include:

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

Internet Draft                               Electronic Signature Policies

A validation process that supports a specific signature policy as 
identified by the signature policy OID. Such an implementation should 
conform to a human readable description provided all the processing 
rules 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 of 
implementation may be simpler to implement initially, but can be 
difficult to enhance to support numerous additional signature policies.

A validation process that is dynamically programmable and able to adapt 
its validation rules in accordance with a description 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 the validation rules 
specified as part of the signature policy are known by the 
implementation. (i.e. only requires modification if there are 
additional rules specified).

The precise content of a signature policy is not mandated by the 
current document. However, a signature policy must be sufficiently 
definitive to avoid any ambiguity as to its implementation 
requirements. It must be absolutely clear under which conditions an 
electronic signature should be accepted. For this reason, it should 
contain the following information:

     * General information about the signature policy which includes:
        - a unique identifier of the policy;
        - the name of the issuer of the policy;
        - the date the policy was issued;
        - the field of application of the policy.

     * The signature verification policy which includes:
       - the signing period,
       - 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 to be provided by the 
         signer/collected by verifier;
       - any constraints on signature algorithms and key lengths.
     * Other signature policy rules required to meet the objectives of 
       the signature.

Variations of the validation policy rules may apply to different 
commitment types.

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 35]

Internet Draft                               Electronic Signature Policies

B.2     Identification of Signature Policy

When data is signed the signer indicates the signature policy 
applicable to that electronic signature by including an object 
identifier for the signature policy with the signature. The signer and 
verifier must apply the rules specified by the identified policy. In 
addition to the identifier of the signature policy the signer must 
include the hash 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. This can 
includes:

     * A URL where a copy of the Signature Policy may be obtained;
     * A user notice 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 the context of a signature policy.

A "Signature Policy" will be identifiable by an OID (Object Identifier) 
and verifiable using a hash of the signature policy.

B.3     General Signature Policy Information

General information should be recorded about the signature policy along 
with the definition of the rules which form the signature policy as 
described in subsequent subsections. This should include:

     * Policy Object Identifier: The "Signature Policy" will be 
       identifiable by an OID (Object Identifier) whose last component 
       (i.e. right most) is an integer that is specific to a particular 
        version issued on the given date.
     * Date of issue: When the "Signature Policy" was issued.
     * Signature Policy Issuer name: An identifier for the body 
       responsible for issuing the Signature Policy. This may be used 
       by the signer or verifying in deciding if a policy is to be 
       trusted, in which case the signer/verifier must authenticate 
       the origin of the signature policy as coming from the identified 
       issuer.
     * Signing period: The start time and date, optionally with an end 
       time and date, for the period over which the signature policy 
       may be used to generate electronic signatures.
     * Field of application: This defines in general terms the general 
       legal/contract/application contexts in which the signature 
       policy is to be used and the specific purposes for which the 
       electronic signature is to be applied.

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

Internet Draft                               Electronic Signature Policies

B.4     Recognized Commitment Types

The signature validation policy may recognize one or more types of 
commitment as being supported by electronic signatures produced under 
the security policy. If an electronic signature does not contain a 
recognized commitment type then the semantics of the electronic 
signature is dependent on the data being signed and the context in 
which it is being used.

Only recognized commitment types are allowed in an electronic 
signature.

The definition of a commitment type includes:
     * the object identifier for the commitment;
     * the contractual/legal/application context in which the signature 
        may be used (e.g. submission of messages);
     * a description of the support provided within the terms of the 
       context (e.g. proof that the identified source submitted the 
       message if the signature is created when message submission is 
       initiated).

The definition of a commitment type can be registered:
     * as part of the validation policy;
     * as part of the application/contract/legal environment;
     * as part of generic register of definitions.

The legal/contractual context will determine the rules applied to the 
signature, as defined by the signature policy and its recognized 
commitment types, make it fit for purpose intended.

B.5     Rules for Use of Certification Authorities

The certificate validation process of the verifier, and hence the 
certificates that may be used by the signer for a valid electronic 
signature, may be constrained by the combination of the trust point and 
certificate path constraints in the signature validation policy.

B.5.1   Trust Points

The signature validation policy defines the certification authority 
trust points that are to be used for signature verification. Several 
trust points may be specified under one signature policy. Specific 
trust points may be specified for a particular type of commitment 
defined under the signature policy. For a signature to be valid a 
certification path must exists between the Certification Authority 
that has granted the certificate selected by the signer (i.e. the used 
user-certificate) and one of the trust point of the "Signature 
Validation Policy".

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 37]

Internet Draft                               Electronic Signature Policies

B.5.2   Certification Path

There may be constraints on the use 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 the certification chain 
       between the user certificate and the certificate of the trusted 
       point to a given set of certificate policies, or equivalents 
       identified through certificate policy mapping.
     * The naming constraints limit the forms of names that the CA is 
       allowed to certify.

Name constraints are particularly important when a "Signature policy" 
identifies more than one trust point. In this case, a certificate of a 
particular trusted point may only be used to verify signatures from 
users with names permitted under the name constraint.

Certificate Authorities may be organized in a tree structure, this tree 
structure may represent the trust relationship between various CA(s) 
and the users CA. Alternatively, a mesh relationship may exist where a 
combination of tree and peer cross-certificates may be used. The 
requirement of the certificate path in this document is that it 
provides the trust relationship between all the CAs and the signers 
user certificate. The starting point from a verification point of view,
 is the "trust point". A trust point is usually a CA that publishes 
self-certified certificates, is the starting point from which the 
verifier verifies the certificate chain. Naming constraints may 
apply from the trust point, in which case they apply throughout the set 
of certificates that make up the certificate path down to the signer's 
user certificate.

Policy constraints can be easier to process but to be effective require 
the presence of a certificate policy identifier in the certificates 
used in a certification path.

Certificate path processing, thus generally starts with one of the 
trust point from the signature policy and ends with the user 
certificate. The certificate path processing procedures defined in RFC 
2459 section 6 identifies the following initial parameters that are 
selected by 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 and 
       whether certificate policy mapping are allowed;
     * restrictions on the certificate path length.

The signature validation policy identifies constraints on these 
parameters.

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 38]

Internet Draft                               Electronic Signature Policies

B.6     Revocation Rules

The signature policy should defines rules specifying requirements for 
the use of certificate revocation lists (CRLs) and/or on-line 
certificate status check service to check the validity of 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 with 
CRLs checks being carried out for certificate status that are 
unavailable from OCSP servers. The verifier may take into account 
information in the certificate in deciding how best to check the 
revocation status (e.g. a certificate extension field about authority 
information access or a CRL distribution point) provided that it does 
not conflict with the signature policy revocation rules.

B.7     Rules for the Use of Roles

Roles can be supported as claimed roles or as certified roles using 
Attribute Certificates. 

B.7.1   Attribute Values

When signature under a role is mandated by the signature policy, then 
either Attribute Certificates may be used or the signer may provide a 
claimed role attribute. The acceptable attribute types or values may be 
dependent on the type of commitment. For example, a user may have 
several roles that allow the user to sign data that imply commitments 
based on one or more of his roles.

B.7.2   Trust Points for Certified Attributes

When a signature under a certified role is mandated by the signature 
policy, Attribute Authorities are used and need to be validated as part 
of the overall validation of the electronic signature. The trust points 
for Attribute Authorities do not need to be the same as the trust 
points to evaluate a certificate from the CA of the signer. Thus the 
trust point for verifying roles need not be the same as trust point 
used to validate the certificate path of the user's key. 

Naming and certification policy constraints may apply to the AA in 
similar circumstance to when they apply to CA. Constraints on the AA 
and CA need not be exactly the same. 

AA(s) may be used when a signer is creating a signature on behalf of an 
organization, they can be particularly useful when the signature 
represents an organizational role. AA(s) may or may not be the same 
authority as CA(s).

Thus, the Signature Policy identifies trust points that can be used for 
Attribute Authorities, either by reference to the same trust points as 
used for Certification Authorities, or by an independent list.

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

Internet Draft                               Electronic Signature Policies

B.7.3   Certification Path for Certified Attributes

Attribute Authorities may be organized in a tree structure in similar 
way to CA where the AAs are the leafs of such a tree. Naming and other 
constraints may be required on attribute certificate paths in a similar 
manner to other electronic signature certificate paths.  

Thus, the Signature Policy identify constraints on the following 
parameters used as input 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 and excluded naming 
       subtrees;
     * restrictions on the certificate path length.

B.8     Rules for the Use of Timestamping and Timing

The following rules should be used when specifying, constraints on the 
certificate paths for timestamping authorities, constraints on the 
timestamping authority names and general timing constraints.

B.8.1   Trust Points and Certificate Paths

Signature keys from timestamping authorities will need to be supported 
by a certification path. The certification path used for timestamping 
authorities requires a trustpoint and possibly path constraints in the 
same way that the certificate path for the signer's key.

B.8.2   Timestamping Authority Names

Restrictions may need to be placed by the validation policy on the 
named entities that may act a timestamping authorities.

B.8.3   Timing Constraints - Caution Period

Before an electronic signature may really be valid, the verifier has to 
be sure that the holder of the private key was really the only one in 
possession of key at the time of signing. However, there is an 
inevitable delay between a compromise or loss of key being noted, and a 
report of revocation being distributed. To allow greater confidence in 
the validity of a signature, a "cautionary period" may be identified 
before a signature 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.

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 40]

Internet Draft                               Electronic Signature Policies

B.8.4   Timing Constraints - Timestamp Delay

There will be some delay between the time that a signature is created 
and 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 by the signer. Thus the signature policy should 
specify a maximum acceptable delay between the signing time as claimed 
by the signer and the time included within the timestamp.

B.9     Rules for Verification Data to be followed

By specifying the requirements on the signer and verifier the 
responsibilities of the two parties can be clearly defined to establish 
all the necessary information.

These verification data rules should include:
* requirements on the signer to provide given signed attributes;
* requirements on the verifier to obtain additional certificates, CRLs, 
results of on line certificate status checks and to use timestamps (if 
no already provided by the signer).

B.10    Rules for Algorithm Constraints and Key Lengths
The signature validation policy may identify a set of signing 
algorithms (hashing, public key, combinations) and minimum key lengths 
that may be used:

     * by the signer in creating the signature;
     * in end entity public key Certificates;
     * CA Certificates;
     * attribute Certificates;
     * by the timestamping authority.

B.11    Other Signature Policy Rules

The signature policy may specify additional policy rules, for example 
rules that relate to the environment used by the signer. These 
additional rules may be defined in computer processable and/or human 
readable form.

B.12    Signature Policy Protection

When signer or verifier obtains a copy of the Signature Policy from an 
issuer, the source should be authenticated (for example by using 
electronic signatures). When the signer references a signature policy 
the Object Identifier (OID) of the policy, the hash value and the hash 
algorithm OID of that policy must be included in the Electronic 
Signature. 

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

Internet Draft                               Electronic Signature Policies

It is a mandatory requirement of this present document that the 
signature policy value computes to one, and only one hash value using 
the specified hash algorithm. This means that there must be a single 
binary value of the encoded form of the signature policy for the unique 
hash value to be calculated. For example, there may exist a particular 
file type, length and format on which the hash value is calculated 
which is fixed and definitive for a particular signature policy.

The hash value may be obtained by:

      the signer performing his own computation of the hash over the 
      signature policy using his preferred hash algorithm permitted by
      the signature policy, and the definitive binary encoded form.
      
      the signer, having verified the source of the policy, may use 
      both the hash algorithm and the hash value included in the 
      computer processable form of the policy (see section 6.1).

ETSI TC-SEC, Ross, Pinkas, Pope         Experimental RFC         [Page 42]