Subject: Re: Server-signatures: Re: proposed key usaged text -- the final round

From: [email-masked]
Date: Wed, 1 Dec 1999 10:53:11 -0500

Shouldn't most of this distinction be handled by distinguishing
between certificates based on the object class of the subject, especially
the object classes organizational person,  organizational role, application
process, and application entity?

          Tom Gindin

"Anders Rundgren" <[email-masked]> on 11/30/99 11:58:39 PM

To:   "Denis Pinkas" <[email-masked]>, "Russ Housley"
      <[email-masked]>, "Tim Polk" <[email-masked]>,
      <[email-masked]>, "Tony Bartoletti" <[email-masked]>
cc:
Subject:  Re: Server-signatures: Re: proposed key usaged text -- the final
      round

Tony,
I may be wrong but I assumed that the text below was to be included in the
NR-document
and if so is the case it talks about things like "users" and "personal
information" which
is not coherent with server-generated signatures.

>>    >The protection afforded private keys is a critical factor in main-
>>    >taining security. On a small scale, failure of users to protect
>>    >their private keys will permit an attacker to masquerade as them, or
>>    >decrypt their personal information. [stuff about CA keys deleted]

When I refer to server-based signatures I meant for example things like
automated
bills from energy and phone companies.  Such bills are usually never
touched by
a human and would typically only have a company ID of some kind as subject
when/if
converted into an electronic digitally signed format.

The user is "certificateSubject" or "entity owning the private keys"

<snip>

I agree with your nicely formulated lines regarding "company owned keys"
below

>Let me explore the latter application.  Suppose I am a "company-trusted"
>employee, using a company-owned "private key".  I assume further that the
>company has its own mechanism for (hoping to) control who has the use of
>a given key at a given time, or at least who is responsible for its use.
>
>Now, I use the private key in question, entering into some obligation with
>an external RP.  Later, I attempt to deny my actions, causing this RP some
>hardship.
>
>My understanding is that this "bindings" in question look like:
>
>   RP <---> Transaction <---> Key/Cert <---> Company <---> Me
>
>That is, the RP must take up issue with the company, being the owner
>(or certSubject or Operator) of the key, directly.  It falls upon the
>company to follow the chain, so to speak, and take me to task.
>
>The central point is that the RP has only a certificate, and its
>"named holder", to point to in a dispute.  If the means by which
>the company above "secures the connection between key and user"
>is hidden from view, no amount of NR-servicing on the RP side can
>suffice to hold the "user" accountable.  They are forced instead to
>pressure the company, who may in turn pressure the employee.

>Perhaps I don't fully understand all of the details you assume to
>hold in the server-based example.  I may be confusing different
>scenarios:
>
>1.  Cert says "owned by BigCorp, as key nnn" but I control its use,
>    or at least I did last Thursday when I checked it out.

This is the hard one.  "I" may have checked it out but I installed in
an automated system which is administered and owned by BigCorp

>2.  Cert says "owned by Tony", and the company controls its use in
>    some automated system, with my supposed blessings/restrictions.
>
>In the second case, the RP would be expected to come after me directly.
>If I am innocent, I am forced to take issue with the company.

Unusual case but possible¨

>
>In each case, the RP can turn only to the "certificateSubject".

Absolutely!  But the reference in the cited text in the beginning is
slightly wrong if
it deals woth personal data in situations like #1

Anders