[MS-ICPR]:
ICertPassage Remote Protocol
Intellectual Property Rights Notice for Open Specifications Documentation
Technical Documentation. Microsoft publishes Open Specifications documentation (“this documentation”) for protocols, file formats, data portability, computer languages, and standards support. Additionally, overview documents cover inter-protocol relationships and interactions.
Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you can make copies of it in order to develop implementations of the technologies that are described in this documentation and can distribute portions of it in your implementations that use these technologies or in your documentation as necessary to properly document the implementation. You can also distribute in your implementation, with or without modification, any schemas, IDLs, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications documentation.
No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation.
Patents. Microsoft has patents that might cover your implementations of the technologies described in the Open Specifications documentation. Neither this notice nor Microsoft's delivery of this documentation grants any licenses under those patents or any other Microsoft patents. However, a given Open Specifications document might be covered by the Microsoft Open Specifications Promise or the Microsoft Community Promise. If you would prefer a written license, or if the technologies described in this documentation are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting .
License Programs. To see all of the protocols in scope under a specific license program and the associated patents, visit the Patent Map.
Trademarks. The names of companies and products contained in this documentation might be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. For a list of Microsoft trademarks, visit
Fictitious Names. The example companies, organizations, products, domain names, email addresses, logos, people, places, and events that are depicted in this documentation are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.
Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than as specifically described above, whether by implication, estoppel, or otherwise.
Tools. The Open Specifications documentation does not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments, you are free to take advantage of them. Certain Open Specifications documents are intended for use in conjunction with publicly available standards specifications and network programming art and, as such, assume that the reader either is familiar with the aforementioned material or has immediate access to it.
Support. For questions and support, please contact .
Revision Summary
Date / Revision History / Revision Class / Comments3/2/2007 / 1.0 / New / Version 1.0 release
4/3/2007 / 1.1 / Minor / Version 1.1 release
5/11/2007 / 1.2 / Minor / Version 1.2 release
6/1/2007 / 1.2.1 / Editorial / Changed language and formatting in the technical content.
7/3/2007 / 1.2.2 / Editorial / Changed language and formatting in the technical content.
8/10/2007 / 2.0 / Major / IDL was updated.
9/28/2007 / 2.0.1 / Editorial / Changed language and formatting in the technical content.
10/23/2007 / 3.0 / Major / Converted document to unified format and updated technical content.
1/25/2008 / 3.0.1 / Editorial / Changed language and formatting in the technical content.
3/14/2008 / 3.0.2 / Editorial / Changed language and formatting in the technical content.
6/20/2008 / 4.0 / Major / Updated and revised the technical content.
7/25/2008 / 4.0.1 / Editorial / Changed language and formatting in the technical content.
8/29/2008 / 4.0.2 / Editorial / Fix capitalization issues.
10/24/2008 / 4.0.3 / Editorial / Changed language and formatting in the technical content.
12/5/2008 / 4.0.4 / Editorial / Editorial Update.
1/16/2009 / 4.0.5 / Editorial / Changed language and formatting in the technical content.
2/27/2009 / 4.0.6 / Editorial / Changed language and formatting in the technical content.
4/10/2009 / 5.0 / Major / Updated and revised the technical content.
5/22/2009 / 5.0.1 / Editorial / Changed language and formatting in the technical content.
7/2/2009 / 6.0 / Major / Updated and revised the technical content.
8/14/2009 / 6.0.1 / Editorial / Changed language and formatting in the technical content.
9/25/2009 / 6.1 / Minor / Clarified the meaning of the technical content.
11/6/2009 / 6.1.1 / Editorial / Changed language and formatting in the technical content.
12/18/2009 / 6.1.2 / Editorial / Changed language and formatting in the technical content.
1/29/2010 / 7.0 / Major / Updated and revised the technical content.
3/12/2010 / 8.0 / Major / Updated and revised the technical content.
4/23/2010 / 9.0 / Major / Updated and revised the technical content.
6/4/2010 / 10.0 / Major / Updated and revised the technical content.
7/16/2010 / 11.0 / Major / Updated and revised the technical content.
8/27/2010 / 12.0 / Major / Updated and revised the technical content.
10/8/2010 / 12.1 / Minor / Clarified the meaning of the technical content.
11/19/2010 / 13.0 / Major / Updated and revised the technical content.
1/7/2011 / 13.0 / None / No changes to the meaning, language, or formatting of the technical content.
2/11/2011 / 13.0 / None / No changes to the meaning, language, or formatting of the technical content.
3/25/2011 / 14.0 / Major / Updated and revised the technical content.
5/6/2011 / 14.0 / None / No changes to the meaning, language, or formatting of the technical content.
6/17/2011 / 14.1 / Minor / Clarified the meaning of the technical content.
9/23/2011 / 15.0 / Major / Updated and revised the technical content.
12/16/2011 / 16.0 / Major / Updated and revised the technical content.
3/30/2012 / 16.0 / None / No changes to the meaning, language, or formatting of the technical content.
7/12/2012 / 16.1 / Minor / Clarified the meaning of the technical content.
10/25/2012 / 16.1 / None / No changes to the meaning, language, or formatting of the technical content.
1/31/2013 / 16.1 / None / No changes to the meaning, language, or formatting of the technical content.
8/8/2013 / 17.0 / Major / Updated and revised the technical content.
11/14/2013 / 17.0 / None / No changes to the meaning, language, or formatting of the technical content.
2/13/2014 / 17.0 / None / No changes to the meaning, language, or formatting of the technical content.
5/15/2014 / 17.0 / None / No changes to the meaning, language, or formatting of the technical content.
6/30/2015 / 18.0 / Major / Significantly changed the technical content.
10/16/2015 / 18.0 / None / No changes to the meaning, language, or formatting of the technical content.
7/14/2016 / 19.0 / Major / Significantly changed the technical content.
6/1/2017 / 19.0 / None / No changes to the meaning, language, or formatting of the technical content.
9/15/2017 / 20.0 / Major / Significantly changed the technical content.
Table of Contents
1Introduction
1.1Glossary
1.2References
1.2.1Normative References
1.2.2Informative References
1.3Overview
1.4Relationship to Other Protocols
1.5Prerequisites and Preconditions
1.6Applicability Statement
1.7Versioning and Capability Negotiation
1.8Vendor-Extensible Fields
1.9Standards Assignments
2Messages
2.1Transport
2.2Common Data Types
2.2.1Request Format
2.2.2Response Format
3Protocol Details
3.1ICertPassage Client Details
3.1.1Abstract Data Model
3.1.2Timers
3.1.3Initialization
3.1.4Message Processing and Sequencing Rules
3.1.4.1Processing ICertPassage:: CertServerRequest
3.1.5Timer Events
3.1.6Other Local Events
3.2ICertPassage Server Details
3.2.1Abstract Data Model
3.2.2Timers
3.2.3Initialization
3.2.4Message Processing and Sequencing Rules
3.2.4.1ICertPassage Interface
3.2.4.1.1CertServerRequest (Opnum 0)
3.2.5Timer Events
3.2.6Other Local Events
4Protocol Examples
5Security
5.1Security Considerations for Implementers
5.2Index of Security Parameters
6Appendix A: Full IDL
7Appendix B: Product Behavior
8Change Tracking
9Index
1Introduction
This document specifies the ICertPassage Remote Protocol. This protocol is a subset of the Windows Client Certificate Enrollment Protocol, as specified in [MS-WCCE]. The difference between this protocol and the Windows Client Certificate Enrollment Protocol is that this protocol only allows the client to enrollcertificates, whereas the Windows Client Certificate Enrollment Protocol provides enrollment and additional functionality, such as the capability to read certification authority (CA) data and configuration information. Reading and understanding the Windows Client Certificate Enrollment Protocol, as specified in [MS-WCCE], is essential to understanding the ICertPassage Remote Protocol.
Sections 1.5, 1.8, 1.9, 2, and 3 of this specification are normative. All other sections and examples in this specification are informative.
1.1Glossary
This document uses the following terms:
Active Directory: A general-purpose network directory service. Active Directory also refers to the Windows implementation of a directory service. Active Directory stores information about a variety of objects in the network. User accounts, computer accounts, groups, and all related credential information used by the Windows implementation of Kerberos are stored in Active Directory. Active Directory is either deployed as Active Directory Domain Services (AD DS) or Active Directory Lightweight Directory Services (AD LDS). [MS-ADTS] describes both forms. For more information, see [MS-AUTHSOD] section 1.1.1.5.2, Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Kerberos, and DNS.
certificate: A certificate is a collection of attributes and extensions that can be stored persistently. The set of attributes in a certificate can vary depending on the intended usage of the certificate. A certificate securely binds a public key to the entity that holds the corresponding private key. A certificate is commonly used for authentication and secure exchange of information on open networks, such as the Internet, extranets, and intranets. Certificates are digitally signed by the issuing certification authority (CA) and can be issued for a user, a computer, or a service. The most widely accepted format for certificates is defined by the ITU-T X.509 version 3 international standards. For more information about attributes and extensions, see [RFC3280] and [X509] sections 7 and 8.
certificate enrollment: The process of acquiring a digital certificate from a certificate authority (CA), which typically requires an end entity to first makes itself known to the CA (either directly, or through a registration authority). This certificate and its associated private key establish a trusted identity for an entity that is using the public key–based services and applications. Also referred to as simply "enrollment".
certification authority (CA): A third party that issues public keycertificates. Certificates serve to bind public keys to a user identity. Each user and certification authority (CA) can decide whether to trust another user or CA for a specific purpose, and whether this trust should be transitive. For more information, see [RFC3280].
client: A computer on which the remote procedure call (RPC) client is executing.
digital signature: A value that is generated by using a digital signature algorithm, taking as input a private key and an arbitrary-length string, such that a specific verification algorithm is satisfied by the value, the input string, and the public key corresponding to the input private key.
Distributed Component Object Model (DCOM): The Microsoft Component Object Model (COM) specification that defines how components communicate over networks, as specified in [MS-DCOM].
dynamic endpoint: A network-specific server address that is requested and assigned at run time. For more information, see [C706].
endpoint: A network-specific address of a remote procedure call (RPC) server process for remote procedure calls. The actual name and type of the endpoint depends on the RPC protocol sequence that is being used. For example, for RPC over TCP (RPC Protocol Sequence ncacn_ip_tcp), an endpoint might be TCP port 1025. For RPC over Server Message Block (RPC Protocol Sequence ncacn_np), an endpoint might be the name of a named pipe. For more information, see [C706].
endpoint mapper: A service on a remote procedure call (RPC) server that maintains a database of dynamic endpoints and allows clients to map an interface/object UUID pair to a local dynamic endpoint. For more information, see [C706].
enroll: To request and acquire a digital certificate from a certificate authority (CA). This is typically accomplished through a certificate enrollment process.
private key: One of a pair of keys used in public-key cryptography. The private key is kept secret and is used to decrypt data that has been encrypted with the corresponding public key. For an introduction to this concept, see [CRYPTO] section 1.8 and [IEEE1363] section 3.1.
public key: One of a pair of keys used in public-key cryptography. The public key is distributed freely and published as part of a digital certificate. For an introduction to this concept, see [CRYPTO] section 1.8 and [IEEE1363] section 3.1.
public-private key pair: The association of a public key and its corresponding private key when used in cryptography. Also referred to simply as a "key pair". For an introduction to public-private key pairs, see [IEEE1363] section 3.
remote procedure call (RPC): A context-dependent term commonly overloaded with three meanings. Note that much of the industry literature concerning RPC technologies uses this term interchangeably for any of the three meanings. Following are the three definitions: (*) The runtime environment providing remote procedure call facilities. The preferred usage for this meaning is "RPC runtime". (*) The pattern of request and response message exchange between two parties (typically, a client and a server). The preferred usage for this meaning is "RPC exchange". (*) A single message from an exchange as defined in the previous definition. The preferred usage for this term is "RPC message". For more information about RPC, see [C706].
RPC endpoint: A network-specific address of a server process for remote procedure calls (RPCs). The actual name of the RPC endpoint depends on the RPC protocol sequence being used. For example, for the NCACN_IP_TCP RPC protocol sequence an RPC endpoint might be TCP port 1025. For more information, see [C706].
server: A computer on which the remote procedure call (RPC) server is executing.
universally unique identifier (UUID): A 128-bit value. UUIDs can be used for multiple purposes, from tagging objects with an extremely short lifetime, to reliably identifying very persistent objects in cross-process communication such as client and server interfaces, manager entry-point vectors, and RPC objects. UUIDs are highly likely to be unique. UUIDs are also known as globally unique identifiers (GUIDs) and these terms are used interchangeably in the Microsoft protocol technical documents (TDs). Interchanging the usage of these terms does not imply or require a specific algorithm or mechanism to generate the UUID. Specifically, the use of this term does not imply or require that the algorithms described in [RFC4122] or [C706] must be used for generating the UUID.
well-known endpoint: A preassigned, network-specific, stable address for a particular client/server instance. For more information, see [C706].
MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.
1.2References
Links to a document in the Microsoft Open Specifications library point to the correct section in the most recently published version of the referenced document. However, because individual documents in the library are not updated at the same time, the section numbers in the documents may not match. You can confirm the correct section numbering by checking the Errata.
1.2.1Normative References
We conduct frequent surveys of the normative references to assure their continued availability. If you have any issue with finding a normative reference, please contact . We will assist you in finding the relevant information.
[C706] The Open Group, "DCE 1.1: Remote Procedure Call", C706, August 1997,
[MS-CRTD] Microsoft Corporation, "Certificate Templates Structure".
[MS-CSRA] Microsoft Corporation, "Certificate Services Remote Administration Protocol".
[MS-DCOM] Microsoft Corporation, "Distributed Component Object Model (DCOM) Remote Protocol".
[MS-DTYP] Microsoft Corporation, "Windows Data Types".
[MS-RPCE] Microsoft Corporation, "Remote Procedure Call Protocol Extensions".
[MS-WCCE] Microsoft Corporation, "Windows Client Certificate Enrollment Protocol".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997,
[RFC2797] Myers, M., Liu, X., Schaad, J., and Weinstein, J., "Certificate Management Messages Over CMS", RFC 2797, April 2000,
[RFC2986] Nystrom, M. and Kaliski, B., "PKCS#10: Certificate Request Syntax Specification", RFC 2986, November 2000,
[RFC3280] Housley, R., Polk, W., Ford, W., and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002,
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004,
[UNICODE4.0] The Unicode Consortium, "Unicode 4.0.0",
[X509] ITU-T, "Information Technology - Open Systems Interconnection - The Directory: Public-Key and Attribute Certificate Frameworks", Recommendation X.509, August 2005,
[X660] ITU-T, "Information Technology - Open Systems Interconnection - Procedures for the Operation of OSI Registration Authorities: General Procedures and Top Arcs of the ASN.1 Object Identifier Tree", Recommendation X.660, August 2004,
[X690] ITU-T, "Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", Recommendation X.690, July 2002,
1.2.2Informative References
None.
1.3Overview
The ICertPassage Remote Protocol exposes a Remote Procedure Call (RPC) (as specified in [MS-RPCE]) interface that allows a client to interact with a certification authority (CA) to request and receive X.509 certificates (as specified in [X509]) from the CA. The ICertPassage Remote Protocol only provides certificate enrollment functionality. The Windows Client Certificate Enrollment Protocol (as specified in [MS-WCCE]) provides a larger set of functionality, including reading CA data and configuration information. The certificate enrollment process and protocol overview are as specified in [MS-WCCE] section 1.3.
The ICertPassage interface defines one method: CertServerRequest(section3.2.4.1.1).
1.4Relationship to Other Protocols
The ICertPassage Remote Protocol depends on the Remote Procedure Call Protocol Extensions, as specified in [MS-RPCE]. No other Windows protocol depends on the ICertPassage Remote Protocol. The following diagram shows the layering of the protocol stack.
Figure 1: ICRP Protocol Stack
The ICertPassage Remote Protocol shares ADM elements with Windows Client Certificate Enrollment Protocol [MS-WCCE] as specified in section 3.1.1 and section 3.2.1. The ICertPassage Remote Protocol, the Certificate Services Remote Administration Protocol, and the Windows Client Certificate Enrollment Protocol use a common list of configuration data elements, defined in [MS-WCCE] section 3.2.1.1.4.
1.5Prerequisites and Preconditions
The ICertPassage Remote Protocol has the same prerequisites as the Windows Client Certificate Enrollment Protocol, as specified in [MS-WCCE] section 1.5.