Flanga Certificate Practice Statement

Version 1.0

Updated 2017/01/01

Approved by Flanga Policy Management Authority

1. Introduction

1.1 Overview

This Certification Practice Statement ("CPS") document outlines the certification services practices for Flanga Public Key Infrastructure ("Flanga PKI")

Flanga PKI services include, but are not limited to, issuing, managing, validating, revoking, and renewing Certificates in accordance with the requirements of the Flanga PKI Certificate Policy ("CP"). It is recommended that readers familiarize themselves with the Flanga CP prior to reading this document.

The Flanga PKI conforms to the current version of the guidelines adopted by the Certification Authority/Browser Forum (“CAB Forum”) when issuing publicly trusted certificates, including the Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates (“Baseline Requirements”). CAB Forum documents can be found at https://www.cabforum.org. If there is any conflict between this CPS and a relevant CAB Forum requirement or guideline, then the CAB Forum requirement or guideline shall take precedence.

Other documents related to the behavior and control of the Flanga PKI, such as a Subscriber Agreement and Privacy Policy, can be found at Flanga Repository

Per IETF PKIX RFC 3647, this CPS is divided into nine components that cover security controls, practices, and procedures for certification services provided by the Flanga PKI.

The following Certification Authorities are covered under this CPS:

CA Type Distinguished Name Key Pair Type and Parameters SHA256-Fingerprint Not Before Not After
Root CA C=DE,O=Flanga,
CN=Flanga Global Root R1
n has 8192,
7F:0E:9C:8F:40:79:BC:33:56:8F:4F:B0:3C:D1:94:B1: 21:D9:DD:99:4E:ED:7C:64:C7:4F:FF:F2:2B:12:AD:1A Jan 1, 2017 00:00:00 UTC Jan 1, 2047 00:00:00 UTC
Root CA C=DE,O=Flanga,
CN=Flanga Global Root R2
n has 8192,
Jan 1, 2017 00:00:00 UTC Jan 1, 2047 00:00:00 UTC
Root CA C=DE,O=Flanga,
CN=Flanga Global Root R3
n has 8192,
Jan 1, 2017 00:00:00 UTC Jan 1, 2047 00:00:00 UTC
Root CA C=DE,O=Flanga,
CN=Flanga Global Root R4
Jan 1, 2017 00:00:00 UTC Jan 1, 2047 00:00:00 UTC

This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/

1.2 Document Name and Identification

This is the Flanga Certificate Practices Statement. This docment was approved for publication by the Flanga Policy Management Authority, and is made available at https://cps.flanga.io https://pki.flanga.io/repository

The following revisions have been made:

Date Changes Version
Jan 1, 2017 Original 1.0

1.3 PKI Participants

1.3.1 Certification Authorities

Flanga is a CA that provides services including, but not limited to, issuing, managing, validating, revoking, and renewing privately-trusted Certificates. These services are performed in accordance with the requirements of the Flanga Certificate Practice (CP) and this CPS. These services are provided to the general public with exceptions as deemed appropriate by Flanga Management or in accordance with relevant law.

1.3.2 Registration Authorities

Flanga serves as its own RA. RA services are not performed by third parties.

1.3.3 Subscribers

See definition of "Subscriber" in Section 1.6.1 Definitions.

1.3.4 Relying Parties

See definition of "Relying Party" in Section 1.6.1 Definitions.

Relying Parties must verify the validity of certificates via CRL or OCSP prior to relying on certificates. CRL and OCSP location information is provided within certificates.

1.3.5 Other parties

Other participants include CAs that cross-sign or issue subordinates to the Flanga PKI

Flanga PKI vendors and service providers with access to confidential information or privileged systems are required to operate in compliance with the Flanga CP.

1.4 Certificate Usage

1.4.1 Appropriate certificate uses

Certificate Type Authority to Issue
Server Authentication Yes
Client Authentication Yes
Codesigning Yes
Extended Validation Yes
Timestamping Yes
DocumentSign Yes

1.4.2 Prohibited certificate uses

Certificates may not be used:

  • For any purpose not explicitly defined in Section 1.4.1 of this document
  • For any application requiring fail-safe performance such as any system in which failure could lead to injury, death, or environmental damage.
  • For software or hardware architectures that provide facilities for interference with encrypted communications, including but not limited to a) active eavesdropping (e.g., Man-in-the-middle attacks) b) traffic management of domain names or internet protocol (IP) addresses that the organization does not own or control. Note that these restrictions shall apply regardless of whether a relying party communicating through the software or hardware architecture has knowledge of its providing facilities for interference with encrypted communications.
  • For any usage which is not related to Flanga or any of Flanga's provided services (this also includes public available websites).
  • When prohibited by law.
