miPDFsign Cloud CA — CP/CPS

1 · Introduction

1.1 Overview

The miPDFsign Cloud CA is the internal public-key infrastructure operated by miPDFsign for its e-signature platform at cloud-signing.com. It issues organization document seals: X.509 certificates used exclusively by the platform's server-side signing service to apply PAdES (PDF Advanced Electronic Signature) seals on behalf of the customer organization that owns the signature flow.

The hierarchy is two-tier:

• miPDFsign Cloud Root CA G2 — self-signed trust anchor (RSA-4096, 20 years). Used only to sign Issuing CA certificates and the root CRL.
• miPDFsign Cloud Document Signing CA G2 — operational issuing CA (RSA-4096, 10 years, path length 0). Signs organization document seals and the issuing CRL.
• Organization document seals — end-entity certificates (RSA-3072, 3 years), one per customer organization, e.g. CN=Acme GmbH Document Seal, O=Acme GmbH.
• Personal signature certificates — end-entity certificates (RSA-3072) issued per signing operation and short-lived (15 minutes) for organizations that opt in, naming the individual signer, e.g. CN=Jo Signer, E=jo@acme.example, O=Acme GmbH.

1.2 Document name and identification

This document is identified by the object identifier arc 1.3.6.1.4.1.66283.2 (IANA Private Enterprise Number 66283, registered to cloud-signing.com and operated by miPDFsign). Certificates issued under this CPS assert one of two certificate policies: 1.3.6.1.4.1.66283.2.1 ("miPDFsign Cloud organization document seal") or 1.3.6.1.4.1.66283.2.2 ("miPDFsign Cloud personal signature"). They are separate policies because the subject and the identity assurance differ — see section 3.

1.3 PKI participants

• CA / RA: miPDFsign operates both the certification authority and the registration function. There are no external registration authorities.
• Subscribers: customer organizations of miPDFsign Cloud. Subscribers never hold the private key; keys are generated, stored and used exclusively inside the platform.
• Relying parties: anyone validating a PDF sealed by the platform (e.g. in Adobe Acrobat or via the signature validator).

1.4 Certificate usage

Document seals are used only for digital signatures on PDF documents produced by miPDFsign Cloud (key usage digitalSignature + contentCommitment, extended key usage id-kp-documentSigning, RFC 9336). Any other use — TLS, code signing, e-mail — is prohibited and technically prevented by the certificate profile.

1.5 Policy administration

This CPS is maintained by miPDFsign. Questions and revocation requests: office@mitterbucher.com. Changes are versioned; the current version is always published at /docs/cps.html.

2 · Publication and repository responsibilities

The CA publishes all public material in the machine-readable repository at https://cloud-signing.com/api/ca:

These URLs are embedded in every issued certificate (AIA caIssuers, CRL distribution point, certificatePolicies CPS qualifier) and are kept stable for the lifetime of the certificates that reference them. CRLs are re-issued at least every 24 hours and immediately after a revocation; their nextUpdate is 7 days.

3 · Identification and authentication

A document seal is issued only to an organization with an active miPDFsign Cloud tenant. The subject name is derived from the organization's registered account name: CN=<Organization> Document Seal, O=<Organization>, OU=miPDFsign Cloud Organization Seal. The organization's identity is authenticated through the platform's account and billing relationship; no additional out-of-band identity vetting is performed at this assurance level.

A personal signature certificate is issued only for a signer acting within a tenant that opted into this certificate type, and names only that signer: CN=<Signer>, E=<email>, O=<Organization>, OU=miPDFsign Cloud Personal Signature. The subject is taken from the platform's own record of the signer — the authenticated account, or the e-mail address the tenant invited to sign — never from free-form input.

What a personal signature certificate does and does not attest. It attests who was authenticated by, or invited through, the platform for that signing operation. It does not attest the signer's legally verified identity: no identity document is checked, no video or in-person identification takes place, no register is consulted. Relying parties requiring vetted legal identities should rely on the platform's qualified signing methods (e.g. ID-Austria) or organization-supplied certificates instead.

4 · Certificate life-cycle

4.1 Issuance

