rfc3125.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,635 行 · 第 1/5 页
TXT
1,635 行
signature policy for an electronic signature to be potentially valid.
The signature validation policy is described as follows:
Ross, et al. Experimental [Page 6]
RFC 3125 Electronic Signature Policies September 2001
SignatureValidationPolicy ::= SEQUENCE {
signingPeriod SigningPeriod,
commonRules CommonRules,
commitmentRules CommitmentRules,
signPolExtensions SignPolExtensions OPTIONAL
}
The signingPeriod identifies the date and time before which the
signature policy SHOULD NOT be used for creating signatures, and an
optional date after which it should not be used for creating
signatures.
SigningPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime OPTIONAL }
3.3 Common Rules
The CommonRules define rules that are common to all commitment types.
These rules are defined in terms of trust conditions for
certificates, time-stamps and attributes, along with any constraints
on attributes that may be included in the electronic signature.
CommonRules ::= SEQUENCE {
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
If a field is present in CommonRules then the equivalent field must
not be present in any of the CommitmentRules (see below). If any of
the following fields are not present in CommonRules then it must be
present in each CommitmentRule:
* signerAndVeriferRules;
* signingCertTrustCondition;
* timeStampTrustCondition.
Ross, et al. Experimental [Page 7]
RFC 3125 Electronic Signature Policies September 2001
3.4 Commitment Rules
The CommitmentRules consists of the validation rules which apply to
given commitment types:
CommitmentRules ::= SEQUENCE OF CommitmentRule
The CommitmentRule for given commitment types are defined in terms of
trust conditions for certificates, time-stamps and attributes, along
with any constraints on attributes that may be included in the
electronic signature.
CommitmentRule ::= SEQUENCE {
selCommitmentTypes SelectedCommitmentTypes,
signerAndVeriferRules [0] SignerAndVerifierRules
OPTIONAL,
signingCertTrustCondition [1] SigningCertTrustCondition
OPTIONAL,
timeStampTrustCondition [2] TimestampTrustCondition
OPTIONAL,
attributeTrustCondition [3] AttributeTrustCondition
OPTIONAL,
algorithmConstraintSet [4] AlgorithmConstraintSet
OPTIONAL,
signPolExtensions [5] SignPolExtensions
OPTIONAL
}
SelectedCommitmentTypes ::= SEQUENCE OF CHOICE {
empty NULL,
recognizedCommitmentType CommitmentType }
If the SelectedCommitmentTypes indicates "empty" then this rule
applied when a commitment type is not present (i.e., the type of
commitment is indicated in the semantics of the message). Otherwise,
the electronic signature must contain a commitment type indication
that must fit one of the commitments types that are mentioned in
CommitmentType.
A specific commitment type identifier must not appear in more than
one commitment rule.
CommitmentType ::= SEQUENCE {
identifier CommitmentTypeIdentifier,
fieldOfApplication [0] FieldOfApplication OPTIONAL,
semantics [1] DirectoryString OPTIONAL }
Ross, et al. Experimental [Page 8]
RFC 3125 Electronic Signature Policies September 2001
The fieldOfApplication and semantics fields define the specific use
and meaning of the commitment within the overall field of application
defined for the policy.
3.5 Signer and Verifier Rules
The following rules apply to the format of electronic signatures
defined using [ES-FORMATS].
The SignerAndVerifierRules consists of signer rule and verification
rules as defined below:
SignerAndVerifierRules ::= SEQUENCE {
signerRules SignerRules,
verifierRules VerifierRules }
3.5.1 Signer Rules
The signer rules identify:
* if the eContent is empty and the signature is calculated using
a hash of signed data external to CMS structure.
* the CMS signed attributes that must be provided by the signer
under this policy;
* the CMS unsigned attribute that must be provided by the signer
under this policy;
* whether the certificate identifiers from the full certification
path up to the trust point must be provided by the signer in
the SigningCertificate attribute;
* whether a signer's certificate, or all certificates in the
certification path to the trust point must be by the signer in
the * certificates field of SignedData.
SignerRules ::= SEQUENCE {
externalSignedData BOOLEAN OPTIONAL,
-- True if signed data is external to CMS structure
-- False if signed data part of CMS structure
-- Not present if either allowed
mandatedSignedAttr CMSAttrs,
-- Mandated CMS signed attributes
mandatedUnsignedAttr CMSAttrs,
-- Mandated CMS unsigned attributed
mandatedCertificateRef [0] CertRefReq DEFAULT signerOnly,
-- Mandated Certificate Reference
Ross, et al. Experimental [Page 9]
RFC 3125 Electronic Signature Policies September 2001
mandatedCertificateInfo [1] CertInfoReq DEFAULT none,
-- Mandated Certificate Info
signPolExtensions [2] SignPolExtensions OPTIONAL
}
CMSattrs ::= SEQUENCE OF OBJECT IDENTIFIER
The mandated SignedAttr field must include the object identifier for
all those signed attributes required by this document as well as
additional attributes required by this policy.
The mandatedUnsignedAttr field must include the object identifier for
all those unsigned attributes required by this document as well as
additional attributes required by this policy. For example, if a
signature time-stamp <see section 1.1) is required by the signer the
object identifier for this attribute must be included.
The mandatedCertificateRef identifies whether just the signer's
certificate, or all the full certificate path must be provided by the
signer.
CertRefReq ::= ENUMERATED {
signerOnly (1),
-- Only reference to signer cert mandated
fullpath (2)
-- References for full cert path up to a trust point required
}
The mandatedCertificateInfo field identifies whether a signer's
certificate, or all certificates in the certification path to the
trust point must be provided by the signer in the certificates field
of SignedData.
CertInfoReq ::= ENUMERATED {
none (0) ,
-- No mandatory requirements
signerOnly (1) ,
-- Only reference to signer cert mandated
fullpath (2)
-- References for full cert path up to a
-- trust point mandated
}
Ross, et al. Experimental [Page 10]
RFC 3125 Electronic Signature Policies September 2001
3.5.2 Verifier Rules
The verifier rules identify:
* The CMS unsigned attributes that must be present under this
policy and must be added by the verifier if not added by the
signer.
VerifierRules ::= SEQUENCE {
mandatedUnsignedAttr MandatedUnsignedAttr,
signPolExtensions SignPolExtensions OPTIONAL
}
MandatedUnsignedAttr ::= CMSAttrs
-- Mandated CMS unsigned attributed
3.6 Certificate and Revocation Requirement
The SigningCertTrustCondition, TimestampTrustCondition and
AttributeTrustCondition (defined in subsequent sub-sections) make use
of two ASN1 structures which are defined below: CertificateTrustTrees
and CertRevReq.
3.6.1 Certificate Requirements
The certificateTrustTrees identifies a set of self signed
certificates for the trust points used to start (or end) certificate
path processing and the initial conditions for certificate path
validation as defined RFC 2459 [7] section 4. This ASN1 structure is
used to define policy for validating the signing certificate, the
TSA's certificate and attribute certificates.
CertificateTrustTrees ::= SEQUENCE OF CertificateTrustPoint
CertificateTrustPoint ::= SEQUENCE {
trustpoint Certificate,
-- self-signed certificate
pathLenConstraint [0] PathLenConstraint OPTIONAL,
acceptablePolicySet [1] AcceptablePolicySet OPTIONAL,
-- If not present "any policy"
nameConstraints [2] NameConstraints OPTIONAL,
policyConstraints [3] PolicyConstraints OPTIONAL }
The trustPoint field gives the self signed certificate for the CA
that is used as the trust point for the start of certificate path
processing.
Ross, et al. Experimental [Page 11]
RFC 3125 Electronic Signature Policies September 2001
The pathLenConstraint field gives the maximum number of CA
certificates that may be in a certification path following the
trustpoint. A value of zero indicates that only the given trustpoint
certificate and an end-entity certificate may be used. If present,
the pathLenConstraint field must be greater than or equal to zero.
Where pathLenConstraint is not present, there is no limit to the
allowed length of the certification path.
PathLenConstraint ::= INTEGER (0..MAX)
The acceptablePolicySet field identifies the initial set of
certificate policies, any of which are acceptable under the signature
policy. AcceptablePolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= OBJECT IDENTIFIER
The nameConstraints field indicates a name space within which all
subject names in subsequent certificates in a certification path must
be located. Restrictions may apply to the subject distinguished name
or subject alternative names. Restrictions apply only when the
specified name form is present. If no name of the type is in the
certificate, the certificate is acceptable.
Restrictions are defined in terms of permitted or excluded name
subtrees. Any name matching a restriction in the excludedSubtrees
field is invalid regardless of information appearing in the
permittedSubtrees.
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?