> > Ahh, that explains it. Thanks for looking into it.
> >
> > The documentation on iCRLs was a little cryptic to me. It said that no
> > lookup methods were used (?). Now you say the store is also not used.
> How
> > do I get the iCRL into the verification process? Also, does the current
> > 1.0.0 icrl code enforce the "same trust-anchor" method of tying iCRL
> issuer
> > to the CA it is revoking for?
> >
>
> You can get CRLs into the process using X509_STORE_CTX_set0_crls(). As
Hmmm... my code does that but I get 'Different CRL Scope' on the SNAP from the
26th.
> indicated in the docs, some protocols (PKCS#7 and CMS) do this
> automatically.
>
A pkcs7 with crls in the container will automatically use them? Cool. How do
you tell the p7 verify function when you want to require crl checking for each
cert in the chain (X509_V_FLAG_CRL_CHECK_ALL) and when you just want EE
checking. Also, this raises another question. I was using P7's without data
as nice 'identity chain containers' (.p7c files) rather than concatenated PEM
files. Of course I have to unpack them to verify the identity. The docs make
the p7 verify function seem to be basically about the data:
The type of p7 must be signedData. There must be at least one signature
on the data and if the content is detached indata cannot be NULL.
If I call p7 verify with PKCS7_NOSIGS can I verify an "empty" p7 that has only
certs and crls?
> At some point indirect CRL lookup using stores will be included too. The
> indirect CRL code though is very new and (apart from the PKITS tests)
> untested.
>
> Yes it does include the same trust anchor requirement of RFC5280. Some
> security concerns have been raise on the PKIX mailing lists about the
> possibilities of unathorised CRLs being accepted in some scenarios which
> is
> why the indirect CRL checking is disabled by default.
Yes, I'd been following that conversation, which is why I asked. With Name
Constraints in any CA outside our direct control I think that would not be an
issue.
>
> > I'd be happy to help continue testing indirect CRLs, as they are a
> feature
> > we would like. We have root and first-level intermediate CA's on
> smartcards
> > "offline" (in a safe) because they are infrequently used. We would like
> to
> > have a single indirect CRL issuer (issued by root) so we can require
> full
> > chain CRL checking AND enforce timely updates to the CRL's while keeping
> our
> > infrequently used private keys out of normal circulation.
> >
> >
>
> Having a single CRL might cause problems with circular dependencies. There
> was
> a PKITS test that included this but it was later marked as not being
> required.
>
> It's a case of how you issue a CRL for the indirect CRL issuer. If
> it issues a CRL covering itself then it is effectively indicating its own
> validity. In the case of the indirect CRL issuer private key being
> compromised
> that is of course not trustworthy.
>
I'd considered this too. It is tricky. I think our solution will be something
like this: Have your iCRL crldp=root. Pre-generate a year's worth of daily
empty crls for root, keep them fairly secure. You dole them out to the
directory/web server on a daily basis, unless there is a compromise of the one
lynchpin key (iCRL issuer's key). That warrants a trip to the safe....
Of course, if you think that level 1 CA compromises (root is level 0) are
equally rare as iCRL key compromises, then I guess you could say this method
obviates the need for an indirect crl issuer for the L1 CA's.....
> Steve.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