Also, note that Certificates do not guarantee anything regarding reputation, honesty, or the current state of endpoint security. A Certificate only represents that the information contained in it was verified as reasonably correct when the Certificate was issued.

1.5 Policy Administration

1.5.1 Contact administering the document

This CPS document is maintained by the Flanga Policy Management Authority.

1.5.2 Contact Person

The Flanga Policy Management Authority can be contacted at:


1.5.3 Person determining CPS suitability for the policy

The Flanga Policy Management Authority is responsible for determining the suitability of this CPS. The Flanga Policy Management Authority is informed by results and recommendations received.

1.5.4 CPS approval procedures

The Flanga Policy Management Authority approves any revisions to this CPS document after formal review.

1.6 Definitions and acronyms

1.6.1 Definitions

  • ACME
    • Automated Certificate Management Environment
  • BRs
    • Baseline Requirements
  • CA
    • Certificate Authority
  • CAA
    • Certificate Authority Authorization
  • CP
    • Certificate Policy
  • CPS
    • Certification Practice Statement
  • DV
    • Domain Validation
  • FQDN
    • Fully Qualified Domain Name
  • HSM
    • Hardware Security Module
  • IDN
    • Internationalized Domain Name
  • IP
    • Internet Protocol
  • PKI
    • Public Key Infrastructure
  • PMA
    • Policy Management Authority
  • RA
    • Registration Authority
  • SAN
    • Subject Alternative Name
  • TLD
    • Top Level Domain

2. Publication and Repository Responsibilities

2.1 Repositories

Flanga CP, CPS, Privacy Policy and Subscriber Agreement are made publicly available in the Policy Repository, which can be found at:


2.2 Publication of certification information

Records of all Flanga root and intermediate certificates, including those that have been revoked, are available in the Certificate Repository:


Flanga certificates contain URLs to locations where certificate-related information is published, including revocation information via OCSP and/or CRLs.

2.3 Time or frequency of publication

New or updated Flanga CP, CPS, Privacy Policy and Subscriber Agreement are made publicly available as soon as possible. This typically means within seven days of receipt or approval.

New or updated Flanga root and intermediate certificates are made publicly available as soon as possible. This typically means within seven days of creation.

2.4 Access controls on repositories

Read only access to the Policy Repository and certificate information is unrestricted. Write access is protected by logical and physical controls.

3. Identification and Authentication

3.1 Naming

3.1.1 Type of Names

Certificate distinguished names and subject alternative names are compliant with the CP.

3.1.2 Need for names to be meaningful

Flanga certificates include a "Subject" field which identifies the subject entity (i.e. organization or domain). The subject entity is identified using a distinguished name.

Flanga certificates include an "Issuer" field which identifies the issuing entity. The issuing entity is identified using a distinguished name.

3.1.3 Anonymity or pseudonymity of subscribers

Subscribers are not identified in DV certificates, which have subject fields identifying only domain names (not people or organizations). Relying parties should consider DV certificate subscribers to be anonymous.

3.1.4 Rules for interpreting various name forms

Distinguished names in certificates are to be interpreted using X.500 standards and ASN.1 syntax. RFC 2253 and RFC 2616 provide more information.

Certificates do not assert any specific relationship between subscribers and registrants of domain names contained in certificates.

Regarding Internationalized Domain Names, Flanga will have no objection so long as the domain is resolvable via DNS. It is the CA’s position that homoglyph spoofing should be dealt with by registrars, and Web browsers should have sensible policies for when to display the punycode versions of names.

3.1.5 Uniqueness of names

No stipulation.

3.1.6 Recognition, authentication, and role of trademarks

Flanga reserves the right to make all decisions regarding Subscriber names in certificates. Entities requesting certificates will be required to demonstrate their right to use names (e.g. demonstrate control of a domain name), but trademark rights are not verified.

3.2 Initial identity validation

Flanga may elect not to issue any certificate at its sole discretion.

3.2.1 Method to prove posession of private key

Applicants are required to prove possession of the Private Key corresponding to the Public Key in a Certificate request, which can be done by signing the request with the Private Key.

3.2.2 Authentication of organization and domain identity

Validation for DV certificates involves demonstrating proper control over a domain. Flanga validates domain control primarily in an automated fashion. In exceptional cases control may be validated using methods similar to those provided by this fashin, but performed manually.

There are three methods used for demonstrating domain control:

  • Agreed-Upon Change to Website.