summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3125.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3125.txt')
-rw-r--r--doc/rfc/rfc3125.txt2467
1 files changed, 2467 insertions, 0 deletions
diff --git a/doc/rfc/rfc3125.txt b/doc/rfc/rfc3125.txt
new file mode 100644
index 0000000..f8a88f0
--- /dev/null
+++ b/doc/rfc/rfc3125.txt
@@ -0,0 +1,2467 @@
+
+
+
+
+
+
+Network Working Group J. Ross
+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.
+
+
+
+Ross, et al. Experimental [Page 1]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+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
+
+
+
+Ross, et al. Experimental [Page 2]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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.
+
+
+
+
+Ross, et al. Experimental [Page 3]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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.
+
+
+
+
+Ross, et al. Experimental [Page 4]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+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.
+
+
+
+
+
+Ross, et al. Experimental [Page 5]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+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:
+
+
+
+
+
+
+
+Ross, et al. Experimental [Page 6]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+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.
+
+
+
+
+
+Ross, et al. Experimental [Page 7]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+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 }
+
+
+
+
+Ross, et al. Experimental [Page 8]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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
+
+
+
+Ross, et al. Experimental [Page 9]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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
+ }
+
+
+
+
+
+
+
+
+Ross, et al. Experimental [Page 10]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+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 RFC 2459 [7] section 4. This ASN1 structure is
+ used to define policy for validating the signing certificate, the
+ TSA's certificate and attribute certificates.
+
+CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
+
+CertificateTrustPoint ::= SEQUENCE {
+ trustpoint Certificate,
+ -- self-signed certificate
+ pathLenConstraint [0] PathLenConstraint OPTIONAL,
+ acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
+ -- If not present "any policy"
+ nameConstraints [2] NameConstraints OPTIONAL,
+ policyConstraints [3] PolicyConstraints OPTIONAL }
+
+
+ The trustPoint field gives the self signed certificate for the CA
+ that is used as the trust point for the start of certificate path
+ processing.
+
+
+
+
+Ross, et al. Experimental [Page 11]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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.
+
+
+
+Ross, et al. Experimental [Page 12]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+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}
+
+
+
+
+Ross, et al. Experimental [Page 13]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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),RFC 2450.
+ bothCheck (2),
+ -- Both CRL and OCSP checks must be carried out
+ eitherCheck (3),
+ -- At least one of CRL or OCSP checks must be
+ -- carried out
+ noCheck (4),
+ -- no check is mandated
+ other (5)
+ -- Other mechanism as defined by signature policy
+ -- extension
+ }
+
+ Revocation requirements are specified in terms of:
+
+ * clrCheck: Checks must be made against current CRLs (or
+ authority revocation lists);
+ * ocspCheck: The revocation status must be checked using the
+ Online Certificate Status Protocol (RFC 2450);
+ * bothCheck: Both OCSP and CRL checks must be carried out;
+ * eitherCheck: Either OCSP or CRL checks must be carried out;
+ * noCheck: No check is mandated.
+
+3.7 Signing Certificate Trust Conditions
+
+ The SigningCertTrustCondition field identifies trust conditions for
+ certificate path processing used to validate the signing certificate.
+
+SigningCertTrustCondition ::= SEQUENCE {
+ signerTrustTrees CertificateTrustTrees,
+ signerRevReq CertRevReq
+ }
+
+
+
+
+
+Ross, et al. Experimental [Page 14]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+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
+
+
+
+Ross, et al. Experimental [Page 15]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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:
+
+
+
+
+
+
+Ross, et al. Experimental [Page 16]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+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
+ }
+
+
+
+
+Ross, et al. Experimental [Page 17]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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
+
+
+
+Ross, et al. Experimental [Page 18]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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", RFC 3126,
+ June 2001.
+
+ [TSP] Adams, C, Pinkas, D., Zuccherato, R. and P. Cain,
+ "Internet X.509 Public Key Infrastructure Time-Stamp
+ Protocol (TSP)", RFC 3161, August 2001.
+
+ [OCSP] Myers, M., Ankney, R., Malpani, R., Galperin, S. and C.
+ Adams, "On-line Status Certificate Protocol", RFC 2560,
+ June 1999.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
+ RFC 2634, June 1999.
+
+ [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
+ June 1999.
+
+ [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
+ X.509 Public Key Infrastructure, Certificate and CRL
+ Profile," RFC 2459, January 1999.
+
+ [PKCS9] RSA Laboratories, "The Public-Key Cryptography Standards
+ (PKCS)", RSA Data Security Inc., Redwood City,
+ California, November 1993 Release.
+
+
+
+
+
+Ross, et al. Experimental [Page 19]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ [ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems.
+ Non-Repudiation Framework. April 1997.
+
+7. Authors' Addresses
+
+ This Experimental RFC has been produced in ETSI TC-SEC.
+
+ ETSI
+ F-06921 Sophia Antipolis, Cedex - FRANCE
+ 650 Route des Lucioles - Sophia Antipolis
+ Valbonne - FranceTel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
+ secretariat@etsi.fr
+ http://www.etsi.org
+
+ Contact Point
+
+ Harri Rasilainen
+ ETSI
+ 650 Route des Lucioles
+ F-06921 Sophia Antipolis Cedex
+ FRANCE
+
+ 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
+
+
+
+Ross, et al. Experimental [Page 20]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+Annex A (normative):
+
+ ASN.1 Definitions This annex provides the reference definition of the
+ ASN.1 syntax signature policies definitions for new syntax defined in
+ this document.
+
+A.1 Definitions Using X.208 (1988) ASN.1 Syntax
+
+ NOTE: The ASN.1 Module defined in section A.1 has precedence over
+ that defined in Annex A-2 in the case of any conflict.
+
+ ETS-ElectronicSignaturePolicies-88syntax { iso(1) member-body(2)
+ us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0)
+ 7}
+
+DEFINITIONS EXPLICIT TAGS ::=
+BEGIN
+-- EXPORTS All
+
+IMPORTS
+
+-- Internet X.509 Public Key Infrastructure
+ - Certificate and CRL Profile: RFC 2560
+ 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,
+
+
+
+Ross, et al. Experimental [Page 21]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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,
+
+
+
+Ross, et al. Experimental [Page 22]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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 {
+
+
+
+Ross, et al. Experimental [Page 23]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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,
+
+
+
+Ross, et al. Experimental [Page 24]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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 (RFC 2450)
+ bothCheck (2),
+ -- Both CRL and OCSP checks must be carried out
+ eitherCheck (3),
+ -- At least one of CRL or OCSP checks must be carried out
+ noCheck (4),
+ -- no check is mandated
+ other (5)
+ -- Other mechanism as defined by signature policy extension
+ }
+
+SigningCertTrustCondition ::= SEQUENCE {
+ signerTrustTrees CertificateTrustTrees,
+ signerRevReq CertRevReq
+ }
+
+TimestampTrustCondition ::= SEQUENCE {
+ ttsCertificateTrustTrees [0] CertificateTrustTrees
+ OPTIONAL,
+ ttsRevReq [1] CertRevReq
+ OPTIONAL,
+ ttsNameConstraints [2] NameConstraints
+ OPTIONAL,
+ cautionPeriod [3] DeltaTime
+ OPTIONAL,
+ signatureTimestampDelay [4] DeltaTime
+ OPTIONAL }
+
+DeltaTime ::= SEQUENCE {
+ deltaSeconds INTEGER,
+ deltaMinutes INTEGER,
+
+
+
+Ross, et al. Experimental [Page 25]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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
+
+
+
+Ross, et al. Experimental [Page 26]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ }
+
+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: RFC 2560
+ 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
+
+
+
+Ross, et al. Experimental [Page 27]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+-- 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,
+
+
+
+Ross, et al. Experimental [Page 28]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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
+
+
+
+Ross, et al. Experimental [Page 29]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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 }
+
+
+
+Ross, et al. Experimental [Page 30]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+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 (RFC 2450)
+ bothCheck (2),
+ -- Both CRL and OCSP checks must be carried out
+ eitherCheck (3),
+ -- At least one of CRL or OCSP checks must be
+ -- carried out
+ noCheck (4),
+ -- no check is mandated
+
+
+
+Ross, et al. Experimental [Page 31]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ 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 }
+
+
+
+
+Ross, et al. Experimental [Page 32]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+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-ElectronicPolicies-97Syntax
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ross, et al. Experimental [Page 33]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+Annex B (informative):
+
+B.1 Signature Policy and Signature Validation Policy
+
+ The definition of electronic signature mentions: "a commitment has
+ been explicitly endorsed under a "Signature Policy", at a given time,
+ by a signer under an identifier, e.g., a name or a pseudonym, and
+ optionally a role."
+
+ Electronic signatures are commonly applied within the context of a
+ legal or contractual framework. This establishes the requirements on
+ the electronic signatures and any special semantics (e.g., agreement,
+ intent). These requirements may be defined in very general abstract
+ terms or in terms of detailed rules. The specific semantics
+ associated with an electronic signature implied by a legal or
+ contractual framework are outside the scope of this document.
+
+ If the signature policy is recognized, within the legal/contractual
+ context, as providing commitment, then the signer explicitly agrees
+ with terms and conditions which are implicitly or explicitly part of
+ the signed data.
+
+ When two independent parties want to evaluate an electronic
+ signature, it is fundamental that they get the same result. It is
+ therefore important that the conditions agreed by the signer at the
+ time of signing are indicated to the verifier and any arbitrator. An
+ aspect that enables this to be known by all parties is the signature
+ policy. The technical implications of the signature policy on the
+ electronic signature with all the validation data are called the
+ "Signature Validation Policy". The signature validation policy
+ specifies the rules used to validate the signature.
+
+ This document does not mandate the form and encoding of the
+ specification of the signature policy. However, for a given
+ signature policy there must be one definitive form that has a unique
+ binary encoded value.
+
+ This document includes, as an option, a formal structure for
+ signature validation policy based on the use of Abstract Syntax
+ Notation 1 (ASN.1).
+
+ Given the specification of the signature policy and its hash value an
+ implementation of a verification process must obey the rules defined
+ in the specification.
+
+ This document places no restriction on how it should be implemented.
+ Provide the implementation conforms to the conformance requirements
+ as define in section 5 implementation options include:
+
+
+
+Ross, et al. Experimental [Page 34]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ A validation process that supports a specific signature policy as
+ identified by the signature policy OID. Such an implementation
+ should conform to a human readable description provided all the
+ processing rules of the signature policy are clearly defined.
+ However, if additional policies need to be supported, then such an
+ implementation would need to be customized for each additional
+ policy. This type of implementation may be simpler to implement
+ initially, but can be difficult to enhance to support numerous
+ additional signature policies.
+
+ A validation process that is dynamically programmable and able to
+ adapt its validation rules in accordance with a description of the
+ signature policy provided in a computer-processable language. This
+ present document defines such a policy using an ASN.1 structure (see
+ 6.1). This type of implementation could support multiple signature
+ policies without being modified every time, provided all the
+ validation rules specified as part of the signature policy are known
+ by the implementation. (i.e., only requires modification if there
+ are additional rules specified).
+
+ The precise content of a signature policy is not mandated by the
+ current document. However, a signature policy must be sufficiently
+ definitive to avoid any ambiguity as to its implementation
+ requirements. It must be absolutely clear under which conditions an
+ electronic signature should be accepted. For this reason, it should
+ contain the following information:
+
+ * General information about the signature policy which includes:
+ - a unique identifier of the policy;
+ - the name of the issuer of the policy;
+ - the date the policy was issued;
+ - the field of application of the policy.
+
+ * The signature verification policy which includes:
+ - the signing period,
+ - a list of recognized commitment types;
+ - rules for Use of Certification Authorities;
+ - rules for Use of Revocation Status Information;
+ - rules for Use of Roles;
+ - rules for use of Time-Stamping and Timing;
+ - signature verification data to be provided by the
+ signer/collected by verifier;
+ - any constraints on signature algorithms and key lengths.
+ * Other signature policy rules required to meet the objectives of
+ the signature.
+
+ Variations of the validation policy rules may apply to different
+ commitment types.
+
+
+
+Ross, et al. Experimental [Page 35]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+B.2 Identification of Signature Policy
+
+ When data is signed the signer indicates the signature policy
+ applicable to that electronic signature by including an object
+ identifier for the signature policy with the signature. The signer
+ and verifier must apply the rules specified by the identified policy.
+ In addition to the identifier of the signature policy the signer must
+ include the hash of the signature policy, so it can be verified that
+ the policy selected by the signer is the identical to the one being
+ used the verifier.
+
+ A signature policy may be qualified by additional information. This
+ can includes:
+
+ * A URL where a copy of the Signature Policy may be obtained;
+ * A user notice that should be displayed when the signature is
+ verified;
+
+ If no signature policy is identified then the signature may be
+ assumed to have been generated/verified without any policy
+ constraints, and hence may be given no specific legal or contractual
+ significance through the context of a signature policy.
+
+ A "Signature Policy" will be identifiable by an OID (Object
+ Identifier) and verifiable using a hash of the signature policy.
+
+B.3 General Signature Policy Information
+
+ General information should be recorded about the signature policy
+ along with the definition of the rules which form the signature
+ policy as described in subsequent subsections. This should include:
+
+ * Policy Object Identifier: The "Signature Policy" will be
+ identifiable by an OID (Object Identifier) whose last component
+ (i.e., right most) is an integer that is specific to a
+ particular version issued on the given date.
+ * Date of issue: When the "Signature Policy" was issued.
+ * Signature Policy Issuer name: An identifier for the body
+ responsible for issuing the Signature Policy. This may be used
+ by the signer or verifying in deciding if a policy is to be
+ trusted, in which case the signer/verifier must authenticate
+ the origin of the signature policy as coming from the
+ identified issuer.
+ * Signing period: The start time and date, optionally with an end
+ time and date, for the period over which the signature policy
+ may be used to generate electronic signatures.
+
+
+
+
+
+Ross, et al. Experimental [Page 36]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ * 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.
+
+B.4 Recognized Commitment Types
+
+ The signature validation policy may recognize one or more types of
+ commitment as being supported by electronic signatures produced under
+ the security policy. If an electronic signature does not contain a
+ recognized commitment type then the semantics of the electronic
+ signature is dependent on the data being signed and the context in
+ which it is being used.
+
+ Only recognized commitment types are allowed in an electronic
+ signature.
+
+ The definition of a commitment type includes:
+
+ * the object identifier for the commitment;
+ * the contractual/legal/application context in which the
+ signature may be used (e.g., submission of messages);
+ * a description of the support provided within the terms of the
+ context (e.g., proof that the identified source submitted the
+ message if the signature is created when message submission is
+ initiated).
+
+ The definition of a commitment type can be registered:
+
+ * as part of the validation policy;
+ * as part of the application/contract/legal environment;
+ * as part of generic register of definitions.
+
+ The legal/contractual context will determine the rules applied to the
+ signature, as defined by the signature policy and its recognized
+ commitment types, make it fit for purpose intended.
+
+B.5 Rules for Use of Certification Authorities
+
+ The certificate validation process of the verifier, and hence the
+ certificates that may be used by the signer for a valid electronic
+ signature, may be constrained by the combination of the trust point
+ and certificate path constraints in the signature validation policy.
+
+
+
+
+
+
+
+
+Ross, et al. Experimental [Page 37]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+B.5.1 Trust Points
+
+ The signature validation policy defines the certification authority
+ trust points that are to be used for signature verification. Several
+ trust points may be specified under one signature policy. Specific
+ trust points may be specified for a particular type of commitment
+ defined under the signature policy. For a signature to be valid a
+ certification path must exists between the Certification Authority
+ that has granted the certificate selected by the signer (i.e., the
+ used user-certificate) and one of the trust point of the "Signature
+ Validation Policy".
+
+B.5.2 Certification Path
+
+ There may be constraints on the use of certificates issued by one or
+ more CA(s) in the certificate chain and trust points. The two prime
+ constraints are certificate policy constraints and naming
+ constraints:
+
+ * Certificate policy constraints limit the certification chain
+ between the user certificate and the certificate of the trusted
+ point to a given set of certificate policies, or equivalents
+ identified through certificate policy mapping.
+ * The naming constraints limit the forms of names that the CA is
+ allowed to certify.
+
+ Name constraints are particularly important when a "Signature policy"
+ identifies more than one trust point. In this case, a certificate of
+ a particular trusted point may only be used to verify signatures from
+ users with names permitted under the name constraint.
+
+ Certificate Authorities may be organized in a tree structure, this
+ tree structure may represent the trust relationship between various
+ CA(s) and the users CA. Alternatively, a mesh relationship may exist
+ where a combination of tree and peer cross-certificates may be used.
+ The requirement of the certificate path in this document is that it
+ provides the trust relationship between all the CAs and the signers
+ user certificate. The starting point from a verification point of
+ view, is the "trust point". A trust point is usually a CA that
+ publishes self-certified certificates, is the starting point from
+ which the verifier verifies the certificate chain. Naming
+ constraints may apply from the trust point, in which case they apply
+ throughout the set of certificates that make up the certificate path
+ down to the signer's user certificate.
+
+ Policy constraints can be easier to process but to be effective
+ require the presence of a certificate policy identifier in the
+ certificates used in a certification path.
+
+
+
+Ross, et al. Experimental [Page 38]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ Certificate path processing, thus generally starts with one of the
+ trust point from the signature policy and ends with the user
+ certificate. The certificate path processing procedures defined in
+ RFC 2459 section 6 identifies the following initial parameters that
+ are selected by the verifier in certificate path processing:
+
+ * acceptable certificate policies;
+ * naming constraints in terms of constrained and excluded naming
+ subtree;
+ * requirements for explicit certificate policy indication and
+ whether certificate policy mapping are allowed;
+ * restrictions on the certificate path length.
+
+ The signature validation policy identifies constraints on these
+ parameters.
+
+B.6 Revocation Rules
+
+ The signature policy should defines rules specifying requirements for
+ the use of certificate revocation lists (CRLs) and/or on-line
+ certificate status check service to check the validity of a
+ certificate. These rules specify the mandated minimum checks that
+ must be carried out.
+
+ It is expected that in many cases either check may be selected with
+ CRLs checks being carried out for certificate status that are
+ unavailable from OCSP servers. The verifier may take into account
+ information in the certificate in deciding how best to check the
+ revocation status (e.g., a certificate extension field about
+ authority information access or a CRL distribution point) provided
+ that it does not conflict with the signature policy revocation rules.
+
+B.7 Rules for the Use of Roles
+
+ Roles can be supported as claimed roles or as certified roles using
+ Attribute Certificates.
+
+B.7.1 Attribute Values
+
+ When signature under a role is mandated by the signature policy, then
+ either Attribute Certificates may be used or the signer may provide a
+ claimed role attribute. The acceptable attribute types or values may
+ be dependent on the type of commitment. For example, a user may have
+ several roles that allow the user to sign data that imply commitments
+ based on one or more of his roles.
+
+
+
+
+
+
+Ross, et al. Experimental [Page 39]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+B.7.2 Trust Points for Certified Attributes
+
+ When a signature under a certified role is mandated by the signature
+ policy, Attribute Authorities are used and need to be validated as
+ part of the overall validation of the electronic signature. The
+ trust points for Attribute Authorities do not need to be the same as
+ the trust points to evaluate a certificate from the CA of the signer.
+ Thus the trust point for verifying roles need not be the same as
+ trust point used to validate the certificate path of the user's key.
+
+ Naming and certification policy constraints may apply to the AA in
+ similar circumstance to when they apply to CA. Constraints on the AA
+ and CA need not be exactly the same.
+
+ AA(s) may be used when a signer is creating a signature on behalf of
+ an organization, they can be particularly useful when the signature
+ represents an organizational role. AA(s) may or may not be the same
+ authority as CA(s).
+
+ Thus, the Signature Policy identifies trust points that can be used
+ for Attribute Authorities, either by reference to the same trust
+ points as used for Certification Authorities, or by an independent
+ list.
+
+B.7.3 Certification Path for Certified Attributes
+
+ Attribute Authorities may be organized in a tree structure in similar
+ way to CA where the AAs are the leafs of such a tree. Naming and
+ other constraints may be required on attribute certificate paths in a
+ similar manner to other electronic signature certificate paths.
+
+ Thus, the Signature Policy identify constraints on the following
+ parameters used as input to the certificate path processing:
+
+ * acceptable certificate policies, including requirements for
+ explicit certificate policy indication and whether certificate
+ policy mapping is allowed;
+ * naming constraints in terms of constrained and excluded naming
+ subtrees;
+ * restrictions on the certificate path length.
+
+B.8 Rules for the Use of Time-Stamping and Timing
+
+ The following rules should be used when specifying, constraints on
+ the certificate paths for time-stamping authorities, constraints on
+ the time-stamping authority names and general timing constraints.
+
+
+
+
+
+Ross, et al. Experimental [Page 40]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+B.8.1 Trust Points and Certificate Paths
+
+ Signature keys from time-stamping authorities will need to be
+ supported by a certification path. The certification path used for
+ time-stamping authorities requires a trustpoint and possibly path
+ constraints in the same way that the certificate path for the
+ signer's key.
+
+B.8.2 Time-Stamping Authority Names
+
+ Restrictions may need to be placed by the validation policy on the
+ named entities that may act a time-stamping authorities.
+
+B.8.3 Timing Constraints - Caution Period
+
+ Before an electronic signature may really be valid, the verifier has
+ to be sure that the holder of the private key was really the only one
+ in possession of key at the time of signing. However, there is an
+ inevitable delay between a compromise or loss of key being noted, and
+ a report of revocation being distributed. To allow greater
+ confidence in the validity of a signature, a "cautionary period" may
+ be identified before a signature may be said to be valid with high
+ confidence. A verifier may revalidate a signature after this
+ cautionary signature, or wait for this period before validating a
+ signature.
+
+ The validation policy may specify such a cautionary period.
+
+B.8.4 Timing Constraints - Time-Stamp 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.
+
+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.
+
+
+
+
+
+
+
+Ross, et al. Experimental [Page 41]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ These verification data rules should include:
+
+ * requirements on the signer to provide given signed attributes;
+ * requirements on the verifier to obtain additional certificates,
+ CRLs, results of on line certificate status checks and to use
+ time-stamps (if no already provided by the signer).
+
+B.10 Rules for Algorithm Constraints and Key Lengths
+
+ The signature validation policy may identify a set of signing
+ algorithms (hashing, public key, combinations) and minimum key
+ lengths that may be used:
+
+ * by the signer in creating the signature;
+ * in end entity public key Certificates;
+ * CA Certificates;
+ * attribute Certificates;
+ * by the time-stamping authority.
+
+B.11 Other Signature Policy Rules
+
+ The signature policy may specify additional policy rules, for example
+ rules that relate to the environment used by the signer. These
+ additional rules may be defined in computer processable and/or human
+ readable form.
+
+B.12 Signature Policy Protection
+
+ When signer or verifier obtains a copy of the Signature Policy from
+ an issuer, the source should be authenticated (for example by using
+ electronic signatures). When the signer references a signature
+ policy the Object Identifier (OID) of the policy, the hash value and
+ the hash algorithm OID of that policy must be included in the
+ Electronic Signature.
+
+ It is a mandatory requirement of this present document that the
+ signature policy value computes to one, and only one hash value using
+ the specified hash algorithm. This means that there must be a single
+ binary value of the encoded form of the signature policy for the
+ unique hash value to be calculated. For example, there may exist a
+ particular file type, length and format on which the hash value is
+ calculated which is fixed and definitive for a particular signature
+ policy.
+
+
+
+
+
+
+
+
+Ross, et al. Experimental [Page 42]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+ The hash value may be obtained by:
+
+ the signer performing his own computation of the hash over the
+ signature policy using his preferred hash algorithm permitted by
+ the signature policy, and the definitive binary encoded form.
+
+ the signer, having verified the source of the policy, may use both
+ the hash algorithm and the hash value included in the computer
+ processable form of the policy (see section 6.1).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ross, et al. Experimental [Page 43]
+
+RFC 3125 Electronic Signature Policies September 2001
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ross, et al. Experimental [Page 44]
+