Denis,
I totally support your proposal of a "Signing Policy" as a new signed
attribute under ESS, except for the few minor suggestions that I have
interspersed below. It can address both the purpose for my proposed
"counterSignatureScope" attribute and the issue I raised in a previous
message about indicating HOW a "private key" is used to digitally sign
things in particular instances versus what is indicated through its related
public-key certificate.
Francois Rousseau
AEPOS Technologies
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),
Since CounterSignatureQualifier is a BIT STRING and that bit "0" indicates
that no validation at all has been performed, you will need to include some
instructions below that explain that when the "noValidationPerformed"
qualifier bit "0" is turn on, other qualifier "bits" can NOT be turn on.
signatureValueValid (1),
As per Section 5.4 of CMS, the content signature value is computed over a
message digest, which includes the message digest of the original signed
content with any signed attributes if present. Although under CMS the
counter signer is NOT mandated to validate the original content, the
counter signer could still validate that the message digest of the original
signed content with any present signed attributes match with the original
signature. This is what the "signatureValueValid" qualifier as originally
proposed by Dr. Henson was supposed to be addressing.
However, the counter signer could also validate that the original content
matches with the message digest. This is what the "messageDigestValid"
qualifier as originally proposed by Dr. Henson was supposed to be
addressing. To address these two separate aspects, I suggest that you
insert the choice of a "messageDigestValid" bit between the
"signatureValueValid" bit "1" and the "signingTimesTrusted" bit "2" and
renumber accordingly.
If the counter signer validates both the original content and also
validates that the message digest of the original signed content with any
signed attributes match with the original signature, both the
"signatureValueValid" and the "messageDigestValid" bits would than be turn on.
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,
As suggested above, item 2 would than read:
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 <new>. This does not imply
that access to the original content is available <end>,
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,
An new item would have to be inserted between items 2 and 3 to address the
"messageDigestValid" qualifier suggested above, which would read:
x) whether the messageDigest attribute matches that of the original content,
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.