Request for Comments: 3125 Security & Standards
Category: Experimental D. Pinkas
Integris
N. Pope
Security & Standards
September 2001
Electronic Signature Policies
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document defines signature policies for electronic signatures. A
signature policy is a set of rules for the creation and validation of
an electronic signature, under which the validity of signature can be
determined. A given legal/contractual context may recognize a
particular signature policy as meeting its requirements.
A signature policy has a globally unique reference, which is bound to
an electronic signature by the signer as part of the signature
calculation.
The signature policy needs to be available in human readable form so
that it can be assessed to meet the requirements of the legal and
contractual context in which it is being applied.
To allow for the automatic processing of an electronic signature
another part of the signature policy specifies the electronic rules
for the creation and validation of the electronic signature in a
computer processable form. In the current document the format of the
signature policy is defined using ASN.1.
The contents of this 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.
Table of Contents
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
This document is intended to cover signature policies which can be
used with electronic signatures for various types of transactions,
including business transactions (e.g., purchase requisition,
contract, and invoice applications). Electronic signatures can be
used for any transaction between an individual and a company, between
two companies, between an individual and a governmental body, etc.
This document is independent of any environment. It can be applied
to any environment e.g., smart cards, GSM SIM cards, special programs
for electronic signatures etc.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
as shown) are to be interpreted as described in [RFC2119].
2. Major Parties
The document uses the following terms:
* the Signature Policy Issuer;
* the Signer;
* the Verifier;
* the Arbitrator;
* Trusted Service Providers (TSP);
The Signature Policy Issuer (which is a Trusted Service Provider
(TSP)) issues signatures policies that define the technical and
procedural requirements for electronic signature creation, and
validation/ verification, in order to meet a particular business
need.
The Signer is the entity that creates the electronic signature. When
the signer digitally signs over an signature policy identifier, it
represents a commitment on behalf of the signing entity that the data
being signed is signed under the rules defined by the signature
policy.
The Verifier is the entity that validates the electronic signature,
it may be a single entity or multiple entities. The verifier MUST
validate the electronic signature under the rules defined by the
electronic signature policy for the signature to be valid.
An arbitrator, is an entity which arbitrates disputes between a
signer and a verifier. It acts as verifier when it verifies the
electronic signature after it has been previously validated.
The Trusted Service Providers (TSPs) are one or more entities that
help to build trust relationships between the signer and verifier.
Use of TSP specific services MAY be mandated by signature policy.
TSP supporting services include: user certificates, cross-
certificates, time-stamping tokens,CRLs, ARLs, OCSP responses.
A Trusted Service Providers (TSPs) MAY be a Signature Policy Issuer,
as Such, the TSP MUST define the technical and procedural
requirements for electronic signature creation and validation, in
order to meet a particular business need.
The following other TSPs are used to support the functions defined in
this document:
* Certification Authorities;
* Registration Authorities;
* Repository Authorities (e.g., a Directory);
* Time-Stamping Authorities;
* One-line Certificate Status Protocol responders;
* Attribute Authorities.
Certification Authorities provide users with public key certificates.
Registration Authorities allows the registration of entities before a
CA generates certificates.
Repository Authorities publish CRLs issued by CAs, , cross-
certificates (i.e., CA certificates) issued by CAs, signature
policies issued by Signature Policy Issuers and optionally public key
certificates (i.e., leaf certificates) issued by CAs.
Time-Stamping Authorities attest that some data was formed before a
given trusted time.
One-line Certificate Status Protocol responders (OSCP responders)
provide information about the status (i.e., revoked, not revoked,
unknown) of a particular certificate.
Attributes Authorities provide users with attributes linked to public
key certificates
An Arbitrator is an entity that arbitrates disputes between a signer
and a verifier.
3. Signature Policy Specification
A signature policy specification includes general information about
the policy, the validation policy rules and other signature policy
information.
This document mandates that:
* an electronic signature must be processed by the signer and
verifier in accordance with the signature policy referenced by
the signer;
* the signature policy referenced by the signer must be
identifiable by an Object Identifier;
* there must exist a specification of the signature policy;
* for a given signature policy there must be one definitive form
of the specification which has a unique binary encoding;
* a hash of the definitive specification, using an agreed
algorithm, must be provided by the signer and checked by the
verifier.
This document defines but does not mandate the form of the signature
policy specification. The signature policy may be specified either:
* in a free form document for human interpretation; or
* in a structured form using an agreed syntax and encoding.
This document defines an ASN.1 based syntax that may be used to
define a structured signature policy. Future versions of this
document may include structured a signature policy specification
using XML.
3.1 Overall ASN.1 Structure
The overall structure of a signature policy defined using ASN.1 is
given in this section. Use of this ASN.1 structure is optional.
This ASN.1 syntax is encoded using the Distinguished Encoding Rules
(DER).
In this structure the policy information is preceded by an identifier
for the hashing algorithm used to protect the signature policy and
followed by the hash value which must be re-calculated and checked
whenever the signature policy is passed between the issuer and
signer/verifier.
The hash is calculated without the outer type and length fields.
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
SignPolicyId ::= OBJECT IDENTIFIER
PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString
The policyIssuerName field identifies the policy issuer in one or
more of the general name forms.
The fieldofApplication is a description of the expected application
of this policy.
The signature validation policy rules are fully processable to allow
the validation of electronic signatures issued under that form of
signature policy. They are described in the rest of this section.
The signPolExtensions is a generic way to extend the definition of
any sub-component of a signature policy.
3.2 Signature Validation Policy
The signature validation policy defines for the signer which data
elements must be present in the electronic signature he provides and
for the verifier which data elements must be present under that
signature policy for an electronic signature to be potentially valid.
The signature validation policy is described as follows:
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions OPTIONAL
}
The signingPeriod identifies the date and time before which the
signature policy SHOULD NOT be used for creating signatures, and an
optional date after which it should not be used for creating
signatures.
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
3.3 Common Rules
The CommonRules define rules that are common to all commitment types.
These rules are defined in terms of trust conditions for
certificates, time-stamps and attributes, along with any constraints
on attributes that may be included in the electronic signature.
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
If a field is present in CommonRules then the equivalent field must
not be present in any of the CommitmentRules (see below). If any of
the following fields are not present in CommonRules then it must be
present in each CommitmentRule:
* signerAndVeriferRules;
* signingCertTrustCondition;
* timeStampTrustCondition.
3.4 Commitment Rules
The CommitmentRules consists of the validation rules which apply to
given commitment types:
CommitmentRules ::= SEQUENCE OF CommitmentRule
The CommitmentRule for given commitment types are defined in terms of
trust conditions for certificates, time-stamps and attributes, along
with any constraints on attributes that may be included in the
electronic signature.
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
If the SelectedCommitmentTypes indicates "empty" then this rule
applied when a commitment type is not present (i.e., the type of
commitment is indicated in the semantics of the message). Otherwise,
the electronic signature must contain a commitment type indication
that must fit one of the commitments types that are mentioned in
CommitmentType.
A specific commitment type identifier must not appear in more than
one commitment rule.
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
The fieldOfApplication and semantics fields define the specific use
and meaning of the commitment within the overall field of application
defined for the policy.
3.5 Signer and Verifier Rules
The following rules apply to the format of electronic signatures
defined using [ES-FORMATS].
The SignerAndVerifierRules consists of signer rule and verification
rules as defined below:
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }
3.5.1 Signer Rules
The signer rules identify:
* if the eContent is empty and the signature is calculated using
a hash of signed data external to CMS structure.
* the CMS signed attributes that must be provided by the signer
under this policy;
* the CMS unsigned attribute that must be provided by the signer
under this policy;
* whether the certificate identifiers from the full certification
path up to the trust point must be provided by the signer in
the SigningCertificate attribute;
* whether a signer's certificate, or all certificates in the
certification path to the trust point must be by the signer in
the * certificates field of SignedData.
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure
-- Not present if either allowed
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions OPTIONAL
}
CMSattrs ::= SEQUENCE OF OBJECT IDENTIFIER
The 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
all those unsigned attributes required by this document as well as
additional attributes required by this policy. For example, if a
signature time-stamp <see section 1.1) is required by the signer the
object identifier for this attribute must be included.
The mandatedCertificateRef identifies whether just the signer's
certificate, or all the full certificate path must be provided by the
signer.
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullpath (2)
-- References for full cert path up to a trust point required
}
The mandatedCertificateInfo field identifies whether a signer's
certificate, or all certificates in the certification path to the
trust point must be provided by the signer in the certificates field
of SignedData.
CertInfoReq ::= ENUMERATED {
none (0) ,
-- No mandatory requirements
signerOnly (1) ,
-- Only reference to signer cert mandated
fullpath (2)
-- References for full cert path up to a
-- trust point mandated
}
3.5.2 Verifier Rules
The verifier rules identify:
* The CMS unsigned attributes that must be present under this
policy and must be added by the verifier if not added by the
signer.
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed
3.6 Certificate and Revocation Requirement
The SigningCertTrustCondition, TimestampTrustCondition and
AttributeTrustCondition (defined in subsequent sub-sections) make use
of two ASN1 structures which are defined below: CertificateTrustTrees
and CertRevReq.
3.6.1 Certificate Requirements
The certificateTrustTrees identifies a set of self signed
certificates for the trust points used to start (or end) certificate
path processing and the initial conditions for certificate path
validation as defined RFC2459 [7] section 4. This ASN1 structure is
used to define policy for validating the signing certificate, the
TSA's certificate and attribute certificates.
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }
The trustPoint field gives the self signed certificate for the CA
that is used as the trust point for the start of certificate path
processing.
The pathLenConstraint field gives the maximum number of CA
certificates that may be in a certification path following the
trustpoint. A value of zero indicates that only the given trustpoint
certificate and an end-entity certificate may be used. If present,
the pathLenConstraint field must be greater than or equal to zero.
Where pathLenConstraint is not present, there is no limit to the
allowed length of the certification path.
PathLenConstraint ::= INTEGER (0..MAX)
The acceptablePolicySet field identifies the initial set of
certificate policies, any of which are acceptable under the signature
policy. AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER
The nameConstraints field indicates a name space within which all
subject names in subsequent certificates in a certification path must
be located. Restrictions may apply to the subject distinguished name
or subject alternative names. Restrictions apply only when the
specified name form is present. If no name of the type is in the
certificate, the certificate is acceptable.
Restrictions are defined in terms of permitted or excluded name
subtrees. Any name matching a restriction in the excludedSubtrees
field is invalid regardless of information appearing in the
permittedSubtrees.
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
The policyConstraints extension constrains path processing in two
ways. It can be used to prohibit policy mapping or require that each
certificate in a path contain an acceptable policy identifier.
The policyConstraints field, if present specifies requirement for
explicit indication of the certificate policy and/or the constraints
on policy mapping.
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
If the inhibitPolicyMapping field is present, the value indicates the
number of additional certificates that may appear in the path
(including the trustpoint's self certificate) before policy mapping
is no longer permitted. For example, a value of one indicates that
policy mapping may be processed in certificates issued by the subject
of this certificate, but not in additional certificates in the path.
If the requireExplicitPolicy field is present, subsequent
certificates must include an acceptable policy identifier. The value
of requireExplicitPolicy indicates the number of additional
certificates that may appear in the path (including the trustpoint's
self certificate) before an explicit policy is required. An
acceptable policy identifier is the identifier of a policy required
by the user of the certification path or the identifier of a policy
which has been declared equivalent through policy mapping.
3.6.2 Revocation Requirements
The RevocRequirements field specifies minimum requirements for
revocation information, obtained through CRLs and/or OCSP responses,
to be used in checking the revocation status of certificates. This
ASN1 structure is used to define policy for validating the signing
certificate, the TSA's certificate and attribute certificates.
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
Certificate revocation requirements are specified in terms of checks
required on:
* endCertRevReq: end certificates (i.e., the signers certificate,
the attribute certificate or the time-stamping authority
certificate).
* caCerts: CA certificates.
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
An authority certificate is certificate issued to an authority (e.g.,
either to a certification authority or to an attribute authority
(AA)).
A 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 {
clrCheck (0),
--Checks must be made against current CRLs
-- (or authority revocation lists (ARL))
ocspCheck (1), -- The revocation status must be checked
-- using the Online Certificate Status Protocol
-- (OCSP),RFC2450.
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be
-- carried out
noCheck (4),
-- no check is mandated
other (5)
-- Other mechanism as defined by signature policy
-- extension
}
Revocation requirements are specified in terms of:
* clrCheck: Checks must be made against current CRLs (or
authority revocation lists);
* ocspCheck: The revocation status must be checked using the
Online Certificate Status Protocol (RFC2450);
* bothCheck: Both OCSP and CRL checks must be carried out;
* eitherCheck: Either OCSP or CRL checks must be carried out;
* noCheck: No check is mandated.
3.7 Signing Certificate Trust Conditions
The SigningCertTrustCondition field identifies trust conditions for
certificate path processing used to validate the signing certificate.
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq
}
3.8 Time-Stamp Trust Conditions
The TimeStampTrustCondition field identifies trust conditions for
certificate path processing used to authenticate the timstamping
authority and constraints on the name of the time-stamping authority.
This applies to the time-stamp that must be present in every ES-T.
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL,
ttsRevReq [1] CertRevReq
OPTIONAL,
ttsNameConstraints [2] NameConstraints
OPTIONAL,
cautionPeriod [3] DeltaTime
OPTIONAL,
signatureTimestampDelay [4] DeltaTime
OPTIONAL }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
deltaHours INTEGER,
deltaDays INTEGER }
If ttsCertificateTrustTrees is not present then the same rule as
defined in certificateTrustCondition applies to certification of the
time-stamping authorities public key.
The tstrRevReq specifies minimum requirements for revocation
information, obtained through CRLs and/or OCSP responses, to be used
in checking the revocation status of the time-stamp that must be
present in the ES-T.
If ttsNameConstraints is not present then there are no additional
naming constraints on the trusted time-stamping authority other than
those implied by the ttsCertificateTrustTrees.
The cautionPeriod field specifies a caution period after the signing
time that it is mandated the verifier must wait to get high assurance
of the validity of the signer's key and that any relevant revocation
has been notified. The revocation status information forming the ES
with Complete validation data must not be collected and used to
validate the electronic signature until after this caution period.
The signatureTimestampDelay field specifies a maximum acceptable time
between the signing time and the time at which the signature time-
stamp, as used to form the ES Time-Stamped, is created for the
verifier. If the signature time-stamp is later that the time in the
signing-time attribute by more than the value given in
signatureTimestampDelay, the signature must be considered invalid.
3.9 Attribute Trust Conditions
If the attributeTrustCondition field is not present then any
certified attributes may not considered to be valid under this
validation policy. The AttributeTrustCondition field is defined as
follows:
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }
If attributeMandated is true then an attribute, certified within the
following constraints, must be present. If false, then the signature
is still valid if no attribute is specified.
The howCertAttribute field specifies whether attributes uncertified
attributes "claimed" by the signer, or certified attributes (i.e.,
Attribute Certificates) or either using the signer attributes
attribute defined in [ES-FORMATS] section 3.12.3.
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
The attrCertificateTrustTrees specifies certificate path conditions
for any attribute certificate. If not present the same rules apply
as in certificateTrustCondition.
The attrRevReq specifies minimum requirements for revocation
information, obtained through CRLs and/or OCSP responses, to be used
in checking the revocation status of Attribute Certificates, if any
are present.
If the attributeConstraints field is not present then there are no
constraints on the attributes that may be validated under this
policy. The attributeConstraints field is defined as follows:
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
If present, the attributeTypeConstarints field specifies the
attribute types which are considered valid under the signature
policy. Any value for that attribute is considered valid.
AttributeTypeConstraints ::= SEQUENCE OF AttributeType
If present, the attributeTypeConstraints field specifies the specific
attribute values which are considered valid under the signature
policy.
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
3.10 Algorithm Constraints
The algorithmConstrains fields, if present, identifies the signing
algorithms (hash, public key cryptography, combined hash and public
key cryptography) that may be used for specific purposes and any
minimum length. If this field is not present then the policy applies
no constraints.
AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- Time-Stamping Authority
}
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits
other SignPolExtensions OPTIONAL
}
An Attribute Authority (AA)is authority which assigns privileges by
issuing attribute certificates
3.11 Signature Policy Extensions
Additional signature policy rules may be added to:
* the overall signature policy structure, as defined in section
3.1;
* the signature validation policy structure, as defined in
section 3.2;
* the common rules, as defined in section 3.3;
* the commitment rules, as defined in section 3.4;
* the signer rules, as defined in section 3.5.1;
* the verifier rules, as defined in section 3.5.2;
* the revocation requirements in section 3.6.2;
* the algorithm constraints in section 3.10.
These extensions to the signature policy rules must be defined using
an ASN.1 syntax with an associated object identifier carried in the
SignPolExtn as defined below:
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
The extnID field must contain the object identifier for the
extension. The extnValue field must contain the DER (see ITU-T
Recommendation X.690 [4]) encoded value of the extension. The
definition of an extension, as identified by extnID must include a
definition of the syntax and semantics of the extension.
4. Security Considerations
4.1 Protection of Private Key
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.
4.2 Choice of Algorithms
Implementers should be aware that cryptographic algorithms become
weaker with time. As new cryptoanalysis techniques are developed and
computing performance improves, the work factor to break a particular
cryptographic algorithm will reduce. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms
to be readily inserted. That is, implementers should be prepared for
the set of mandatory to implement algorithms to change over time.
5. Conformance Requirements
Signer and verifier systems shall be able to process an electronic
signature in accordance with the specification of the signature
policy signature policy referenced identifiable by an Object
Identifier, see section 3.
6. References
[TS101733] ETSI Standard TS 101 733 V.1.2.2 (2000-12) Electronic
Signature Formats. Note: copies of ETSI TS 101 733 can
be freely download from the ETSI web site www.etsi.org.
[ES-FORMATS] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature
Formats for Long Term Electronic Signatures", RFC3126,
June 2001.
[TSP] Adams, C, Pinkas, D., Zuccherato, R. and P. Cain,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC3161, August 2001.
[OCSP] Myers, M., Ankney, R., Malpani, R., Galperin, S. and C.
Adams, "On-line Status Certificate Protocol", RFC2560,
June 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC2634, June 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC2630,
June 1999.
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure, Certificate and CRL
Profile," RFC2459, January 1999.
[PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards
(PKCS)", RSA Data Security Inc., Redwood City,
California, November 1993 Release.
[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems.
Non-Repudiation Framework. April 1997.
7. Authors' Addresses
This Experimental RFChas been produced in ETSI TC-SEC.
ETSI
F-06921 Sophia Antipolis, Cedex - FRANCE
650 Route des Lucioles - Sophia Antipolis
Valbonne - FranceTel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
secretariat@etsi.fr
http://www.etsi.org
Contact Point
Harri Rasilainen
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex
FRANCE
EMail: harri.rasilainen@etsi.fr
John Ross
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom
EMail: ross@secstan.com
Denis Pinkas
Integris, Bull.
68, Route de Versailles
78434 Louveciennes CEDEX
FRANCE
EMail: Denis.Pinkas@bull.net
Nick Pope
Security & Standards
192 Moulsham Street
Chelmsford, Essex
CM2 0LG
United Kingdom
EMail: pope@secstan.com
Annex A (normative):
ASN.1 Definitions This annex provides the reference definition of the
ASN.1 syntax signature policies definitions for new syntax defined in
this document.
A.1 Definitions Using X.208 (1988) ASN.1 Syntax
NOTE: The ASN.1 Module defined in section A.1 has precedence over
that defined in Annex A-2 in the case of any conflict.
ETS-ElectronicSignaturePolicies-88syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0)
7}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS All
IMPORTS
-- Internet X.509 Public Key Infrastructure
- Certificate and CRL Profile: RFC2560
Certificate, AlgorithmIdentifier, CertificateList, Name,
GeneralNames, GeneralName, DirectoryString,Attribute,
AttributeTypeAndValue, AttributeType, AttributeValue,
PolicyInformation, BMPString, UTF8String
FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
;
-- Signature Policy Specification
-- ==============================
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions
OPTIONAL
}
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
CommitmentRules ::= SEQUENCE OF CommitmentRule
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure
-- not present if either allowed
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions
OPTIONAL}
CMSAttrs ::= SEQUENCE OF OBJECT IDENTIFIER
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a trust point required
}
CertInfoReq ::= ENUMERATED {
none (0),
-- No mandatory requirements
signerOnly (1),
-- Only reference to signer cert mandated
fullPath (2)
-- References for full cert path up to a trust point mandated
}
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }
PathLenConstraint ::= INTEGER (0..MAX)
AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq,
caCerts [0] RevReq
}
RevReq ::= SEQUENCE {
enuRevReq EnuRevReq,
exRevReq SignPolExtensions OPTIONAL}
EnuRevReq ::= ENUMERATED {
clrCheck (0), --Checks must be made against current CRLs
-- (or authority revocation lists)
ocspCheck (1), -- The revocation status must be checked
-- using the Online Certificate Status Protocol (RFC2450)
bothCheck (2),
-- Both CRL and OCSP checks must be carried out
eitherCheck (3),
-- At least one of CRL or OCSP checks must be carried out
noCheck (4),
-- no check is mandated
other (5)
-- Other mechanism as defined by signature policy extension
}
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees,
signerRevReq CertRevReq
}
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0] CertificateTrustTrees
OPTIONAL,
ttsRevReq [1] CertRevReq
OPTIONAL,
ttsNameConstraints [2] NameConstraints
OPTIONAL,
cautionPeriod [3] DeltaTime
OPTIONAL,
signatureTimestampDelay [4] DeltaTime
OPTIONAL }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER,
deltaMinutes INTEGER,
deltaHours INTEGER,
deltaDays INTEGER }
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN,
-- Attribute must be present
howCertAttribute HowCertAttribute,
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL,
attrRevReq [1] CertRevReq OPTIONAL,
attributeConstraints [2] AttributeConstraints OPTIONAL }
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
AttributeConstraints ::= SEQUENCE {
attributeTypeConstarints [0] AttributeTypeConstraints
OPTIONAL,
attributeValueConstarints [1] AttributeValueConstraints
OPTIONAL }
AttributeTypeConstraints ::= SEQUENCE OF AttributeType
AttributeValueConstraints ::= SEQUENCE OF AttributeTypeAndValue
AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on:
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL,
-- signer
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL,
-- issuer of end entity certs.
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL,
-- issuer of CA certificates
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL,
-- Attribute Authority
tsaCertAlgorithmConstraints [4] AlgorithmConstraints OPTIONAL
-- Time-Stamping Authority
}
AlgorithmConstraints ::= SEQUENCE OF AlgAndLength
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER,
minKeyLength INTEGER OPTIONAL,
-- Minimum key length in bits other
SignPolExtensions OPTIONAL
}
SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
extnValue OCTET STRING }
END -- ETS-ElectronicSignaturePolicies-88syntax --
A.2 Definitions Using X.680 1997 ASN.1 Syntax
NOTE: The ASN.1 module defined in section A.1 has precedence over
that defined in section A.2 in the case of any conflict.
ETS-ElectronicSignaturePolicies-97Syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 8}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS All -
IMPORTS
-- Internet X.509 Public Key Infrastructure
-- Certificate and CRL Profile: RFC2560
Certificate, AlgorithmIdentifier, CertificateList, Name,
GeneralNames, GeneralName, DirectoryString, Attribute,
AttributeTypeAndValue, AttributeType, AttributeValue,
PolicyInformation
FROM PKIX1Explicit93
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
nid-pkix1-explicit-88(1)}
;
-- S/MIME Object Identifier arcs used in the present document
-- ==================================================================
-- S/MIME OID arc used in the present document
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
-- S/MIME Arcs
-- id-mod OBJECT IDENTIFIER ::= { id-smime 0 }
-- modules
-- id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
-- content types
-- id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
-- attributes
-- id-spq OBJECT IDENTIFIER ::= { id-smime 5 }
-- signature policy qualifier
-- id-cti OBJECT IDENTIFIER ::= { id-smime 6 }
-- commitment type identifier
-- Signature Policy Specification
-- ==============================
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier,
signPolicyInfo SignPolicyInfo,
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET STRING
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
dateOfIssue GeneralizedTime,
policyIssuerName PolicyIssuerName,
fieldOfApplication FieldOfApplication,
signatureValidationPolicy SignatureValidationPolicy,
signPolExtensions SignPolExtensions
OPTIONAL
}
SignPolicyId ::= OBJECT IDENTIFIER
PolicyIssuerName ::= GeneralNames
FieldOfApplication ::= DirectoryString
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions OPTIONAL
}
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
CommitmentRules ::= SEQUENCE OF CommitmentRule
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure