다음을 통해 공유


PKI Enhancements in Windows Vista and Windows Server 2008

I’m Avi Ben-Menahem, the lead program manager for the PKI and smart card technologies in Windows Security. The PKI (Public Key Infrastructure) team in Microsoft is responsible for the different technologies related to digital certificates, these technologies and products include the CA (Certificate Authority), the client enrollment API and UI, OCSP (Online Certificate Status Protocol) Responder, SCEP (Simple Certificate Enrollment Protocol) and the smart card subsystem in Windows.

 In Windows Vista and Windows Server 2008 the PKI team focused on 4 main investments pillars:

1. Crypto enhancements - it was not an easy task, but I'm proud to say that the Microsoft crypto and PKI platform now supports the most advanced crypto algorithms such as ECC and the SHA-2 hashing alg family out of the box. The Microsoft CA can now issue ECC certificates and the Microsoft client can enroll and validate ECC and SHA-2 based certificates. Moreover, the platform is now dynamic enough to allow plugability of new algorithms much easily than before. The use of the new crypto and hash algorithms will be mandated by the US government as well as some of the European governments in the next few years making the OS support key for Microsoft PKI success in those market segments.

2. Revocation enhancements - In the revocation space we've made significant improvements. OCSP (Online Certificate Status Protocol) is now supported natively in the Windows platform. The OCSP client is included as part of Windows Vista and Windows Server 2008 and a new OCSP Responder is available as part of the Certificate Server role. Additional revocation checking enhancements such as CRL pre-fetching, OCSP response stapling and CAPI diagnostics are also introduced to improve our PKI revocation story as well as to improve the user experience when using PKI-aware applications. Revocation was always one of the biggest problems in PKI, especially in the internet age. Introducing OCSP and enhancing the revocation platform will significantly assist deploying PKI for such large scale scenarios.

3. Management and monitoring - this topic has been a major pain point in the past and we invested significant efforts on the server side to improve that experience. We made it real easy for administrators to deploy PKI and to manage their PKI from a single console. A new CA MOM Pack was created, the CA was armed with a bunch of new performance counters, and the PKI View monitoring console was added to the server default setup. Most important, the CA setup was written from scratch to allow simple and easy deployment of the CA and now provides "one click setup" for deploying the CA.

4. Certificate Services Client - on the client side of the Microsoft PKI we focused on both the UX (User experience) and on the developer experience. A completely new set of developer enrollment API is introduced (CertEnroll). This new COM based library replaces the legacy XEnroll library which been around for a long time and provides an OO developer experience and the ability to practically modify any request extension or attribute. Pretty powerful stuff. By doing that we ensure we give the proper developer support to enable PKI-Aware applications development.

Again, this is just a high level overview of the work we've done. Want to read more? See https://www.microsoft.com/downloads/details.aspx?FamilyID=9bf17231-d832-4ff9-8fb8-0539ba21ab95&displaylang=en .

- Avi Ben-Menahem

Comments

  • Anonymous
    June 04, 2007
    PingBack from http://www.andrewhay.ca/archives/136

  • Anonymous
    January 03, 2008
    Does the 2008 SCEP server have any changes?  Specifically, I was hoping for support for the getcachain command and several other newer features since draft 13 of the SCEP protocol. Does the OCSP responder support acting as a relay for scalability? In Vista, how does one access the OCSP client?  Can it be called programmatically through C# .Net 3.5 or somehow via WCF in .Net 3.5?

  • Anonymous
    January 11, 2008
    I am interest in whether or not the OCSP client is configurable. In large scale deployments the OCSP Responder/Repeater IP addresses are not know at the time of certificate issuance. Can the client be configured to point to an IP rather than relying on the information provided in the certificate itself?

  • Anonymous
    August 11, 2008
    The comment has been removed