Suppose we have the hierarchical trust model as seen below.
Alice will trust Doris' public key iff there is a Certifcation Path from her to Doris. Alice thus pocesses a valid certificate of A.
Does Alice need to have a certificate of D, B and C as well? What happens if Alice explicitly does not trust C. Will she trust Doris, because Doris is indirectly certified by A?
Thanks
I think you need to be more specific about what you mean by "What happens if Alice explicitly does not trust C." Alice, and only Alice, has decided not to trust C, or A has revoked C's certificate?
My understanding of Alice's (abstract) process is:
// find a signature that she can verify
1. Alice will see that cert_Doris is signed by cert_C and ask "do I have a verification key for cert_C?" .... No.
2. cert_C is signed by cert_A, "do I have a verification key for cert_A?" ... Yes.
// then go back down the chain actually performing verifications
3. Does the signature on cert_A check out, and is the certificate valid (ie not revoked)? ... Yes
4. Does the signature on cert_C check out, and is the certificate valid (ie not revoked)? ... Yes
5. Does the signature on cert_Doris check out, and is the certificate valid (ie not revoked)? ... Yes
6. Now Alice trusts Doris because they have a common anchor of trust.
The details of this process will obviously depend on which PKI software your organization uses.
As @MaartenBodewes points out: notice that this process does not require Alice to be connected to A, in fact, that process would work fine for Eric who doesn't even have certificates himself, as long as he has decided to trust A. (This is how certificate pinning in browsers works, since TLS clients typically don't have certificates, they are like Eric.)
As for
What happens if Alice explicitly does not trust C.
It's entirely possible that your PKI software will allow Alice (or any of the CAs above Alice) to blacklist a specific user, or a specific CA, without globally revoking their certificate, though I've never actually heard of a PKI which offers that.
As for
Does Alice need to have a certificate of D, B and C as well?
Technically no, having the verification key for A is cryptographically sufficient, though for large organizations, like a government, with many many departmental CAs and users, doing a full search every time can be very slow, so Alice may locally cache certificates once she's deemed them trustworthy so that future searches are faster. This could lead to security problems if revocation is not checked all the way back to the root each time. That's up to the specific software, and the organization's policies to decide if that risk is worth the inconvenience of slow searches.
The whole idea that there needs to be a path from Alice to Doris is incorrect. There just needs to be a valid certificate chain from Doris to a trusted certificate in the trust store of Alice. And Doris - of course - needs to prove that she has the private key that belongs to the certificate of Doris herself.
So all Alice requires is a trusted certificate A or C. She needs to retrieve all intermediate certificates if she doesn't have a full chain (if she just has A she needs to retrieve C - usually it is send to Alice by Doris). She needs to be able to verify the signature for the certificates and the validity of the certificates in the chain. The validation procedure may check key usage, key extensions, validity period and of course certificate status/revocation etc. The chain may also consist of just the certificate of Doris if that is trusted directly (certificate pinning).
Finally the signature of the private key needs to be verified using the public key of Doris certificate. Or the private key may be need to be used to decrypt a challenge or session key.
Alice doesn't even need a certificate / private key herself. Currently my browser doesn't have my certificate either. Only those entities that are required to authenticate themselves have to have a private key and corresponding certificate.
