RE: CA vs. EE cert processing

[Stephen Kent <kent@xxxxxxxxxxx>]

Alan,

>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..

No argument about what the CA and relying parties should do.  Of course, in
practice the latter tend not to do all of what is nominally required.

>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.

Each part is trusted relative to its functions, yes.

>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.

Ah, now I see your point.  You are suggesting that while X.509 was not in
error for not requiring CAs to mark CA certs, even when they are v3 certs,
because one might build a system that relied upon the CAs, and all EEs, not
doing the wrong thing.  Note that one has to rely on all CAs and EEs since
otherwise an EE can take advantage of the lack of marking to pretend it is
a CA.  This is an unwise basis on which to build a system, from a security
perspective, and thus I do fault X.509, despite your description of a
context in which the ambuguity might be mitigated.

>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.

Yes, that's right, and that's what 2459 already says.

Steve