This is an answer to an E-mail from Francois Rousseau posted some time ago
about countersignatures.
As you will see the issue is more complex than it looks. A signing Policy is
proposed to be an additional signed attribute. The full text for such an
additional section is provided.
In a previous message I have suggested the addition of a
"counterSignatureScope" attribute in ESS to explicitly indicate
whether or not the countersigning process has validated the
original content. This new attribute could address concerns raised
by various people under this mailing list. Dr. Steve Henson has
even proposed some minor modifications/expansions to this
counterSignatureScope attribute to make it more precise.
Further to my original message and to address another non-repudiation
concern, I would also like to see if there is an interest in generalizing
such an attribute in order to also effectively define the scope of a
standard digital signature.
It is my understanding that under the German digital signature law,
before a private key can be used to digitally sign something, every
usage of the key requires a new card holder verification. To
accommodate this requirement there is currently a plan for extending
PKCS#11 with new functions and a new attribute. The intention is
that a PIN would be needed each time the private key is being used.
However, for reliable non-repudiation, there are no means to
indicate that such a verification of the PIN was performed under
the current signed data syntax of CMS.
The counterSignatureScope attribute could be generalized/expanded in
a "signatureScope" attribute to also address this scenario and possibly
others.
Any thoughts?
The generalization I propose is different. See the proposal hereunder.
Francois Rousseau
AEPOS Technologies
I would propose to generalize the concept so that a signer can mention the
conditions under which he agrees to comply with when signing with his/her
private key.
I thus propose to consider a Signing Policy (defined hereafter in ASN.1) that
would be just another signed attribute under ESS and that would be placed on
either the inner or outer SignedData message.
This would capture the notion you proposed with the CounterSignatureScope
attribute. Here is some text proposal to be added:
=================================================
SigningPolicy
The SigningPolicy identifies the conditions under which :
(a) the signer agrees to comply with when signing with his/her
private key and
(b) the signature should be relied upon.
The signing policy is defined as follows:
SigningPolicy ::= SEQUENCE {
signPolicyIdentifier SignPolicyId,
signPolicyQualifier SignPolicyQualifier,
counterSignQualifier counterSignQualifier OPTIONAL,
signPolicyUri SignPolicyUri OPTIONAL,
signPolicyHash SignPolicyHash OPTIONAL
}
SignPolicyId ::= OBJECT IDENTIFIER
SignPolicyQualifier ::= CHOICE {
policySignPolicyQualifier ANY DEFINED BY signPolicyIdentifier,
internetSignPolicyQualifier InternetSignPolicyQualifier }
InternetSignPolicyQualifier ::= ENUMERATED {
proof_of_receipt (1),
proof_of_delivery (2),
proof_of_approval (3),
proof_of_creation (4),
proof_of_sender (5),
proof_of_origin (6)
}
CounterSignatureQualifier ::= BIT STRING {
noValidationPerformed (0),
signatureValueValid (1),
signingTimesTrusted (2),
signingTimesValid (3),
signerCertificatesNotRevoked (4),
certificationPathsCorrect (5),
certificationPathsValid (6) }
signPolicyUri ::= IA5String
SignPolicyHash ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest }
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
Digest ::= OCTET STRING -- hash of inner content
-- of the signed Policy
The signPolicyIdentifier mandates the signing policy to be used in
the relying party's signature and path validation and identifies a
qualifier for the signature.
The following list of qualifiers is supported for Internet signing
policy qualifiers. This list is by no means exhaustive and currently
corresponds to the values supported by [IDUP]. It is anticipated
that it may be extended in future versions of this specification.
"Non-repudiation of Receipt" prevents a message recipient's
false denial of having received a message (whose content was
not necessarily looked at by the recipient).
"Non-repudiation of Delivery" prevents a message recipient's
false denial of having received and looked at the content of a
message.
"Non-repudiation of Approval" prevents a message recipient's
false denial of having approved the content of a received
message.
"Non-repudiation of Creation" prevents a message creator's
false denial of creating a message.
"Non-repudiation of Sender" prevents a message creator's
false denial of sending a message (that was not necessarily
created by the sender).
"Non-repudiation of Origin" prevents a message creator's
false denial of creating and sending a message.
The CounterSignatureQualifier may be present if the signature is over an
already CMS signed message. Such a message may be signed by multiple signers.
In that case the CounterSignatureQualifier indicates the degree of validation
performed by the countersigner over all the previous signatures. A range of
validations can be performed starting from none. When different degrees of
validation can be performed on the previous signatures, the least common
denominator will be indicated.
Each validation is made in accordance with the signing policy mentioned by
each signer and is performed for the time the original signer placed its
signature. Such validation may indicate:
1) whether no validation at all has been performed,
2) whether the combination of the signedAttributes contained within
the original signed message and the message digest of the content,
matches with the signature appended by each original signer,
3) whether the various signature times are considered as trustable
(the use of the signingTime attribute by each signer is required),
4) whether the times each signer placed its signature were all
within the validity period of each certificate,
5) whether all signer's public key certificates were not-revoked,
at the time each signer placed its signature,
6) whether all the certification paths leading to a root key were
valid for each signing policy, but no revocation checking has
been done.
7) whether all the certification paths leading to a root key
were valid for each signing policy and revocation checking
has been done for the time at which each signer placed its
signature.
Other countersignature qualifiers could be added if required
in the future.
The SignPolicyUri contains a pointer to a Signature Policy
Statement (SPS). Such statement must be signed by the Authority
providing the statement. The pointer is in the form of a URI.
The SignPolicyHash contains a hash of the inner content of the SPS.
The definition of AlgorithmIdentifier is imported from X.509.
Implementations supporting the SignPolicyHash must support SHA-1
for the AlgorithmIdentifier.