Subject: Re: Signing what you don't understand: a practical example

From: [email-masked]
Date: Tue, 11 Jul 2000 21:10:45 -0400

For Denis' technique to have any real use, there would also need to be
an indicator somewhere in the certificate that "the private key of this
pair is held in a Bider-compliant smart card".  Doing that (and it could go
into any of several extensions, or a new one could be defined), is
considerably easier than changing the signature format.
     For PKCS 1.5, of course, he could change that format just by defining
a hash function parameter value (if PKCS #1 would agree), or a new OID for
SHA-1 (SHA1OnBiderCard ??).  Getting verifiers to understand either of
these might be interesting, though.

          Tom Gindin

Aram Perez <[email-masked]> on 07/11/2000 08:44:48 PM

To:   [email-masked]
cc:
Subject:  Re: Signing what you don't understand: a practical example

Hi Denis,

[snip]
> 2. Encode the algorithm ID for the hash function and the hash value into
an
> ASN.1 value of type DigestInfo (see Section 11) with the Distinguished
> Encoding Rules (DER), where the type DigestInfo has the syntax
>
> DigestInfo ::= SEQUENCE {
> digestAlgorithm AlgorithmIdentifier,
> digest OCTET STRING,
> flags BIT STRING OPTIONAL
> }
>
> Meaning of 'flags' bits:
> first bit: content-not-understood
> subsequent bits: not defined at this time
>
> In case the value of the first bit of 'flags' is 0, the 'flags' field may
> be omitted for purposes of backward compatibility. However, this is not
> recommended. If omitted, the interpretation of the 'flags' field is
> application-dependent.
>
> The first field identifies the hash function and the second contains the
> hash value. Let T be the DER encoding.
>
> 3. If emLen is less than ||T|| + 10 then output "intended encoded message
> length too short".
>
> 4. Generate an octet string PS consisting of emLen-||T||-2 octets with
value
> FF (hexadecimal). The length of PS will be at least 8 octets.
>
> 5. Concatenate PS, the DER encoding T, and other padding to form the
encoded
> message EM as
> EM = 01 || PS || 00 || T
> 6. Output EM.

[Warning: Long sentence ahead.] If you received a signed message from me,
formatted per your instructions and with the flags parameter, how would you
know that I was using the security device you have described, that the
message was displayed on that device and that I really understood what I
signed? I can easily create an identical message on my insecure PC with
today's smartcards or just with the right software.

Regards,
Aram Perez

---

From: Aram Perez <[email-masked]>
Date: Tue, 11 Jul 2000 18:35:54 -0700

Hi Tom,

> considerably easier than changing the signature format.

But how does the CA know that I'm using a "Bider-compliant smart card"
(BCSC)? Do I have to physically show up somewhere with my BCSC to prove that
I have one? Since the BCSC isn't fully specified, I don't know if it allows
me to keep a backup copy of my signature key. If it does, then I
might/probably could feed the backup into a software only system.

Regards,
Aram Perez

[snip]

---

From: "denis bider" <[email-masked]>
Date: Wed, 12 Jul 2000 17:08:21 +0200

Hello Tom,

I don't quite understand why such an indicator within a certificate would be
needed for this technique to have any real use.

The current possible outcomes of a standard signature verification process
are:
- valid, and
- invalid.

What I am proposing is, essentially, that the possible range of returns be
widened to at least:
- valid (== technically and semantically valid)
- valid but not binding (== technically valid, semantically invalid)
- invalid (== technically and semantically invalid)

The security device I was mentioning was only intended to show a practical
situation where the widened range of possible returns, as outlined above,
WILL be needed sooner or later. Ie, it is just *a* usage scenario; it is not
an attempt to encompass all possible usage scenarios.

Regards,

denis

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 12. julij 2000 03:11
To: Aram Perez
Cc: [email-masked]
Subject: Re: Signing what you don't understand: a practical example

          Tom Gindin

To:   [email-masked]
cc:

Hi Denis,

[snip]
an
value
encoded

Regards,
Aram Perez

---

From: Antonio Lioy <[email-masked]>
Date: Wed, 12 Jul 2000 17:26:57 +0200

I think that what is being discussed in this thread is all
about the meaning (i.e. semantics) of a technically valid
digital signature. This could be easily achived by the
"signature policy" extension that is requested by the ETSI
draft for European electronic documents:

http://www.etsi.org/technicalactiv/ElectronicSignatures.htm

As e-documents will require much more extensions than just
the semantics of the signature (e.g. also the timestamping,
the role of the signer, the location) it is better to define
all of them in a general framework (such as the one above)
rather than to insert bit and pieces in various formats that
are then hard to mix up and reconcile. I would therefore
prefer to have a plain signature format (i.e. just the data
and its signature = public-key encrypted digest) and then
build on top of that to get more services (such as the
signature semantics that somebody is advocating here).

Just my 2c,

Antonio Lioy

---

From: Malte Borcherding <[email-masked]>
Date: Wed, 12 Jul 2000 17:42:23 +0200

Denis,

as pointed out by others in previous mails, the key usage extension in a
certificate is currently the usual place to carry the information you require.
In case this is not enough (say, because you want to use the same key pair for
different purposes), you might want to include a signature policy into your
signature. Such a concept is described in the ETSI Standard ES 201733, available
at http://www.etsi.org/SEC/el-sign.htm , or as Internet-Draft at
http://www.ietf.org/internet-drafts/draft-ietf-smime-esformats-00.txt . Such a
policy can carry information about the commitment type and the signature
environment. Apart from that, it can also contain information on how the
signature has to be verified in order to be regarded as valid.  Furthermore,
this standard also binds the certificate cryptographically to the signature,
such that it is clear which certificate is meant to be used for verification.

As for the question of a secure signature apparatus including a secure viewer,
this has been (and still is) subject to heavy debate in the various standards
related to legally binding digital signatures. Bottom line: There is currently
no practical solution for a highly secure display component which at the same
time can be used for many different document formats and has any chance of
widespread use. Some mobile devices come close to the required security, as they
are generally less subject to malicious attacks. Lack of technical security has
to be met by processes, like educating users on how to keep theit PCs free of
viruses.

Malte