RE: CA vs. EE cert processing

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Stephen - not to extend this debate - 
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.


I see no ambiguity - just flexibility - 2459 can profile this
flexibility out if desired.

regards alan



> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Thursday, April 08, 1999 1:49 AM
> To:	Alan Lloyd
> Cc:	ietf-pkix@imc.org
> Subject:	RE: CA vs. EE cert processing
> 
> Alan,
> 
> I disagree. There is no obvious reason for this base standard to allow
> for
> this ambiguity.   This is not a problem that is out of scope for the
> base
> standard.  we agree, though, that adherence to the 2459 profile
> advoids
> ambiguity.  The reason for this debate is that some folks felt the
> ambiguity was the fault of 2459, whereas the analysis shows it to be
> intrinsic in X.509.  Thus no fix to 2459 will remove the ambiguity.
> 
> steve