EE cert is not check for valid date, valid key usage, eku.
libpkix only checks leaf for revocation.
Are you certain about that ?
There is code in pkix_pl_ekuchecker.c to check the EKU, code in pkix_pl_cert.c to check key usage and validity .
Is this not specifically not happening on the EE but on other certs ?
it does not check leaf cert only. All others get checked as a part of pkix_BuildForwardDepthFirstSearch. Caller of pkix_BuildForwardDepthFirstSearch does not check the cert and sets state->status to BUILD_INITIAL that makes libpkix to search for an issuer of leaf cert without it validation. Chain building should probably start from state->status = BUILD_CERTVALIDATING to validate the leaf.
comment 0 seems like two separate bug reports:
a) EE certs not checked for validity, key usage, etc.
b) CA certs not checked for revocation.
Those are independent problems. Please file another bug for the latter.
I corresponded with some other folks about this issue. They stated that
RFC 3280's cert patch validation algorithm assumes that the caller has
already tested that the leaf certs meets its expectations. They stated
that the algorithm as stated in RFC 3280 does not validate the leaf cert
except to show that it does or does not chain to a trust anchor. They
stated that the Java code that calls the Java version of libPKIX always
checks the leaf cert itself first. So, I think that's the right thing
for our CERT_* verification functions to do, rather than trying to change
libPKIX itself to do that.
Note that this requirement affects all our "wrapper" functions, including
the old CERT_VreifyCert* functions, CERT_VerifyCACertForUsage, and also
our NEW function that Kai, Steve and Bob are working on in bug 294531.
this bug is fixed by patch to bug 390888, when we start using libpkix wrapper as a substitution to CERT_VerifyCertChain function.
Can you explain this a little? I don't see where you're calling any functions
to check the leaf. I see that you're calling cert_ProcessingParamsSetKuAndEku()
to set the KU and EKU, but doesn't that just check that the issuer chain is
valid, not the leaf?
FYI, we can add policy OIDs to the list of things that PKIX is not checking in
Steve, The 4 old public CERT_VerifyCert* functions
all check that the leaf meets their criteria, then they call
CERT_VerifyCertChain to check that it chains to a trust anchor trusted for
When we set out to replace the old CERT_Verify code with libPKIX, we
initially attempted to replace all 4 of those functions with code that
merely calls libPKIX (see the early patches for bug 390888). Then we
discovered that libPKIX wasn't doing any checks on the leaf. To fix that,
we completely changed our approach. We left the four functions intact,
and instead we changed CERT_VerifyCertChain to call libPKIX. So, by the
time CERT_VerifyCertChain has been called, the leaf checking is all done
(apart from the signature, which is checked using the issuer cert). That
takes care of all the old CERT_VerifyCert* functions.
So, now this bug applies mostly to the new CERT_PKIXVerifyCert function(s).
If those functions make the same mistaken assumption that we initially
made when we tried to replace the 4 functions named above, namely that
the PKIX code will check the leaf cert for suitability for the caller's
purpose, then it will have the same flaw as our initial implementation
of the replacements for those 4 functions, before we changed it.
This bug now serves to remind us that the new CERT_PKIXVerifyCert function(s)
must do all the relevant checks on the leaf cert itself, and not rely on
libPKIX to do any of them. Maybe that function does all the leaf checking
already, or maybe not. If not, this bug should be reopened (IMO) until
CERT_PKIXVerifyCert does all the necessary parts.
I believe leaf policy OIDs are checked as a part of cert chain verification process, which happens in pkix_CheckChain.
Thanks for the comments nelson. Now I understand.
Alexei - I've been stepping through pkix_CheckChain, and although the
pkix_PolicyChecker_Check() function does get called for the leaf, it
doesn't actually compare the OID. I will go through it again to figure out
Steve, please reopen the bug if you find that leaf cert is not checked for policy OIDs.
This bug sounds related to bug 408903