< draft-ietf-smime-espolicies-00.txt   draft-ietf-smime-espolicies-01.txt >
Internet Draft ETSI TC-SEC (ETSI) Internet Draft ETSI TC-SEC (ETSI)
S/MIME Working Group J Ross (Security & Standards) S/MIME Working Group J Ross (Security & Standards)
expires in six months D Pinkas (Bull) expires in six months D Pinkas (Bull)
Target Category: Experimental N Pope (Security & Standards) Target Category: Experimental N Pope (Security & Standards)
July 2000 March 2001
Electronic Signature Policies Electronic Signature Policies
<draft-ietf-smime-espolicies-00.txt> <draft-ietf-smime-espolicies-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of section 10 of RFC2026. Internet-Drafts are working provisions of section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 53 skipping to change at page 1, line 53
that it can be assessed to meet the requirements of the legal and that it can be assessed to meet the requirements of the legal and
contractual context in which it is being applied. contractual context in which it is being applied.
To allow for the automatic processing of an electronic signature To allow for the automatic processing of an electronic signature
another part of the signature policy specifies the electronic another part of the signature policy specifies the electronic
rules for the creation and validation of the electronic signature in rules for the creation and validation of the electronic signature in
a computer processable form. In the current document the format of the a computer processable form. In the current document the format of the
signature policy is defined using ASN.1. signature policy is defined using ASN.1.
The contents of this RFC is based on the signature policy defined in The contents of this RFC is based on the signature policy defined in
ETSI ES 201 733 V.1.1.3(2000-05) Copyright (C). ETSI TS 101 733 V1.2.2 The ETSI TS is under the ETSI Copyright (C).
Individual copies of this ETSI deliverable can be downloaded from
http://www.etsi.org.
Internet Draft Electronic Signature Policies Internet Draft Electronic Signature Policies
TABLE OF CONTENTS TABLE OF CONTENTS
Abstract 1 Abstract 1
Table of contents 2 Table of contents 2
1. Introduction 3 1. Introduction 3
2. Major Parties 3 2. Major Parties 3
3. Signature Policy Specification 5 3. Signature Policy Specification 5
skipping to change at page 5, line 39 skipping to change at page 5, line 39
* in a free form document for human interpretation; or * in a free form document for human interpretation; or
* in a structured form using an agreed syntax and encoding. * in a structured form using an agreed syntax and encoding.
This document defines an ASN.1 based syntax that may be used to define This document defines an ASN.1 based syntax that may be used to define
a structured signature policy. Future versions of this document may a structured signature policy. Future versions of this document may
include structured a signature policy specification using XML. include structured a signature policy specification using XML.
3.1 Overall ASN.1 Structure 3.1 Overall ASN.1 Structure
The overall structure of a signature policy defined using ASN.1 is The overall structure of a signature policy defined using ASN.1 is
given in this clause. Use of this ASN.1 structure is optional. given in this section. Use of this ASN.1 structure is optional.
This ASN.1 syntax is encoded using the Distinguished Encoding Rules This ASN.1 syntax is encoded using the Distinguished Encoding Rules
(DER). (DER).
Internet Draft Electronic Signature Policies Internet Draft Electronic Signature Policies
In this structure the policy information is preceded by an identifier In this structure the policy information is preceded by an identifier
for the hashing algorithm used to protect the signature policy and for the hashing algorithm used to protect the signature policy and
followed by the hash value which must be re-calculated and checked followed by the hash value which must be re-calculated and checked
whenever the signature policy is passed between the issuer and whenever the signature policy is passed between the issuer and
skipping to change at page 6, line 45 skipping to change at page 6, line 45
FieldOfApplication ::= DirectoryString FieldOfApplication ::= DirectoryString
The policyIssuerName field identifies the policy issuer in one or more The policyIssuerName field identifies the policy issuer in one or more
of the general name forms. of the general name forms.
The fieldofApplication is a description of the expected application of The fieldofApplication is a description of the expected application of
this policy. this policy.
The signature validation policy rules are fully processable to allow The signature validation policy rules are fully processable to allow
the validation of electronic signatures issued under that form of the validation of electronic signatures issued under that form of
signature policy. They are described in the rest of this clause. signature policy. They are described in the rest of this section.
The signPolExtensions is a generic way to extend the definition of any The signPolExtensions is a generic way to extend the definition of any
sub-component of a signature policy. sub-component of a signature policy.
3.2 Signature Validation Policy 3.2 Signature Validation Policy
The signature validation policy defines for the signer which data The signature validation policy defines for the signer which data
elements must be present in the electronic signature he provides and elements must be present in the electronic signature he provides and
for the verifier which data elements must be present under that for the verifier which data elements must be present under that
signature policy for an electronic signature to be potentially valid. signature policy for an electronic signature to be potentially valid.
skipping to change at page 10, line 10 skipping to change at page 10, line 10
The mandatedSignedAttr field must include the object identifier for The mandatedSignedAttr field must include the object identifier for
all those signed attributes required by this document as well as all those signed attributes required by this document as well as
additional attributes required by this policy. additional attributes required by this policy.
Internet Draft Electronic Signature Policies Internet Draft Electronic Signature Policies
The mandatedUnsignedAttr field must include the object identifier for The mandatedUnsignedAttr field must include the object identifier for
all those unsigned attributes required by this document as well as all those unsigned attributes required by this document as well as
additional attributes required this policy. For example, if a signature additional attributes required this policy. For example, if a signature
timestamp (see clause 1.1) is required by the signer the object timestamp is required by the signer the object identifier for this
identifier for this attribute must be included. attribute must be included.
The mandatedCertificateRef identifies whether just the signer's The mandatedCertificateRef identifies whether just the signer's
certificate, or all the full certificate path must be provided by the certificate, or all the full certificate path must be provided by the
signer. signer.
CertRefReq ::= ENUMERATED { CertRefReq ::= ENUMERATED {
signerOnly (1), signerOnly (1),
-- Only reference to signer cert mandated -- Only reference to signer cert mandated
fullPath (2) fullPath (2)
skipping to change at page 11, line 10 skipping to change at page 11, line 10
} }
MandatedUnsignedAttr ::= CMSAttrs MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed -- Mandated CMS unsigned attributed
Internet Draft Electronic Signature Policies Internet Draft Electronic Signature Policies
3.6 Certificate and Revocation Requirement 3.6 Certificate and Revocation Requirement
The SigningCertTrustCondition, TimestampTrustCondition and The SigningCertTrustCondition, TimestampTrustCondition and
AttributeTrustCondition (defined in subsequent sub-clauses) make use of AttributeTrustCondition (defined in subsequent sub-sections) make use of
two ASN1 structures which are defined below: CertificateTrustTrees and two ASN1 structures which are defined below: CertificateTrustTrees and
CertRevReq. CertRevReq.
3.6.1 Certificate Requirements 3.6.1 Certificate Requirements
The certificateTrustTrees identifies a set of self signed certificates The certificateTrustTrees identifies a set of self signed certificates
for the trust points used to start (or end) certificate path processing for the trust points used to start (or end) certificate path processing
and the initial conditions for certificate path validation as defined and the initial conditions for certificate path validation as defined
RFC 2459 [7] section 4. This ASN1 structure is used to define policy RFC 2459 [7] section 4. This ASN1 structure is used to define policy
for validating the signing certificate, the TSA's certificate and for validating the signing certificate, the TSA's certificate and
skipping to change at page 17, line 24 skipping to change at page 17, line 24
} }
An Attribute Authority (AA)is authority which assigns privileges by An Attribute Authority (AA)is authority which assigns privileges by
issuing attribute certificates issuing attribute certificates
3.11 Signature Policy Extensions 3.11 Signature Policy Extensions
Additional signature policy rules may be added to: Additional signature policy rules may be added to:
* the overall signature policy structure, as defined in * the overall signature policy structure, as defined in
clause 3.1; section 3.1;
* the signature validation policy structure, as defined in * the signature validation policy structure, as defined in
clause 3.2; section 3.2;
* the common rules, as defined in clause 3.3; * the common rules, as defined in section 3.3;
* the commitment rules, as defined in clause 3.4; * the commitment rules, as defined in section 3.4;
* the signer rules, as defined in clause 3.5.1; * the signer rules, as defined in section 3.5.1;
* the verifier rules, as defined in clause 3.5.2; * the verifier rules, as defined in section 3.5.2;
* the revocation requirements in clause 3.6.2; * the revocation requirements in section 3.6.2;
* the algorithm constraints in clause 3.10. * the algorithm constraints in section 3.10.
These extensions to the signature policy rules must be defined using These extensions to the signature policy rules must be defined using
an ASN.1 syntax with an associated object identifier carried in the an ASN.1 syntax with an associated object identifier carried in the
SignPolExtn as defined below: SignPolExtn as defined below:
SignPolExtensions ::= SEQUENCE OF SignPolExtn SignPolExtensions ::= SEQUENCE OF SignPolExtn
SignPolExtn ::= SEQUENCE { SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER, extnID OBJECT IDENTIFIER,
extnValue OCTET STRING } extnValue OCTET STRING }
skipping to change at page 21, line 13 skipping to change at page 21, line 13
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
Internet Draft Electronic Signature Policies Internet Draft Electronic Signature Policies
Annex A (normative): Annex A (normative):
ASN.1 Definitions ASN.1 Definitions
This annex provides the reference definition of the ASN.1 syntax This annex provides the reference definition of the ASN.1 syntax
signature policies definitions for new syntax defined in this document. signature policies definitions for new syntax defined in this document.
A.1 Definitions Using X.208 (1988) ASN.1 Syntax A.1 Definitions Using X.208 (1988) ASN.1 Syntax
NOTE: The ASN.1 Module defined in clause A.1 has precedence over that defined in NOTE: The ASN.1 Module defined in section A.1 has precedence over that defined
in
Annex A-2 in the case of any conflict. Annex A-2 in the case of any conflict.
ETS-ElectronicSignaturePolicies-88syntax { iso(1) member-body(2) ETS-ElectronicSignaturePolicies-88syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 7} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 7}
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
IMPORTS IMPORTS
skipping to change at page 27, line 9 skipping to change at page 27, line 9
SignPolExtn ::= SEQUENCE { SignPolExtn ::= SEQUENCE {
extnID OBJECT IDENTIFIER, extnID OBJECT IDENTIFIER,
extnValue OCTET STRING } extnValue OCTET STRING }
END -- ETS-ElectronicSignaturePolicies-88syntax -- END -- ETS-ElectronicSignaturePolicies-88syntax --
Internet Draft Electronic Signature Policies Internet Draft Electronic Signature Policies
A.2 Definitions Using X.680 1997 ASN.1 Syntax A.2 Definitions Using X.680 1997 ASN.1 Syntax
NOTE: The ASN.1 module defined in clause A.1 has precedence over that NOTE: The ASN.1 module defined in section A.1 has precedence over that
defined in clause A.2 in the case of any conflict. defined in section A.2 in the case of any conflict.
ETS-ElectronicSignaturePolicies-97Syntax { iso(1) member-body(2) ETS-ElectronicSignaturePolicies-97Syntax { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 8} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-mod(0) 8}
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All - -- EXPORTS All -
IMPORTS IMPORTS
skipping to change at page 34, line 54 skipping to change at page 34, line 54
This document includes, as an option, a formal structure for signature This document includes, as an option, a formal structure for signature
validation policy based on the use of Abstract Syntax Notation 1 validation policy based on the use of Abstract Syntax Notation 1
(ASN.1). (ASN.1).
Given the specification of the signature policy and its hash value an Given the specification of the signature policy and its hash value an
implementation of a verification process must obey the rules defined implementation of a verification process must obey the rules defined
in the specification. in the specification.
This document places no restriction on how it should be implemented. This document places no restriction on how it should be implemented.
Provide the implementation conforms to the conformance requirements as Provide the implementation conforms to the conformance requirements as
define in clause 5 implementation options include: define in section 5 implementation options include:
Internet Draft Electronic Signature Policies Internet Draft Electronic Signature Policies
A validation process that supports a specific signature policy as A validation process that supports a specific signature policy as
identified by the signature policy OID. Such an implementation should identified by the signature policy OID. Such an implementation should
conform to a human readable description provided all the processing conform to a human readable description provided all the processing
rules of the signature policy are clearly defined. However, if rules of the signature policy are clearly defined. However, if
additional policies need to be supported, then such an implementation additional policies need to be supported, then such an implementation
would need to be customized for each additional policy. This type of would need to be customized for each additional policy. This type of
implementation may be simpler to implement initially, but can be implementation may be simpler to implement initially, but can be
skipping to change at page 36, line 37 skipping to change at page 36, line 37
hence may be given no specific legal or contractual significance hence may be given no specific legal or contractual significance
through the context of a signature policy. through the context of a signature policy.
A "Signature Policy" will be identifiable by an OID (Object Identifier) A "Signature Policy" will be identifiable by an OID (Object Identifier)
and verifiable using a hash of the signature policy. and verifiable using a hash of the signature policy.
B.3 General Signature Policy Information B.3 General Signature Policy Information
General information should be recorded about the signature policy along General information should be recorded about the signature policy along
with the definition of the rules which form the signature policy as with the definition of the rules which form the signature policy as
described in subsequent subclauses. This should include: described in subsequent subsections. This should include:
* Policy Object Identifier: The "Signature Policy" will be * Policy Object Identifier: The "Signature Policy" will be
identifiable by an OID (Object Identifier) whose last component identifiable by an OID (Object Identifier) whose last component
(i.e. right most) is an integer that is specific to a particular (i.e. right most) is an integer that is specific to a particular
version issued on the given date. version issued on the given date.
* Date of issue: When the "Signature Policy" was issued. * Date of issue: When the "Signature Policy" was issued.
* Signature Policy Issuer name: An identifier for the body * Signature Policy Issuer name: An identifier for the body
responsible for issuing the Signature Policy. This may be used responsible for issuing the Signature Policy. This may be used
by the signer or verifying in deciding if a policy is to be by the signer or verifying in deciding if a policy is to be
trusted, in which case the signer/verifier must authenticate trusted, in which case the signer/verifier must authenticate
skipping to change at page 38, line 46 skipping to change at page 38, line 46
of certificates that make up the certificate path down to the signer's of certificates that make up the certificate path down to the signer's
user certificate. user certificate.
Policy constraints can be easier to process but to be effective require Policy constraints can be easier to process but to be effective require
the presence of a certificate policy identifier in the certificates the presence of a certificate policy identifier in the certificates
used in a certification path. used in a certification path.
Certificate path processing, thus generally starts with one of the Certificate path processing, thus generally starts with one of the
trust point from the signature policy and ends with the user trust point from the signature policy and ends with the user
certificate. The certificate path processing procedures defined in RFC certificate. The certificate path processing procedures defined in RFC
2459 clause 6 identifies the following initial parameters that are 2459 section 6 identifies the following initial parameters that are
selected by the verifier in certificate path processing: selected by the verifier in certificate path processing:
* acceptable certificate policies; * acceptable certificate policies;
* naming constraints in terms of constrained and excluded naming * naming constraints in terms of constrained and excluded naming
subtree; subtree;
* requirements for explicit certificate policy indication and * requirements for explicit certificate policy indication and
whether certificate policy mapping are allowed; whether certificate policy mapping are allowed;
* restrictions on the certificate path length. * restrictions on the certificate path length.
The signature validation policy identifies constraints on these The signature validation policy identifies constraints on these
 End of changes. 14 change blocks. 
22 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/