RE: CA vs. EE cert processing

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

When one builds a system comprising many CA functions for different
product domains, its likely that the key generation function is used to
generate keys for more than one of these CA functions - however this
approach is according to trust and operational requirements. Naturally
the theory in this process is that the root level CA function then in
fact signs the subordinate CA function certificate with its key and the
sub CA also signs its certs with its own key. However, we also expect in
this process - in terms of procedure that the root level CA could check
components of the certificate it is signing - such as the extensions
being applied - eg BC = CA .. and the client software used - the
certficate using system also checks this correctly..
 
ie. one must also verify that if a CA is using BC = CA that the client
has in fact verified that - again the proof of doing that is in the
system design and implementation. ie what gives proof of path
processing. Its all part of the system verification process - that each
part of the PKI is coherent and trusted.


My point was that X.509 states that this extension is set or not  to let
the certificate using system determine if it can use the public key to
validate certficates .. However, the standard also permits non extended
certficates to be used in a system and the certificate using system to
verify certificates  with the implicit knowledge that a cert chain does
equal an EE cert with superior CAs. 

My last point is that 2459 can profile X.509 say all CA certs must have
this extension set. EE certs may have this extension set to null or not
be there.

No ambiguity as far as I am concerned.


regards alan
> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Friday, April 09, 1999 10:36 AM
> To:	Alan Lloyd
> Cc:	ietf-pkix@imc.org
> Subject:	RE: CA vs. EE cert processing
> 
> Alan,
> 
> >X.509 defines that Basic Constraints is used to indicate that the
> public
> >key in the cert is valid for testing certificate signatures - by a
> >certificate using system eg. a client or EE. By definition it means
> that
> >in  (eg.) a 3 tier CA model that the root level CA has granted a
> private
> >and public key ( in a cert with BC set to CA) to a middle level CA to
> >issue certificates with and "advertise the fact (in its certificate)
> >that the root trusts the middle CA to issue certs and for clients to
> >validate such certs using the middle CAs public key.
> >
> >It strikes me that any PKIX compliant top level ROOT CA will set this
> >extension to ensure that the correct PKeys are used to validate certs
> >which point to itself. However, what the client software does with
> this
> >extension is another matter. Both have to be compatable. If an EE in
> its
> >validation path gets a cert with which it wants to validate a lower
> >level certificate with and this extension is not set - it should give
> up
> >- if ideology is maintained. However, X.509 permits an exit to this
> >process to enable a CA path to be built and validated without cert
> >extensions - simply because that is what they are - optional
> certificate
> >extensions.
> 
> This is a very muddled description that I have a bit of trouble
> following.
> For example, the root CA in your example would not, in general, grant
> "a
> private and public key" to another CA.  Do you mean the root CA would
> sign
> a cert with the publci key of the middle CA?  Please restate your
> argument
> using terms from X.509 and/or 2459 so I, and maybe others, can more
> clearly
> understand your point.
> 
> Steve