draft-ietf-smime-espolicies-01.txt   rfc3125.txt 
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 Network Working Group J. Ross
<draft-ietf-smime-espolicies-01.txt> Request for Comments: 3125 Security & Standards
Category: Experimental D. Pinkas
Integris
N. Pope
Security & Standards
September 2001
Status of this Memo Electronic Signature Policies
This document is an Internet-Draft and is in full conformance with all Status of this Memo
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 This memo defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. It does not specify an Internet standard of any kind.
time. It is inappropriate to use Internet-Drafts as reference material Discussion and suggestions for improvement are requested.
or to cite them other than as "work in progress." Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2001). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This RFC defines signature policies for electronic signatures. This document defines signature policies for electronic signatures. A
A signature policy is a set of rules for the creation and validation signature policy is a set of rules for the creation and validation of
of an electronic signature, under which the validity of signature can an electronic signature, under which the validity of signature can be
be determined. A given legal/contractual context may recognize a determined. A given legal/contractual context may recognize a
particular signature policy as meeting its requirements. 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 A signature policy has a globally unique reference, which is bound to
another part of the signature policy specifies the electronic an electronic signature by the signer as part of the signature
rules for the creation and validation of the electronic signature in calculation.
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 The signature policy needs to be available in human readable form so
ETSI TS 101 733 V1.2.2 The ETSI TS is under the ETSI Copyright (C). that it can be assessed to meet the requirements of the legal and
Individual copies of this ETSI deliverable can be downloaded from contractual context in which it is being applied.
http://www.etsi.org.
Internet Draft Electronic Signature Policies 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.
TABLE OF CONTENTS The contents of this document is based on the signature policy
defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C).
Individual copies of this ETSI deliverable can be downloaded from
http://www.etsi.org.
Abstract 1 Table of Contents
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
Internet Draft A Signature Policy Format 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 11
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 Time-Stamp Trust Conditions 15
3.9 Attribute Trust Conditions 16
3.10 Algorithm Constraints 17
3.11 Signature Policy Extensions 18
4. Security Considerations 18
4.1 Protection of Private Key 18
4.2 Choice of Algorithms 18
5. Conformance Requirements 19
6. References 19
7. Authors' Addresses 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 38
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 40
B.7.3 Certification Path for Certified Attributes 40
B.8 Rules for the Use of Time-Stamping and Timing 40
B.8.1 Trust Points and Certificate Paths 41
B.8.2 Time-Stamping Authority Names 41
B.8.3 Timing Constraints - Caution Period 41
B.8.4 Timing Constraints - Time-Stamp Delay 41
B.9 Rules for Verification Data to be followed 41
B.10 Rules for Algorithm Constraints and Key Lengths 42
B.11 Other Signature Policy Rules 42
B.12 Signature Policy Protection 42
Full Copyright Statement 44
1. Introduction 1. Introduction
This document is intended to cover signature policies which can be This document is intended to cover signature policies which can be
used with electronic signatures for various types of transactions, used with electronic signatures for various types of transactions,
including business transactions (e.g. purchase requisition, contract, including business transactions (e.g., purchase requisition,
and invoice applications). Electronic signatures can be used for any contract, and invoice applications). Electronic signatures can be
transaction between an individual and a company, between two used for any transaction between an individual and a company, between
companies, between an individual and a governmental body, etc. two companies, between an individual and a governmental body, etc.
This document is independent of any environment. It can be applied This document is independent of any environment. It can be applied
to any environment e.g. smart cards, GSM SIM cards, special programs to any environment e.g., smart cards, GSM SIM cards, special programs
for electronic signatures etc. 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 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].
The document uses the following terms: 2. Major Parties
* the Signature Policy Issuer; The document uses the following terms:
* the Signer;
* the Verifier;
* the Arbitrator;
* Trusted Service Providers (TSP);
The Signature Policy Issuer (which is a Trusted Service Provider (TSP)) * the Signature Policy Issuer;
issues signatures policies that define the technical and procedural * the Signer;
requirements for electronic signature creation, and validation/ * the Verifier;
verification, in order to meet a particular business need. * the Arbitrator;
* Trusted Service Providers (TSP);
The Signer is the entity that creates the electronic signature. When The Signature Policy Issuer (which is a Trusted Service Provider
the signer digitally signs over an signature policy identifier, it (TSP)) issues signatures policies that define the technical and
represents a commitment on behalf of the signing entity that the data procedural requirements for electronic signature creation, and
being signed is signed under the rules defined by the signature policy. validation/ verification, in order to meet a particular business
need.
The Verifier is the entity that validates the electronic signature, it The Signer is the entity that creates the electronic signature. When
may be a single entity or multiple entities. The verifier MUST validate the signer digitally signs over an signature policy identifier, it
the electronic signature under the rules defined by the electronic signature represents a commitment on behalf of the signing entity that the data
policy for the signature to be valid. being signed is signed under the rules defined by the signature
policy.
An arbitrator, is an entity which arbitrates disputes between a signer The Verifier is the entity that validates the electronic signature,
and a verifier. It acts as verifier when it verifies the electronic it may be a single entity or multiple entities. The verifier MUST
signature after it has been previously validated. validate the electronic signature under the rules defined by the
electronic signature policy for the signature to be valid.
Internet Draft Electronic Signature Policies 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.
The Trusted Service Providers (TSPs) are one or more entities that help The Trusted Service Providers (TSPs) are one or more entities that
to build trust relationships between the signer and verifier. Use of TSP help to build trust relationships between the signer and verifier.
specific services MAY be mandated by signature policy. TSP supporting Use of TSP specific services MAY be mandated by signature policy.
services include: user certificates, cross-certificates, timestamping TSP supporting services include: user certificates, cross-
tokens,CRLs, ARLs, OCSP responses. certificates, time-stamping tokens,CRLs, ARLs, OCSP responses.
A Trusted Service Providers (TSPs) MAY be a Signature Policy Issuer, as A Trusted Service Providers (TSPs) MAY be a Signature Policy Issuer,
Such, the TSP MUST define the technical and procedural requirements for as Such, the TSP MUST define the technical and procedural
electronic signature creation and validation, in order to meet a requirements for electronic signature creation and validation, in
particular business need. order to meet a particular business need.
The following other TSPs are used to support the The following other TSPs are used to support the functions defined in
functions defined in this document: this document:
* Certification Authorities; * Certification Authorities;
* Registration Authorities; * Registration Authorities;
* Repository Authorities (e.g. a Directory); * Repository Authorities (e.g., a Directory);
* TimeStamping Authorities; * Time-Stamping Authorities;
* One-line Certificate Status Protocol responders; * One-line Certificate Status Protocol responders;
* Attribute Authorities. * Attribute Authorities.
Certification Authorities provide users with public key certificates. Certification Authorities provide users with public key certificates.
Registration Authorities allows the registration of entities before a Registration Authorities allows the registration of entities before a
CA generates certificates. CA generates certificates.
Repository Authorities publish CRLs issued by CAs, , cross-certificates Repository Authorities publish CRLs issued by CAs, , cross-
(i.e. CA certificates) issued by CAs, signature policies certificates (i.e., CA certificates) issued by CAs, signature
issued by Signature Policy Issuers and optionally public key policies issued by Signature Policy Issuers and optionally public key
certificates (i.e. leaf certificates) issued by CAs. certificates (i.e., leaf certificates) issued by CAs.
TimeStamping Authorities attest that some data was formed before a Time-Stamping Authorities attest that some data was formed before a
given trusted time. given trusted time.
One-line Certificate Status Protocol responders (OSCP responders) One-line Certificate Status Protocol responders (OSCP responders)
provide information about the status (i.e. revoked, not revoked, provide information about the status (i.e., revoked, not revoked,
unknown) of a particular certificate. unknown) of a particular certificate.
Attributes Authorities provide users with attributes linked to public Attributes Authorities provide users with attributes linked to public
key certificates key certificates
An Arbitrator is an entity that arbitrates disputes between a signer An Arbitrator is an entity that arbitrates disputes between a signer
and a verifier. and a verifier.
Internet Draft Electronic Signature Policies 3. Signature Policy Specification
3. Signature Policy Specification A signature policy specification includes general information about
the policy, the validation policy rules and other signature policy
information.
A signature policy specification includes general information about the This document mandates that:
policy, the validation policy rules and other signature policy
information.
This document mandates that: * an electronic signature must be processed by the signer and
* an electronic signature must be processed by the signer and verifier in accordance with the signature policy referenced by
verifier in accordance with the signature policy referenced by the signer;
the signer; * the signature policy referenced by the signer must be
* the signature policy referenced by the signer must be identifiable by an Object Identifier;
identifiable by an Object Identifier; * there must exist a specification of the signature policy;
* there must exist a specification of the signature policy; * for a given signature policy there must be one definitive form
* for a given signature policy there must be one definitive form of the specification which has a unique binary encoding;
of the specification which has a unique binary encoding; * a hash of the definitive specification, using an agreed
* a hash of the definitive specification, using an agreed algorithm, must be provided by the signer and checked by the
algorithm, must be provided by the signer and checked by the verifier.
verifier.
This document defines but does not mandate the form of the signature This document defines but does not mandate the form of the signature
policy specification. The signature policy may be specified either: policy specification. The signature policy may be specified either:
* in a free form document for human interpretation; or * in a free form document for human interpretation; or
* in a structured form using an agreed syntax and encoding. * in a structured form using an agreed syntax and encoding.
This document defines an ASN.1 based syntax that may be used to define This document defines an ASN.1 based syntax that may be used to
a structured signature policy. Future versions of this document may define a structured signature policy. Future versions of this
include structured a signature policy specification using XML. document may include structured a signature policy specification
using XML.
3.1 Overall ASN.1 Structure 3.1 Overall ASN.1 Structure
The overall structure of a signature policy defined using ASN.1 is The overall structure of a signature policy defined using ASN.1 is
given in this section. Use of this ASN.1 structure is optional. given in this section. Use of this ASN.1 structure is optional.
This ASN.1 syntax is encoded using the Distinguished Encoding Rules This ASN.1 syntax is encoded using the Distinguished Encoding Rules
(DER). (DER).
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.
In this structure the policy information is preceded by an identifier The hash is calculated without the outer type and length fields.
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 { SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier, signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo, signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL } signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE { SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId, signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime, dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName, policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication, fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy, signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions signPolExtensions SignPolExtensions
OPTIONAL OPTIONAL
} }
SignPolicyId ::= OBJECT IDENTIFIER SignPolicyId ::= OBJECT IDENTIFIER
PolicyIssuerName ::= GeneralNames PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString FieldOfApplication ::= DirectoryString
The policyIssuerName field identifies the policy issuer in one or more The policyIssuerName field identifies the policy issuer in one or
of the general name forms. 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 fieldofApplication is a description of the expected application
the validation of electronic signatures issued under that form of of this policy.
signature policy. They are described in the rest of this section.
The signPolExtensions is a generic way to extend the definition of any The signature validation policy rules are fully processable to allow
sub-component of a signature policy. the validation of electronic signatures issued under that form of
signature policy. They are described in the rest of this section.
3.2 Signature Validation Policy The signPolExtensions is a generic way to extend the definition of
any sub-component of a signature policy.
The signature validation policy defines for the signer which data 3.2 Signature Validation Policy
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.
Internet Draft Electronic Signature Policies 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.
The signature validation policy is described as follows: The signature validation policy is described as follows:
SignatureValidationPolicy ::= SEQUENCE { SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod, signingPeriod SigningPeriod,
commonRules CommonRules, commonRules CommonRules,
commitmentRules CommitmentRules, commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions OPTIONAL signPolExtensions SignPolExtensions OPTIONAL
} }
The signingPeriod identifies the date and time before which the The signingPeriod identifies the date and time before which the
signature policy SHOULD NOT be used for creating signatures, and an signature policy SHOULD NOT be used for creating signatures, and an
optional date after which it should not be used for creating optional date after which it should not be used for creating
signatures. signatures.
SigningPeriod ::= SEQUENCE { SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime, notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL } notAfter GeneralizedTime OPTIONAL }
3.3 Common Rules 3.3 Common Rules
The CommonRules define rules that are common to all commitment types. The CommonRules define rules that are common to all commitment types.
These rules are defined in terms of trust conditions for certificates, These rules are defined in terms of trust conditions for
timestamps and attributes, along with any constraints on attributes certificates, time-stamps and attributes, along with any constraints
that may be included in the electronic signature. on attributes that may be included in the electronic signature.
CommonRules ::= SEQUENCE { CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL, OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL, OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL, OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL, OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL, OPTIONAL,
signPolExtensions [5] SignPolExtensions signPolExtensions [5] SignPolExtensions
OPTIONAL OPTIONAL
} }
If a field is present in CommonRules then the equivalent field must 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 not be present in any of the CommitmentRules (see below). If any of
following fields are not present in CommonRules then it must be the following fields are not present in CommonRules then it must be
present in each CommitmentRule: present in each CommitmentRule:
* signerAndVeriferRules;
* signingCertTrustCondition;
* timeStampTrustCondition.
Internet Draft Electronic Signature Policies * signerAndVeriferRules;
* signingCertTrustCondition;
* timeStampTrustCondition.
3.4 Commitment Rules 3.4 Commitment Rules
The CommitmentRules consists of the validation rules which apply to The CommitmentRules consists of the validation rules which apply to
given commitment types: given commitment types:
CommitmentRules ::= SEQUENCE OF CommitmentRule CommitmentRules ::= SEQUENCE OF CommitmentRule
The CommitmentRule for given commitment types are defined in terms of The CommitmentRule for given commitment types are defined in terms of
trust conditions for certificates, timestamps and attributes, along trust conditions for certificates, time-stamps and attributes, along
with any constraints on attributes that may be included in the with any constraints on attributes that may be included in the
electronic signature. electronic signature.
CommitmentRule ::= SEQUENCE { CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes, selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL, OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL, OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL, OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL, OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL, OPTIONAL,
signPolExtensions [5] SignPolExtensions signPolExtensions [5] SignPolExtensions
OPTIONAL OPTIONAL
} }
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE { SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL, empty NULL,
recognizedCommitmentType CommitmentType } recognizedCommitmentType CommitmentType }
If the SelectedCommitmentTypes indicates "empty" then this rule applied If the SelectedCommitmentTypes indicates "empty" then this rule
when a commitment type is not present (i.e. the type of commitment is applied when a commitment type is not present (i.e., the type of
indicated in the semantics of the message). Otherwise, the electronic commitment is indicated in the semantics of the message). Otherwise,
signature must contain a commitment type indication that must fit one the electronic signature must contain a commitment type indication
of the commitments types that are mentioned in CommitmentType. 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 A specific commitment type identifier must not appear in more than
commitment rule. one commitment rule.
CommitmentType ::= SEQUENCE { CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier, identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL, fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL } semantics [1] DirectoryString OPTIONAL }
The fieldOfApplication and semantics fields define the specific use and The fieldOfApplication and semantics fields define the specific use
meaning of the commitment within the overall field of application and meaning of the commitment within the overall field of application
defined for the policy. defined for the policy.
Internet Draft Electronic Signature Policies 3.5 Signer and Verifier Rules
3.5 Signer and Verifier Rules The following rules apply to the format of electronic signatures
defined using [ES-FORMATS].
The following rules apply to the format of electronic signatures defined using The SignerAndVerifierRules consists of signer rule and verification
[ES-FORMATS]. rules as defined below:
The SignerAndVerifierRules consists of signer rule and verification
rules as defined below:
SignerAndVerifierRules ::= SEQUENCE { SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules, signerRules SignerRules,
verifierRules VerifierRules } verifierRules VerifierRules }
3.5.1 Signer Rules 3.5.1 Signer Rules
The signer rules identify: The signer rules identify:
* if the eContent is empty and the signature is calculated using * if the eContent is empty and the signature is calculated using
a hash of signed data external to CMS structure. a hash of signed data external to CMS structure.
* the CMS signed attributes that must be provided by the signer * the CMS signed attributes that must be provided by the signer
under this policy; under this policy;
* the CMS unsigned attribute that must be provided by the signer * the CMS unsigned attribute that must be provided by the signer
under this policy; under this policy;
* whether the certificate identifiers from the full certification * whether the certificate identifiers from the full certification
path up to the trust point must be provided by the signer in path up to the trust point must be provided by the signer in
the SigningCertificate attribute; the SigningCertificate attribute;
* whether a signer's certificate, or all certificates in the * whether a signer's certificate, or all certificates in the
certification path to the trust point must be provided by the certification path to the trust point must be by the signer in
signer in the certificates field of SignedData. the * certificates field of SignedData.
SignerRules ::= SEQUENCE { SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL, externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure -- True if signed data is external to CMS structure
-- False if signed data part of CMS structure -- False if signed data part of CMS structure
-- not present if either allowed -- Not present if either allowed
mandatedSignedAttr CMSAttrs, mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes -- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs, mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed -- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly, mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference -- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions OPTIONAL
}
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions OPTIONAL
}
The mandatedSignedAttr field must include the object identifier for CMSattrs ::= SEQUENCE OF OBJECT IDENTIFIER
all those signed attributes required by this document as well as
additional attributes required by this policy.
Internet Draft Electronic Signature Policies The mandated SignedAttr field must include the object identifier for
all those signed attributes required by this document as well as
additional attributes required by this policy.
The mandatedUnsignedAttr field must include the object identifier for The mandatedUnsignedAttr field must include the object identifier for
all those unsigned attributes required by this document as well as all those unsigned attributes required by this document as well as
additional attributes required this policy. For example, if a signature additional attributes required by this policy. For example, if a
timestamp is required by the signer the object identifier for this signature time-stamp <see section 1.1) is required by the signer the
attribute must be included. object identifier for this attribute must be included.
The mandatedCertificateRef identifies whether just the signer's The mandatedCertificateRef identifies whether just the signer's
certificate, or all the full certificate path must be provided by the certificate, or all the full certificate path must be provided by the
signer. signer.
CertRefReq ::= ENUMERATED { CertRefReq ::= ENUMERATED {
signerOnly (1), signerOnly (1),
-- Only reference to signer cert mandated -- Only reference to signer cert mandated
fullPath (2) fullpath (2)
-- References for full cert path up to a trust point required -- References for full cert path up to a trust point required
} }
The mandatedCertificateInfo field identifies whether a signer's The mandatedCertificateInfo field identifies whether a signer's
certificate, or all certificates in the certification path to the trust certificate, or all certificates in the certification path to the
point must be provided by the signer in the certificates field of trust point must be provided by the signer in the certificates field
SignedData. of SignedData.
CertInfoReq ::= ENUMERATED { CertInfoReq ::= ENUMERATED {
none (0) , none (0) ,
-- No mandatory requirements -- No mandatory requirements
signerOnly (1) , signerOnly (1) ,
-- Only reference to signer cert mandated -- Only reference to signer cert mandated
fullPath (2) fullpath (2)
-- References for full cert path up to a -- References for full cert path up to a
-- trust point mandated -- trust point mandated
} }
3.5.2 Verifier Rules 3.5.2 Verifier Rules
The verifier rules identify: 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. * 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 { VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr, mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL signPolExtensions SignPolExtensions OPTIONAL
} }
MandatedUnsignedAttr ::= CMSAttrs MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed -- Mandated CMS unsigned attributed
Internet Draft Electronic Signature Policies 3.6 Certificate and Revocation Requirement
3.6 Certificate and Revocation Requirement
The SigningCertTrustCondition, TimestampTrustCondition and The SigningCertTrustCondition, TimestampTrustCondition and
AttributeTrustCondition (defined in subsequent sub-sections) make use of AttributeTrustCondition (defined in subsequent sub-sections) make use
two ASN1 structures which are defined below: CertificateTrustTrees and of two ASN1 structures which are defined below: CertificateTrustTrees
CertRevReq. and CertRevReq.
3.6.1 Certificate Requirements 3.6.1 Certificate Requirements
The certificateTrustTrees identifies a set of self signed certificates The certificateTrustTrees identifies a set of self signed
for the trust points used to start (or end) certificate path processing certificates for the trust points used to start (or end) certificate
and the initial conditions for certificate path validation as defined path processing and the initial conditions for certificate path
RFC 2459 [7] section 4. This ASN1 structure is used to define policy validation as defined RFC 2459 [7] section 4. This ASN1 structure is
for validating the signing certificate, the TSA's certificate and used to define policy for validating the signing certificate, the
attribute certificates. TSA's certificate and attribute certificates.
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustPoint ::= SEQUENCE { CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate, trustpoint Certificate,
-- self-signed certificate -- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL, pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy" -- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL, nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints 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 The trustPoint field gives the self signed certificate for the CA
that may be in a certification path following the trustpoint. A value that is used as the trust point for the start of certificate path
of zero indicates that only the given trustpoint certificate and an processing.
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 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.
The acceptablePolicySet field identifies the initial set of certificate PathLenConstraint ::= INTEGER (0..MAX)
policies, any of which are acceptable under the signature policy.
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER The acceptablePolicySet field identifies the initial set of
certificate policies, any of which are acceptable under the signature
policy. AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
Internet Draft Electronic Signature Policies CertPolicyId ::= OBJECT IDENTIFIER
The nameConstraints field indicates a name space within which all The nameConstraints field indicates a name space within which all
subject names in subsequent certificates in a certification path must subject names in subsequent certificates in a certification path must
be located. Restrictions may apply to the subject distinguished name or be located. Restrictions may apply to the subject distinguished name
subject alternative names. Restrictions apply only when the specified or subject alternative names. Restrictions apply only when the
name form is present. If no name of the type is in the certificate, the specified name form is present. If no name of the type is in the
certificate is acceptable. certificate, the certificate is acceptable.
Restrictions are defined in terms of permitted or excluded name Restrictions are defined in terms of permitted or excluded name
subtrees. Any name matching a restriction in the excludedSubtrees field subtrees. Any name matching a restriction in the excludedSubtrees
is invalid regardless of information appearing in the ermittedSubtrees. field is invalid regardless of information appearing in the
permittedSubtrees.
NameConstraints ::= SEQUENCE { NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL, permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL } excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE { GeneralSubtree ::= SEQUENCE {
base GeneralName, base GeneralName,
minimum [0] BaseDistance DEFAULT 0, minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL } maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX) BaseDistance ::= INTEGER (0..MAX)
The policyConstraints extension constrains path processing in two ways. The policyConstraints extension constrains path processing in two
It can be used to prohibit policy mapping or require that each ways. It can be used to prohibit policy mapping or require that each
certificate in a path contain an acceptable policy identifier. certificate in a path contain an acceptable policy identifier.
The policyConstraints field, if present specifies requirement for The policyConstraints field, if present specifies requirement for
explicit indication of the certificate policy and/or the constraints on explicit indication of the certificate policy and/or the constraints
policy mapping. on policy mapping.
PolicyConstraints ::= SEQUENCE { PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL, requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL } inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX) SkipCerts ::= INTEGER (0..MAX)
If the inhibitPolicyMapping field is present, the value indicates the If the inhibitPolicyMapping field is present, the value indicates the
number of additional certificates that may appear in the path number of additional certificates that may appear in the path
(including the trustpoint's self certificate) before policy mapping is (including the trustpoint's self certificate) before policy mapping
no longer permitted. For example, a value of one indicates that policy is no longer permitted. For example, a value of one indicates that
mapping may be processed in certificates issued by the subject of this policy mapping may be processed in certificates issued by the subject
certificate, but not in additional certificates in the path. 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.
Internet Draft Electronic Signature Policies 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.
3.6.2 Revocation Requirements 3.6.2 Revocation Requirements
The RevocRequirements field specifies minimum requirements for The RevocRequirements field specifies minimum requirements for
revocation information, obtained through CRLs and/or OCSP responses, to revocation information, obtained through CRLs and/or OCSP responses,
be used in checking the revocation status of certificates. This ASN1 to be used in checking the revocation status of certificates. This
structure is used to define policy for validating the signing ASN1 structure is used to define policy for validating the signing
certificate, the TSA's certificate and attribute certificates. certificate, the TSA's certificate and attribute certificates.
CertRevReq ::= SEQUENCE { CertRevReq ::= SEQUENCE {
endCertRevReq RevReq, endCertRevReq RevReq,
caCerts [0] RevReq caCerts [0] RevReq
} }
Certificate revocation requirements are specified in terms of checks Certificate revocation requirements are specified in terms of checks
required on: required on:
* endCertRevReq: end certificates (i.e. the signers certificate,
the attribute certificate or the timestamping authority
certificate).
* caCerts: CA certificates. * endCertRevReq: end certificates (i.e., the signers certificate,
the attribute certificate or the time-stamping authority
certificate).
RevReq ::= SEQUENCE { * caCerts: CA certificates.
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
An authority certificate is certificate issued to an authority (e.g. RevReq ::= SEQUENCE {
either to a certification authority or to an attribute authority (AA)). enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
A TimeStamping Authority (TSA) is a trusted third party that creates An authority certificate is certificate issued to an authority (e.g.,
time stamp tokens in order to indicate that a datum existed at a either to a certification authority or to an attribute authority
particular point in time. See [TSP] (AA)).
A Time-Stamping 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 { EnuRevReq ::= ENUMERATED {
clrCheck (0), clrCheck (0),
--Checks must be made against current CRLs --Checks must be made against current CRLs
-- (or authority revocation lists (ARL)) -- (or authority revocation lists (ARL))
ocspCheck (1), -- The revocation status must be checked ocspCheck (1), -- The revocation status must be checked
-- using the Online Certificate Status Protocol -- using the Online Certificate Status Protocol
-- (OCSP),RFC 2450. -- (OCSP),RFC 2450.
bothCheck (2), bothCheck (2),
-- Both CRL and OCSP checks must be carried out -- Both CRL and OCSP checks must be carried out
eitherCheck (3), eitherCheck (3),
-- At least one of CRL or OCSP checks must be -- At least one of CRL or OCSP checks must be
-- carried out -- carried out
noCheck (4), noCheck (4),
-- no check is mandated -- no check is mandated
other (5) other (5)
-- Other mechanism as defined by signature policy -- Other mechanism as defined by signature policy
-- extension -- extension
} }
Internet Draft Electronic Signature Policies Revocation requirements are specified in terms of:
Revocation requirements are specified in terms of: * clrCheck: Checks must be made against current CRLs (or
* clrCheck: Checks must be made against current CRLs (or authority revocation lists);
authority revocation lists); * ocspCheck: The revocation status must be checked using the
* ocspCheck: The revocation status must be checked using the Online Certificate Status Protocol (RFC 2450);
Online Certificate Status Protocol (RFC 2450); * bothCheck: Both OCSP and CRL checks must be carried out;
* bothCheck: Both OCSP and CRL checks must be carried out; * eitherCheck: Either OCSP or CRL checks must be carried out;
* eitherCheck: Either OCSP or CRL checks must be carried out; * noCheck: No check is mandated.
* noCheck: No check is mandated.
3.7 Signing Certificate Trust Conditions 3.7 Signing Certificate Trust Conditions
The SigningCertTrustCondition field identifies trust conditions for The SigningCertTrustCondition field identifies trust conditions for
certificate path processing used to validate the signing certificate. certificate path processing used to validate the signing certificate.
SigningCertTrustCondition ::= SEQUENCE { SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees, signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq signerRevReq CertRevReq
} }
3.8 TimeStamp Trust Conditions 3.8 Time-Stamp Trust Conditions
The TimeStampTrustCondition field identifies trust conditions for The TimeStampTrustCondition field identifies trust conditions for
certificate path processing used to authenticate the timstamping certificate path processing used to authenticate the timstamping
authority and constraints on the name of the timestamping authority. authority and constraints on the name of the time-stamping authority.
This applies to the timestamp that must be present in every ES-T. This applies to the time-stamp that must be present in every ES-T.
TimestampTrustCondition ::= SEQUENCE { TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL, OPTIONAL,
ttsRevReq [1] CertRevReq ttsRevReq [1] CertRevReq
OPTIONAL, OPTIONAL,
ttsNameConstraints [2] NameConstraints ttsNameConstraints [2] NameConstraints
OPTIONAL, OPTIONAL,
cautionPeriod [3] DeltaTime cautionPeriod [3] DeltaTime
OPTIONAL, OPTIONAL,
signatureTimestampDelay [4] DeltaTime signatureTimestampDelay [4] DeltaTime
OPTIONAL } OPTIONAL }
DeltaTime ::= SEQUENCE { DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER, deltaSeconds INTEGER,
deltaMinutes INTEGER, deltaMinutes INTEGER,
deltaHours INTEGER, deltaHours INTEGER,
deltaDays 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.
Internet Draft Electronic Signature Policies If ttsCertificateTrustTrees is not present then the same rule as
defined in certificateTrustCondition applies to certification of the
time-stamping authorities public key.
The tstrRevReq specifies minimum requirements for revocation The tstrRevReq specifies minimum requirements for revocation
information, obtained through CRLs and/or OCSP responses, to be used in information, obtained through CRLs and/or OCSP responses, to be used
checking the revocation status of the time stamp that must be present in checking the revocation status of the time-stamp that must be
in the ES-T. present in the ES-T.
If ttsNameConstraints is not present then there are no additional If ttsNameConstraints is not present then there are no additional
naming constraints on the trusted timestamping authority other than naming constraints on the trusted time-stamping authority other than
those implied by the ttsCertificateTrustTrees. those implied by the ttsCertificateTrustTrees.
The cautionPeriod field specifies a caution period after the signing The cautionPeriod field specifies a caution period after the signing
time that it is mandated the verifier must wait to get high assurance 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 of the validity of the signer's key and that any relevant revocation
has been notified. The revocation status information forming the ES has been notified. The revocation status information forming the ES
with Complete validation data must not be collected and used to with Complete validation data must not be collected and used to
validate the electronic signature until after this caution period. validate the electronic signature until after this caution period.
The signatureTimestampDelay field specifies a maximum acceptable time The signatureTimestampDelay field specifies a maximum acceptable time
between the signing time and the time at which the signature timestamp, between the signing time and the time at which the signature time-
as used to form the ES Timestamped, is created for the verifier. If the stamp, as used to form the ES Time-Stamped, is created for the
signature timestamp is later that the time in the signing-time verifier. If the signature time-stamp is later that the time in the
attribute by more than the value given in signatureTimestampDelay, the signing-time attribute by more than the value given in
signature must be considered invalid. signatureTimestampDelay, the signature must be considered invalid.
3.9 Attribute Trust Conditions 3.9 Attribute Trust Conditions
If the attributeTrustCondition field is not present then any certified If the attributeTrustCondition field is not present then any
attributes may not considered to be valid under this validation policy. certified attributes may not considered to be valid under this
The AttributeTrustCondition field is defined as follows: validation policy. The AttributeTrustCondition field is defined as
follows:
AttributeTrustCondition ::= SEQUENCE { AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN, attributeMandated BOOLEAN,
-- Attribute must be present -- Attribute must be present
howCertAttribute HowCertAttribute, howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL, attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL, attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL } attributeConstraints [2] AttributeConstraints OPTIONAL }
If attributeMandated is true then an attribute, certified within the If attributeMandated is true then an attribute, certified within the
following constraints, must be present. If false, then the signature following constraints, must be present. If false, then the signature
is still valid if no attribute is specified. is still valid if no attribute is specified.
The howCertAttribute field specifies whether attributes uncertified The howCertAttribute field specifies whether attributes uncertified
attributes "claimed" by the signer, or certified attributes attributes "claimed" by the signer, or certified attributes (i.e.,
(i.e. Attribute Certificates) or either using the signer Attribute Certificates) or either using the signer attributes
attributes attribute defined in [ES-FORMATS] section 3.12.3. attribute defined in [ES-FORMATS] section 3.12.3.
HowCertAttribute ::= ENUMERATED { HowCertAttribute ::= ENUMERATED {
claimedAttribute (0), claimedAttribute (0),
certifiedAttribtes (1), certifiedAttribtes (1),
either (2) } either (2) }
Internet Draft Electronic Signature Policies
The attrCertificateTrustTrees specifies certificate path conditions for The attrCertificateTrustTrees specifies certificate path conditions
any attribute certificate. If not present the same rules apply as in for any attribute certificate. If not present the same rules apply
certificateTrustCondition. as in certificateTrustCondition.
The attrRevReq specifies minimum requirements for revocation The attrRevReq specifies minimum requirements for revocation
information, obtained through CRLs and/or OCSP responses, to be used in information, obtained through CRLs and/or OCSP responses, to be used
checking the revocation status of Attribute Certificates, if any are in checking the revocation status of Attribute Certificates, if any
present. are present.
If the attributeConstraints field is not present then there are no If the attributeConstraints field is not present then there are no
constraints on the attributes that may be validated under this policy. constraints on the attributes that may be validated under this
The attributeConstraints field is defined as follows: policy. The attributeConstraints field is defined as follows:
AttributeConstraints ::= SEQUENCE { AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL, OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL } OPTIONAL }
If present, the attributeTypeConstarints field specifies the attribute If present, the attributeTypeConstarints field specifies the
types which are considered valid under the signature policy. Any value attribute types which are considered valid under the signature
for that attribute is considered valid. policy. Any value for that attribute is considered valid.
AttributeTypeConstraints ::= SEQUENCE OF AttributeType AttributeTypeConstraints ::= SEQUENCE OF AttributeType
If present, the attributeTypeConstraints field specifies the specific If present, the attributeTypeConstraints field specifies the specific
attribute values which are considered valid under the signature policy. attribute values which are considered valid under the signature
policy.
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
3.10 Algorithm Constraints 3.10 Algorithm Constraints
The algorithmConstrains fields, if present, identifies the signing The algorithmConstrains fields, if present, identifies the signing
algorithms (hash, public key cryptography, combined hash and public key algorithms (hash, public key cryptography, combined hash and public
cryptography) that may be used for specific purposes and any minimum key cryptography) that may be used for specific purposes and any
length. If this field is not present then the policy applies no minimum length. If this field is not present then the policy applies
constraints. no constraints.
AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on: AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL, signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer -- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL, eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs. -- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL, caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates -- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL, aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority -- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- TimeStamping Authority -- Time-Stamping Authority
} }
Internet Draft Electronic Signature Policies
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE { AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER, algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL, minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits -- Minimum key length in bits
other SignPolExtensions OPTIONAL other SignPolExtensions OPTIONAL
} }
An Attribute Authority (AA)is authority which assigns privileges by An Attribute Authority (AA)is authority which assigns privileges by
issuing attribute certificates issuing attribute certificates
3.11 Signature Policy Extensions 3.11 Signature Policy Extensions
Additional signature policy rules may be added to: Additional signature policy rules may be added to:
* the overall signature policy structure, as defined in * the overall signature policy structure, as defined in section
section 3.1; 3.1;
* the signature validation policy structure, as defined in * the signature validation policy structure, as defined in
section 3.2; section 3.2;
* the common rules, as defined in section 3.3; * the common rules, as defined in section 3.3;
* the commitment rules, as defined in section 3.4; * the commitment rules, as defined in section 3.4;
* the signer rules, as defined in section 3.5.1; * the signer rules, as defined in section 3.5.1;
* the verifier rules, as defined in section 3.5.2; * the verifier rules, as defined in section 3.5.2;
* the revocation requirements in section 3.6.2; * the revocation requirements in section 3.6.2;
* the algorithm constraints in section 3.10. * the algorithm constraints in section 3.10.
These extensions to the signature policy rules must be defined using These extensions to the signature policy rules must be defined using
an ASN.1 syntax with an associated object identifier carried in the an ASN.1 syntax with an associated object identifier carried in the
SignPolExtn as defined below: SignPolExtn as defined below:
SignPolExtensions ::= SEQUENCE OF SignPolExtn SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE { SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER, extnID OBJECT IDENTIFIER,
extnValue OCTET STRING } extnValue OCTET STRING }
The extnID field must contain the object identifier for the extension. The extnID field must contain the object identifier for the
The extnValue field must contain the DER (see ITU-T Recommendation extension. The extnValue field must contain the DER (see ITU-T
X.690 [4]) encoded value of the extension. The definition of an Recommendation X.690 [4]) encoded value of the extension. The
extension, as identified by extnID must include a definition of the definition of an extension, as identified by extnID must include a
syntax and semantics of the extension. definition of the syntax and semantics of the extension.
Internet Draft Electronic Signature Policies 4. Security Considerations
4. Security considerations 4.1 Protection of Private Key
To be defined
5. Conformance Requirements The security of the electronic signature mechanism defined in this
document depends on the privacy of the signer's private key.
Implementations must take steps to ensure that private keys cannot be
compromised.
To be defined 4.2 Choice of Algorithms
6. References Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptoanalysis techniques are developed and
computing performance improves, the work factor to break a particular
cryptographic algorithm will reduce. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms
to be readily inserted. That is, implementers should be prepared for
the set of mandatory to implement algorithms to change over time.
[ES201733] ETSI Standard ES 201 733 V1.1.3 (2000-05) Electronic 5. Conformance Requirements
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 Signer and verifier systems shall be able to process an electronic
formats for long term electronic signatures <draft-ietf-smime-esformats> signature in accordance with the specification of the signature
To be published as an INFORMATIONAL RFC. policy signature policy referenced identifiable by an Object
Identifier, see section 3.
[TSP] C. Adams, D. Pinkas, R. Zuccherato, P. Cain. Time Stamp Protocol <draft- 6. References
ietf-pkix-tsp>.
[OCSP] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. [TS101733] ETSI Standard TS 101 733 V.1.2.2 (2000-12) Electronic
On-line Status Certificate Protocol, RFC 2560. Signature Formats. Note: copies of ETSI TS 101 733 can
be freely download from the ETSI web site www.etsi.org.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [ES-FORMATS] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature
Requirement Levels", BCP 14, RFC 2119, March 1997. Formats for Long Term Electronic Signatures", RFC 3126,
June 2001.
[ESS] P. Hoffman, "Enhanced Security Services for S/MIME", RFC 2634 [TSP] Adams, C, Pinkas, D., Zuccherato, R. and P. Cain,
June 1999 "Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
[CMS] R. Housley, "Cryptographic Message Syntax", RFC 2630, RFC 2630, [OCSP] Myers, M., Ankney, R., Malpani, R., Galperin, S. and C.
June 1999. Adams, "On-line Status Certificate Protocol", RFC 2560,
June 1999.
[RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Key Infrastructure, Certificate and CRL Profile," RFC 2459, January Requirement Levels", BCP 14, RFC 2119, March 1997.
1999.
[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
(PKCS)", RSA Data Security Inc., Redwood City, California, November RFC 2634, June 1999.
1993 Release.
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems. [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
Non-Repudiation Framework. April 1997. June 1999.
Internet Draft Electronic Signature Policies [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure, Certificate and CRL
Profile," RFC 2459, January 1999.
7. Authors' Addresses [PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data Security Inc., Redwood City,
California, November 1993 Release.
This Experimental RFC has been produced in ETSI TC-SEC. [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems.
Non-Repudiation Framework. April 1997.
ETSI 7. Authors' Addresses
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 This Experimental RFC has been produced in ETSI TC-SEC.
Harri Rasilainen ETSI
ETSI F-06921 Sophia Antipolis, Cedex - FRANCE
650 Route des Lucioles 650 Route des Lucioles - Sophia Antipolis
F-06921 Sophia Antipolis Cedex Valbonne - FranceTel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
FRANCE secretariat@etsi.fr
harri.rasilainen@etsi.fr http://www.etsi.org
John Ross Contact Point
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom
ross@secstan.com
Denis Pinkas Nick Pope Harri Rasilainen
Bull S.A. Security & Standards ETSI
12, rue de Paris 192 Moulsham Street 650 Route des Lucioles
B.P. 59 Chelmsford, Essex F-06921 Sophia Antipolis Cedex
78231 Le Pecq CM2 0LG FRANCE
FRANCE United Kingdom
pinkas.denis@bull.net pope@secstan.com
Internet Draft Electronic Signature Policies EMail: harri.rasilainen@etsi.fr
8. Full Copyright Statement John Ross
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom
Copyright (C) The Internet Society (2000). All Rights Reserved. EMail: ross@secstan.com
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 Denis Pinkas
by the Internet Society or its successors or assigns. Integris, Bull.
68, Route de Versailles
78434 Louveciennes CEDEX
FRANCE
This document and the information contained herein is provided on an EMail: Denis.Pinkas@bull.net
"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.
Internet Draft Electronic Signature Policies Nick Pope
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom
EMail: pope@secstan.com
Annex A (normative): Annex A (normative):
ASN.1 Definitions
This annex provides the reference definition of the ASN.1 syntax ASN.1 Definitions This annex provides the reference definition of the
signature policies definitions for new syntax defined in this document. ASN.1 syntax signature policies definitions for new syntax defined in
this document.
A.1 Definitions Using X.208 (1988) ASN.1 Syntax 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) NOTE: The ASN.1 Module defined in section A.1 has precedence over
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 7} 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 ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
IMPORTS IMPORTS
-- Internet X.509 Public Key Infrastructure -- Internet X.509 Public Key Infrastructure
- Certificate and CRL Profile: RFC 2459 - Certificate and CRL Profile: RFC 2560
Certificate, AlgorithmIdentifier, CertificateList, Name, Certificate, AlgorithmIdentifier, CertificateList, Name,
GeneralNames, GeneralName, DirectoryString,Attribute, GeneralNames, GeneralName, DirectoryString,Attribute,
AttributeTypeAndValue, AttributeType, AttributeValue, AttributeTypeAndValue, AttributeType, AttributeValue,
PolicyInformation, BMPString, UTF8String PolicyInformation, BMPString, UTF8String
FROM PKIX1Explicit88 FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1) {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)} id-pkix1-explicit-88(1)}
; ;
-- Signature Policy Specification -- Signature Policy Specification
-- ============================== -- ==============================
SignaturePolicy ::= SEQUENCE { SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier, signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo, signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL } signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE { SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId, signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime, dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName, policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication, fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy, signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions signPolExtensions SignPolExtensions
OPTIONAL OPTIONAL
} }
SignPolicyId ::= OBJECT IDENTIFIER
Internet Draft Electronic Signature Policies
PolicyIssuerName ::= GeneralNames PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString FieldOfApplication ::= DirectoryString
SignatureValidationPolicy ::= SEQUENCE { SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod, signingPeriod SigningPeriod,
commonRules CommonRules, commonRules CommonRules,
commitmentRules CommitmentRules, commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions signPolExtensions SignPolExtensions
OPTIONAL OPTIONAL
} }
SigningPeriod ::= SEQUENCE { SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime, notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL } notAfter GeneralizedTime OPTIONAL }
CommonRules ::= SEQUENCE { CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL, OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL, OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL, OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL, OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL, OPTIONAL,
signPolExtensions [5] SignPolExtensions signPolExtensions [5] SignPolExtensions
OPTIONAL OPTIONAL
} }
CommitmentRules ::= SEQUENCE OF CommitmentRule CommitmentRules ::= SEQUENCE OF CommitmentRule
CommitmentRule ::= SEQUENCE { CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes, selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL, OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL, OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL, OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL, OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL, OPTIONAL,
signPolExtensions [5] SignPolExtensions signPolExtensions [5] SignPolExtensions
OPTIONAL OPTIONAL
} }
Internet Draft Electronic Signature Policies
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE { SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL, empty NULL,
recognizedCommitmentType CommitmentType } recognizedCommitmentType CommitmentType }
CommitmentType ::= SEQUENCE { CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier, identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL, fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL } semantics [1] DirectoryString OPTIONAL }
SignerAndVerifierRules ::= SEQUENCE { SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules, signerRules SignerRules,
verifierRules VerifierRules } verifierRules VerifierRules }
SignerRules ::= SEQUENCE { SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL, externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure -- True if signed data is external to CMS structure
-- False if signed data part of CMS structure -- False if signed data part of CMS structure
-- not present if either allowed -- not present if either allowed
mandatedSignedAttr CMSAttrs, mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes -- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs, mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed -- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly, mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference -- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none, mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info -- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions signPolExtensions [2] SignPolExtensions
OPTIONAL} OPTIONAL}
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER
CertRefReq ::= ENUMERATED { CertRefReq ::= ENUMERATED {
signerOnly (1), signerOnly (1),
-- Only reference to signer cert mandated -- Only reference to signer cert mandated
fullPath (2) fullPath (2)
-- References for full cert path up to a trust point required -- References for full cert path up to a trust point required
} }
CertInfoReq ::= ENUMERATED { CertInfoReq ::= ENUMERATED {
none (0), none (0),
-- No mandatory requirements -- No mandatory requirements
signerOnly (1), signerOnly (1),
-- Only reference to signer cert mandated -- Only reference to signer cert mandated
fullPath (2) fullPath (2)
-- References for full cert path up to a trust point mandated -- References for full cert path up to a trust point mandated
} }
Internet Draft Electronic Signature Policies
VerifierRules ::= SEQUENCE { VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr, mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL signPolExtensions SignPolExtensions OPTIONAL
} }
MandatedUnsignedAttr ::= CMSAttrs MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed -- Mandated CMS unsigned attributed
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustPoint ::= SEQUENCE { CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate, trustpoint Certificate,
-- self-signed certificate -- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL, pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy" -- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL, nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL } policyConstraints [3] PolicyConstraints OPTIONAL }
PathLenConstraint ::= INTEGER (0..MAX) PathLenConstraint ::= INTEGER (0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER CertPolicyId ::= OBJECT IDENTIFIER
NameConstraints ::= SEQUENCE { NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL, permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL } excludedSubtrees [1] GeneralSubtrees OPTIONAL }
skipping to change at page 24, line 52 skipping to change at page 25, line 9
BaseDistance ::= INTEGER (0..MAX) BaseDistance ::= INTEGER (0..MAX)
PolicyConstraints ::= SEQUENCE { PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL, requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL } inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX) SkipCerts ::= INTEGER (0..MAX)
CertRevReq ::= SEQUENCE { CertRevReq ::= SEQUENCE {
endCertRevReq RevReq, endCertRevReq RevReq,
caCerts [0] RevReq caCerts [0] RevReq
} }
RevReq ::= SEQUENCE { RevReq ::= SEQUENCE {
enuRevReq EnuRevReq, enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL} exRevReq SignPolExtensions OPTIONAL}
Internet Draft Electronic Signature Policies
EnuRevReq ::= ENUMERATED { EnuRevReq ::= ENUMERATED {
clrCheck (0), --Checks must be made against current CRLs clrCheck (0), --Checks must be made against current CRLs
-- (or authority revocation lists) -- (or authority revocation lists)
ocspCheck (1), -- The revocation status must be checked ocspCheck (1), -- The revocation status must be checked
-- using the Online Certificate Status Protocol (RFC 2450) -- using the Online Certificate Status Protocol (RFC 2450)
bothCheck (2), bothCheck (2),
-- Both CRL and OCSP checks must be carried out -- Both CRL and OCSP checks must be carried out
eitherCheck (3), eitherCheck (3),
-- At least one of CRL or OCSP checks must be carried out -- At least one of CRL or OCSP checks must be carried out
noCheck (4), noCheck (4),
-- no check is mandated -- no check is mandated
other (5) other (5)
-- Other mechanism as defined by signature policy extension -- Other mechanism as defined by signature policy extension
} }
SigningCertTrustCondition ::= SEQUENCE { SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees, signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq signerRevReq CertRevReq
} }
TimestampTrustCondition ::= SEQUENCE { TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL, OPTIONAL,
ttsRevReq [1] CertRevReq ttsRevReq [1] CertRevReq
OPTIONAL, OPTIONAL,
ttsNameConstraints [2] NameConstraints ttsNameConstraints [2] NameConstraints
OPTIONAL, OPTIONAL,
cautionPeriod [3] DeltaTime cautionPeriod [3] DeltaTime
OPTIONAL, OPTIONAL,
signatureTimestampDelay [4] DeltaTime signatureTimestampDelay [4] DeltaTime
OPTIONAL } OPTIONAL }
DeltaTime ::= SEQUENCE { DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER, deltaSeconds INTEGER,
deltaMinutes INTEGER, deltaMinutes INTEGER,
deltaHours INTEGER, deltaHours INTEGER,
deltaDays INTEGER } deltaDays INTEGER }
AttributeTrustCondition ::= SEQUENCE { AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN, attributeMandated BOOLEAN,
-- Attribute must be present -- Attribute must be present
howCertAttribute HowCertAttribute, howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL, attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL, attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL } attributeConstraints [2] AttributeConstraints OPTIONAL }
HowCertAttribute ::= ENUMERATED { HowCertAttribute ::= ENUMERATED {
claimedAttribute (0), claimedAttribute (0),
certifiedAttribtes (1), certifiedAttribtes (1),
either (2) } either (2) }
Internet Draft Electronic Signature Policies
AttributeConstraints ::= SEQUENCE { AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL, OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL } OPTIONAL }
AttributeTypeConstraints ::= SEQUENCE OF AttributeType AttributeTypeConstraints ::= SEQUENCE OF AttributeType
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on: AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL, signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer -- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL, eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs. -- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL, caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates -- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL, aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority -- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- TimeStamping Authority -- Time-Stamping Authority
} }
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE { AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER, algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL, minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits other -- Minimum key length in bits other
SignPolExtensions OPTIONAL SignPolExtensions OPTIONAL
} }
SignPolExtensions ::= SEQUENCE OF SignPolExtn SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE { SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER, extnID OBJECT IDENTIFIER,
extnValue OCTET STRING } extnValue OCTET STRING }
END -- ETS-ElectronicSignaturePolicies-88syntax -- END -- ETS-ElectronicSignaturePolicies-88syntax --
Internet Draft Electronic Signature Policies A.2 Definitions Using X.680 1997 ASN.1 Syntax
A.2 Definitions Using X.680 1997 ASN.1 Syntax
NOTE: The ASN.1 module defined in section A.1 has precedence over that NOTE: The ASN.1 module defined in section A.1 has precedence over
defined in section A.2 in the case of any conflict. that defined in section A.2 in the case of any conflict.
ETS-ElectronicSignaturePolicies-97Syntax { iso(1) member-body(2) ETS-ElectronicSignaturePolicies-97Syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 8} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 8}
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All - -- EXPORTS All -
IMPORTS IMPORTS
-- Internet X.509 Public Key Infrastructure -- Internet X.509 Public Key Infrastructure
Certificate, AlgorithmIdentifier, CertificateList, Name, -- Certificate and CRL Profile: RFC 2560
GeneralNames, GeneralName, DirectoryString, Attribute, Certificate, AlgorithmIdentifier, CertificateList, Name,
AttributeTypeAndValue, AttributeType, AttributeValue, GeneralNames, GeneralName, DirectoryString, Attribute,
PolicyInformation AttributeTypeAndValue, AttributeType, AttributeValue,
PolicyInformation
FROM PKIX1Explicit93 FROM PKIX1Explicit93
{iso(1) identified-organization(3) dod(6) internet(1) {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} security(5) mechanisms(5) pkix(7) id-mod(0)
nid-pkix1-explicit-88(1)}
; ;
-- S/MIME Object Identifier arcs used in the present document -- S/MIME Object Identifier arcs used in the present document
-- ================================================================== -- ==================================================================
-- S/MIME OID arc used in the present document -- S/MIME OID arc used in the present document
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) -- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } -- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
-- S/MIME Arcs -- S/MIME Arcs
-- id-mod OBJECT IDENTIFIER ::= { id-smime 0 } -- id-mod OBJECT IDENTIFIER ::= { id-smime 0 }
-- modules -- modules
-- id-ct OBJECT IDENTIFIER ::= { id-smime 1 } -- id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
-- content types -- content types
-- id-aa OBJECT IDENTIFIER ::= { id-smime 2 } -- id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
-- attributes -- attributes
-- id-spq OBJECT IDENTIFIER ::= { id-smime 5 } -- id-spq OBJECT IDENTIFIER ::= { id-smime 5 }
-- signature policy qualifier -- signature policy qualifier
-- id-cti OBJECT IDENTIFIER ::= { id-smime 6 } -- id-cti OBJECT IDENTIFIER ::= { id-smime 6 }
-- commitment type identifier -- commitment type identifier
Internet Draft Electronic Signature Policies
-- Signature Policy Specification -- Signature Policy Specification
-- ============================== -- ==============================
SignaturePolicy ::= SEQUENCE { SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier, signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo, signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL } signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE { SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId, signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime, dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName, policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication, fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy, signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions signPolExtensions SignPolExtensions
OPTIONAL OPTIONAL
} }
SignPolicyId ::= OBJECT IDENTIFIER SignPolicyId ::= OBJECT IDENTIFIER
PolicyIssuerName ::= GeneralNames PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString FieldOfApplication ::= DirectoryString
SignatureValidationPolicy ::= SEQUENCE { SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod, signingPeriod SigningPeriod,
commonRules CommonRules, commonRules CommonRules,
commitmentRules CommitmentRules, commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions OPTIONAL signPolExtensions SignPolExtensions OPTIONAL
} }
SigningPeriod ::= SEQUENCE { SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime, notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL } notAfter GeneralizedTime OPTIONAL }
Internet Draft Electronic Signature Policies
CommonRules ::= SEQUENCE { CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL, OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL, OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL, OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL, OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL, OPTIONAL,
signPolExtensions [5] SignPolExtensions signPolExtensions [5] SignPolExtensions
OPTIONAL OPTIONAL
} }
CommitmentRules ::= SEQUENCE OF CommitmentRule CommitmentRules ::= SEQUENCE OF CommitmentRule
CommitmentRule ::= SEQUENCE { CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes, selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL, OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL, OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL, OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL, OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL, OPTIONAL,
signPolExtensions [5] SignPolExtensions signPolExtensions [5] SignPolExtensions
OPTIONAL OPTIONAL
} }
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE { SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL, empty NULL,
recognizedCommitmentType CommitmentType } recognizedCommitmentType CommitmentType }
CommitmentType ::= SEQUENCE { CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier, identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL, fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL } semantics [1] DirectoryString OPTIONAL }
SignerAndVerifierRules ::= SEQUENCE { SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules, signerRules SignerRules,
verifierRules VerifierRules } verifierRules VerifierRules }
Internet Draft Electronic Signature Policies
SignerRules ::= SEQUENCE { SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL, externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure -- True if signed data is external to CMS structure
-- False if signed data part of CMS structure -- False if signed data part of CMS structure
-- not present if either allowed -- not present if either allowed
mandatedSignedAttr CMSAttrs,
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes -- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs, mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed -- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly, mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference -- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none, mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info -- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions OPTIONAL signPolExtensions [2] SignPolExtensions OPTIONAL
} }
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER
CertRefReq ::= ENUMERATED { CertRefReq ::= ENUMERATED {
signerOnly (1), signerOnly (1),
-- Only reference to signer cert mandated -- Only reference to signer cert mandated
fullPath (2) fullPath (2)
-- References for full cert path up to a trust -- References for full cert path up to a trust
-- point required -- point required
} }
CertInfoReq ::= ENUMERATED { CertInfoReq ::= ENUMERATED {
none (0) , none (0) ,
-- No mandatory requirements -- No mandatory requirements
signerOnly (1) , signerOnly (1) ,
-- Only reference to signer cert mandated -- Only reference to signer cert mandated
fullPath (2) fullPath (2)
-- References for full cert path up to a -- References for full cert path up to a
-- trust point mandated -- trust point mandated
} }
VerifierRules ::= SEQUENCE { VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr, mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL signPolExtensions SignPolExtensions OPTIONAL
} }
MandatedUnsignedAttr ::= CMSAttrs MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed -- Mandated CMS unsigned attributed
Internet Draft Electronic Signature Policies
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustPoint ::= SEQUENCE { CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate, trustpoint Certificate,
-- self-signed certificate -- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL, pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL, acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy" -- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL, nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL } policyConstraints [3] PolicyConstraints OPTIONAL }
PathLenConstraint ::= INTEGER (0..MAX) PathLenConstraint ::= INTEGER (0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER CertPolicyId ::= OBJECT IDENTIFIER
NameConstraints ::= SEQUENCE { NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL, permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL } excludedSubtrees [1] GeneralSubtrees OPTIONAL }
skipping to change at page 31, line 44 skipping to change at page 31, line 31
BaseDistance ::= INTEGER (0..MAX) BaseDistance ::= INTEGER (0..MAX)
PolicyConstraints ::= SEQUENCE { PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL, requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL } inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX) SkipCerts ::= INTEGER (0..MAX)
CertRevReq ::= SEQUENCE { CertRevReq ::= SEQUENCE {
endCertRevReq RevReq, endCertRevReq RevReq,
caCerts [0] RevReq caCerts [0] RevReq
} }
RevReq ::= SEQUENCE { RevReq ::= SEQUENCE {
enuRevReq EnuRevReq, enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL} exRevReq SignPolExtensions OPTIONAL}
Internet Draft Electronic Signature Policies
EnuRevReq ::= ENUMERATED { EnuRevReq ::= ENUMERATED {
clrCheck (0), clrCheck (0),
-- Checks must be made against current CRLs -- Checks must be made against current CRLs
-- (or authority revocation lists) -- (or authority revocation lists)
ocspCheck (1), ocspCheck (1),
-- The revocation status must be checked using -- The revocation status must be checked using
-- the Online Certificate Status Protocol (RFC 2450) -- the Online Certificate Status Protocol (RFC 2450)
bothCheck (2), bothCheck (2),
-- Both CRL and OCSP checks must be carried out -- Both CRL and OCSP checks must be carried out
eitherCheck (3), eitherCheck (3),
-- At least one of CRL or OCSP checks must be carried out -- At least one of CRL or OCSP checks must be
noCheck (4), -- carried out
noCheck (4),
-- no check is mandated -- no check is mandated
other (5)
other (5)
-- Other mechanism as defined by signature policy -- Other mechanism as defined by signature policy
-- extension -- extension
} }
SigningCertTrustCondition ::= SEQUENCE { SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees, signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq signerRevReq CertRevReq
} }
TimestampTrustCondition ::= SEQUENCE { TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL, OPTIONAL,
ttsRevReq [1] CertRevReq ttsRevReq [1] CertRevReq
OPTIONAL, OPTIONAL,
ttsNameConstraints [2] NameConstraints ttsNameConstraints [2] NameConstraints
OPTIONAL, OPTIONAL,
cautionPeriod [3] DeltaTime cautionPeriod [3] DeltaTime
OPTIONAL, OPTIONAL,
signatureTimestampDelay [4] DeltaTime signatureTimestampDelay [4] DeltaTime
OPTIONAL } OPTIONAL }
DeltaTime ::= SEQUENCE { DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER, deltaSeconds INTEGER,
deltaMinutes INTEGER, deltaMinutes INTEGER,
deltaHours INTEGER, deltaHours INTEGER,
deltaDays INTEGER } deltaDays INTEGER }
AttributeTrustCondition ::= SEQUENCE { AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN, attributeMandated BOOLEAN,
-- Attribute must be present -- Attribute must be present
howCertAttribute HowCertAttribute, howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL, attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL, attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL } attributeConstraints [2] AttributeConstraints OPTIONAL }
Internet Draft Electronic Signature Policies
HowCertAttribute ::= ENUMERATED { HowCertAttribute ::= ENUMERATED {
claimedAttribute (0), claimedAttribute (0),
certifiedAttribtes (1), certifiedAttribtes (1),
either (2) } either (2) }
AttributeConstraints ::= SEQUENCE { AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL, OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL } OPTIONAL }
AttributeTypeConstraints ::= SEQUENCE OF AttributeType AttributeTypeConstraints ::= SEQUENCE OF AttributeType
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
AlgorithmConstraintSet ::= SEQUENCE { AlgorithmConstraintSet ::= SEQUENCE {
-- Algorithm constrains on: -- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL, signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer -- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL, eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs. -- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL, caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates -- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL, aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority -- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- TimeStamping Authority -- Time-Stamping Authority
} }
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE { AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER, algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL, minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits -- Minimum key length in bits
other SignPolExtensions OPTIONAL other SignPolExtensions OPTIONAL
} }
SignPolExtensions ::= SEQUENCE OF SignPolExtn SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE { SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER, extnID OBJECT IDENTIFIER,
extnValue OCTET STRING } extnValue OCTET STRING }
END -- ETS-ElectronicPolicies-97Syntax END -- ETS-ElectronicPolicies-97Syntax
Internet Draft Electronic Signature Policies
Annex B (informative): Annex B (informative):
B.1 Signature Policy and Signature Validation Policy 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 The definition of electronic signature mentions: "a commitment has
legal or contractual framework. This establishes the requirements on been explicitly endorsed under a "Signature Policy", at a given time,
the electronic signatures and any special semantics (e.g. agreement, by a signer under an identifier, e.g., a name or a pseudonym, and
intent). These requirements may be defined in very general abstract optionally a role."
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 Electronic signatures are commonly applied within the context of a
context, as providing commitment, then the signer explicitly agrees legal or contractual framework. This establishes the requirements on
with terms and conditions which are implicitly or explicitly part of the electronic signatures and any special semantics (e.g., agreement,
the signed data. 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.
When two independent parties want to evaluate an electronic signature, If the signature policy is recognized, within the legal/contractual
it is fundamental that they get the same result. It is therefore context, as providing commitment, then the signer explicitly agrees
important that the conditions agreed by the signer at the time of with terms and conditions which are implicitly or explicitly part of
signing are indicated to the verifier and any arbitrator. An aspect the signed data.
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 When two independent parties want to evaluate an electronic
specification of the signature policy. However, for a given signature signature, it is fundamental that they get the same result. It is
policy there must be one definitive form that has a unique binary therefore important that the conditions agreed by the signer at the
encoded value. 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 includes, as an option, a formal structure for signature This document does not mandate the form and encoding of the
validation policy based on the use of Abstract Syntax Notation 1 specification of the signature policy. However, for a given
(ASN.1). signature policy there must be one definitive form that has a unique
binary encoded value.
Given the specification of the signature policy and its hash value an This document includes, as an option, a formal structure for
implementation of a verification process must obey the rules defined signature validation policy based on the use of Abstract Syntax
in the specification. Notation 1 (ASN.1).
This document places no restriction on how it should be implemented. Given the specification of the signature policy and its hash value an
Provide the implementation conforms to the conformance requirements as implementation of a verification process must obey the rules defined
define in section 5 implementation options include: in the specification.
Internet Draft Electronic Signature Policies 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:
A validation process that supports a specific signature policy as A validation process that supports a specific signature policy as
identified by the signature policy OID. Such an implementation should identified by the signature policy OID. Such an implementation
conform to a human readable description provided all the processing should conform to a human readable description provided all the
rules of the signature policy are clearly defined. However, if processing rules of the signature policy are clearly defined.
additional policies need to be supported, then such an implementation However, if additional policies need to be supported, then such an
would need to be customized for each additional policy. This type of implementation would need to be customized for each additional
implementation may be simpler to implement initially, but can be policy. This type of implementation may be simpler to implement
difficult to enhance to support numerous additional signature policies. initially, but can be difficult to enhance to support numerous
additional signature policies.
A validation process that is dynamically programmable and able to adapt A validation process that is dynamically programmable and able to
its validation rules in accordance with a description of the signature adapt its validation rules in accordance with a description of the
policy provided in a computer-processable language. This present signature policy provided in a computer-processable language. This
document defines such a policy using an ASN.1 structure (see 6.1). This present document defines such a policy using an ASN.1 structure (see
type of implementation could support multiple signature policies 6.1). This type of implementation could support multiple signature
without being modified every time, provided all the validation rules policies without being modified every time, provided all the
specified as part of the signature policy are known by the validation rules specified as part of the signature policy are known
implementation. (i.e. only requires modification if there are by the implementation. (i.e., only requires modification if there
additional rules specified). are additional rules specified).
The precise content of a signature policy is not mandated by the The precise content of a signature policy is not mandated by the
current document. However, a signature policy must be sufficiently current document. However, a signature policy must be sufficiently
definitive to avoid any ambiguity as to its implementation definitive to avoid any ambiguity as to its implementation
requirements. It must be absolutely clear under which conditions an requirements. It must be absolutely clear under which conditions an
electronic signature should be accepted. For this reason, it should electronic signature should be accepted. For this reason, it should
contain the following information: contain the following information:
* General information about the signature policy which includes: * General information about the signature policy which includes:
- a unique identifier of the policy; - a unique identifier of the policy;
- the name of the issuer of the policy; - the name of the issuer of the policy;
- the date the policy was issued; - the date the policy was issued;
- the field of application of the policy. - the field of application of the policy.
* The signature verification policy which includes: * The signature verification policy which includes:
- the signing period, - the signing period,
- a list of recognized commitment types; - a list of recognized commitment types;
- rules for Use of Certification Authorities; - rules for Use of Certification Authorities;
- rules for Use of Revocation Status Information; - rules for Use of Revocation Status Information;
- rules for Use of Roles; - rules for Use of Roles;
- rules for use of Timestamping and Timing; - rules for use of Time-Stamping and Timing;
- signature verification data to be provided by the - signature verification data to be provided by the
signer/collected by verifier; signer/collected by verifier;
- any constraints on signature algorithms and key lengths. - any constraints on signature algorithms and key lengths.
* Other signature policy rules required to meet the objectives of * Other signature policy rules required to meet the objectives of
the signature. the signature.
Variations of the validation policy rules may apply to different
commitment types.
Internet Draft Electronic Signature Policies
B.2 Identification of Signature Policy Variations of the validation policy rules may apply to different
commitment types.
When data is signed the signer indicates the signature policy B.2 Identification of 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 When data is signed the signer indicates the signature policy
includes: 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 URL where a copy of the Signature Policy may be obtained; A signature policy may be qualified by additional information. This
* A user notice that should be displayed when the signature is can includes:
verified;
If no signature policy is identified then the signature may be assumed * A URL where a copy of the Signature Policy may be obtained;
to have been generated/verified without any policy constraints, and * A user notice that should be displayed when the signature is
hence may be given no specific legal or contractual significance verified;
through the context of a signature policy.
A "Signature Policy" will be identifiable by an OID (Object Identifier) If no signature policy is identified then the signature may be
and verifiable using a hash of the signature policy. 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.
B.3 General Signature Policy Information A "Signature Policy" will be identifiable by an OID (Object
Identifier) and verifiable using a hash of the signature policy.
General information should be recorded about the signature policy along B.3 General Signature Policy Information
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 General information should be recorded about the signature policy
identifiable by an OID (Object Identifier) whose last component along with the definition of the rules which form the signature
(i.e. right most) is an integer that is specific to a particular policy as described in subsequent subsections. This should include:
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.
Internet Draft Electronic Signature Policies * 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.
B.4 Recognized Commitment Types * 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.
The signature validation policy may recognize one or more types of B.4 Recognized Commitment Types
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 The signature validation policy may recognize one or more types of
signature. 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.
The definition of a commitment type includes: Only recognized commitment types are allowed in an electronic
* the object identifier for the commitment; signature.
* 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: The definition of a commitment type includes:
* 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 * the object identifier for the commitment;
signature, as defined by the signature policy and its recognized * the contractual/legal/application context in which the
commitment types, make it fit for purpose intended. 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).
B.5 Rules for Use of Certification Authorities The definition of a commitment type can be registered:
The certificate validation process of the verifier, and hence the * as part of the validation policy;
certificates that may be used by the signer for a valid electronic * as part of the application/contract/legal environment;
signature, may be constrained by the combination of the trust point and * as part of generic register of definitions.
certificate path constraints in the signature validation policy.
B.5.1 Trust Points 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.
The signature validation policy defines the certification authority B.5 Rules for Use of Certification Authorities
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".
Internet Draft Electronic Signature Policies 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.2 Certification Path B.5.1 Trust Points
There may be constraints on the use of certificates issued by one or The signature validation policy defines the certification authority
more CA(s) in the certificate chain and trust points. The two prime trust points that are to be used for signature verification. Several
constraints are certificate policy constraints and naming constraints: 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".
* Certificate policy constraints limit the certification chain B.5.2 Certification Path
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" There may be constraints on the use of certificates issued by one or
identifies more than one trust point. In this case, a certificate of a more CA(s) in the certificate chain and trust points. The two prime
particular trusted point may only be used to verify signatures from constraints are certificate policy constraints and naming
users with names permitted under the name constraint. constraints:
Certificate Authorities may be organized in a tree structure, this tree * Certificate policy constraints limit the certification chain
structure may represent the trust relationship between various CA(s) between the user certificate and the certificate of the trusted
and the users CA. Alternatively, a mesh relationship may exist where a point to a given set of certificate policies, or equivalents
combination of tree and peer cross-certificates may be used. The identified through certificate policy mapping.
requirement of the certificate path in this document is that it * The naming constraints limit the forms of names that the CA is
provides the trust relationship between all the CAs and the signers allowed to certify.
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 Name constraints are particularly important when a "Signature policy"
the presence of a certificate policy identifier in the certificates identifies more than one trust point. In this case, a certificate of
used in a certification path. a particular trusted point may only be used to verify signatures from
users with names permitted under the name constraint.
Certificate path processing, thus generally starts with one of the Certificate Authorities may be organized in a tree structure, this
trust point from the signature policy and ends with the user tree structure may represent the trust relationship between various
certificate. The certificate path processing procedures defined in RFC CA(s) and the users CA. Alternatively, a mesh relationship may exist
2459 section 6 identifies the following initial parameters that are where a combination of tree and peer cross-certificates may be used.
selected by the verifier in certificate path processing: 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.
* acceptable certificate policies; Policy constraints can be easier to process but to be effective
* naming constraints in terms of constrained and excluded naming require the presence of a certificate policy identifier in the
subtree; certificates used in a certification path.
* 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 Certificate path processing, thus generally starts with one of the
parameters. 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:
Internet Draft Electronic Signature Policies * 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.
B.6 Revocation Rules The signature validation policy identifies constraints on these
parameters.
The signature policy should defines rules specifying requirements for B.6 Revocation Rules
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 The signature policy should defines rules specifying requirements for
CRLs checks being carried out for certificate status that are the use of certificate revocation lists (CRLs) and/or on-line
unavailable from OCSP servers. The verifier may take into account certificate status check service to check the validity of a
information in the certificate in deciding how best to check the certificate. These rules specify the mandated minimum checks that
revocation status (e.g. a certificate extension field about authority must be carried out.
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 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.
Roles can be supported as claimed roles or as certified roles using B.7 Rules for the Use of Roles
Attribute Certificates.
B.7.1 Attribute Values Roles can be supported as claimed roles or as certified roles using
Attribute Certificates.
When signature under a role is mandated by the signature policy, then B.7.1 Attribute Values
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 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.
When a signature under a certified role is mandated by the signature B.7.2 Trust Points for Certified Attributes
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 When a signature under a certified role is mandated by the signature
similar circumstance to when they apply to CA. Constraints on the AA policy, Attribute Authorities are used and need to be validated as
and CA need not be exactly the same. 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.
AA(s) may be used when a signer is creating a signature on behalf of an Naming and certification policy constraints may apply to the AA in
organization, they can be particularly useful when the signature similar circumstance to when they apply to CA. Constraints on the AA
represents an organizational role. AA(s) may or may not be the same and CA need not be exactly the same.
authority as CA(s).
Thus, the Signature Policy identifies trust points that can be used for AA(s) may be used when a signer is creating a signature on behalf of
Attribute Authorities, either by reference to the same trust points as an organization, they can be particularly useful when the signature
used for Certification Authorities, or by an independent list. represents an organizational role. AA(s) may or may not be the same
authority as CA(s).
Internet Draft Electronic Signature Policies 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.
B.7.3 Certification Path for Certified Attributes B.7.3 Certification Path for Certified Attributes
Attribute Authorities may be organized in a tree structure in similar 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 way to CA where the AAs are the leafs of such a tree. Naming and
constraints may be required on attribute certificate paths in a similar other constraints may be required on attribute certificate paths in a
manner to other electronic signature certificate paths. similar manner to other electronic signature certificate paths.
Thus, the Signature Policy identify constraints on the following Thus, the Signature Policy identify constraints on the following
parameters used as input to the certificate path processing: parameters used as input to the certificate path processing:
* acceptable certificate policies, including requirements for * acceptable certificate policies, including requirements for
explicit certificate policy indication and whether certificate explicit certificate policy indication and whether certificate
policy mapping is allowed; policy mapping is allowed;
* naming constraints in terms of constrained and excluded naming * naming constraints in terms of constrained and excluded naming
subtrees; subtrees;
* restrictions on the certificate path length. * restrictions on the certificate path length.
B.8 Rules for the Use of Timestamping and Timing B.8 Rules for the Use of Time-Stamping and Timing
The following rules should be used when specifying, constraints on the The following rules should be used when specifying, constraints on
certificate paths for timestamping authorities, constraints on the the certificate paths for time-stamping authorities, constraints on
timestamping authority names and general timing constraints. the time-stamping authority names and general timing constraints.
B.8.1 Trust Points and Certificate Paths B.8.1 Trust Points and Certificate Paths
Signature keys from timestamping authorities will need to be supported Signature keys from time-stamping authorities will need to be
by a certification path. The certification path used for timestamping supported by a certification path. The certification path used for
authorities requires a trustpoint and possibly path constraints in the time-stamping authorities requires a trustpoint and possibly path
same way that the certificate path for the signer's key. constraints in the same way that the certificate path for the
signer's key.
B.8.2 Timestamping Authority Names B.8.2 Time-Stamping Authority Names
Restrictions may need to be placed by the validation policy on the Restrictions may need to be placed by the validation policy on the
named entities that may act a timestamping authorities. named entities that may act a time-stamping authorities.
B.8.3 Timing Constraints - Caution Period B.8.3 Timing Constraints - Caution Period
Before an electronic signature may really be valid, the verifier has to Before an electronic signature may really be valid, the verifier has
be sure that the holder of the private key was really the only one in to be sure that the holder of the private key was really the only one
possession of key at the time of signing. However, there is an 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 inevitable delay between a compromise or loss of key being noted, and
report of revocation being distributed. To allow greater confidence in a report of revocation being distributed. To allow greater
the validity of a signature, a "cautionary period" may be identified confidence in the validity of a signature, a "cautionary period" may
before a signature may be said to be valid with high confidence. A be identified before a signature may be said to be valid with high
verifier may revalidate a signature after this cautionary signature, or confidence. A verifier may revalidate a signature after this
wait for this period before validating a signature. cautionary signature, or wait for this period before validating a
signature.
The validation policy may specify such a cautionary period. The validation policy may specify such a cautionary period.
Internet Draft Electronic Signature Policies B.8.4 Timing Constraints - Time-Stamp Delay
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 time-stamped.
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 time-stamp.
There will be some delay between the time that a signature is created B.9 Rules for Verification Data to be followed
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.
By specifying the requirements on the signer and verifier the These verification data rules should include:
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 signer to provide given signed attributes; * requirements on the verifier to obtain additional certificates,
* requirements on the verifier to obtain additional certificates, CRLs, CRLs, results of on line certificate status checks and to use
results of on line certificate status checks and to use timestamps (if time-stamps (if no already provided by the signer).
no already provided by the signer).
B.10 Rules for Algorithm Constraints and Key Lengths 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; The signature validation policy may identify a set of signing
* in end entity public key Certificates; algorithms (hashing, public key, combinations) and minimum key
* CA Certificates; lengths that may be used:
* attribute Certificates;
* by the timestamping authority.
B.11 Other Signature Policy Rules * by the signer in creating the signature;
* in end entity public key Certificates;
* CA Certificates;
* attribute Certificates;
* by the time-stamping authority.
The signature policy may specify additional policy rules, for example B.11 Other Signature Policy Rules
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 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.
When signer or verifier obtains a copy of the Signature Policy from an B.12 Signature Policy Protection
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.
Internet Draft Electronic Signature Policies 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.
It is a mandatory requirement of this present document that the It is a mandatory requirement of this present document that the
signature policy value computes to one, and only one hash value using signature policy value computes to one, and only one hash value using
the specified hash algorithm. This means that there must be a single 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 binary value of the encoded form of the signature policy for the
hash value to be calculated. For example, there may exist a particular unique hash value to be calculated. For example, there may exist a
file type, length and format on which the hash value is calculated particular file type, length and format on which the hash value is
which is fixed and definitive for a particular signature policy. calculated which is fixed and definitive for a particular signature
policy.
The hash value may be obtained by: The hash value may be obtained by:
the signer performing his own computation of the hash over the the signer performing his own computation of the hash over the
signature policy using his preferred hash algorithm permitted by signature policy using his preferred hash algorithm permitted by
the signature policy, and the definitive binary encoded form. the signature policy, and the definitive binary encoded form.
the signer, having verified the source of the policy, may use the signer, having verified the source of the policy, may use both
both the hash algorithm and the hash value included in the the hash algorithm and the hash value included in the computer
computer processable form of the policy (see section 6.1). processable form of the policy (see section 6.1).
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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 of
developing 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 448 change blocks. 
1282 lines changed or deleted 1230 lines changed or added

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