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

From: [email-masked]
Date: Wed, 12 Jul 2000 11:52:42 -0400

An RP will trust the presence of such a high-assurance indicator above
the value of an ordinary digital signature only if he is credibly assured
that the indicator's presence actually proves something.  The natural way
to do this is to indicate the presence of a high-assurance device in the
certificate.  If no such indication is present, the RP has no reason to
believe that the attack Aram describes is very difficult - so he won't
trust a signature with the indicator any more than one without it.

          Tom Gindin

"denis bider" <[email-masked]> on 07/12/2000 11:08:21 AM

Please respond to <[email-masked]>

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   <[email-masked]>
Subject:  RE: Signing what you don't understand: a practical example

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

     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: "John Ross" <[email-masked]>
Date: Wed, 12 Jul 2000 17:41:39 +0100

Please have a look at the following internet draft:
"Electronic Signature Formats for long term electronic signature"

at
http://www.ietf.org/html.charters/smime-charter.html

I believe it proposes solutions to the problems being raised here.

Regards

John Ross

-----Original Message-----
From: "denis bider" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Date: 12 July 2000 16:10
Subject: RE: Signing what you don't understand: a practical example

be
not

---

From: [email-masked]
Date: Wed, 12 Jul 2000 18:27:07 -0400

Responses below.  Do we need a standard abbreviation similar to AFAIK
for wording which contains an escape clause (like one of my answers below),
and if so, what should it be?

          Tom Gindin

Aram Perez <[email-masked]> on 07/12/2000 12:28:44 PM

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

Hi Tom,

> [Tom Gindin] The same problem exists with current smart cards, but some
> people are putting indicators that a key is on a smart card into their
> certificates already.  Either the CA generates the key on and delivers
the
> smart card, or the user shows up with card in hand.  Hopefully, a BCSC
> would not allow signature key backup.

When you say "some people are putting indicators that a key is on a smart
card into their certificates already", does the CA check that fact? Who's
liable if the indicator is positive when in fact I have no smart card? If
the CA generates the key, how do I know the CA doesn't keep a copy?

[Tom Gindin] 1) The CA is certainly supposed to check that a key is on a
smart card before including a CertificatePolicy or ExtendedKeyUsage which
implies that the key is on one; 2) The CA is approximately as liable
(warning: weasel wording ahead!) for certifying this fact properly as for
certifying the contents of SubjectAltName properly; 3) As far as key
generation goes, this is just a higher value smart card - if the CA can be
trusted for generation today he can probably be trusted for it on these.

Regards,
Aram Perez