[3037] in cryptography@c2.net mail archive
RE: Pseudonymous S/MIME certs?
daemon@ATHENA.MIT.EDU (P. J. Ponder)
Wed Jul 22 12:06:48 1998
Date: Wed, 22 Jul 1998 11:14:58 -0400 (EDT)
From: "P. J. Ponder" <ponder@freenet.tlh.fl.us>
To: "Brown, R Ken" <brownrk1@texaco.com>
cc: cryptography@c2.net
In-Reply-To: <896c7c3540c3d111ab9f00805fa78ce2013f82d6@texaco.com>
The administrative disadvantage of having to go back to Verisign or
whomever to handle the management of certs is a compelling reason for
organizations to have their own root level certificates, and as Ken points
out many companies are much larger and better known than any CA, anyway.
The real point, though, is the one that Carl Ellison (and others) keeps
stating, which is: The entity actually granting the right or privilege or
attesting to the identity of an individual, key, meme, or long lasting
persona, is the only logical source for the granting of the right or the
attestation. No third party is needed, and additional liabilities are
raised when additional actors are added to an otherwise sufficient
procedure. There is no business case for a free standing CA.
Carl et al can correct me if I've mistated the argument or its logical
conclusion.
--
pj
On Tue, 21 Jul 1998, Brown, R Ken wrote:
> Ben Laurie replied to Enzo Michelangeli
> >
> >> By the way: are there technical or legal issues preventing someone
> from
> >> using a personal certificate, issued by Verisign or equivalent, to
> initiate
> >> a certification chain useable by third parties? The advantage, of
> course,
> >> would be the inheritance of the trust when the message is received by
> >> popular agents which come with the public keys of those CA's built-in
> (like
> >> Messenger or Outlook Express).
>
> >I think there are legal and common sense issues and possibly technical
> >ones, too:
> >Technical: I don't know whether enough products actually support cert
> >chains (admittedly I've never tested it, but since they are almost
> never
> >used in real life, I rather doubt anyone else has either).
> >Legal: seems to me this would not be a permitted use of an ordinary
> >cert.
> >Common-sense: just coz I trust A, doesn't mean I trust B who A signed
> >for.
>
> Maybe for an individual certificate user. But if Cosmic Mega Corp need
> to get into certificates they don't want to be going back to Verisign
> (or anyone else) for every one of their server (never mind
> individuals). They want to root certificates somewhere in their
> corporate headquarters and then issue their own, showing that the
> various branches and subsidiaries of the company are trusted and
> authorised by the corporate centre. They also want to be able to control
> the validity, scope and expiration themselves and to easily be able to
> add or remove certificates for test or development servers or projects.
> And they want to be able to delegate limited authority to larger
> subsidiaries. (When you have branch offices with 50 or 60 servers in
> them you don't want to be forced to control everything from the centre,
> but you don't want to give the local people all the control either -
> there have to be all sorts of checks and balances - which digital
> certificates are very compatible with of course)
>
> In fact almost the *last* thing big companies want is branches and
> subsidiaries going out on their own and getting Verisign or whoever to
> give them certificates. After all, a large bank or well-known
> manufacturer probably has a better reputation and a bigger name than
> Verisign does.
>
> And I think you are right - there doesn't seem to be any commercially
> available software that allows big companies to do this sort of thing
> easily, in a way that integrates with the tools they already use for
> security/directory management and works with popular Internet servers
> and browsers, and also allows one internal CA to trust certificates for
> webservers, email, and whatever else needs it (or if there are I can
> think of a Mega Corporation who might want to hear about it).
>
> Ken Brown (usual disclaimer - I amd not speaking for Texaco at all)
>
>