Seals are issued automatically the first time an organization signs with the platform's built-in method after CA activation. Key generation and certificate issuance happen server-side in one step; the private key never exists outside the platform.

4.2 Renewal

A new seal (with a new key) is issued automatically when the current one expires within 30 days or has been revoked. Old signatures remain verifiable: PAdES timestamps and LTV material preserve validity beyond certificate expiry.

4.3 Revocation

Three revocation channels exist: the platform operator (console), the subscriber organization itself (self-service in the administration area), and the public report / revocation-request form open to anyone — including relying parties (office@mitterbucher.com works too). Reports are processed within 24 hours; revocations take effect on the CRL and OCSP immediately. Reason codes follow RFC 5280. An incident-response plan (compromise at any tier, outages, mis-issuance; 24-hour response target) is maintained alongside this CPS.

5 · Facility, management and operational controls

• Key protection: the Root and Issuing CA private keys live in an external key service (KMS, OpenBao Transit) on a separate, hardened machine — non-exportable, never leaving the KMS; signing is a delegated, authenticated and logged call. Short-lived seal / personal-signature keys are generated per operation and, where persisted at all, encrypted with the platform's data-protection key ring.
• Access control: CA administration is restricted to the platform-operator role (PlatformAdmin), protected by strong authentication incl. two-factor authentication.
• Audit logging: every issuance and revocation is written to the platform's append-only audit trail with actor, timestamp and certificate serial.
• Backups: encrypted database backups include the encrypted key material; the data-protection key ring is managed separately.

5.8 · CA termination

There is no guaranteed minimum term of operation — miPDFsign Cloud is a non-qualified trust service with no supervisory continuity obligation. On cessation, the shutdown is announced with reasonable notice (~60 days), no new certificates are issued, a final long-dated CRL is published, and the public repository (root certificate + final CRL) is kept available best-effort or handed to a static host; the CA signing keys are cryptographically destroyed in the KMS. Already-produced PAdES-LT/LTA signatures stay verifiable regardless — their timestamps and revocation evidence are embedded in the document, so validity at signing time does not depend on these services staying online.

6 · Technical security controls

There is no key escrow and no key export. Serial numbers carry ≥ 120 bits of CSPRNG entropy. All repository endpoints are served exclusively over TLS.

7 · Certificate and CRL profiles

7.1 Document seal profile

A personal signature certificate uses the same profile, with two differences: the subject is CN=<Signer>, E=<email>, O=<Org>, OU=miPDFsign Cloud Personal Signature — with the address repeated as an rfc822Name in subjectAltName, where RFC 5280 wants it — and the policy is 1.3.6.1.4.1.66283.2.2. It is issued per signing operation with a 15-minute validity, and its private key is discarded afterwards rather than stored — so nothing valid outlives the session, and the embedded RFC-3161 timestamp carries the proof from then on.

7.2 CRL and OCSP profiles

X.509 v2 CRLs (RFC 5280) with cRLNumber and authorityKeyIdentifier; thisUpdate/nextUpdate span 7 days; entries carry RFC 5280 reason codes.

The OCSP responder (RFC 6960) at /api/ca/ocsp answers for all certificates issued by the Issuing CA. Responses are signed directly by the Issuing CA (RFC 6960 §2.6), embed the CA certificate, echo the request nonce when present (RFC 8954) and are valid for 24 hours. Serials not present in the issuance registry are answered unknown. Both the POST binding (application/ocsp-request) and the GET binding (base64 request in the URL, RFC 6960 A.1) are supported.

8 · Compliance and audit

This CPS is deliberately structured along RFC 3647 and oriented toward ETSI EN 319 411-1 (NCP) so the CA can grow into an externally audited trust-service operation (e.g. Adobe Approved Trust List membership) without re-architecting. As of this version, the CA has not undergone an external conformity assessment.

9 · Other business and legal matters

Seals issued under this policy constitute (advanced-style) electronic seals at platform assurance level; they are not qualified certificates and are not issued by a qualified trust service provider in the sense of eIDAS. miPDFsign provides the CA "as is" without warranty beyond the practices described here; liability is governed by the miPDFsign Cloud terms of service. Governing law: Austria.

© miPDFsign · This document: /docs/cps.html · Repository: /api/ca