Certificate Issuance Policy

How, when, and why we issue certificates.

XIVAuth operates a Certificate Authority (CA) that issues X.509 certificates to users, characters, and developers. These certificates are intended for use by third-party applications to cryptographically verify the identity of XIVAuth users and characters, or to authenticate code published by developers. This document describes the types of certificates issued, the conditions under which they are issued, and how the CA infrastructure operates.

Certificate Types

XIVAuth issues three types of certificates. Each certificate type has a distinct purpose and a different set of constraints on who may request one.

User Identification Certificates

User identification certificates bind a public key to an XIVAuth user account. Applications may use these certificates to verify that a given signature or key belongs to a specific XIVAuth user.

  • Subject: A XIVAuth user account
  • Validity period: Not more than 1 year from issuance
  • Key usage: digitalSignature
  • Extended key usages:
    • XIVAuth User Identification (1.3.6.1.4.1.65394.10.3.2)
  • Subject Alternative Names:
    • urn:xivauth:user:<user-uuid>: a URI representing a specific user account.
  • Access: Available to all users with a verified email.

Character Identification Certificates

Character identification certificates bind a public key to a verified character registration on XIVAuth. To request a character identification certificate, a user must have positively proven they own the character they wish to verify.

  • Subject: A verified character registration on XIVAuth
  • Validity period: Not more than 1 year from issuance
  • Key usage: digitalSignature, keyAgreement (EC keys) or keyEncipherment (RSA keys)
  • Extended key usages:
    • XIVAuth Character Identification (1.3.6.1.4.1.65394.10.3.1)
  • Subject Alternative Names:
    • urn:xivauth:character:lodestone:<lodestone-id>: the character's Lodestone ID
    • urn:xivauth:character:persistent_key:<persistent-key>: an internal identifier that uniquely identifies this user/character pair.
  • Common Name: A human-readable snapshot of the character name and home world at the time of issuance. Consumers must not use the Common Name for identity verification; it may become stale if the character is renamed or transferred to a different game world. The Subject Alternative Name URIs are the authoritative identity.
  • Prerequisite: The character registration must be verified before a certificate can be issued.
  • Access: Available to all users with a verified email.

Code Signing Certificates

Code signing certificates allow developers and teams to cryptographically sign applications intended for use within the greater FINAL FANTASY XIV ecosystem. These certificates are intended for use with code signing workflows and are not suitable as identity tokens. Furthermore, as the XIVAuth Root CA is not included in any system trust stores, verification of signatures are the responsibility of a relying party.

  • Subject: A XIVAuth user account or a developer team
  • Validity period: Not more than 1 year from issuance
  • Key usage: digitalSignature
  • Extended key usage: codeSigning
  • Access: Restricted, only available upon manual approval.

Application Subordinate CAs

Certain applications may require the ability to issue certificates for their own purposes. In this case, XIVAuth may issue a subordinate CA certificate to the application. Subordinate CA certificates are operated by XIVAuth, and their key material is not available to the requesting application. All other policies in this document apply to certificates issued by a subordinate CA, including the appropriate prerequisite and access controls.

In general, these subordinate CAs are meant for cases where an application wants to ensure that the certificate was issued within their context, that is, for that application only. Applications must take care to verify that the certificate was not issued by an untrusted subordinate CA.

  • Subject: The name of the application requesting a CA
  • Validity period: Not more than 3 years from issuance
  • Key usage: keyCertSign
  • Extended key usages:
    • XIVAuth User Identification (1.3.6.1.4.1.65394.10.3.2)
    • XIVAuth Character Identification (1.3.6.1.4.1.65394.10.3.1)
  • Subject Alternative Names:
    • urn:xivauth:app:<app-id>: the app that requested this certificate
  • Access: Not yet issued.

Key Requirements

All certificate requests must include a public key that meets the following minimum strength requirements. Requests using weaker or unsupported key types are rejected.

  • RSA: Minimum 2048-bit key size
  • EC (Elliptic Curve): Minimum 256-bit key size; permitted curves are prime256v1, secp384r1, and secp521r1
  • Other key types: Not accepted

A given public key is bound to a single subject and certificate type at issuance. If a key has already been used for one subject or type, it may not be reused for a different subject or type. Generate a new key pair for each distinct identity or purpose.

A public key that has previously appeared in a revoked certificate may not be used to request a new certificate, regardless of the certificate type or subject, or prior certificate status.

Certificate Limits and Renewal

Certificates may only be renewed (defined as reusing the same keypair and identity) is subject to a renewal window. Renewals of certificates are only permitted once at least 75% of the certificate's validity period has elapsed, or after one year, whichever comes first. Renewal requests made before the window opens will be rejected.

Revocation

Both users and the XIVAuth system can revoke issued certificates. Revocation is permanent and cannot be undone.

User-Initiated Revocation

Users may revoke their own certificates for any of the following reasons:

  • unspecified: no specific reason given
  • key_compromise: the private key has been lost, stolen, or exposed
  • superseded: the certificate has been replaced by a newer one
  • cessation_of_operation: the certificate is no longer needed

System-Initiated Revocation

XIVAuth may revoke certificates for operational or policy reasons, including CA key compromise, affiliation changes, or policy violations. If a CA certificate is revoked, all certificates issued under it may be considered untrusted by relying parties, depending on how the issuing CA's revocation is handled.

CA Infrastructure

XIVAuth's CA infrastructure is designed to allow relying parties to validate certificate status at any time. All issued certificates contain the following extensions to support this:

  • Authority Information Access (AIA):
    • OCSP responder URL: for real-time certificate status checks
    • CA Issuers URL: for downloading the issuing CA certificate in DER format
  • CRL Distribution Points: A URL where the Certificate Revocation List (CRL) for the issuing CA can be downloaded.
  • Basic Constraints: CA:FALSE, critical. All issued certificates are end-entity certificates and may not themselves sign other certificates

XIVAuth operates a single OCSP responder. Queries for unknown serial numbers return an error response rather than a "good" or "unknown" status.

CA certificates are rotated over time. When a CA is retired, it is deactivated and no longer used for new issuance, but the CA certificate and OCSP/CRL data for certificates it issued remain accessible. The CA slug embedded in AIA URLs is permanent and will not change after any certificate has been issued under that CA.