-- 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-ElectronicPolicies-97Syntax
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:
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.
B.2 Identification of Signature Policy
When data is signed the signer indicates the signature policy
applicable to that electronic signature by including an object
identifier for the signature policy with the signature. The signer
and verifier must apply the rules specified by the identified policy.
In addition to the identifier of the signature policy the signer must
include the hash of the signature policy, so it can be verified that
the policy selected by the signer is the identical to the one being
used the verifier.
A signature policy may be qualified by additional information. This
can includes:
* A URL where a copy of the Signature Policy may be obtained;
* A user notice that should be displayed when the signature is
verified;
If no signature policy is identified then the signature may be
assumed to have been generated/verified without any policy
constraints, and hence may be given no specific legal or contractual
significance through the context of a signature policy.
A "Signature Policy" will be identifiable by an OID (Object
Identifier) and verifiable using a hash of the signature policy.
B.3 General Signature Policy Information
General information should be recorded about the signature policy
along with the definition of the rules which form the signature
policy as described in subsequent subsections. This should include:
* Policy Object Identifier: The "Signature Policy" will be
identifiable by an OID (Object Identifier) whose last component
(i.e., right most) is an integer that is specific to a
particular version issued on the given date.
* Date of issue: When the "Signature Policy" was issued.
* Signature Policy Issuer name: An identifier for the body
responsible for issuing the Signature Policy. This may be used
by the signer or verifying in deciding if a policy is to be
trusted, in which case the signer/verifier must authenticate
the origin of the signature policy as coming from the
identified issuer.
* Signing period: The start time and date, optionally with an end
time and date, for the period over which the signature policy
may be used to generate electronic signatures.
* Field of application: This defines in general terms the general
legal/contract/application contexts in which the signature
policy is to be used and the specific purposes for which the
electronic signature is to be applied.
B.4 Recognized Commitment Types
The signature validation policy may recognize one or more types of
commitment as being supported by electronic signatures produced under
the security policy. If an electronic signature does not contain a
recognized commitment type then the semantics of the electronic
signature is dependent on the data being signed and the context in
which it is being used.
Only recognized commitment types are allowed in an electronic
signature.
The definition of a commitment type includes:
* the object identifier for the commitment;
* the contractual/legal/application context in which the
signature may be used (e.g., submission of messages);
* a description of the support provided within the terms of the
context (e.g., proof that the identified source submitted the
message if the signature is created when message submission is
initiated).
The definition of a commitment type can be registered:
* as part of the validation policy;
* as part of the application/contract/legal environment;
* as part of generic register of definitions.
The legal/contractual context will determine the rules applied to the
signature, as defined by the signature policy and its recognized
commitment types, make it fit for purpose intended.
B.5 Rules for Use of Certification Authorities
The certificate validation process of the verifier, and hence the
certificates that may be used by the signer for a valid electronic
signature, may be constrained by the combination of the trust point
and certificate path constraints in the signature validation policy.
B.5.1 Trust Points
The signature validation policy defines the certification authority
trust points that are to be used for signature verification. Several
trust points may be specified under one signature policy. Specific
trust points may be specified for a particular type of commitment
defined under the signature policy. For a signature to be valid a
certification path must exists between the Certification Authority
that has granted the certificate selected by the signer (i.e., the
used user-certificate) and one of the trust point of the "Signature
Validation Policy".
B.5.2 Certification Path
There may be constraints on the use of certificates issued by one or
more CA(s) in the certificate chain and trust points. The two prime
constraints are certificate policy constraints and naming
constraints:
* Certificate policy constraints limit the certification chain
between the user certificate and the certificate of the trusted
point to a given set of certificate policies, or equivalents
identified through certificate policy mapping.
* The naming constraints limit the forms of names that the CA is
allowed to certify.
Name constraints are particularly important when a "Signature policy"
identifies more than one trust point. In this case, a certificate of
a particular trusted point may only be used to verify signatures from
users with names permitted under the name constraint.
Certificate Authorities may be organized in a tree structure, this
tree structure may represent the trust relationship between various
CA(s) and the users CA. Alternatively, a mesh relationship may exist
where a combination of tree and peer cross-certificates may be used.
The requirement of the certificate path in this document is that it
provides the trust relationship between all the CAs and the signers
user certificate. The starting point from a verification point of
view, is the "trust point". A trust point is usually a CA that
publishes self-certified certificates, is the starting point from
which the verifier verifies the certificate chain. Naming
constraints may apply from the trust point, in which case they apply
throughout the set of certificates that make up the certificate path
down to the signer's user certificate.
Policy constraints can be easier to process but to be effective
require the presence of a certificate policy identifier in the
certificates used in a certification path.
Certificate path processing, thus generally starts with one of the
trust point from the signature policy and ends with the user
certificate. The certificate path processing procedures defined in
RFC2459 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.
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.
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.
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.
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).
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 RFCEditor function is currently provided by the
Internet Society.