Home   A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Y   Z  

Electronic Signature Policies :: RFC3125








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 


 

RFC, FYI, BCP