Subject: RE: Dual-signed certificates

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 26 Jul 2000 16:52:18 -0600

To respond to several of the Chicken and Egg points raised, obviously the second signature could not be included within the scope of the first.  I was remiss in describing this as a certificate attribute, because that would imply that it was embedded within the certificate signed by the issuer. So some new kind of format would have to be devised, where the signature would be appended.

I rather like the concept of a self-signed certificate that contains the original certificate as an extension within it.  If I trust the signer and his public key through some out of band mechanism, or thorough continued use, I can stop there, but if I haven't received the key any other way I can look inside and proceed from there.

After reading the comments by Simon Tardell and Denis Pinckas, I realized that perhaps I hadn't made my original point sufficiently clear.  In the meantime, some jocular references to 7-11 and McDonalds providing physical point of presense confirmation to a CA actually helps make my point.

The present, more or less-well-accepted CA model is that the subscriber goes to a local RA and requests a certificate be issued in his name.  That RA is then free to add or modify whatever it likes to the certificate request, and sends it on to the CA to be certified.

But the CA, depending on its CP and CPS, may add, modify, or delete information in the certificate request to suit its own purposes.  It could add DN qualification to make the DN unique, it could add various policy OIDs and policy constraints -- whatever it wishes to do.

It then sends the certificate back to the user, or posts it in a repository, but with no nonrepudiable evidence that either the RA or the subscriber had in fact agreed to those changes or additions!

Moreover, a rogue CA could create two such certificates, one containing terms favorable to it, and another closer to what the subscriber had originally requested.  Now, because the inclusion of the certificate in a transaction to be signed is (1) optional, and (2) only applies to transactions per se and not to session authentication or encryption, the relying party has no way of knowing whether the user in fact agreed to those terms..

This is why relying on a signed CMS object won't work -- the RP has no good way of knowing whether that format was expected or not.

Denis proposed:

><There exists a way, including by a procedure that is verifiable for
every received signature by any relying party. In the stuff that got
signed, you include the identifier of the certificate. This may be
done by using CMS (or is mandated in ES 201733). There is no need to
invent a double-signed certificate.

The point is that this procedure works for every legitimate document that I signed, but is not enforceable AS AN EXPECTATION against some illegitimate use of my certificate/key.

Now I grant that a CA can easily create a key pair and a certificate that would impersonate me for some small number of documents.  But I would attempt to repudiate that so-called signature by saying, "That signature and key is not mine, and I have never sees or made beneficial use of that key.  My key is xxxxxxx, and in fact I _have_ made extensive use of that key, and I have signalled my acceptance of that key, the certificate, and the terms and conditions of that certificate by counter-signing it and distributing widely in that counter-signed format."

The rogue CA could claim the same thing, of coruse, but then I would ask to see demonstrated beneficial use on my behalf, for example goods that were ordered and delivered (and accepted) to my address, based on that key.

A dual-signed certificate would also be beneficial to the good CAs, because it would provide a degree of proof that I had in fact accepted the certificate.

I believe that there is another point to be made here as well, and that is that trust accumulates incrementally with every accepted and reliable use of the key.

For the very first transaction with a particular subscriber, the relying party has little or no basis for trust, per se, except that if he trusts the CA he can presumably trust that the subscriber is correctly (if not unambiguously) identified.  So I know that the subject is "Bob Jones" or maybe "Village Idiot #13", but I don't know that I can trust that particular individual to either do or not do particular things.  Even if the certificate claims that the subscriber has agree to certain terms and conditions, I have no way of verifying the fact that that subscriber has really agreed to those terms, and I probably cannot sue the CA to enforce those terms if the subscriber defaults.  So I really want to know what representations the subscriber is making to me, directly.

However, for every transaction after the first, I have an additional degree of knowledge regarding that user.  I may not even care what his name is, or whether he has agreed to this, that, or the other certificate policy, so long as I get paid for the agreed upon transaction.

Sooner or later, the original identification by the RA and CA becomes almost irrelevant -- after all, they weren't testifying as to whether the person was financially solvent and a responsible bill payer, but I will come to know that.

Likewise, to switch metaphors, if I am a hospital administrator and I decide to revoke a doctor's staff priviledges because too many of his patients have been dying, I really don't care what some public CA happens to think about the validity of that doctor's certificate.

The point is that in many respects we tend to grant an excessive amount of authority to the CA in terms of establishing policy, etc., and yet in most cases (other than some closed user groups) the CA is not in a position to be able to enforce those policies against a particular user.  So the real issue is what terms and conditions the subscriber has agreed to, and how that acceptance can be reliably made known.

