Subject: Signing Policy

From: Denis Pinkas <[email-masked]>
Date: Wed, 28 Oct 1998 15:57:27 -0800

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.

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 29 Oct 1998 01:56:58 +0000

Denis Pinkas wrote:
> As you will see the issue is more complex than it looks. 

Indeed it is. There is also the issue of trust. A trusted countersigner
is a different beast from a trusted signer and likewise a trusted
countersigning CA is different from a normal end user CA.

I might trust an end user to sign a message (via a chain to a trusted
root) but I certainly wouldn't trust them to countersign a message
purporting to contain trusted timestamps and verifying chains in the
original SignerInfo.

This might be handled by some certificate extensions in the
countersigning certificate and the issuer certificate. This could either
be done either in a simple way (e.g. "certificate key approved for
countersigning" and "CA certificate can sign countersigning
certificates") or in a more intricate fashion ("trusted to countersign
with a trusted timestamp" etc etc).

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

---

From: Francois Rousseau <[email-masked]>
Date: Thu, 29 Oct 1998 12:27:15 -0500

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

>attribute. Here is some text proposal to be added:

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.

>  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>,

>     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,