O.5 TLS Certificate Profile and Validation

33.2033G Security3GPPAccess security for IP-based servicesTS

O.5.1 TLS Certificate

X.509 digital certificates shall be used for authentication in TLS. All X.509 certificates shall be signed by a trusted party. The certificates shall be profiled as specified in clause 6.1 in TS 33.310 [24] with the following additions:

– for TLS entity certificates:

– CRL distribution point in the certificates shall not be mandatory.

– The common name CN shall be the FQDN (Fully Qualified Domain Name) of the server. Only a single FQDN is allowed in the CN field.

– The subjectAltName shall contain the FQDN (Fully Qualified Domain Name) of the server.

– for TLS CA certificates:

– TLS CA certificates shall have no restriction in the issuer name.

O.5.2 Certificate validation

TLS certificates shall be verified as part of a certificate chain that chains up to a trusted Root certificate. The chain may contain intermediate Certification Authority (CA) certificates.

Usually the first certificate in the chain is not explicitly included in the certificate chain that is sent by the P-CSCF to the UE. In the cases where the first certificate is explicitly included, it shall already be known to the verifying party ahead of time and shall not contain any changes to the certificate, with the possible exception of the certificate serial number, validity period and the value of the signature. If changes other than the certificate serial number, validity period and the value of the signature exist in the root certificate that was sent by the P-CSCF to the UE in comparison to the known root certificate, the UE shall conclude that the certificate verification has failed.

UEs shall build the certificate chain and validate the TLS certificate according to the "Certification Path Validation" procedures described in RFC 5280 [52]. In general, X.509 certificates support a liberal set of rules for determining if the issuer name of a certificate matches the subject name of another. The rules are such that two name fields may be declared to match even though a binary comparison of the two name fields does not indicate a match. RFC 5280 [52] recommends that certificate authorities restrict the encoding of name fields so that an implementation can declare a match or mismatch using simple binary comparison. Accordingly, the DER-encoded tbsCertificate.issuer field of a certificate shall be an exact match to the DER-encoded tbsCertificate.subject field of its issuer certificate. An implementation may compare an issuer name to a subject name by performing a binary comparison of the DER-encoded tbsCertificate.issuer and tbsCertificate.subject fields.

O.5.3 Certificate Revocation

Certificate Revocation Lists (CRLs) may be checked as part of certificate path validation. CRL infrastructure is optional to implement. The CRL, if used, should be profiled as specified in clause 6 in TS 33.310 [24].

Annex P (normative):
Co-existence of authentication schemes IMS AKA, GPRS-IMS-Bundled Authentication, NASS-IMS-bundled authentication, SIP Digest and Trusted Node Authentication