ietf-smime
[Top] [All Lists]

Re: I-D ACTION:draft-ietf-smime-ess-09.txt

1998-10-26 12:52:22
Francois Rousseau wrote:

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.


I think the problem is that with current crypto hardware it is difficult
to find some reliable way to say how a private key was used in a
"particular case". 

My suggestion was meant to imply that the certificate could contain some
indication saying that the private key can *only* be used in this way.

This would mean in practice that a CA would include this flag in an end
user certificate if the certificate was part of some hardware that
always required the PIN to be entered for each signature. Either
extended key usage or policy could be used for this purpose.

Trying to handle both cases (PIN entered on each signing and PIN only
entered once initially) with the same private key and certificate
present considerable problems considering how simple most "smart card"
technology currently is. In practice it would be much more easily
handled just using separate keys and certificates.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk
PGP key: via homepage.


<Prev in Thread] Current Thread [Next in Thread>