I've come across what seems to be a strange quirk with CERT_PKIXVerifyCert():
Start with a local keystore that contains an end-cert and a completely
unrelated CA cert ...
- receive an unknown blob (DER) over the wire (it's the same end-cert
but lets pretend we don't know this)
- convert the blob into a cert using:
CERTCertificate *cert = CERT_NewTempCertificate(handle, &der_cert,
NULL /*nickname*/,
PR_FALSE /*isperm*/,
PR_TRUE /* copyDER */);
- call CERT_PKIXVerifyCert() with:
/* in */
cert_pi_trustAnchors = completely unrelated cert with
CERT_IsCACert() && .isRoot
cert_pi_useOnlyTrustAnchors = PR_TRUE
/* I don't think the rest matter but */
cert_pi_useAIACertFetch = PR_FALSE
cert_pi_revocationFlags = crl_strict: 0, ocsp: 0, ocsp_strict: 0,
ocsp_post: 0 (I think)
/* out */
cert_po_errorLog = ...
cert_po_trustAnchor = ...
[cert_po_certList =
it then returns:
SECSuccess
cert_po_errorLog.count = 0
cert_po_trustAnchor = NULL
so I try a few variations:
- local key store that contains the end-cert and no root cert at all:
same result
- local key store that contains the end-cert and the end cert's CA
which is passed in: same result
however, if the local key store does not contain the end-cert, then
the unknown blob is only accepted when cert_pi_trustAnchors has the
correct CA
Perhaps my code is broken, but it would appear that provided the DER
blob fed into CERT_NewTempCertificate() is already in the NSS DB, it
is trusted implicitly? I guess if the trust anchor comes back NULL I
interpret this as trust established because the cert's already in the
local DB.
--
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
