You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/getting-started.mdx
+5-40Lines changed: 5 additions & 40 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -76,53 +76,18 @@ A signed digital certificate verifies the authenticity of an entity, such as a s
76
76
77
77
## Signing and certificates
78
78
79
-
Once you initially attach a manifest to an asset, it has information about the origin of the asset, such as the name of the tool that created it (for example, Photoshop) and your name as the _actor_ who created or modified it. Each time someone edits or updates the asset using a tool that supports CAI, it adds a new manifest with the actions taken and the certificate of the tool/site; this becomes the _active manifest_, which then references any prior manifests as ingredients.
79
+
A manifest attached to an asset contains information about the origin of the asset, such as the name of the tool that created it (for example, Photoshop) and the name of the _actor_ who created or modified it. Each time someone edits or updates the asset using a tool that supports CAI, it adds a new manifest with the actions taken and the certificate of the tool/site; this becomes the _active manifest_, which then references any prior manifests as ingredients.
80
80
81
-
Each manifest is digitally signed with the application's or client's credentials. To make validation of the credentials possible, the manifest also includes the signing certificate chain. The "chain" of certificates starts with the certificate from the last tool that signed the manifest (known as the "end-entity") followed by the certificate that signed it, and so on, back to the original CA issuer. In other words, a user knows they can trust that the manifest is valid because there is a "trust chain" that goes back to a trusted root certificate authority. That's why you need to acquire a security certificate from a legitimate certificate authority.
81
+
Each manifest is digitally signed with the application's or client's credentials. To enable validation of the credentials, the manifest also includes the signing certificate chain. The "chain" of certificates starts with the certificate from the last tool that signed the manifest (known as the "end-entity") followed by the certificate that signed it, and so on, back to the original CA issuer. A user can trust that the manifest is valid because there is a "trust chain" that goes back to a trusted root certificate authority. That's why you need to acquire a security certificate from a legitimate certificate authority.
82
82
83
83
In practice, to use a certificate with the CAI SDK, follow this process:
84
84
85
85
1. Purchase security credentials (certificate and key) from a certificate authority. Either email protection or document signing certificates are valid.
86
-
2. Extract the certificate by using a tool such as OpenSSL. You could also host the certificate in a secure environment like a hardware security module (HSM).
87
-
3. Use one of the supporting CAI libraries or C2PA Tool to sign manifests using the certificate.
86
+
2. Extract the certificate by using a tool such as OpenSSL (for use during development). In production, you should host the private key in a secure environment like a hardware security module (HSM).
87
+
3. Use one of the supporting CAI libraries or C2PA Tool to sign manifests using the certificate and your private key.
88
88
89
89
:::tip
90
-
For a short tutorial example, see [Signing manifests](manifest/signing-manifests.md). For more information on how to get and use a signing certificate in production, see [Getting and using a signing certificate](prod-cert.mdx).
91
-
:::
92
-
93
-
### Getting a security certificate
94
-
95
-
To create or modify Content Credentials, you must have a valid security certificate and key that conform to the requirements laid out in the [C2PA specification Trust Model section](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_trust_model).
96
-
97
-
You must purchase a X.509 v3 security certificate from a certificate authority (CA). There are many CAs that issue certificates. Some of the most popular ones are:
The above list is for reference only; inclusion does not imply endorsement by CAI or Adobe, Inc.
105
-
106
-
When you purchase a certificate, you must select at least one of the extended key usage (EKU) fields that specify what the certificate can be used for: **email protection** and **document signing**. Applications that use the CAI SDK won't accept the certificate unless it has one of these EKUs.
107
-
108
-
### Extracting the certificate
109
-
110
-
To work with the certificate, you need to extract it. When the CAI SDK adds Content Credentials to an asset, it incorporates the certificate (including the associated public key) into the manifest.
111
-
112
-
:::info Important
113
-
The _private key_ associated with the certificate is extremely sensitive. Always treat it with the highest security to ensure your credentials are not compromised. If someone does obtain your private key, they will be able to sign C2PA manifests and other content on your behalf without your consent.
114
-
:::
115
-
116
-
### Using the certificate to sign a manifest
117
-
118
-
The simplest way to add a C2PA manifest to an asset file is by using C2PA Tool (`c2patool`). You can run C2PA Tool tool manually from the command line (for example, during development) and more generally from any executable program that can call out to the shell, such as a Node.js application as shown in the [c2patool Node.js service example](c2pa-node-example/).
119
-
120
-
The prerelease libraries for [Node.js](c2pa-node/), [Python](c2pa-python/), and [C++/C](c2pa-c/) can also add and sign a manifest.
121
-
122
-
Similarly, using the Rust SDK, you can [add a manifest to an asset file](https://docs.rs/c2pa/latest/c2pa/#example-adding-a-manifest-to-a-file), referencing the certificate and private key file. For a simple example of creating and signing a manifest from a C program, see the [c2c2pa repository](https://github.com/contentauth/c2c2pa).
123
-
124
-
:::warning Warning
125
-
Accessing a private key and certificate directly from the file system is fine during development, but doing so in production may be insecure. Instead use a Key Management Service (KMS) or a hardware security module (HSM) to access the certificate and key; for example as show in the [C2PA Python Example](https://github.com/contentauth/c2pa-python-example).
90
+
For a short tutorial example, see [Signing manifests](signing/signing-manifests.md). For more information on how to get and use a signing certificate in production, see [Getting and using a signing certificate](signing/prod-cert.mdx).
Copy file name to clipboardExpand all lines: docs/signing/prod-cert.mdx
+26Lines changed: 26 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,6 +19,32 @@ The process to purchase a certificate and key is different for each CA: You migh
19
19
20
20
The certificate chain starts with the certificate from the last tool that signed the manifest (known as the "end-entity") followed by the certificate that signed it, and so on, back to the original CA issuer. This enables a validating application to determine that the manifest is valid because the certificate chain goes back to a trusted root certificate authority.
21
21
22
+
### Signature types
23
+
24
+
The following table describes the signature algorithms and types that the CAI SDK supports. You must supply credentials (certificates and keys) that correspond to the signing algorithm. Signing/validation will fail if the the supplied credentials don't support the signature type.
|`id-Ed25519`| EdDSA (Edwards-Curve DSA) with SHA-512 (SHA-2) and Curve25519 | Ed25519 instance ONLY. |[RFC 8410 section 3](https://www.rfc-editor.org/rfc/rfc8410.html#section-3)|
38
+
39
+
:::info
40
+
41
+
<aname="table-note"></a>
42
+
<sup>*</sup> ES256, ES384, and ES512 signatures must be in IEEE P1363 format.
43
+
44
+
:::
45
+
46
+
The information in this table is based on the [C2PA specification Trust Model section](https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#_trust_model). The C2PA specification also covers two other certificates for timestamp responses and OCSP certificate revocation, which are not covered here.
47
+
22
48
### Certificate signing requests (CSRs)
23
49
24
50
A CSR is just an unsigned certificate that's a template for the certificate that you're requesting. The CA creates a new certificate with the parameters specified in the CSR, and signs it with their root certificate, which makes it a valid certificate.
0 commit comments