(This point of view may of course be anathema to those who espouse a top-down, authoritarian control structure, including many European countries and perhaps the US DOD.  Chacun a son gout.:-)

Bob

>>> Simon Tardell <[email-masked]> 07/22/00 06:46AM >>>
>      However, do people think it appropriate for the real external
> certificate to be carried around inside a CMS SignedData or a 
> self-signed certificate?  It certainly can be done, but should it?

If I've been reading the thread correctly the physical world analogy of the
"threat" that this would countermeasure is that a bank noone ever heard of
would issue an ID card with my picture (which they can do, because they saw
my ID card once) to someone who doesn't look like me and the question is not
whether you can trust the odd-looking fellow, but whether you can trust that
bank. 

When it comes to well-known banks, government branches, etc I assume they
won't do this, and I would not trust even my closest friends to be able to
assert with any degrees of certitude if a bank is honest or not issuing
certs. And no number of assertions that a Mickey Mouse CA issues a
certificate to the right guy would make me trust that CA to always do the
right thing (even if I would trust the particular certs it issued).

I am bit skeptical here, not because web-of-trust models don't have a
legitimate use, but rather because they don't mix very well with PKI.

Simon

Simon Tardell, Software Architect, iD2 Technologies
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
[email-masked], http://www.iD2tech.com 
Securing the Internet economy

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 27 Jul 2000 09:13:37 +0200

Bob,

(text deleted)

I will only comment on one point.

> Denis proposed:
> 
> There exists a way, including by a procedure that is verifiable for

> The point is that this procedure works for every legitimate 
> document that I signed, but is not enforceable AS AN EXPECTATION 
> against some illegitimate use of my certificate/key.
 
> Now I grant that a CA can easily create a key pair and a certificate 
> that would impersonate me for some small number of documents.  But 
> I would attempt to repudiate that so-called signature by saying, 
> "That signature and key is not mine, and I have never sees or made 
> beneficial use of that key.  

Not exactly. You are going to challenge the CA/RA to prove that you
asked for that public key, no matter if the private has been used.
If the CA/RA cannot present the right registration information, then
you win.

> My key is xxxxxxx, and in fact 
> I _have_ made extensive use of that key, and I have signalled my 
> acceptance of that key, the certificate, and the terms and 
> conditions of that certificate by counter-signing it and distributing 
> widely in that counter-signed format."

This would not prove anything in the case you just mention above,
because the (bad) CA could do that "for" you.
 
> The rogue CA could claim the same thing, of coruse, but then 
> I would ask to see demonstrated beneficial use on my behalf, 
> for example goods that were ordered and delivered (and accepted) 
> to my address, based on that key.

No. This is not necessary. The registration information is
essential.

Denis

(further text deleted)

---

From: "Simon McMahon" <[email-masked]>
Date: Fri, 28 Jul 2000 18:42:40 +1000

Hi Bob,

> The present, more or less-well-accepted CA model is that the subscriber
goes to a local RA and requests a certificate be issued in his name.  That
RA is then free to add or modify whatever it likes to the certificate
request, and sends it on to the CA to be certified.
>
> But the CA, depending on its CP and CPS, may add, modify, or delete
information in the certificate request to suit its own purposes.  It could
add DN qualification to make the DN unique, it could add various policy OIDs
and policy constraints -- whatever it wishes to do.
>
> It then sends the certificate back to the user, or posts it in a
repository, but with no nonrepudiable evidence that either the RA or the
subscriber had in fact agreed to those changes or additions!
How well accepted is that model ? You are suggesting that a certificate may
bare little resemblance to what the subscriber asked for. Of course that
will require the subject to acknowledge / accept the certificate. An
alternative model is where all the conditions are decided upon at
registration time and the RA and CA do not mess about with any policy OIDs
so that the cert is accepted by virtue of the fact that it (at least the
policy relevant parts) are derived solely from request.

> Moreover, a rogue CA could create two such certificates, one containing
terms favorable to it, and another closer to what the subscriber had
originally requested.  Now, because the inclusion of the certificate in a
transaction to be signed is (1) optional, and (2) only applies to
transactions per se and not to session authentication or encryption, the
relying party has no way of knowing whether the user in fact agreed to those
terms..
>
> This is why relying on a signed CMS object won't work -- the RP has no
good way of knowing whether that format was expected or not.
RPs that trust rogue CAs shouldn't be considered a valid argument for PKI
architecture discussions. If you build complexity into the protocols to try
and accomidate every such thing then it will not get deployed widely and
people will consider alternatives. Look what happened to SET.

Regards,

Simon McMahon
ERACOM Pty. Ltd.