Chapter 3. Supported Standards and Protocols Red Hat Certificate System is based on many public and standard protocols and RFCs, to ensure the best possible performance and interoperability. The major standards and protocols used or supported by Certificate System 10 are outlined in this chapter, to help administrators plan their client services effectively. 3.1. TLS, ECC, and RSA The Transport Layer Security (TLS) protocol is an universally accepted standard for authenticated and encrypted communication between clients and servers. Both client and server authentication occur over TLS. TLS uses a combination of public-key and symmetric-key encryption. Symmetric-key encryption is much faster than public-key encryption, but public-key encryption provides better authentication techniques. An TLS session always begins with an exchange of messages called handshake , initial communication between the server and client. The handshake allows the server to authenticate itself to the client using public-key techniques, optionally allows the client to authenticate to the server, then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and integrity verification during the session that follows. TLS supports a variety of different cryptographic algorithms, or ciphers , for operations such as authenticating the server and client, transmitting certificates, and establishing session keys. Clients and servers may support different cipher suites, or sets of ciphers. Among other functions, the handshake determines how the server and client negotiate which cipher suite is used to authenticate each other, to transmit certificates, and to establish session keys. Key-exchange algorithms like RSA and Elliptic Curve Diffie-Hellman (ECDH) govern the way the server and client determine the symmetric keys to use during an TLS session. TLS supports ECC (Elliptic Curve Cryptography) cipher suites, as well as RSA. The Certificate System supports both RSA and ECC public-key cryptographic systems natively. In more recent practise, key-exchange algorithms are being superseded by key-agreement protocols where each of the two or more parties can influence the outcome when establishing a common key for secure communication. Key agreement is preferrable to key exchange because it allows for Perfect Forward Secrecy (PFS) to be implemented. When PFS is used, random public keys (also called temporary cipher parameters or ephemeral keys ) are generated for each session by a non-deterministic algorithm for the purposes of key agreement. As a result, there is no single secret value which could lead to the compromise of multiple messages, protecting past and future communication alike. 3.1.1. Supported cipher suites Cipher and hashing algorithms are in a constant flux with regard to various vulnerabilities and security strengths. As a general rule, Red Hat Certificate System follows the NIST guideline and supports TLS 1.2 cipher suites. Warning for a Common Criteria setup, ONLY the ciphers listed under the following section are allowed. 3.1.2. Strongly advised TLS cipher suites The Transport Layer Security (TLS) protocol is a universally accepted standard for authenticated and encrypted communication between clients and servers. Red Hat Certificate System supports the following TLS 1.2 cipher suites when the server is acting either as a server or as a client: ECC TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 RSA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Warning For a Common Criteria setup, ONLY these ciphers are allowed. 3.2. Allowed key algorithms and their sizes Red Hat Certificate System supports the following key algorithms and sizes if they are provided by the underlying PKCS #11 module. Allowed RSA key sizes: 2048 bits or greater Allowed EC curves or equivalent as defined in the FIPS PUB 186-4 standard: nistp256 nistp384 nistp521 3.3. Allowed hash functions The following keyed hash messages authentication (HMAC) are allowed: SHA-256 SHA-384 SHA-512 The following cryptographic hashing functions are allowed: SHA-256 SHA-384 SHA-512 3.4. IPv4 and IPv6 addresses Certificate System supports both IPv4 addresses and IPv6 addresses. In a very wide variety of circumstances, Certificate System subsystems or operations reference a host name or IP address; supporting both IPv4- and IPv6-style addresses ensures forward compatibility with network protocols. The operations that support IPv6 connections include the following: Communications between subsystems, including between the TPS, TKS, and CA and for joining security domains Token operations between the TPS and the Enterprise Security Client Subsystem logging Access control instructions Operations performed with Certificate System tools, including the pki utility, the Subject Alt Name Extension tool, HttpClient, and the Bulk Issuance Tool Client communications, including both the pkiconsole utility and IPv6-enabled browsers for web services Certificate request names and certificate subject names, including user, server, and router certificates Publishing Connecting to LDAP databases for internal databases and authentication directories Any time a host name or URL is referenced, an IP address can be used: An IPv4 address must be in the format n.n.n.n or n.n.n.n,m.m.m.m . For example, 128.21.39.40 or 128.21.39.40,255.255.255.00 . An IPv6 address uses a 128-bit namespace, with the IPv6 address separated by colons and the netmask separated by periods. For example, 0:0:0:0:0:0:13.1.68.3 , FF01::43 , or 0:0:0:0:0:0:13.1.68.3,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0 . If DNS is properly configured, then an IPv4 or IPv6 address can be used to connect to the web services pages and to the subsystem Java consoles. The most common method is to use fully-qualified domain names: To use IPv6 numeric addresses, replace the fully-qualified domain name in the URL with the IPv6 address, enclosed in brackets: [<IPv6_address>] . For example: 3.5. Supported PKIX formats and protocols The Certificate System supports many of the protocols and formats defined in Public-Key Infrastructure (X.509) by the IETF. In addition to the PKIX standards listed here, other PKIX-listed standards are available at the IETF Datatracker website. Table 3.1. PKIX standards supported in Certificate System 10 Format or Protocol RFC or Draft Description X.509 version 1 and version 3 Digital certificate formats recommended by the International Telecommunications Union (ITU). Certificate Request Message Format (CRMF) RFC 4211 A message format to send a certificate request to a CA. Certificate Management Message Formats (CMMF) Message formats to send certificate requests and revocation requests from end entities to a CA and to return information to end entities. CMMF has been subsumed by another standard, CMC. Certificate Management Messages over CS (CMC) RFC 5274 A general interface to public-key certification products based on CS and PKCS #10, including a certificate enrollment protocol for RSA-signed certificates with Diffie-Hellman public-keys. CMC incorporates CRMF and CMMF. Cryptographic Message Syntax (CMS) RFC 2630 A superset of PKCS #7 syntax used for digital signatures and encryption. PKIX Certificate and CRL Profile RFC 5280 A standard developed by the IETF for a public-key infrastructure for the Internet. It specifies profiles for certificates and CRLs. Online Certificate Status Protocol (OCSP) RFC 6960 A protocol useful in determining the current status of a digital certificate without requiring CRLs.

Commands:
https://ipv6host.example.com:8443/ca/services pkiconsole https://ipv6host.example.com:8443/ca
https://[00:00:00:00:123:456:789:00:]:8443/ca/services pkiconsole https://[00:00:00:00:123:456:789:00:]:8443/ca