I do not think that this issue, which I raised in my previous message on a
"signatureScope" attribute, of how "private keys" are used, which I will
call a "Secure Sign" issue, can be resolved with public-key certificates.
The "Key Usage" extension from PKIX-1 may indicate the purpose of the
public key contained in the certificate. The selection of the
"digitalSignature" bit does not indicate how the private key is used in a
particular case, but only that it can be used to performed digital
signatures. Similarly the "Extended Key Usage" extension from PKIX-1 may
indicate one or more purposes for which the certified public key may be
used, in addition to or in place of the basic purposes indicated in the key
usage extension field. It still does not indicate how the private key is
used in a particular case. Similarly the "Certificate Policies" extension
from PKIX-1 may contain a sequence of one or more policy information terms,
each of which consists of an object identifier (OID) and optional
qualifiers. These policy information terms indicate the policy under which
the certificate has been issued and the purposes for which the certificate
may be used. It still does not indicate how the private key is used in a
particular case. Although the "Signing Certificate" attribute from ESS
allows to bind under the signature of the sequence of policy IDs from the
"Certificate Policies" extension from PKIX-1, it still does not address how
the private key is used in a particular case.
Indeed this is an issue with indicating HOW a "private key" is used to
digitally sign things in particular instances and not with its related
public-key certificate. This should only be reflected in each particular
digitally signed thing. However, there are currently no means under CMS
and/or ESS to indicate under what circumstances a "private key" was used to
perform a particular digital signature. Ultimately, unless the
cryptographic module performing such a "secure sign" function could append
this "signatureScope" attribute on its own, I agree with Dr. Henson that
there will always be a trust issue with the user/application including such
an attribute.
Any more thoughts?
Francois Rousseau
AEPOS Technologies
Dr Stephen Henson wrote:
I'm not sure if I follow this. If the "signatureScope" is meant to be
a signed attribute and signed by the signer then it would not be
trustable: any certificate (whether the verification was performed or
not) could include any value they wanted.
There are several possible alternatives. One is an indicator in the
signer's certificate (or issuing CA): since this is signed by the CA it
would be trustable, but that makes it a PKIX issue. This might add a
complication to the S/MIME chain verification in some cases.
Alternatively a countersigner could verify that the signing certificate
was valid for this purpose and include a bit in the proposed
counterSignatureScope signed attribute. This adds the complication that
the client would need to trust the counter signing authority as a "proxy
chain verifier".
Steve.
Francois Rousseau wrote:
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?