Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 390536 - Cert validation functions must validate leaf cert themselves
: Cert validation functions must validate leaf cert themselves
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: trunk
: All All
: P1 enhancement (vote)
: 3.12
Assigned To: Alexei Volkov
Depends on:
  Show dependency treegraph
Reported: 2007-08-01 14:53 PDT by Alexei Volkov
Modified: 2008-03-26 15:16 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description Alexei Volkov 2007-08-01 14:53:37 PDT
EE cert is not check for valid date, valid key usage, eku.

libpkix only checks leaf for revocation.
Comment 1 Julien Pierre 2007-08-01 15:09:46 PDT

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 ?
Comment 2 Alexei Volkov 2007-08-01 15:59:49 PDT
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 3 Nelson Bolyard (seldom reads bugmail) 2007-08-01 18:47:58 PDT
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.
Comment 4 Nelson Bolyard (seldom reads bugmail) 2007-08-28 12:56:08 PDT
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.
Comment 5 Alexei Volkov 2007-09-18 15:01:42 PDT
this bug is fixed by patch to bug 390888, when we start using libpkix wrapper as a  substitution to CERT_VerifyCertChain function.
Comment 6 Steve Parkinson 2007-10-18 08:49:07 PDT
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
the leaf.
Comment 7 Nelson Bolyard (seldom reads bugmail) 2007-10-18 09:39:28 PDT
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 
the purpose.  

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.
Comment 8 Alexei Volkov 2007-10-18 10:00:10 PDT
I believe leaf policy OIDs are checked as a part of cert chain verification process, which happens in pkix_CheckChain.
Comment 9 Steve Parkinson 2007-10-18 10:27:29 PDT
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

Comment 10 Alexei Volkov 2007-10-18 11:30:48 PDT
Steve, please reopen the bug if you find that leaf cert is not checked for policy OIDs.
Comment 11 Kai Engert (:kaie) 2008-03-26 15:16:34 PDT
This bug sounds related to bug 408903

Note You need to log in before you can comment on or make changes to this bug.