<aside> ℹ️

The XIVAuth Certificate Authority is still undergoing active development, and implementation details may change.

Furthermore, the XIVAuth Certificate Authority is an optional feature designed for certain applications whose needs cannot be met via simple attestation. Examples include federated services or public data blobs that need to be associated/proven to have been made by a user with access to a specific character.

</aside>

XIVAuth implements a certificate authority that is used to issue certificates to certain entities such as players and characters. This service is free to use for all XIVAuth users, though some constraints apply.

While the XIVAuth Certificate Authority should not be considered a high-trust CA, it attempts to at least reasonably structure itself such that enterprise paradigms can be used. XIVAuth will loosely implement the rules specified in the CA/Browser Forum Baseline Requirements.

<aside> ☢️

XIVAuth CA certificates should NOT be installed into any root CA store on any computer. These certificates are not intended, nor do they have the requisite security design, to be considered a root of “general trust” akin to any true certificate authority.

</aside>

OID Reference

Root Certificate Authority

The production instance of XIVAuth maintains a root certificate with the Common Name XIVAuth Root CA. Key material for this certificate is stored offline on two separate Yubikeys, with encrypted backups of its key material being stored online.

The current root CA can be downloaded from https://pki.xivauth.net/rootca/[TBD].cer. CRLs for this certificate are distributed from http://pki.xivauth.net/rootca/[TBD].crl, and are updated yearly.

• Q: Why use secp384r1?

Character Attestation Certificate Authority

Users may request (via a CSR) a certificate for their characters issued by the XIVAuth Character Attestation CA. To request this certificate, a user must have proven ownership over the character to request. This certificate is stored on XIVAuth servers, and is generally considered a “hot” certificate.

In the future, XIVAuth may offer PKCS #7-formatted attestations of character ownership. In this case, this CA will be the signer of record.

The exact structure of this certificate is still to be determined, though both the Lodestone ID and Persistent Key will be included in the certificate’s Subject field. Certificates may be renewed or replaced freely by making a new CSR. Certificates issued by this CA will meet the following:

• They will be listed as an End Entity certificate, and will not be able to sign certificates or act as a certificate authority.
• They will have key usages defined for Digital Signature and Key Agreement (for EC keys) or Key Encipherment (for RSA keys).
  • NOTE: While Key Agreement and Key Encipherment are permitted, developers are strongly encouraged to consider using ECDHE for ephemeral communications, especially between clients. See Issue #384 from the CA/Browser Forum.
  • Ed25519 certificates will not be supported at this time.
• They will have an XIVAuth defined EKU only to prevent their usage by other compliant systems.
• They will be issued with the following Distinguished Name information:
  • Common Name: FirstName LastName (LodestoneID)