Re: Soft signatures

• Previous message: Tom St Denis: "Re: Blowfish Sign Extension implementation risk"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Sun, 02 May 2004 21:58:24 -0600

Nomen Nescio <nobody@dizum.com> writes:
> I had an idea the other day for "soft" signatures. These are digital
> signatures which aren't completely binding. Maybe you'd like to make
> a signed statement with a large degree of certainty about who you were,
> but to leave open a small possibility that it might have been forged.

part of the problem is that there is some semantic ambiguity between
the concept of signatures and the term "digital signatures".

typical digital signature starts out with computing a secure hash of
the message, "enccrypting" the secure hash, transmitting the message
and the encrypted hash. The recipient then recomputs the secure hash
of the message, decrypts the transmitted version and compares the two
values. If there is any bit difference, then either 1) the message is
tampered with in some way or 2) some problem in encrypt/decrypt.

the definition of secure hash typically is such that it is hard to
tell the amount of mismatch ... just that there is some mismatch.

The encrypt/decrypt part (not the message tampering angle) is a part
of three-factor authentication ... aka

1) something you have
2) something you know
3) something you are

... now, digital signature, typically just represents that you (in
some way) "have" the corresponding private key. There is some hope
that the private key hasn't been replicated and you are actually the
only person with that private key (aka something you have, typically
presumes that you uniquely possess the object).

now, this "digital signature" still just represents message integrity
and "something you have" authentication .... not really anything about
things like non-repudiation and/or forging agreement.

To get from this technology (that just happens to have a label
containing the character string "signature") ... to things like real
Signature ... carries with it things like intent and non-repudiation.
For some time there were arguments that if a certificate contained the
bit flag called "non-repudiation" ... any message validated with the
certificate's public key couldn't be repudiated. A relying party just
needed to find some certificate authority willing to issue a
certificate with your public key and the non-repudiation flag in it.
There has been lots of past threads about what extra operations are
needed at the time a signature is created to even begin
non-repudiation issues. various are referenced in the following
collection on client and radius authentication:
http://www.garlic.com/~lynn/subpubkey.html#radius
and identity, authentication, and privacy:
http://www.garlic.com/~lynn/subpubkey.html#privacy

So one of the issues that I raised at:
http://www.nist.gov/public_affairs/confpage/new040412.htm

was issue of using private keys for both authentication as well as for
agreeing to some business process (like authorizing some operation,
demonstrating agreement and/or intent like in real signatures). the
conflict is that there can be challenge/response authentication
mechanisms that send you random data, you sign the random data and
send it back to authenticate who you area. The problem is that you
aren't "signing" the data (in the sense that people sign documents)
... you are just establishing "something you have authentication". The
issue, is that if you ever use a private key as part of "signing"
random data for "something you have" authentication purposes, the
random data might actually not be random ... it could actually be some
valid transaction. the solution might be that before you use your
private key to ever sign anything, you first combine the message
(before doing the secure hash) with a couple kilobytes of legal text
excplicitly stating what kind of signature operation you believe you
are performing. Part of the issue is there may not just be one way to
forge something. Note that this kind of forging is akin to phishing
... convincing you to do something w/o you really realizing what it
was you were doing.

The real issue is that "digital signature" technology is being used
for a number of different business purposes. There is simple,
"something you have" authentication. However, attempting to move
upstream to higher value operations like human signatures that carry
with it implication of intent and agreement can creates severe
problems.

Using the same technology for simple authentication as well as intent
and agreement can create a fundamentally flawed environment.
Basically, the use of digital signatures in pure authentication
operations already implies the use of signatures for operations that
are specificly nonbinding; aka the digital signature is purely to
prove who i am and doesn't include any signature concept that i'm
agreeing to anything.

... at the conference, there were also a number of references to
"naked public keys" ... i.e. another way of describing aads.
http://www.garlic.com/~lynn/index.html#aads

the issue is tha most people observe that public keys are running
around armored in something called (x.509) certificates. The
certificates aren't actually to armor the public keys but to to armor
the business relationship between the public keys and some amount of
other information.

