As per Relevance of the word electronic, we have this rfc below:
Network Working Group J.
Request for Comments: 3125 Security &
Category: Experimental D.
N.
Security &
September 2001
Electronic Signature
Status of this
This memo defines an Experimental Protocol for the
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
Copyright (C) The Internet Society (2001). All Rights Reserved
This document defines signature policies for electronic signatures.
signature policy is a set of rules for the creation and validation
an electronic signature, under which the validity of signature can
determined. A given legal/contractual context may recognize
particular signature policy as meeting its requirements
A signature policy has a globally unique reference, which is bound
an electronic signature by the signer as part of the
calculation
The signature policy needs to be available in human readable form
that it can be assessed to meet the requirements of the legal
contractual context in which it is being applied
To allow for the automatic processing of an electronic
another part of the signature policy specifies the electronic
for the creation and validation of the electronic signature in
computer processable form. In the current document the format of
signature policy is defined using ASN.1.
The contents of this document is based on the signature
defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C).
Individual copies of this ETSI deliverable can be downloaded
http://www.etsi.org
Ross, et al. Experimental [Page 1]
RFC 3125 Electronic Signature Policies September 2001
Table of
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.
This document is intended to cover signature policies which can
used with electronic signatures for various types of transactions
including business transactions (e.g., purchase requisition
contract, and invoice applications). Electronic signatures can
used for any transaction between an individual and a company,
two companies, between an individual and a governmental body, etc
This document is independent of any environment. It can be
to any environment e.g., smart cards, GSM SIM cards, special
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
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
(TSP)) issues signatures policies that define the technical
procedural requirements for electronic signature creation,
validation/ verification, in order to meet a particular
need
The Signer is the entity that creates the electronic signature.
the signer digitally signs over an signature policy identifier,
represents a commitment on behalf of the signing entity that the
being signed is signed under the rules defined by the
policy
The Verifier is the entity that validates the electronic signature
it may be a single entity or multiple entities. The verifier
validate the electronic signature under the rules defined by
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
signer and a verifier. It acts as verifier when it verifies
electronic signature after it has been previously validated
The Trusted Service Providers (TSPs) are one or more entities
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
requirements for electronic signature creation and validation,
order to meet a particular business need
The following other TSPs are used to support the functions defined
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
CA generates certificates
Repository Authorities publish CRLs issued by CAs, , cross
certificates (i.e., CA certificates) issued by CAs,
policies issued by Signature Policy Issuers and optionally public
certificates (i.e., leaf certificates) issued by CAs
Time-Stamping Authorities attest that some data was formed before
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
key
An Arbitrator is an entity that arbitrates disputes between a
and a verifier
Ross, et al. Experimental [Page 4]
RFC 3125 Electronic Signature Policies September 2001
3. Signature Policy
A signature policy specification includes general information
the policy, the validation policy rules and other signature
information
This document mandates that
* an electronic signature must be processed by the signer
verifier in accordance with the signature policy referenced
the signer
* the signature policy referenced by the signer must
identifiable by an Object Identifier
* there must exist a specification of the signature policy
* for a given signature policy there must be one definitive
of the specification which has a unique binary encoding
* a hash of the definitive specification, using an
algorithm, must be provided by the signer and checked by
verifier
This document defines but does not mandate the form of the
policy specification. The signature policy may be specified either
* in a free form document for human interpretation;
* in a structured form using an agreed syntax and encoding
This document defines an ASN.1 based syntax that may be used
define a structured signature policy. Future versions of
document may include structured a signature policy
using XML
3.1 Overall ASN.1
The overall structure of a signature policy defined using ASN.1
given in this section. Use of this ASN.1 structure is optional
This ASN.1 syntax is encoded using the Distinguished Encoding
(DER).
In this structure the policy information is preceded by an
for the hashing algorithm used to protect the signature policy
followed by the hash value which must be re-calculated and
whenever the signature policy is passed between the issuer
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
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId
dateOfIssue GeneralizedTime
policyIssuerName PolicyIssuerName
fieldOfApplication FieldOfApplication
signatureValidationPolicy SignatureValidationPolicy
signPolExtensions
}
SignPolicyId ::= OBJECT
PolicyIssuerName ::=
FieldOfApplication ::=
The policyIssuerName field identifies the policy issuer in one
more of the general name forms
The fieldofApplication is a description of the expected
of this policy
The signature validation policy rules are fully processable to
the validation of electronic signatures issued under that form
signature policy. They are described in the rest of this section
The signPolExtensions is a generic way to extend the definition
any sub-component of a signature policy
3.2 Signature Validation
The signature validation policy defines for the signer which
elements must be present in the electronic signature he provides
for the verifier which data elements must be present under
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
}
The signingPeriod identifies the date and time before which
signature policy SHOULD NOT be used for creating signatures, and
optional date after which it should not be used for
signatures
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime
notAfter GeneralizedTime OPTIONAL }
3.3 Common
The CommonRules define rules that are common to all commitment types
These rules are defined in terms of trust conditions
certificates, time-stamps and attributes, along with any
on attributes that may be included in the electronic signature
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0]
OPTIONAL
signingCertTrustCondition [1]
OPTIONAL
timeStampTrustCondition [2]
OPTIONAL
attributeTrustCondition [3]
OPTIONAL
algorithmConstraintSet [4]
OPTIONAL
signPolExtensions [5]
}
If a field is present in CommonRules then the equivalent field
not be present in any of the CommitmentRules (see below). If any
the following fields are not present in CommonRules then it must
present in each CommitmentRule
* signerAndVeriferRules
* signingCertTrustCondition
* timeStampTrustCondition
Ross, et al. Experimental [Page 7]
RFC 3125 Electronic Signature Policies September 2001
3.4 Commitment
The CommitmentRules consists of the validation rules which apply
given commitment types
CommitmentRules ::= SEQUENCE OF
The CommitmentRule for given commitment types are defined in terms
trust conditions for certificates, time-stamps and attributes,
with any constraints on attributes that may be included in
electronic signature
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes
signerAndVeriferRules [0]
OPTIONAL
signingCertTrustCondition [1]
OPTIONAL
timeStampTrustCondition [2]
OPTIONAL
attributeTrustCondition [3]
OPTIONAL
algorithmConstraintSet [4]
OPTIONAL
signPolExtensions [5]
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL
recognizedCommitmentType CommitmentType }
If the SelectedCommitmentTypes indicates "empty" then this
applied when a commitment type is not present (i.e., the type
commitment is indicated in the semantics of the message). Otherwise
the electronic signature must contain a commitment type
that must fit one of the commitments types that are mentioned
CommitmentType
A specific commitment type identifier must not appear in more
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
and meaning of the commitment within the overall field of
defined for the policy
3.5 Signer and Verifier
The following rules apply to the format of electronic
defined using [ES-FORMATS].
The SignerAndVerifierRules consists of signer rule and
rules as defined below
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules
verifierRules VerifierRules }
3.5.1 Signer
The signer rules identify
* if the eContent is empty and the signature is calculated
a hash of signed data external to CMS structure
* the CMS signed attributes that must be provided by the
under this policy
* the CMS unsigned attribute that must be provided by the
under this policy
* whether the certificate identifiers from the full
path up to the trust point must be provided by the signer
the SigningCertificate attribute
* whether a signer's certificate, or all certificates in
certification path to the trust point must be by the signer
the * certificates field of SignedData
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL
-- True if signed data is external to CMS
-- False if signed data part of CMS
-- Not present if either
mandatedSignedAttr CMSAttrs
-- Mandated CMS signed
mandatedUnsignedAttr CMSAttrs
-- Mandated CMS unsigned
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly
-- Mandated Certificate
Ross, et al. Experimental [Page 9]
RFC 3125 Electronic Signature Policies September 2001
mandatedCertificateInfo [1] CertInfoReq DEFAULT none
-- Mandated Certificate
signPolExtensions [2] SignPolExtensions
}
CMSattrs ::= SEQUENCE OF OBJECT
The mandated SignedAttr field must include the object identifier
all those signed attributes required by this document as well
additional attributes required by this policy
The mandatedUnsignedAttr field must include the object identifier
all those unsigned attributes required by this document as well
additional attributes required by this policy. For example, if
signature time-stamp required by the signer
object identifier for this attribute must be included
The mandatedCertificateRef identifies whether just the signer'
certificate, or all the full certificate path must be provided by
signer
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert
fullpath (2)
-- References for full cert path up to a trust point
}
The mandatedCertificateInfo field identifies whether a signer'
certificate, or all certificates in the certification path to
trust point must be provided by the signer in the certificates
of SignedData
CertInfoReq ::= ENUMERATED {
none (0) ,
-- No mandatory
signerOnly (1) ,
-- Only reference to signer cert
fullpath (2)
-- References for full cert path up to
-- trust point
}
Ross, et al. Experimental [Page 10]
RFC 3125 Electronic Signature Policies September 2001
3.5.2 Verifier
The verifier rules identify
* The CMS unsigned attributes that must be present under
policy and must be added by the verifier if not added by
signer
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr
signPolExtensions SignPolExtensions
}
MandatedUnsignedAttr ::=
-- Mandated CMS unsigned
3.6 Certificate and Revocation
The SigningCertTrustCondition, TimestampTrustCondition
AttributeTrustCondition (defined in subsequent sub-sections) make
of two ASN1 structures which are defined below:
and CertRevReq
3.6.1 Certificate
The certificateTrustTrees identifies a set of self
certificates for the trust points used to start (or end)
path processing and the initial conditions for certificate
validation as defined RFC 2459 [7] section 4. This ASN1 structure
used to define policy for validating the signing certificate,
TSA's certificate and attribute certificates
CertificateTrustTrees ::= SEQUENCE OF
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate
-- self-signed
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
that is used as the trust point for the start of certificate
processing
Ross, et al. Experimental [Page 11]
RFC 3125 Electronic Signature Policies September 2001
The pathLenConstraint field gives the maximum number of
certificates that may be in a certification path following
trustpoint. A value of zero indicates that only the given
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
allowed length of the certification path
PathLenConstraint ::= INTEGER (0..MAX
The acceptablePolicySet field identifies the initial set
certificate policies, any of which are acceptable under the
policy. AcceptablePolicySet ::= SEQUENCE OF
CertPolicyId ::= OBJECT
The nameConstraints field indicates a name space within which
subject names in subsequent certificates in a certification path
be located. Restrictions may apply to the subject distinguished
or subject alternative names. Restrictions apply only when
specified name form is present. If no name of the type is in
certificate, the certificate is acceptable
Restrictions are defined in terms of permitted or excluded
subtrees. Any name matching a restriction in the
field is invalid regardless of information appearing in
permittedSubtrees
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF
GeneralSubtree ::= SEQUENCE {
base GeneralName
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX
The policyConstraints extension constrains path processing in
ways. It can be used to prohibit policy mapping or require that
certificate in a path contain an acceptable policy identifier
The policyConstraints field, if present specifies requirement
explicit indication of the certificate policy and/or the
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
number of additional certificates that may appear in the
(including the trustpoint's self certificate) before policy
is no longer permitted. For example, a value of one indicates
policy mapping may be processed in certificates issued by the
of this certificate, but not in additional certificates in the path
If the requireExplicitPolicy field is present,
certificates must include an acceptable policy identifier. The
of requireExplicitPolicy indicates the number of
certificates that may appear in the path (including the trustpoint'
self certificate) before an explicit policy is required.
acceptable policy identifier is the identifier of a policy
by the user of the certification path or the identifier of a
which has been declared equivalent through policy mapping
3.6.2 Revocation
The RevocRequirements field specifies minimum requirements
revocation information, obtained through CRLs and/or OCSP responses
to be used in checking the revocation status of certificates.
ASN1 structure is used to define policy for validating the
certificate, the TSA's certificate and attribute certificates
CertRevReq ::= SEQUENCE {
endCertRevReq RevReq
caCerts [0]
}
Certificate revocation requirements are specified in terms of
required on
* endCertRevReq: end certificates (i.e., the signers certificate
the attribute certificate or the time-stamping
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
(AA)).
A Time-Stamping Authority (TSA) is a trusted third party that
time-stamp tokens in order to indicate that a datum existed at
particular point in time. See [TSP].
EnuRevReq ::= ENUMERATED {
clrCheck (0),
--Checks must be made against current
-- (or authority revocation lists (ARL))
ocspCheck (1), -- The revocation status must be
-- using the Online Certificate Status
-- (OCSP),RFC 2450.
bothCheck (2),
-- Both CRL and OCSP checks must be carried
eitherCheck (3),
-- At least one of CRL or OCSP checks must
-- carried
noCheck (4),
-- no check is
other (5)
-- Other mechanism as defined by signature
--
}
Revocation requirements are specified in terms of
* clrCheck: Checks must be made against current CRLs (
authority revocation lists);
* ocspCheck: The revocation status must be checked using
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
The SigningCertTrustCondition field identifies trust conditions
certificate path processing used to validate the signing certificate
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees
signerRevReq
}
Ross, et al. Experimental [Page 14]
RFC 3125 Electronic Signature Policies September 2001
3.8 Time-Stamp Trust
The TimeStampTrustCondition field identifies trust conditions
certificate path processing used to authenticate the
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]
OPTIONAL
ttsRevReq [1]
OPTIONAL
ttsNameConstraints [2]
OPTIONAL
cautionPeriod [3]
OPTIONAL
signatureTimestampDelay [4]
OPTIONAL }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER
deltaMinutes INTEGER
deltaHours INTEGER
deltaDays INTEGER }
If ttsCertificateTrustTrees is not present then the same rule
defined in certificateTrustCondition applies to certification of
time-stamping authorities public key
The tstrRevReq specifies minimum requirements for
information, obtained through CRLs and/or OCSP responses, to be
in checking the revocation status of the time-stamp that must
present in the ES-T
If ttsNameConstraints is not present then there are no
naming constraints on the trusted time-stamping authority other
those implied by the ttsCertificateTrustTrees
The cautionPeriod field specifies a caution period after the
time that it is mandated the verifier must wait to get high
of the validity of the signer's key and that any relevant
has been notified. The revocation status information forming the
with Complete validation data must not be collected and used
validate the electronic signature until after this caution period
The signatureTimestampDelay field specifies a maximum acceptable
between the signing time and the time at which the signature time
stamp, as used to form the ES Time-Stamped, is created for
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
signing-time attribute by more than the value given
signatureTimestampDelay, the signature must be considered invalid
3.9 Attribute Trust
If the attributeTrustCondition field is not present then
certified attributes may not considered to be valid under
validation policy. The AttributeTrustCondition field is defined
follows
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN
-- Attribute must be
howCertAttribute HowCertAttribute
attrCertificateTrustTrees [0] CertificateTrustTrees OPTIONAL
attrRevReq [1] CertRevReq OPTIONAL
attributeConstraints [2] AttributeConstraints OPTIONAL }
If attributeMandated is true then an attribute, certified within
following constraints, must be present. If false, then the
is still valid if no attribute is specified
The howCertAttribute field specifies whether attributes
attributes "claimed" by the signer, or certified attributes (i.e.,
Attribute Certificates) or either using the signer
attribute defined in [ES-FORMATS] section 3.12.3.
HowCertAttribute ::= ENUMERATED {
claimedAttribute (0),
certifiedAttribtes (1),
either (2) }
The attrCertificateTrustTrees specifies certificate path
for any attribute certificate. If not present the same rules
as in certificateTrustCondition
The attrRevReq specifies minimum requirements for
information, obtained through CRLs and/or OCSP responses, to be
in checking the revocation status of Attribute Certificates, if
are present
If the attributeConstraints field is not present then there are
constraints on the attributes that may be validated under
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]
OPTIONAL
attributeValueConstarints [1]
OPTIONAL }
If present, the attributeTypeConstarints field specifies
attribute types which are considered valid under the
policy. Any value for that attribute is considered valid
AttributeTypeConstraints ::= SEQUENCE OF
If present, the attributeTypeConstraints field specifies the
attribute values which are considered valid under the
policy
AttributeValueConstraints ::= SEQUENCE OF
3.10 Algorithm
The algorithmConstrains fields, if present, identifies the
algorithms (hash, public key cryptography, combined hash and
key cryptography) that may be used for specific purposes and
minimum length. If this field is not present then the policy
no constraints
AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL
--
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL
-- issuer of end entity certs
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL
-- issuer of CA
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL
-- Attribute
tsaCertAlgorithmConstraints [4] AlgorithmConstraints
-- Time-Stamping
}
AlgorithmConstraints ::= SEQUENCE OF
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER
minKeyLength INTEGER OPTIONAL
-- Minimum key length in
other SignPolExtensions
}
Ross, et al. Experimental [Page 17]
RFC 3125 Electronic Signature Policies September 2001
An Attribute Authority (AA)is authority which assigns privileges
issuing attribute
3.11 Signature Policy
Additional signature policy rules may be added to
* the overall signature policy structure, as defined in
3.1;
* the signature validation policy structure, as defined
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
an ASN.1 syntax with an associated object identifier carried in
SignPolExtn as defined below
SignPolExtensions ::= SEQUENCE OF
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER
extnValue OCTET STRING }
The extnID field must contain the object identifier for
extension. The extnValue field must contain the DER (see ITU-
Recommendation X.690 [4]) encoded value of the extension.
definition of an extension, as identified by extnID must include
definition of the syntax and semantics of the extension
4. Security
4.1 Protection of Private
The security of the electronic signature mechanism defined in
document depends on the privacy of the signer's private key
Implementations must take steps to ensure that private keys cannot
compromised
4.2 Choice of
Implementers should be aware that cryptographic algorithms
weaker with time. As new cryptoanalysis techniques are developed
computing performance improves, the work factor to break a
Ross, et al. Experimental [Page 18]
RFC 3125 Electronic Signature Policies September 2001
cryptographic algorithm will reduce. Therefore,
algorithm implementations should be modular allowing new
to be readily inserted. That is, implementers should be prepared
the set of mandatory to implement algorithms to change over time
5. Conformance
Signer and verifier systems shall be able to process an
signature in accordance with the specification of the
policy signature policy referenced identifiable by an
Identifier, see section 3.
6.
[TS101733] ETSI Standard TS 101 733 V.1.2.2 (2000-12)
Signature Formats. Note: copies of ETSI TS 101 733
be freely download from the ETSI web site www.etsi.org
[ES-FORMATS] Pinkas, D., Ross, J. and N. Pope, "Electronic
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-
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
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, "
X.509 Public Key Infrastructure, Certificate and
Profile," RFC 2459, January 1999.
[PKCS9] RSA Laboratories, "The Public-Key Cryptography
(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'
This Experimental RFC has been produced in ETSI TC-SEC
F-06921 Sophia Antipolis, Cedex -
650 Route des Lucioles - Sophia
Valbonne - FranceTel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
secretariat@etsi.
http://www.etsi.
Contact
Harri
650 Route des
F-06921 Sophia Antipolis
EMail: harri.rasilainen@etsi.
John
Security &
192 Moulsham
Chelmsford,
CM2 0
United
EMail: ross@secstan.
Denis
Integris, Bull
68, Route de
78434 Louveciennes
EMail: Denis.Pinkas@bull.
Nick
Security &
192 Moulsham
Chelmsford,
CM2 0
United
EMail: pope@secstan.
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
ASN.1 syntax signature policies definitions for new syntax defined
this document
A.1 Definitions Using X.208 (1988) ASN.1
NOTE: The ASN.1 Module defined in section A.1 has precedence
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 ::=
-- EXPORTS
-- Internet X.509 Public Key
- Certificate and CRL Profile: RFC 2560
Certificate, AlgorithmIdentifier, CertificateList, Name
GeneralNames, GeneralName, DirectoryString,Attribute
AttributeTypeAndValue, AttributeType, AttributeValue
PolicyInformation, BMPString, UTF8
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
-- ==============================
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier
signPolicyInfo SignPolicyInfo
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET
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
}
PolicyIssuerName ::=
FieldOfApplication ::=
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod
commonRules CommonRules
commitmentRules CommitmentRules
signPolExtensions
}
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime
notAfter GeneralizedTime OPTIONAL }
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0]
OPTIONAL
signingCertTrustCondition [1]
OPTIONAL
timeStampTrustCondition [2]
OPTIONAL
attributeTrustCondition [3]
OPTIONAL
algorithmConstraintSet [4]
OPTIONAL
signPolExtensions [5]
}
CommitmentRules ::= SEQUENCE OF
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes
signerAndVeriferRules [0]
OPTIONAL
signingCertTrustCondition [1]
OPTIONAL
timeStampTrustCondition [2]
OPTIONAL
Ross, et al. Experimental [Page 22]
RFC 3125 Electronic Signature Policies September 2001
attributeTrustCondition [3]
OPTIONAL
algorithmConstraintSet [4]
OPTIONAL
signPolExtensions [5]
}
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
-- False if signed data part of CMS
-- not present if either
mandatedSignedAttr CMSAttrs
-- Mandated CMS signed
mandatedUnsignedAttr CMSAttrs
-- Mandated CMS unsigned
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly
-- Mandated Certificate
mandatedCertificateInfo [1] CertInfoReq DEFAULT none
-- Mandated Certificate
signPolExtensions [2]
OPTIONAL
CMSAttrs ::= SEQUENCE OF OBJECT
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert
fullPath (2)
-- References for full cert path up to a trust point
}
CertInfoReq ::= ENUMERATED {
Ross, et al. Experimental [Page 23]
RFC 3125 Electronic Signature Policies September 2001
none (0),
-- No mandatory
signerOnly (1),
-- Only reference to signer cert
fullPath (2)
-- References for full cert path up to a trust point
}
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr
signPolExtensions SignPolExtensions
}
MandatedUnsignedAttr ::=
-- Mandated CMS unsigned
CertificateTrustTrees ::= SEQUENCE OF
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate
-- self-signed
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 ::= OBJECT
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF
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 ::= SEQUENCE {
enuRevReq EnuRevReq
exRevReq SignPolExtensions OPTIONAL
EnuRevReq ::= ENUMERATED {
clrCheck (0), --Checks must be made against current
-- (or authority revocation lists
ocspCheck (1), -- The revocation status must be
-- using the Online Certificate Status Protocol (RFC 2450)
bothCheck (2),
-- Both CRL and OCSP checks must be carried
eitherCheck (3),
-- At least one of CRL or OCSP checks must be carried
noCheck (4),
-- no check is
other (5)
-- Other mechanism as defined by signature policy
}
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees
signerRevReq
}
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0]
OPTIONAL
ttsRevReq [1]
OPTIONAL
ttsNameConstraints [2]
OPTIONAL
cautionPeriod [3]
OPTIONAL
signatureTimestampDelay [4]
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
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]
OPTIONAL
attributeValueConstarints [1]
OPTIONAL }
AttributeTypeConstraints ::= SEQUENCE OF
AttributeValueConstraints ::= SEQUENCE OF
AlgorithmConstraintSet ::= SEQUENCE { -- Algorithm constrains on
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL
--
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL
-- issuer of end entity certs
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL
-- issuer of CA
aaCertAlgorithmConstraints [3] AlgorithmConstraints OPTIONAL
-- Attribute
tsaCertAlgorithmConstraints [4] AlgorithmConstraints
-- Time-Stamping
}
AlgorithmConstraints ::= SEQUENCE OF
AlgAndLength ::= SEQUENCE {
algID OBJECT IDENTIFIER
minKeyLength INTEGER OPTIONAL
-- Minimum key length in bits
SignPolExtensions
Ross, et al. Experimental [Page 26]
RFC 3125 Electronic Signature Policies September 2001
}
SignPolExtensions ::= SEQUENCE OF
SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER
extnValue OCTET STRING }
END -- ETS-ElectronicSignaturePolicies-88syntax --
A.2 Definitions Using X.680 1997 ASN.1
NOTE: The ASN.1 module defined in section A.1 has precedence
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 ::=
-- EXPORTS All -
-- Internet X.509 Public Key
-- Certificate and CRL Profile: RFC 2560
Certificate, AlgorithmIdentifier, CertificateList, Name
GeneralNames, GeneralName, DirectoryString, Attribute
AttributeTypeAndValue, AttributeType, AttributeValue
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
-- ==================================================================
-- S/MIME OID arc used in the present
-- id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
-- S/MIME
-- id-mod OBJECT IDENTIFIER ::= { id-smime 0 }
--
Ross, et al. Experimental [Page 27]
RFC 3125 Electronic Signature Policies September 2001
-- id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
-- content
-- id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
--
-- id-spq OBJECT IDENTIFIER ::= { id-smime 5 }
-- signature policy
-- id-cti OBJECT IDENTIFIER ::= { id-smime 6 }
-- commitment type
-- Signature Policy
-- ==============================
SignaturePolicy ::= SEQUENCE {
signPolicyHashAlg AlgorithmIdentifier
signPolicyInfo SignPolicyInfo
signPolicyHash SignPolicyHash OPTIONAL }
SignPolicyHash ::= OCTET
SignPolicyInfo ::= SEQUENCE {
signPolicyIdentifier SignPolicyId
dateOfIssue GeneralizedTime
policyIssuerName PolicyIssuerName
fieldOfApplication FieldOfApplication
signatureValidationPolicy SignatureValidationPolicy
signPolExtensions
}
SignPolicyId ::= OBJECT
PolicyIssuerName ::=
FieldOfApplication ::=
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod
commonRules CommonRules
commitmentRules CommitmentRules
signPolExtensions SignPolExtensions
}
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime
notAfter GeneralizedTime OPTIONAL }
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0]
OPTIONAL
Ross, et al. Experimental [Page 28]
RFC 3125 Electronic Signature Policies September 2001
signingCertTrustCondition [1]
OPTIONAL
timeStampTrustCondition [2]
OPTIONAL
attributeTrustCondition [3]
OPTIONAL
algorithmConstraintSet [4]
OPTIONAL
signPolExtensions [5]
}
CommitmentRules ::= SEQUENCE OF
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes
signerAndVeriferRules [0]
OPTIONAL
signingCertTrustCondition [1]
OPTIONAL
timeStampTrustCondition [2]
OPTIONAL
attributeTrustCondition [3]
OPTIONAL
algorithmConstraintSet [4]
OPTIONAL
signPolExtensions [5]
}
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
-- False if signed data part of CMS
-- not present if either
Ross, et al. Experimental [Page 29]
RFC 3125 Electronic Signature Policies September 2001
mandatedSignedAttr CMSAttrs
-- Mandated CMS signed
mandatedUnsignedAttr CMSAttrs
-- Mandated CMS unsigned
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly
-- Mandated Certificate
mandatedCertificateInfo [1] CertInfoReq DEFAULT none
-- Mandated Certificate
signPolExtensions [2] SignPolExtensions
}
CMSAttrs ::= SEQUENCE OF OBJECT
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert
fullPath (2)
-- References for full cert path up to a
-- point
}
CertInfoReq ::= ENUMERATED {
none (0) ,
-- No mandatory
signerOnly (1) ,
-- Only reference to signer cert
fullPath (2)
-- References for full cert path up to
-- trust point
}
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr
signPolExtensions SignPolExtensions
}
MandatedUnsignedAttr ::=
-- Mandated CMS unsigned
CertificateTrustTrees ::= SEQUENCE OF
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate
-- self-signed
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 ::= OBJECT
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF
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 ::= SEQUENCE {
enuRevReq EnuRevReq
exRevReq SignPolExtensions OPTIONAL
EnuRevReq ::= ENUMERATED {
clrCheck (0),
-- Checks must be made against current
-- (or authority revocation lists
ocspCheck (1),
-- The revocation status must be checked
-- the Online Certificate Status Protocol (RFC 2450)
bothCheck (2),
-- Both CRL and OCSP checks must be carried
eitherCheck (3),
-- At least one of CRL or OCSP checks must
-- carried
noCheck (4),
-- no check is
Ross, et al. Experimental [Page 31]
RFC 3125 Electronic Signature Policies September 2001
other (5)
-- Other mechanism as defined by signature
--
}
SigningCertTrustCondition ::= SEQUENCE {
signerTrustTrees CertificateTrustTrees
signerRevReq
}
TimestampTrustCondition ::= SEQUENCE {
ttsCertificateTrustTrees [0]
OPTIONAL
ttsRevReq [1]
OPTIONAL
ttsNameConstraints [2]
OPTIONAL
cautionPeriod [3]
OPTIONAL
signatureTimestampDelay [4]
OPTIONAL }
DeltaTime ::= SEQUENCE {
deltaSeconds INTEGER
deltaMinutes INTEGER
deltaHours INTEGER
deltaDays INTEGER }
AttributeTrustCondition ::= SEQUENCE {
attributeMandated BOOLEAN
-- Attribute must be
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]
OPTIONAL
attributeValueConstarints [1]
OPTIONAL }
Ross, et al. Experimental [Page 32]
RFC 3125 Electronic Signature Policies September 2001
AttributeTypeConstraints ::= SEQUENCE OF
AttributeValueConstraints ::= SEQUENCE OF
AlgorithmConstraintSet ::= SEQUENCE {
-- Algorithm constrains on
signerAlgorithmConstraints [0] AlgorithmConstraints OPTIONAL
--
eeCertAlgorithmConstraints [1] AlgorithmConstraints OPTIONAL
-- issuer of end entity certs
caCertAlgorithmConstraints [2] AlgorithmConstraints OPTIONAL
-- issuer of CA
aaCertAlgorithmConstraints [3] AlgorithmConstraints 