Hi I'm working on a Proof of Concept for a 3 tier PKI solution, all tiers will be standalone with no Active Directory membership (security constraint). I have a requirement to provide access to CRLs using 3 methods, SCEP, HTTP and LDAP. SCEP and HTTP I'm fairly happy with, it the LDAP component I'm not so sure. I plan to stand up a AD LDS instance to act as a CDP, but I'm not entire sure whether a standalone AD LDS instance can act as a CDP? As there appears to be very little information out there, I appreciate there is some info on publishing or retrieving CRLs, but does anyone have any pointers for setting up an instance as a CDP with anonymous read requests (network routers required to read CDP) and controlled write operations. Any guidance would be much appreciated. Thanks Stuart

Martin This is most helpful and extremely thorough. I'll work off your comments and report back as further reference for other. Regards Stuart

The latest best practice recommends using a single highly available HTTP-based CDP for revocation and avoiding LDAP altogether: http://technet.microsoft.com/en-us/library/ee619730(v=ws.10).aspx This could make you life a bit easier :) Cheers JJ Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

I definitely agree, however there are situations where best practices are not applicable. If the LDAP CDP is not striclty required I would also recommend to drop it and use a single HTTP based CDP instead. Regards Martin

Jason Thanks for your post, most helpful. I was aware of the latest best practise, however, I have a security constraint that dictates SCEP, HTTP and LDAP for CDP. Failing to deliver all 3 components would result is failed accreditation, and a failed service offering. Personally I think there is a place for simplification and the use of a single CDP - but unfortunately I have a compliance document to follow! Regards Stuart

One minor correction, SCEP can be used also to query for CRLs, (not sure if this is true for NDES though). For more information see http://www.cisco.com/warp/public/707/crl-ca-scep-qa.pdf or http://tools.ietf.org/html/draft-nourse-scep-23#page-14 However I haven't seen this in practice yet. Regards Martin

Yeah, I'm not sure NDES provides that though as it seems quite a simple implementation of SCEP. I've never seen any customers use it that way, it is always used for enrollment and hence you still need to define your standard CDPs using HTTP and/or LDAP. Anyhow, apologies for spoiling Tipster, be interesting to hear how you get on though! Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

SCEP/NDES is indeed an interesting statement. The originator of the policy document doesn't explicitly reference the use of NDES as there is no direct steer towards a particular technology, so SCEP is referenced. Obviously NDES is the MS implementation of SCEP, so I'm hoping that I can either question the statement or provide a partial success of CRL recovery. From early tests with a particular vendor, it appears that during the enrolment process a CRL is recovered - however, there is some uncertainty as to whether the single CRL relating to the issuing CA server is recovered using NDES or HTTP; something I have to test further. Thank you for the ongoing discussion, this is most helpful. And apologies for the vague aspects of my post!