RE: Certificate requests for encryption keys

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Some comments - Generally because the logic of this one seems wrong.
> -----Original Message-----
> From:	pgut001@cs.auckland.ac.nz 
> Sent:	Wednesday, June 09, 1999 6:23 PM
> To:	ietf-pkix@imc.org
> Subject:	Re: Certificate requests for encryption keys
> 
> Anne Anderson - Sun Microsystems <aha@East.Sun.COM> writes:
> 
> >I would like to see any Subject, including an End-Entity, be able to
> issue
> >certificates for encryption keys (and possibly other types as well).
> 
> I proposed this some time ago, but there didn't seem to be any
> interest in it.
> Here's the message from last time...
> 
> Peter.
> 
> -- Snip --
> 
> Current X.509 profiles all require the presence of an arbitrarily
> large and
> all-encompassing PKI to function properly.  Unfortunately this doesn't
> take
> into account two very common cases:
	This is because - X.509 is part of a directory authentication
framework that by defintion relies on and is defined by X.500 directory
based information objects and attributes -  that must exist  in a named
hierarchy - ie 509 relates to the authentication framework of an X.500
distributed directory information model that contains attributes (and
objects) that add security and trust mechanisms (CAs PKIs and Certs) etc
to this. 

	 
> 1. Two parties who have an established trust relationship and want to
> share
>    keys.  This is a very common case for businesses who would
> typically have
>    existing bilateral trading arrangements and neither require, nor
> care for,
>    an external (or internal) CA.  Keys for the other party would be
> held as
>    part of the standard account records maintained by both sides,
> which would
>    also contain information such as account balance information
> required for
>    standard business practices).  Simply registering the other parties
> public
>    key in the account record represents the easiest and most reliable
> way of
>    managing the public key, whereas using a third-party certificate
> requires
>    complex certificate handling, reliance on a third-party CRL, and
> the
>    creation of an unnecessary parallel trust infrastructure which adds
> nothing
>    (apart from complexity) to the existing trust mechanism.
> 
>    A typical example of this would be users who are submitting
> electronic tax
>    returns: The tax department knows who its "customers" are, and
> *everyone*
>    knows who the tax department is.  A CA doesn't even fit into this
> model.
> 
	So this is bi lateral - mutual out of band trust relationship  -
it is not directory based - PKI trust model.

	This is like arguing that a ship is not a car !

	However, most tax departments have done it this old way for the
last 2000 years - but now they are adopting PKI...

> 2. An end entity who has a CA-certified authentication cert and wants
> to use it
>    to issue their own confidentiality keys.  If an end entity has an
>    authentication cert then there's no real need for CA-issued
> confidentiality
>    certs, especially since this grants the end entity a far greater
> degree of
>    control over their keys.  For example the end entity might wish to
> roll over
>    their confidentiality keys once a month, a prudent security
> precaution which
>    could end up bankrupting them if it were attempted with
> CA-certified keys.
> 
	Again this does not reflect a natural hierachy of trust - or the
logic of what a CA or EE is.. ie an EE is just that and End Entity and
its certificate by definition cannot be used to verify issue or
certificates..
	Why debate that something which is identified at the end of the
line cannot do something which can only be done by something within the
line!

	 All one needs to make this work is make the entity that wants
to manage its own confidentiality keys NOT and end entity - ie a CA
function because it generates its own certs - it is by definition a CA
function..

	A CA is represented by additional attributes of a directory
object...


> Unfortunately both of these items, while perfectly sensible, represent
> a
> paradox for X.509, since a certificate is incapable of representing
> them:
> There's no way to create a standalone end-entity certificate
> containing a
> public key, and there's no way for an end entity to create/certify
> their own
> confidentiality keys.
> 
	There is no paradox for X.509 - there are just flaws in the
logic presented.

	snip

	If one wnats to build a PKI system as represented by an X.509
model in the context of a distributed directory service - everything
works
	If one throws away the directory information model and the
hierarchical rules of trust and CA functions identification that are
assigned to that directory model , etc  and create unrealistic
situations outside that - and then say these are flaws - IMHO the debate
is strange..

	I use my boat on the sea and my car on the roads - I understand
the modelling and engineering of these items to the extent that if  I
reverse their usage - nothing works - and costs me heaps :-)

	regards alan