For a long time, business have used fairly armored processes, where
the information and actual operations of any value were carried on in
an armored environment ... the armoring designed to protect both the
information and the validity of the operations.

It was observed that there was the possibility of performing some
number of low/no value operations in the wild ... outside of
traditional business controls and in an offline environment w/o direct
recourse to the real business operation. The result was somewhat the
creation of armored certificates that contain a subset of information
(that might be found in an armored business process environment)
... where some amount of the information and a public key were armored
in a "certificate". These armored certificates would promote some
number of low/no value operations to proceed in the wild outside of
normal prudent business controls.

One of the issues that cropped up in the mid-90s was the severe privacy
and liability issues with over abundance of information in an
x.509 identity certificate ... and the retrencing to a severely truncated
"relying-party-only" certificate. .. misc. past references:
http://www.garlic.com/~lynn/subpubkey.html#rpo

the truncation of the armored binding between information and a public
key for a relying-party-only certificate might be as little as a
public key and an account number.

so the scenario goes that a armored business operation creates an
armored relying-party-only certificate (drastic subset of information
present inside the armored business operation) that is allowed to
float around in the wild. this relying-party-only certificate
(containing drastic subset of information that the relying-party
already has) is periodically sent back to the relying-party as part of
some business operation that will occur within the confines of a
traditional armored business environment (containing a superset of
information contained in the armored relying-party-only certificate).

the repeated assertion is that in such scenarios that the existance of
an armored relying-party-only certificate floating around in the wild,
AND being transmited back to the relying-party is redundant and
superfluous to the relying-party business operation.

the observation is that in the AADS scenario where the public key is
contained in the armored business operation along with lots of other
information ... can be done without the protective certificate
armoring that is necessary when the public key and its related
information is allowed to float around in the wild.

the actual issue is that such repositories inside normal, prudent
business operations isn't actually a naked environment ... it is
typically protected as required not only for the actual information
but also the actual business processes that go on in such an
environment.

It is only when such information is allowed out in the wild ... that
the protective armoring (say analogous to space suits) is required to
provide integrity of the public key bound to specific information.

One of the issues exemplified by the relying-party-only certificate
case is that for operations of any value, they also need to occur
within an armored/protected environment. Given that such an
environment is used for business operations of environment, having
separate armoring for a small restricted subset of the business
information is redundant and superfluous (like it typically isn't
necessary to wear a space suit on the surface of the earth).

The certificate armoring is specifically targeted at providing support
for low/no value operations occuring in the wild, outside the bounds
of normal business process operations.

So the AADS public keys aren't really naked inside normal business
operations .... they just don't need to have the space suit protective
armoring that is necessary for existing in a wild and hostile
environment. To some extent this is akin to some science fiction movie
where people who have only familiarity with airless planets are
dismayed at the thought of earth inhabitants going around in the open
on the surface w/o space suits. It isn't that they are naked, it is
just that they are operating in a less hostile environment.
Furthermore, since there is some presumption that a valid business
process will be occuring in that environment, there should be other
safeguards in place making certificate armoring redundant and
superfluous.

so to slightly wonder back in the direction of the original topic
... the current armoring of a public key and information in a
certificate doesn't even include the demonstration that you are in
agreement with what is in the certificate. current certificate-based
infrastructures don't have you signing the contents of the certificate
... and then the certification authyority signing the composite
including your signature of agreement.

this issue has to do with whether or not the contents of a ceritifcate
can create any legal obligations for you. If I'm agreeing to some sort
of legal obligation, i'm typically required to sign &/or initial every
document. In the existing certificate-base paradigm, there is a

1) message
2) digital signature
3) certificate

the only thing that I've actually signed is the message, I haven't
signed the certificate ... so it isn't impossible that a different
certificate (with my public key) could be substituted. The current
environment doesn't have the key owner signing either the certificate
and/or the choice of certificate that is included with any message.

and already discussed, with possibility for private keys being used to
sign both random data (in purely authentication scenarios) and
possibly legal documents (as in real signatures demonstrating intent
and agreement), there is signficiant ambiguity about the meaning of
any digital signature.

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

• Previous message: Tom St Denis: "Re: Blowfish Sign Extension implementation risk"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]