From 4b8ee6845a95206bb5b5662e3a9d58c94c113224 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Tue, 27 Jul 2021 11:21:39 -0400 Subject: [PATCH 01/33] Add first draft of Fulcio TAP Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 105 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 candidate-fulcio-tap.md diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md new file mode 100644 index 00000000..dcfec0fe --- /dev/null +++ b/candidate-fulcio-tap.md @@ -0,0 +1,105 @@ +* TAP: +* Title: Fulcio for TUF developer key management +* Version: 0 +* Last-Modified: 27/07/2021 +* Author: Marina Moore, Joshua Lock, Asra Ali, Luke Hinds, Jussi Kukkonen, Trishank Kuppusamy +* Type: Standardization +* Status: Draft +* Content-Type: markdown +* Created: 27/07/2021 +* +TUF-Version: +* +Post-History: + +# Abstract +In order to achieve end-to-end software update security, TUF requires developers to sign updates with a private key. However, this has proven challenging for some implementers as developers then have to create, store, and secure these private keys in order to ensure they remain private. This TAP proposes using Sigstore’s Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. Targets roles may delegate to Fulcio identities instead of private keys, and these identities, and the corresponding certificates can be used for verification. + +# Motivation +Developer key management has been a major concern for TUF adoptions, especially for projects with a small number of developers or limited resources. TUF currently requires that every targets metadata signer creates and manages a private key. However, many developers in large TUF adoptions, including PyPI, do not want the extra burden of protecting a private key for use in deployment. + +Protecting a private key from loss or compromise is no simple matter. [Several](https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm) [attacks](https://jsoverson.medium.com/how-two-malicious-npm-packages-targeted-sabotaged-one-other-fed7199099c8) on software update systems have been achieved through the use of a compromised key, as securing private keys can be challenging and sometimes expensive (yubikeys etc). + +This TAP proposes a way for developers to use their existing OpenID Connect (OIDC) accounts – such as an email account – to verify their identity, so that they do not have to manage any additional keys or passwords. + +# Rationale +In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://www.minilock.io) - a tool which derives ed25519 keys from a user-chosen passphrase – to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is no longer maintained. + +In this TAP, we instead propose use of the Sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys. Sigstore provides two services, Fuclio (a WebPKI) and Rekor (a transparency log). With sigstore, short-lived keys do not need to be secured as they are only valid for a small window. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. + +# Specification +In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to developer email addresses, to be verified by Fulcio. These delegations MAY replace ed25519 keys for developers in order to simplify their key management. Fulcio generates short-lived signing certificates backed by OIDC authentication of a developer’s email address. Because the certificates are short-lived, the developer will not be responsible for protecting this key in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. + +## Delegation format +In order to facilitate use of Fulcio, delegations may list an email address and location of a Fulcio server instead of a public key. So, this TAP adds a “sigstore-oidc" keytype for a KEY with the following format: + +``` +{ + “keytype”: “sigstore-oidc", + “scheme”: SERVER, + “keyval”: { + “email”: EMAIL, + “issuer”: ISSUER + } +} +``` + +Where SERVER is the Fulcio server used to generate the certificate, EMAIL is the identity of the party who is authorized to sign, and ISSUER is the OIDC entity used by Fulcio for verification. The client MUST establish trust in the Fulcio server using a trusted channel before using it for verification (see Verification) + + +Using this mechanism, the developer requests a certificate from Fulcio, verifies their identity using OIDC, uses the certificate to sign their targets metadata, and uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Fulcio root key using a secure offline method. + +## Signature format +A signature using a Fulcio key should include the Fulcio certificate for use in verification. For this verification, this TAP adds a ‘cert’ field to ‘signatures’. With this field, signatures would look like: + +``` +"signatures" : [ + { "keyid" : KEYID, + "sig" : SIGNATURE, + “cert”: CERTIFICATE } + , ... ] +``` +Where CERTIFICATE is a Fulcio signing certificate in PEM format. CERTIFICATE MUST be uploaded to a timestamped transparency log upon creation. + +## Signing +In order to sign metadata using Fulcio, a developer would: +* Generate a key pair locally +* Initiate an OIDC session to Fulcio to retrieve their email from a OIDC provider +* Perform a challenge by encrypting their email with the public key +* Request a short-lived certificate from Fulcio + * Fulcio will upload the certificate to a timestamped transparency log +* Use this certificate to sign targets metadata, then include the certificate in ‘signatures’ as indicated above +* Upload the metadata to the repository +* The repository will automatically perform verification (see below) with Fulcio and the transparency log to ensure that the certificate is current and valid. + +## Verification +While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to SERVER. Additionally, they must ensure that SERVER is a known, trusted Fulcio root. The trusted Fulcio root MUST be communicated to the client using a secure channel before the update process, such as metadata signed by an offline root key or during initial client configuration. + +In addition, the repository MUST, and clients SHOULD additionally query the transparency log to ensure that the Fulcio certificate is valid at the time that it was used. + +## Auditors +Developers should monitor the TL for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer should replace any compromised metadata, and report the compromise to the maintainers of the Fulcio server and any targets metadata owners who delegate to the compromised account. + +In addition to developer monitoring, the TL should have auditors that watch the log for any suspicious activity. If something bad is found in the TL, then auditors must indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata before verifying any Fulcio-signed delegated targets. The auditor only signs metadata if all signatures in the TL look good. If the auditor detects a problem, they may revoke the auditor-signed metadata. + +If the bad certificates are due to a compromised Fulcio server, the Fulcio server SHOULD be revoked using the root of trust. + +# Security Analysis + +This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds 2 additional services that may be compromised: the Fulcio server and the transparency log. In this section, we will analyse the impact and recovery in each of these cases. + +If the Fulcio server is compromised, it may issue certificates on behalf of any developer who uses Fulcio to verify their identity. However, the Fulcio server is backed by offline keys that are signed by TUF root keys, and so it is possible to recover from any server compromise. Additionally, all Fulcio certificates are published to a transparency log, so auditors will notice if the Fulcio server is misbehaving and indicate this to users, for example through the use of auditor-signed metadata. + +If only the transparency log is compromised, the attacker will not be able to do anything without cooperation from the Fulcio server. However, if the attacker compromises both the Fulcio server and the transparency log, they would be able to issue fake Fulcio certificates that also appear valid on the transparency log. If this happens, developers auditing the transparency log would notice the mis-issued certificates, and the Fulcio server and transparency log could both be recovered using offline root keys. + + +# Backwards Compatibility + +Clients that do not recognize Fulcio certs will not be able to validate signatures from Fulcio certs, but they will be able to parse the metadata. + +‘Cert’ is a new field added to ‘signatures’. Clients that do not recognize Fulcio certs will ignore this field by default. + +# Augmented Reference Implementation + +TODO + +# Copyright +This document has been placed in the public domain. From 7db2f6def026b5f794d1544ff32155d3854a1b5f Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 12 Aug 2021 14:31:49 -0400 Subject: [PATCH 02/33] [Fulcio TAP] Minor clarifications and corrections Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index dcfec0fe..7084a229 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -2,7 +2,7 @@ * Title: Fulcio for TUF developer key management * Version: 0 * Last-Modified: 27/07/2021 -* Author: Marina Moore, Joshua Lock, Asra Ali, Luke Hinds, Jussi Kukkonen, Trishank Kuppusamy +* Author: Marina Moore, Joshua Lock, Asra Ali, Luke Hinds, Jussi Kukkonen, Trishank Kuppusamy, axel simon * Type: Standardization * Status: Draft * Content-Type: markdown @@ -23,7 +23,7 @@ This TAP proposes a way for developers to use their existing OpenID Connect (OID # Rationale In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://www.minilock.io) - a tool which derives ed25519 keys from a user-chosen passphrase – to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is no longer maintained. -In this TAP, we instead propose use of the Sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys. Sigstore provides two services, Fuclio (a WebPKI) and Rekor (a transparency log). With sigstore, short-lived keys do not need to be secured as they are only valid for a small window. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. +In this TAP, we instead propose use of the Sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides two services, Fuclio (a WebPKI) and Rekor (a transparency log). With sigstore, short-lived keys do not need to be secured as they are only valid for a small window. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. # Specification In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to developer email addresses, to be verified by Fulcio. These delegations MAY replace ed25519 keys for developers in order to simplify their key management. Fulcio generates short-lived signing certificates backed by OIDC authentication of a developer’s email address. Because the certificates are short-lived, the developer will not be responsible for protecting this key in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. @@ -44,9 +44,9 @@ In order to facilitate use of Fulcio, delegations may list an email address and Where SERVER is the Fulcio server used to generate the certificate, EMAIL is the identity of the party who is authorized to sign, and ISSUER is the OIDC entity used by Fulcio for verification. The client MUST establish trust in the Fulcio server using a trusted channel before using it for verification (see Verification) - Using this mechanism, the developer requests a certificate from Fulcio, verifies their identity using OIDC, uses the certificate to sign their targets metadata, and uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Fulcio root key using a secure offline method. + ## Signature format A signature using a Fulcio key should include the Fulcio certificate for use in verification. For this verification, this TAP adds a ‘cert’ field to ‘signatures’. With this field, signatures would look like: @@ -68,7 +68,12 @@ In order to sign metadata using Fulcio, a developer would: * Fulcio will upload the certificate to a timestamped transparency log * Use this certificate to sign targets metadata, then include the certificate in ‘signatures’ as indicated above * Upload the metadata to the repository -* The repository will automatically perform verification (see below) with Fulcio and the transparency log to ensure that the certificate is current and valid. + +The repository would: +* automatically perform verification (see below) with Fulcio and the transparency log to ensure that the certificate is current and valid. + +Most of these steps SHOULD be done automatically using a tool, to simplify operations for developers. + ## Verification While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to SERVER. Additionally, they must ensure that SERVER is a known, trusted Fulcio root. The trusted Fulcio root MUST be communicated to the client using a secure channel before the update process, such as metadata signed by an offline root key or during initial client configuration. From 57f3476d3801d8efeae03a377b7c08bae11af476 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 19 Aug 2021 14:49:53 -0400 Subject: [PATCH 03/33] [Fulcio TAP] Add links and clarifications Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 7084a229..67aa027d 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -1,5 +1,5 @@ * TAP: -* Title: Fulcio for TUF developer key management +* Title: Ephemeral identity verification using Sigstore's Fulcio for TUF developer key management * Version: 0 * Last-Modified: 27/07/2021 * Author: Marina Moore, Joshua Lock, Asra Ali, Luke Hinds, Jussi Kukkonen, Trishank Kuppusamy, axel simon @@ -7,23 +7,22 @@ * Status: Draft * Content-Type: markdown * Created: 27/07/2021 -* +TUF-Version: -* +Post-History: +* TUF-Version: # Abstract -In order to achieve end-to-end software update security, TUF requires developers to sign updates with a private key. However, this has proven challenging for some implementers as developers then have to create, store, and secure these private keys in order to ensure they remain private. This TAP proposes using Sigstore’s Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. Targets roles may delegate to Fulcio identities instead of private keys, and these identities, and the corresponding certificates can be used for verification. +In order to achieve end-to-end software update security, TUF requires developers to sign updates with a private key. However, this has proven challenging for some implementers as developers then have to create, store, and secure these private keys in order to ensure they remain private. This TAP proposes using Sigstore’s Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. TUF targets roles may delegate to Fulcio identities instead of private keys, and these identities, and the corresponding certificates can be used for verification. # Motivation Developer key management has been a major concern for TUF adoptions, especially for projects with a small number of developers or limited resources. TUF currently requires that every targets metadata signer creates and manages a private key. However, many developers in large TUF adoptions, including PyPI, do not want the extra burden of protecting a private key for use in deployment. -Protecting a private key from loss or compromise is no simple matter. [Several](https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm) [attacks](https://jsoverson.medium.com/how-two-malicious-npm-packages-targeted-sabotaged-one-other-fed7199099c8) on software update systems have been achieved through the use of a compromised key, as securing private keys can be challenging and sometimes expensive (yubikeys etc). +Protecting a private key from loss or compromise is no simple matter. [Several](https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm) [attacks](https://jsoverson.medium.com/how-two-malicious-npm-packages-targeted-sabotaged-one-other-fed7199099c8) on software update systems have been achieved through the use of a compromised key, as securing private keys can be challenging and sometimes expensive (using hardware tokens such as Yubikeys etc), especially over a period of time. This TAP proposes a way for developers to use their existing OpenID Connect (OIDC) accounts – such as an email account – to verify their identity, so that they do not have to manage any additional keys or passwords. # Rationale -In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://www.minilock.io) - a tool which derives ed25519 keys from a user-chosen passphrase – to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is no longer maintained. +In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://www.minilock.io) - a tool which derives ed25519 keys from a user-chosen passphrase - to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is [no longer maintained](https://github.com/kaepora/miniLock). -In this TAP, we instead propose use of the Sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides two services, Fuclio (a WebPKI) and Rekor (a transparency log). With sigstore, short-lived keys do not need to be secured as they are only valid for a small window. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. +In this TAP, we instead propose use of the sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides two services, [Fulcio](https://github.com/sigstore/fulcio) (a WebPKI) and [Rekor](https://github.com/sigstore/rekor) (a transparency log). With sigstore, short-lived keys do not need to be secured as they are only valid for a small window of time. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. # Specification In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to developer email addresses, to be verified by Fulcio. These delegations MAY replace ed25519 keys for developers in order to simplify their key management. Fulcio generates short-lived signing certificates backed by OIDC authentication of a developer’s email address. Because the certificates are short-lived, the developer will not be responsible for protecting this key in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. From a509f6da18de74e60afce5ffc12bd0cfd5de1b16 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Tue, 31 Aug 2021 15:07:53 -0400 Subject: [PATCH 04/33] Apply suggestions from code review Co-authored-by: axel simon --- candidate-fulcio-tap.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 67aa027d..a3145f4b 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -22,7 +22,7 @@ This TAP proposes a way for developers to use their existing OpenID Connect (OID # Rationale In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://www.minilock.io) - a tool which derives ed25519 keys from a user-chosen passphrase - to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is [no longer maintained](https://github.com/kaepora/miniLock). -In this TAP, we instead propose use of the sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides two services, [Fulcio](https://github.com/sigstore/fulcio) (a WebPKI) and [Rekor](https://github.com/sigstore/rekor) (a transparency log). With sigstore, short-lived keys do not need to be secured as they are only valid for a small window of time. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. +In this TAP, we instead propose use of the sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides two services, [Fulcio](https://github.com/sigstore/fulcio) (a WebPKI) and [Rekor](https://github.com/sigstore/rekor) (a transparency log). With sigstore, long-term efforts to keep private keys secure are not necessary, as short-lived keys are only valid for a small window of time. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. # Specification In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to developer email addresses, to be verified by Fulcio. These delegations MAY replace ed25519 keys for developers in order to simplify their key management. Fulcio generates short-lived signing certificates backed by OIDC authentication of a developer’s email address. Because the certificates are short-lived, the developer will not be responsible for protecting this key in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. @@ -41,9 +41,9 @@ In order to facilitate use of Fulcio, delegations may list an email address and } ``` -Where SERVER is the Fulcio server used to generate the certificate, EMAIL is the identity of the party who is authorized to sign, and ISSUER is the OIDC entity used by Fulcio for verification. The client MUST establish trust in the Fulcio server using a trusted channel before using it for verification (see Verification) +Where SERVER is the Fulcio server used to generate the certificate, EMAIL is the identity of the party who is authorized to sign, and ISSUER is the OIDC entity used by Fulcio for verification. The client MUST establish trust in the Fulcio server using a trusted channel before using it for verification (see Verification). -Using this mechanism, the developer requests a certificate from Fulcio, verifies their identity using OIDC, uses the certificate to sign their targets metadata, and uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Fulcio root key using a secure offline method. +Using this mechanism, the developer requests a certificate from Fulcio, verifies their identity using OIDC, uses the certificate to sign their targets metadata, and uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Fulcio root key using a secure offline method prior to verifying the signature and associated certificate. ## Signature format @@ -71,7 +71,7 @@ In order to sign metadata using Fulcio, a developer would: The repository would: * automatically perform verification (see below) with Fulcio and the transparency log to ensure that the certificate is current and valid. -Most of these steps SHOULD be done automatically using a tool, to simplify operations for developers. +Most of these steps SHOULD be done automatically using a tool, to simplify operations for developers and minimise the risk of human errors. ## Verification @@ -80,7 +80,7 @@ While performing the steps in the [TUF client workflow](https://theupdateframewo In addition, the repository MUST, and clients SHOULD additionally query the transparency log to ensure that the Fulcio certificate is valid at the time that it was used. ## Auditors -Developers should monitor the TL for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer should replace any compromised metadata, and report the compromise to the maintainers of the Fulcio server and any targets metadata owners who delegate to the compromised account. +Developers should monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer should replace any compromised metadata, and report the compromise to the maintainers of the Fulcio server and any targets metadata owners who delegate to the compromised account. In addition to developer monitoring, the TL should have auditors that watch the log for any suspicious activity. If something bad is found in the TL, then auditors must indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata before verifying any Fulcio-signed delegated targets. The auditor only signs metadata if all signatures in the TL look good. If the auditor detects a problem, they may revoke the auditor-signed metadata. From 54801342da317720850427835b95ce91be2feadf Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Tue, 31 Aug 2021 15:12:00 -0400 Subject: [PATCH 05/33] [Fulcio TAP] Generalize email to OIDC identity Fulcio can use any OIDC identity. This changes the metadata format to reflect this. Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index a3145f4b..e327cdf2 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -28,20 +28,20 @@ In this TAP, we instead propose use of the sigstore project. Sigstore has a grow In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to developer email addresses, to be verified by Fulcio. These delegations MAY replace ed25519 keys for developers in order to simplify their key management. Fulcio generates short-lived signing certificates backed by OIDC authentication of a developer’s email address. Because the certificates are short-lived, the developer will not be responsible for protecting this key in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. ## Delegation format -In order to facilitate use of Fulcio, delegations may list an email address and location of a Fulcio server instead of a public key. So, this TAP adds a “sigstore-oidc" keytype for a KEY with the following format: +In order to facilitate use of Fulcio, delegations may list an OIDC identity, such as an email address, and location of a Fulcio server instead of a public key. So, this TAP adds a “sigstore-oidc" keytype for a KEY with the following format: ``` { “keytype”: “sigstore-oidc", “scheme”: SERVER, “keyval”: { - “email”: EMAIL, + “identity”: IDENTITY, “issuer”: ISSUER } } ``` -Where SERVER is the Fulcio server used to generate the certificate, EMAIL is the identity of the party who is authorized to sign, and ISSUER is the OIDC entity used by Fulcio for verification. The client MUST establish trust in the Fulcio server using a trusted channel before using it for verification (see Verification). +Where SERVER is the Fulcio server used to generate the certificate, IDENTITY is the OIDC identity of the party who is authorized to sign, and ISSUER is the OIDC entity used by Fulcio for verification. The client MUST establish trust in the Fulcio server using a trusted channel before using it for verification (see Verification). Using this mechanism, the developer requests a certificate from Fulcio, verifies their identity using OIDC, uses the certificate to sign their targets metadata, and uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Fulcio root key using a secure offline method prior to verifying the signature and associated certificate. From c31cc6dfea5fb6beb743e23da19a5c9cb65bc190 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Fri, 10 Sep 2021 12:43:55 -0400 Subject: [PATCH 06/33] Add explicit recomendation to use auditors for the TL Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index e327cdf2..b9d308f5 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -88,11 +88,11 @@ If the bad certificates are due to a compromised Fulcio server, the Fulcio serve # Security Analysis -This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds 2 additional services that may be compromised: the Fulcio server and the transparency log. In this section, we will analyse the impact and recovery in each of these cases. +This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds 2 additional services that may be compromised: the Fulcio server and the transparency log. In this section, we will analyze the impact and recovery in each of these cases. If the Fulcio server is compromised, it may issue certificates on behalf of any developer who uses Fulcio to verify their identity. However, the Fulcio server is backed by offline keys that are signed by TUF root keys, and so it is possible to recover from any server compromise. Additionally, all Fulcio certificates are published to a transparency log, so auditors will notice if the Fulcio server is misbehaving and indicate this to users, for example through the use of auditor-signed metadata. -If only the transparency log is compromised, the attacker will not be able to do anything without cooperation from the Fulcio server. However, if the attacker compromises both the Fulcio server and the transparency log, they would be able to issue fake Fulcio certificates that also appear valid on the transparency log. If this happens, developers auditing the transparency log would notice the mis-issued certificates, and the Fulcio server and transparency log could both be recovered using offline root keys. +If only the transparency log is compromised, the attacker will not be able to do anything without cooperation from the Fulcio server. However, if the attacker compromises both the Fulcio server and the transparency log, they would be able to issue fake Fulcio certificates that also appear valid on the transparency log. If this happens, developers auditing the transparency log would notice the mis-issued certificates, and the Fulcio server and transparency log could both be recovered using offline root keys. Implementations using this TAP SHOULD ensure that there are active auditors watching the transparency log. # Backwards Compatibility From 07fc2298ca4df26bc67fcb56125eb213d289fd62 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Fri, 10 Sep 2021 13:40:22 -0400 Subject: [PATCH 07/33] Add OIDC compromise to security analysis Also clarify that auditors may use TAP 3 multi-role delegations Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index b9d308f5..6b36a49c 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -56,7 +56,7 @@ A signature using a Fulcio key should include the Fulcio certificate for use in “cert”: CERTIFICATE } , ... ] ``` -Where CERTIFICATE is a Fulcio signing certificate in PEM format. CERTIFICATE MUST be uploaded to a timestamped transparency log upon creation. +Where CERTIFICATE is a Fulcio x509 signing certificate in PEM format. CERTIFICATE MUST be uploaded to a timestamped transparency log upon creation. ## Signing In order to sign metadata using Fulcio, a developer would: @@ -90,7 +90,9 @@ If the bad certificates are due to a compromised Fulcio server, the Fulcio serve This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds 2 additional services that may be compromised: the Fulcio server and the transparency log. In this section, we will analyze the impact and recovery in each of these cases. -If the Fulcio server is compromised, it may issue certificates on behalf of any developer who uses Fulcio to verify their identity. However, the Fulcio server is backed by offline keys that are signed by TUF root keys, and so it is possible to recover from any server compromise. Additionally, all Fulcio certificates are published to a transparency log, so auditors will notice if the Fulcio server is misbehaving and indicate this to users, for example through the use of auditor-signed metadata. +If a developer's OIDC credentials are compromised, the developer should use existing TUF processes for revocation. Specifically they should ask the delegator to replace any metadata that includes the compromised OIDC account. + +If the Fulcio server is compromised, it may issue certificates on behalf of any developer who uses Fulcio to verify their identity. However, the Fulcio server is backed by offline keys that are signed by TUF root keys, and so it is possible to recover from any server compromise. Additionally, all Fulcio certificates are published to a transparency log, so auditors will notice if the Fulcio server is misbehaving and indicate this to users, for example through the use of [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) to a threshold of both auditor-signed metadata and developer-signed metadata. If only the transparency log is compromised, the attacker will not be able to do anything without cooperation from the Fulcio server. However, if the attacker compromises both the Fulcio server and the transparency log, they would be able to issue fake Fulcio certificates that also appear valid on the transparency log. If this happens, developers auditing the transparency log would notice the mis-issued certificates, and the Fulcio server and transparency log could both be recovered using offline root keys. Implementations using this TAP SHOULD ensure that there are active auditors watching the transparency log. From 22c70e7f6b3dc87c805d0daea30ebfaaeefca514 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Mon, 29 Nov 2021 11:39:01 -0500 Subject: [PATCH 08/33] Clarify use of multi-role delegations Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 6b36a49c..9a29e938 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -82,7 +82,7 @@ In addition, the repository MUST, and clients SHOULD additionally query the tran ## Auditors Developers should monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer should replace any compromised metadata, and report the compromise to the maintainers of the Fulcio server and any targets metadata owners who delegate to the compromised account. -In addition to developer monitoring, the TL should have auditors that watch the log for any suspicious activity. If something bad is found in the TL, then auditors must indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata before verifying any Fulcio-signed delegated targets. The auditor only signs metadata if all signatures in the TL look good. If the auditor detects a problem, they may revoke the auditor-signed metadata. +In addition to developer monitoring, the TL should have auditors that watch the log for any suspicious activity. If something bad is found in the TL, then auditors must indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using multi-role delegations before verifying any Fulcio-signed delegated targets. The auditor only signs metadata if all signatures in the TL look good. If the auditor detects a problem, they may revoke the auditor-signed metadata. If the bad certificates are due to a compromised Fulcio server, the Fulcio server SHOULD be revoked using the root of trust. From 5bbab5d7ef24190ed7ca5af6352af2ff6cebf5ed Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Mon, 29 Nov 2021 11:58:24 -0500 Subject: [PATCH 09/33] Apply suggestions from code review adds consistent capitalization and some clarifications Co-authored-by: axel simon --- candidate-fulcio-tap.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 9a29e938..b115bd1c 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -1,5 +1,5 @@ * TAP: -* Title: Ephemeral identity verification using Sigstore's Fulcio for TUF developer key management +* Title: Ephemeral identity verification using sigstore's Fulcio for TUF developer key management * Version: 0 * Last-Modified: 27/07/2021 * Author: Marina Moore, Joshua Lock, Asra Ali, Luke Hinds, Jussi Kukkonen, Trishank Kuppusamy, axel simon @@ -10,17 +10,17 @@ * TUF-Version: # Abstract -In order to achieve end-to-end software update security, TUF requires developers to sign updates with a private key. However, this has proven challenging for some implementers as developers then have to create, store, and secure these private keys in order to ensure they remain private. This TAP proposes using Sigstore’s Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. TUF targets roles may delegate to Fulcio identities instead of private keys, and these identities, and the corresponding certificates can be used for verification. +In order to achieve end-to-end software update security, TUF requires developers to sign updates with a private key. However, this has proven challenging for some implementers as developers then have to create, store, and secure these private keys in order to ensure they remain private. This TAP proposes using sigstore’s Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. TUF "targets" roles may delegate to Fulcio identities instead of private keys, and these identities (and the corresponding certificates) may be used for verification. # Motivation -Developer key management has been a major concern for TUF adoptions, especially for projects with a small number of developers or limited resources. TUF currently requires that every targets metadata signer creates and manages a private key. However, many developers in large TUF adoptions, including PyPI, do not want the extra burden of protecting a private key for use in deployment. +Developer key management has been a major concern for TUF adoptions, especially for projects with a small number of developers or limited resources. TUF currently requires that every targets metadata signer creates and manages a private key. However, many developers in large TUF adoptions, including the Python Package Index (PyPI), do not want the extra burden of having to protect a private key for use in deployment. Protecting a private key from loss or compromise is no simple matter. [Several](https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm) [attacks](https://jsoverson.medium.com/how-two-malicious-npm-packages-targeted-sabotaged-one-other-fed7199099c8) on software update systems have been achieved through the use of a compromised key, as securing private keys can be challenging and sometimes expensive (using hardware tokens such as Yubikeys etc), especially over a period of time. This TAP proposes a way for developers to use their existing OpenID Connect (OIDC) accounts – such as an email account – to verify their identity, so that they do not have to manage any additional keys or passwords. # Rationale -In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://www.minilock.io) - a tool which derives ed25519 keys from a user-chosen passphrase - to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is [no longer maintained](https://github.com/kaepora/miniLock). +In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://www.minilock.io) – a tool which derives ed25519 keys from a user-chosen passphrase – to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is [no longer maintained](https://github.com/kaepora/miniLock) and has been archived. In this TAP, we instead propose use of the sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides two services, [Fulcio](https://github.com/sigstore/fulcio) (a WebPKI) and [Rekor](https://github.com/sigstore/rekor) (a transparency log). With sigstore, long-term efforts to keep private keys secure are not necessary, as short-lived keys are only valid for a small window of time. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. @@ -28,7 +28,7 @@ In this TAP, we instead propose use of the sigstore project. Sigstore has a grow In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to developer email addresses, to be verified by Fulcio. These delegations MAY replace ed25519 keys for developers in order to simplify their key management. Fulcio generates short-lived signing certificates backed by OIDC authentication of a developer’s email address. Because the certificates are short-lived, the developer will not be responsible for protecting this key in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. ## Delegation format -In order to facilitate use of Fulcio, delegations may list an OIDC identity, such as an email address, and location of a Fulcio server instead of a public key. So, this TAP adds a “sigstore-oidc" keytype for a KEY with the following format: +In order to facilitate use of Fulcio, delegations may list an OIDC identity, such as an email address, and location of a Fulcio server instead of a public key. To do so, this TAP adds a “sigstore-oidc" keytype for a KEY with the following format: ``` { @@ -88,11 +88,11 @@ If the bad certificates are due to a compromised Fulcio server, the Fulcio serve # Security Analysis -This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds 2 additional services that may be compromised: the Fulcio server and the transparency log. In this section, we will analyze the impact and recovery in each of these cases. +This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds 2 additional services that may be compromised: the Fulcio server and the Rekor transparency log. In this section, we will analyze the impact and recovery in each of these cases. If a developer's OIDC credentials are compromised, the developer should use existing TUF processes for revocation. Specifically they should ask the delegator to replace any metadata that includes the compromised OIDC account. -If the Fulcio server is compromised, it may issue certificates on behalf of any developer who uses Fulcio to verify their identity. However, the Fulcio server is backed by offline keys that are signed by TUF root keys, and so it is possible to recover from any server compromise. Additionally, all Fulcio certificates are published to a transparency log, so auditors will notice if the Fulcio server is misbehaving and indicate this to users, for example through the use of [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) to a threshold of both auditor-signed metadata and developer-signed metadata. +If the Fulcio server is compromised, it may issue certificates on behalf of any attacker who uses Fulcio to verify their identity. However, the Fulcio server is backed by offline keys that are signed by TUF root keys, and so it is possible to recover from any Fulcio server compromise. Additionally, all Fulcio certificates are published to a transparency log, so auditors will notice if the Fulcio server is misbehaving and indicate this to users, for example through the use of [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) to a threshold of both auditor-signed metadata and developer-signed metadata. If only the transparency log is compromised, the attacker will not be able to do anything without cooperation from the Fulcio server. However, if the attacker compromises both the Fulcio server and the transparency log, they would be able to issue fake Fulcio certificates that also appear valid on the transparency log. If this happens, developers auditing the transparency log would notice the mis-issued certificates, and the Fulcio server and transparency log could both be recovered using offline root keys. Implementations using this TAP SHOULD ensure that there are active auditors watching the transparency log. From 3f3a67a838cce7a6b74e482cc9845e35cec09ae8 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Mon, 29 Nov 2021 12:00:22 -0500 Subject: [PATCH 10/33] capitalize shoulds and musts Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index b115bd1c..5ea4706f 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -47,7 +47,7 @@ Using this mechanism, the developer requests a certificate from Fulcio, verifies ## Signature format -A signature using a Fulcio key should include the Fulcio certificate for use in verification. For this verification, this TAP adds a ‘cert’ field to ‘signatures’. With this field, signatures would look like: +A signature using a Fulcio key MUST include the Fulcio certificate for use in verification. For this verification, this TAP adds a ‘cert’ field to ‘signatures’. With this field, signatures would look like: ``` "signatures" : [ @@ -75,22 +75,22 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification -While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to SERVER. Additionally, they must ensure that SERVER is a known, trusted Fulcio root. The trusted Fulcio root MUST be communicated to the client using a secure channel before the update process, such as metadata signed by an offline root key or during initial client configuration. +While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to SERVER. Additionally, they MUST ensure that SERVER is a known, trusted Fulcio root. The trusted Fulcio root MUST be communicated to the client using a secure channel before the update process, such as metadata signed by an offline root key or during initial client configuration. In addition, the repository MUST, and clients SHOULD additionally query the transparency log to ensure that the Fulcio certificate is valid at the time that it was used. ## Auditors -Developers should monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer should replace any compromised metadata, and report the compromise to the maintainers of the Fulcio server and any targets metadata owners who delegate to the compromised account. +Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata, and report the compromise to the maintainers of the Fulcio server and any targets metadata owners who delegate to the compromised account. -In addition to developer monitoring, the TL should have auditors that watch the log for any suspicious activity. If something bad is found in the TL, then auditors must indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using multi-role delegations before verifying any Fulcio-signed delegated targets. The auditor only signs metadata if all signatures in the TL look good. If the auditor detects a problem, they may revoke the auditor-signed metadata. +In addition to developer monitoring, the TL SHOULD have auditors that watch the log for any suspicious activity. If something bad is found in the TL, then auditors MUST indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using multi-role delegations before verifying any Fulcio-signed delegated targets. The auditor only signs metadata if all signatures in the TL look good. If the auditor detects a problem, they may revoke the auditor-signed metadata. -If the bad certificates are due to a compromised Fulcio server, the Fulcio server SHOULD be revoked using the root of trust. +If the bad certificates are due to a compromised Fulcio server, the Fulcio server MUST be revoked using the root of trust. # Security Analysis This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds 2 additional services that may be compromised: the Fulcio server and the Rekor transparency log. In this section, we will analyze the impact and recovery in each of these cases. -If a developer's OIDC credentials are compromised, the developer should use existing TUF processes for revocation. Specifically they should ask the delegator to replace any metadata that includes the compromised OIDC account. +If a developer's OIDC credentials are compromised, the developer SHOULD use existing TUF processes for revocation. Specifically they SHOULD ask the delegator to replace any metadata that includes the compromised OIDC account. If the Fulcio server is compromised, it may issue certificates on behalf of any attacker who uses Fulcio to verify their identity. However, the Fulcio server is backed by offline keys that are signed by TUF root keys, and so it is possible to recover from any Fulcio server compromise. Additionally, all Fulcio certificates are published to a transparency log, so auditors will notice if the Fulcio server is misbehaving and indicate this to users, for example through the use of [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) to a threshold of both auditor-signed metadata and developer-signed metadata. From 1cb0ba69ab4269deda00588d64c95c6db78185fa Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Tue, 30 Nov 2021 11:13:36 -0500 Subject: [PATCH 11/33] Update candidate-fulcio-tap.md Co-authored-by: axel simon --- candidate-fulcio-tap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 5ea4706f..9a600317 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -77,7 +77,7 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to SERVER. Additionally, they MUST ensure that SERVER is a known, trusted Fulcio root. The trusted Fulcio root MUST be communicated to the client using a secure channel before the update process, such as metadata signed by an offline root key or during initial client configuration. -In addition, the repository MUST, and clients SHOULD additionally query the transparency log to ensure that the Fulcio certificate is valid at the time that it was used. +In addition, the repository MUST, and clients SHOULD additionally query the transparency log to ensure that the Fulcio certificate is valid at the time that it was used. This may be done by directly querying the transparency log or, in cases where online verification is not possible, via the use of stapled inclusion proofs, evidence gathered by the signer from the log and presented alongside the software and signature. ## Auditors Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata, and report the compromise to the maintainers of the Fulcio server and any targets metadata owners who delegate to the compromised account. From f6f9312257a3a28f75e7ac639f975a2c6d662a53 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 16 Dec 2021 11:42:59 -0500 Subject: [PATCH 12/33] [Fulcio TAP] Add link to augmented reference implementation Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 9a600317..547ecece 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -105,7 +105,7 @@ Clients that do not recognize Fulcio certs will not be able to validate signatur # Augmented Reference Implementation -TODO +The pull request [#181](https://github.com/theupdateframework/go-tuf/pull/181) in go-tuf adds this feature. # Copyright This document has been placed in the public domain. From 61f2cc93415b2694682cfce4a6c3d8319e774213 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Mon, 10 Jan 2022 15:12:38 -0500 Subject: [PATCH 13/33] [fulcio TAP] clarify auditor signatures and revocation Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 547ecece..0657455d 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -82,7 +82,7 @@ In addition, the repository MUST, and clients SHOULD additionally query the tran ## Auditors Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata, and report the compromise to the maintainers of the Fulcio server and any targets metadata owners who delegate to the compromised account. -In addition to developer monitoring, the TL SHOULD have auditors that watch the log for any suspicious activity. If something bad is found in the TL, then auditors MUST indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using multi-role delegations before verifying any Fulcio-signed delegated targets. The auditor only signs metadata if all signatures in the TL look good. If the auditor detects a problem, they may revoke the auditor-signed metadata. +In addition to developer monitoring, the TL SHOULD have auditors that watch the log for any suspicious activity. If something bad is found in the TL, then auditors MUST indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using multi-role delegations before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. If the bad certificates are due to a compromised Fulcio server, the Fulcio server MUST be revoked using the root of trust. From e8e61117447d8af7e4a28a273600f4a8d3917d89 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Tue, 22 Mar 2022 10:02:47 -0700 Subject: [PATCH 14/33] Add clarifications about verification Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 0657455d..a8b624e6 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -43,7 +43,7 @@ In order to facilitate use of Fulcio, delegations may list an OIDC identity, suc Where SERVER is the Fulcio server used to generate the certificate, IDENTITY is the OIDC identity of the party who is authorized to sign, and ISSUER is the OIDC entity used by Fulcio for verification. The client MUST establish trust in the Fulcio server using a trusted channel before using it for verification (see Verification). -Using this mechanism, the developer requests a certificate from Fulcio, verifies their identity using OIDC, uses the certificate to sign their targets metadata, and uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Fulcio root key using a secure offline method prior to verifying the signature and associated certificate. +Using this mechanism, the developer requests a certificate from Fulcio, verifies their identity using OIDC, uses the certificate to sign their targets metadata, and uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Fulcio and Rekor root keys using a secure offline method prior to verifying the signature and associated certificate. ## Signature format @@ -77,10 +77,10 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to SERVER. Additionally, they MUST ensure that SERVER is a known, trusted Fulcio root. The trusted Fulcio root MUST be communicated to the client using a secure channel before the update process, such as metadata signed by an offline root key or during initial client configuration. -In addition, the repository MUST, and clients SHOULD additionally query the transparency log to ensure that the Fulcio certificate is valid at the time that it was used. This may be done by directly querying the transparency log or, in cases where online verification is not possible, via the use of stapled inclusion proofs, evidence gathered by the signer from the log and presented alongside the software and signature. +In addition, the repository MUST, and clients SHOULD additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was used. This may be done by directly querying the transparency log or, in cases where online verification is not possible, via the use of stapled inclusion proofs, evidence gathered by the signer from the log and presented alongside the software and signature. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Fulcio and Rekor roots. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). ## Auditors -Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata, and report the compromise to the maintainers of the Fulcio server and any targets metadata owners who delegate to the compromised account. +Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and report the compromise to any targets metadata owners who delegate to the compromised account. In addition to developer monitoring, the TL SHOULD have auditors that watch the log for any suspicious activity. If something bad is found in the TL, then auditors MUST indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using multi-role delegations before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. From c64897730a21030fd0419f23a8a7c18a779c7ab1 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Wed, 30 Mar 2022 16:45:34 -0400 Subject: [PATCH 15/33] Move Fulcio root cert to delegating metadata Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index a8b624e6..3ceba661 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -22,10 +22,10 @@ This TAP proposes a way for developers to use their existing OpenID Connect (OID # Rationale In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://www.minilock.io) – a tool which derives ed25519 keys from a user-chosen passphrase – to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is [no longer maintained](https://github.com/kaepora/miniLock) and has been archived. -In this TAP, we instead propose use of the sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides two services, [Fulcio](https://github.com/sigstore/fulcio) (a WebPKI) and [Rekor](https://github.com/sigstore/rekor) (a transparency log). With sigstore, long-term efforts to keep private keys secure are not necessary, as short-lived keys are only valid for a small window of time. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. +In this TAP, we instead propose use of the sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides a few services, including [Fulcio](https://github.com/sigstore/fulcio) (a WebPKI) and [Rekor](https://github.com/sigstore/rekor) (a transparency log). With sigstore, long-term efforts to keep private keys secure are not necessary, as short-lived keys are only valid for a small window of time. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. # Specification -In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to developer email addresses, to be verified by Fulcio. These delegations MAY replace ed25519 keys for developers in order to simplify their key management. Fulcio generates short-lived signing certificates backed by OIDC authentication of a developer’s email address. Because the certificates are short-lived, the developer will not be responsible for protecting this key in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. +In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to developer email addresses, to be verified by Fulcio. These delegations MAY replace public keys for developers (such as ed25519 keys) in order to simplify their key management. Fulcio generates short-lived signing certificates backed by OIDC authentication of a developer’s email address. Because the certificates are short-lived, the developer will not be responsible for protecting this key in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. ## Delegation format In order to facilitate use of Fulcio, delegations may list an OIDC identity, such as an email address, and location of a Fulcio server instead of a public key. To do so, this TAP adds a “sigstore-oidc" keytype for a KEY with the following format: @@ -33,17 +33,18 @@ In order to facilitate use of Fulcio, delegations may list an OIDC identity, suc ``` { “keytype”: “sigstore-oidc", - “scheme”: SERVER, + “scheme”: "Fulcio", “keyval”: { “identity”: IDENTITY, - “issuer”: ISSUER + “issuer”: ISSUER, + "root-cert": ROOT_CERTIFICATE } } ``` -Where SERVER is the Fulcio server used to generate the certificate, IDENTITY is the OIDC identity of the party who is authorized to sign, and ISSUER is the OIDC entity used by Fulcio for verification. The client MUST establish trust in the Fulcio server using a trusted channel before using it for verification (see Verification). +Where IDENTITY is the OIDC identity of the party who is authorized to sign, ISSUER is the OIDC entity used by Fulcio for verification, and ROOT_CERTIFICATE is the root certificate for this Fulcio server. -Using this mechanism, the developer requests a certificate from Fulcio, verifies their identity using OIDC, uses the certificate to sign their targets metadata, and uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Fulcio and Rekor root keys using a secure offline method prior to verifying the signature and associated certificate. +Using this mechanism, the developer requests a certificate from Fulcio, verifies their identity using OIDC, uses the certificate to sign their targets metadata, and uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Rekor root keys using a secure offline method prior to verifying the signature and associated certificate. ## Signature format @@ -75,7 +76,7 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification -While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to SERVER. Additionally, they MUST ensure that SERVER is a known, trusted Fulcio root. The trusted Fulcio root MUST be communicated to the client using a secure channel before the update process, such as metadata signed by an offline root key or during initial client configuration. +While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to ROOT_CERTIFICATE. In addition, the repository MUST, and clients SHOULD additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was used. This may be done by directly querying the transparency log or, in cases where online verification is not possible, via the use of stapled inclusion proofs, evidence gathered by the signer from the log and presented alongside the software and signature. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Fulcio and Rekor roots. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). From cbf1e06316dd8e29a06f701c669b198cc66742ca Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Wed, 30 Mar 2022 16:58:30 -0400 Subject: [PATCH 16/33] Add detail about verifying with Rekor Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 3ceba661..25d77ed7 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -78,7 +78,9 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to ROOT_CERTIFICATE. -In addition, the repository MUST, and clients SHOULD additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was used. This may be done by directly querying the transparency log or, in cases where online verification is not possible, via the use of stapled inclusion proofs, evidence gathered by the signer from the log and presented alongside the software and signature. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Fulcio and Rekor roots. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). +In addition, the repository MUST, and clients SHOULD additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was used. To do the user can directly querying the transparency log for the Fulcio certificate. They can then verify that the certificate was uploaded to the Rekor, and use the timestamp in Rekor to verify that the key was valid at the time it was used to sign TUF metadata. + +In cases where online verification is not possible, stapled inclusion proofs, evidence gathered by the signer from the log, may be presented alongside the software and signature. The user may use these proofs instead of directly querying Rekor's transparecy log. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Rekor root. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). ## Auditors Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and report the compromise to any targets metadata owners who delegate to the compromised account. From cc4d9a451f534e2e678ead16934afa76b1322519 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Wed, 30 Mar 2022 17:50:55 -0400 Subject: [PATCH 17/33] Apply suggestions from code review Co-authored-by: Trishank Karthik Kuppusamy --- candidate-fulcio-tap.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 25d77ed7..40289e6c 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -78,9 +78,9 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to ROOT_CERTIFICATE. -In addition, the repository MUST, and clients SHOULD additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was used. To do the user can directly querying the transparency log for the Fulcio certificate. They can then verify that the certificate was uploaded to the Rekor, and use the timestamp in Rekor to verify that the key was valid at the time it was used to sign TUF metadata. +In addition, the repository MUST, and clients SHOULD additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was used. To do the user can directly query the transparency log for the Fulcio certificate. They can then verify that the certificate was uploaded to the Rekor, and use the timestamp in Rekor to verify that the key was valid at the time it was used to sign TUF metadata. -In cases where online verification is not possible, stapled inclusion proofs, evidence gathered by the signer from the log, may be presented alongside the software and signature. The user may use these proofs instead of directly querying Rekor's transparecy log. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Rekor root. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). +In cases where online verification is not possible, stapled inclusion proofs (i.e., evidence gathered by the signer from the log) MAY be presented alongside the software and signature. The user MAY use these proofs instead of directly querying Rekor's transparecy log. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Rekor root. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). ## Auditors Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and report the compromise to any targets metadata owners who delegate to the compromised account. From a680f56239827a7b47bb9fe1e280ba85dc5f9799 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 28 Apr 2022 15:09:16 -0400 Subject: [PATCH 18/33] client check SHOULD -> MAY Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 40289e6c..83aa5ad1 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -78,7 +78,7 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to ROOT_CERTIFICATE. -In addition, the repository MUST, and clients SHOULD additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was used. To do the user can directly query the transparency log for the Fulcio certificate. They can then verify that the certificate was uploaded to the Rekor, and use the timestamp in Rekor to verify that the key was valid at the time it was used to sign TUF metadata. +In addition, the repository MUST, and clients MAY additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was used. To do the user can directly query the transparency log for the Fulcio certificate. They can then verify that the certificate was uploaded to the Rekor, and use the timestamp in Rekor to verify that the key was valid at the time it was used to sign TUF metadata. In cases where online verification is not possible, stapled inclusion proofs (i.e., evidence gathered by the signer from the log) MAY be presented alongside the software and signature. The user MAY use these proofs instead of directly querying Rekor's transparecy log. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Rekor root. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). From eb50378a4d539b6897e47ad8998bde72bab9444f Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Fri, 24 Jun 2022 10:25:40 -0500 Subject: [PATCH 19/33] Clarify when Fulcio certs should be valid Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 83aa5ad1..8bb69953 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -78,9 +78,9 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to ROOT_CERTIFICATE. -In addition, the repository MUST, and clients MAY additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was used. To do the user can directly query the transparency log for the Fulcio certificate. They can then verify that the certificate was uploaded to the Rekor, and use the timestamp in Rekor to verify that the key was valid at the time it was used to sign TUF metadata. +In addition, the repository MUST, and clients MAY additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was issued. To do so the user can directly query the transparency log for the Fulcio certificate. They can then verify that the certificate was uploaded to the Rekor, and use the timestamp in Rekor to verify that the key was valid at the time it was used to sign TUF metadata. -In cases where online verification is not possible, stapled inclusion proofs (i.e., evidence gathered by the signer from the log) MAY be presented alongside the software and signature. The user MAY use these proofs instead of directly querying Rekor's transparecy log. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Rekor root. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). +In cases where online verification is not possible, stapled inclusion proofs (i.e., evidence gathered by the signer from the log) MAY be presented alongside the software and signature. The client MAY use these proofs instead of directly querying Rekor's transparecy log. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Rekor root. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). ## Auditors Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and report the compromise to any targets metadata owners who delegate to the compromised account. From 4910aa0f26784e23f2461bed32cb400febacbe28 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Tue, 26 Jul 2022 11:01:07 -0400 Subject: [PATCH 20/33] [Fulcio TAP] Remove Rekor requirement If certificates are uploaded while they are valid, the Rekor check is not needed. This commit also clarifies the tradeoffs for clients deciding whether to check Rekor directly. Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 8bb69953..8e116102 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -15,7 +15,7 @@ In order to achieve end-to-end software update security, TUF requires developers # Motivation Developer key management has been a major concern for TUF adoptions, especially for projects with a small number of developers or limited resources. TUF currently requires that every targets metadata signer creates and manages a private key. However, many developers in large TUF adoptions, including the Python Package Index (PyPI), do not want the extra burden of having to protect a private key for use in deployment. -Protecting a private key from loss or compromise is no simple matter. [Several](https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm) [attacks](https://jsoverson.medium.com/how-two-malicious-npm-packages-targeted-sabotaged-one-other-fed7199099c8) on software update systems have been achieved through the use of a compromised key, as securing private keys can be challenging and sometimes expensive (using hardware tokens such as Yubikeys etc), especially over a period of time. +Protecting a private key from loss or compromise is no simple matter. [Several](https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm) [attacks](https://jsoverson.medium.com/how-two-malicious-npm-packages-targeted-sabotaged-one-other-fed7199099c8) on software update systems have been achieved through the use of a compromised key, as securing private keys can be challenging and sometimes expensive (using hardware tokens such as Yubikeys etc), especially over a period of time. This TAP proposes a way for developers to use their existing OpenID Connect (OIDC) accounts – such as an email account – to verify their identity, so that they do not have to manage any additional keys or passwords. @@ -70,7 +70,7 @@ In order to sign metadata using Fulcio, a developer would: * Upload the metadata to the repository The repository would: -* automatically perform verification (see below) with Fulcio and the transparency log to ensure that the certificate is current and valid. +* automatically perform verification (see below) with Fulcio and the transparency log to ensure that the certificate is current and valid. If the signature is uploaded to the repository during the validity window of the Fulcio certificate, the repository MAY skip the Rekor timestamp verification. Most of these steps SHOULD be done automatically using a tool, to simplify operations for developers and minimise the risk of human errors. @@ -78,12 +78,12 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to ROOT_CERTIFICATE. -In addition, the repository MUST, and clients MAY additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was issued. To do so the user can directly query the transparency log for the Fulcio certificate. They can then verify that the certificate was uploaded to the Rekor, and use the timestamp in Rekor to verify that the key was valid at the time it was used to sign TUF metadata. +In addition, the repository SHOULD, and clients MAY additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was issued. To do so the user can directly query the transparency log for the Fulcio certificate. They can then verify that the certificate was uploaded to the Rekor, and use the timestamp in Rekor to verify that the key was valid at the time it was used to sign TUF metadata. The repository SHOULD skip this step if the Fulcio certificate was valid at the time it was uploaded to the repository. Clients MAY skip this step if they would like to rely on the repository to perform the timeliness check. If the client skips this check and the repository is compromised, an attacker could allow the use of expired Fulcio certificates. In cases where online verification is not possible, stapled inclusion proofs (i.e., evidence gathered by the signer from the log) MAY be presented alongside the software and signature. The client MAY use these proofs instead of directly querying Rekor's transparecy log. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Rekor root. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). ## Auditors -Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and report the compromise to any targets metadata owners who delegate to the compromised account. +Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and ensure the security of their OIDC account. If the OIDC account cannot be recovered, the developer MUST contact the role that delegates to them to replace the delegation to their OIDC identity. In addition to developer monitoring, the TL SHOULD have auditors that watch the log for any suspicious activity. If something bad is found in the TL, then auditors MUST indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using multi-role delegations before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. @@ -93,7 +93,7 @@ If the bad certificates are due to a compromised Fulcio server, the Fulcio serve This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds 2 additional services that may be compromised: the Fulcio server and the Rekor transparency log. In this section, we will analyze the impact and recovery in each of these cases. -If a developer's OIDC credentials are compromised, the developer SHOULD use existing TUF processes for revocation. Specifically they SHOULD ask the delegator to replace any metadata that includes the compromised OIDC account. +If a developer's OIDC credentials are compromised, the developer SHOULD use existing TUF processes for revocation. Specifically they SHOULD ask the delegator to replace any metadata that includes the compromised OIDC account. If the developer's credentials were compromised, but later recovered, the developer may still use these credentials, but any metadata files that were created while the credentials were compromised should be replaced with a higher version of those metadata files so that the compromised files will not be downloaded (using the existing snapshot protection). If the Fulcio server is compromised, it may issue certificates on behalf of any attacker who uses Fulcio to verify their identity. However, the Fulcio server is backed by offline keys that are signed by TUF root keys, and so it is possible to recover from any Fulcio server compromise. Additionally, all Fulcio certificates are published to a transparency log, so auditors will notice if the Fulcio server is misbehaving and indicate this to users, for example through the use of [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) to a threshold of both auditor-signed metadata and developer-signed metadata. From f8f252d98e5a7effe5b645bd26339808de2942cc Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 28 Jul 2022 14:03:16 -0400 Subject: [PATCH 21/33] [Fulcio TAP] Update Fulcio details from code review Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 42 +++++++++++++++++++++-------------------- 1 file changed, 22 insertions(+), 20 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 8e116102..3d060d57 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -13,19 +13,19 @@ In order to achieve end-to-end software update security, TUF requires developers to sign updates with a private key. However, this has proven challenging for some implementers as developers then have to create, store, and secure these private keys in order to ensure they remain private. This TAP proposes using sigstore’s Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. TUF "targets" roles may delegate to Fulcio identities instead of private keys, and these identities (and the corresponding certificates) may be used for verification. # Motivation -Developer key management has been a major concern for TUF adoptions, especially for projects with a small number of developers or limited resources. TUF currently requires that every targets metadata signer creates and manages a private key. However, many developers in large TUF adoptions, including the Python Package Index (PyPI), do not want the extra burden of having to protect a private key for use in deployment. +Developer key management has been a major concern for TUF adoptions, especially for projects with a small number of developers or limited resources. TUF currently requires that every targets metadata signer creates and manages a private key. However, many developers that upload packages to large TUF adoptions, including the Python Package Index (PyPI), manage small or under-resourced projects and do not want the extra burden of having to store and protect a private key for use in deployment. Protecting a private key from loss or compromise is no simple matter. [Several](https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm) [attacks](https://jsoverson.medium.com/how-two-malicious-npm-packages-targeted-sabotaged-one-other-fed7199099c8) on software update systems have been achieved through the use of a compromised key, as securing private keys can be challenging and sometimes expensive (using hardware tokens such as Yubikeys etc), especially over a period of time. -This TAP proposes a way for developers to use their existing OpenID Connect (OIDC) accounts – such as an email account – to verify their identity, so that they do not have to manage any additional keys or passwords. +This TAP proposes a way for developers to use their existing OpenID Connect (OIDC) accounts – such as an email account – to use identity instead of a key as part of a verification policy, so that they do not have to manage any additional keys or passwords. # Rationale In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://www.minilock.io) – a tool which derives ed25519 keys from a user-chosen passphrase – to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is [no longer maintained](https://github.com/kaepora/miniLock) and has been archived. -In this TAP, we instead propose use of the sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides a few services, including [Fulcio](https://github.com/sigstore/fulcio) (a WebPKI) and [Rekor](https://github.com/sigstore/rekor) (a transparency log). With sigstore, long-term efforts to keep private keys secure are not necessary, as short-lived keys are only valid for a small window of time. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. +In this TAP, we instead propose use of the sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides a few services, including [Fulcio](https://github.com/sigstore/fulcio) (a CA) and [Rekor](https://github.com/sigstore/rekor) (a transparency log). With sigstore, long-term efforts to keep private keys secure are not necessary, as signing keys are ephemeral and only used for a single signing event. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. # Specification -In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to developer email addresses, to be verified by Fulcio. These delegations MAY replace public keys for developers (such as ed25519 keys) in order to simplify their key management. Fulcio generates short-lived signing certificates backed by OIDC authentication of a developer’s email address. Because the certificates are short-lived, the developer will not be responsible for protecting this key in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. +In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to any OIDC identity, including developer email addresses, to be verified by Fulcio. These delegations MAY replace public keys for developers (such as ed25519 keys) in order to simplify their key management. Fulcio generates short-lived signing keys and uses certificates to bind these keys to an identity backed by OIDC authentication. Because the ephemeral keys listed in the certificates are short-lived, the developer will not be responsible for protecting signing keys in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. ## Delegation format In order to facilitate use of Fulcio, delegations may list an OIDC identity, such as an email address, and location of a Fulcio server instead of a public key. To do so, this TAP adds a “sigstore-oidc" keytype for a KEY with the following format: @@ -42,9 +42,9 @@ In order to facilitate use of Fulcio, delegations may list an OIDC identity, suc } ``` -Where IDENTITY is the OIDC identity of the party who is authorized to sign, ISSUER is the OIDC entity used by Fulcio for verification, and ROOT_CERTIFICATE is the root certificate for this Fulcio server. +Where IDENTITY is the OIDC identity of the party who is authorized to sign, ISSUER is the OIDC entity used by Fulcio for verification, and ROOT_CERTIFICATE is the root certificate or certificate chain for this Fulcio server. -Using this mechanism, the developer requests a certificate from Fulcio, verifies their identity using OIDC, uses the certificate to sign their targets metadata, and uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Rekor root keys using a secure offline method prior to verifying the signature and associated certificate. +Using this mechanism, the developer requests a certificate from Fulcio, Fulcio verifies the developer's identity using OIDC, the developer uses the signing key listed in the certificate to sign their targets metadata, and finally the developer uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Rekor root keys using a secure offline method prior to verifying the signature and associated certificate. ## Signature format @@ -57,20 +57,20 @@ A signature using a Fulcio key MUST include the Fulcio certificate for use in ve “cert”: CERTIFICATE } , ... ] ``` -Where CERTIFICATE is a Fulcio x509 signing certificate in PEM format. CERTIFICATE MUST be uploaded to a timestamped transparency log upon creation. +Where CERTIFICATE is a Fulcio X.509 signing certificate in PEM format. CERTIFICATE MUST be uploaded to a timestamped transparency log upon creation. ## Signing In order to sign metadata using Fulcio, a developer would: * Generate a key pair locally -* Initiate an OIDC session to Fulcio to retrieve their email from a OIDC provider -* Perform a challenge by encrypting their email with the public key +* Initiate an OIDC session to obtain a signed identity token containing an identity such as an email from an OIDC provider +* Perform a challenge by signing the subjest of the identity token with the public key * Request a short-lived certificate from Fulcio - * Fulcio will upload the certificate to a timestamped transparency log -* Use this certificate to sign targets metadata, then include the certificate in ‘signatures’ as indicated above + * Fulcio will upload the certificate to a Certificate Transparency log +* Use the generated private key to sign targets metadata, then include the certificate in ‘signatures’ as indicated above * Upload the metadata to the repository +* Upload the certificate to the timestamped Fulcio transparency log. -The repository would: -* automatically perform verification (see below) with Fulcio and the transparency log to ensure that the certificate is current and valid. If the signature is uploaded to the repository during the validity window of the Fulcio certificate, the repository MAY skip the Rekor timestamp verification. +The repository would automatically perform verification (see below) with Fulcio and the transparency log to ensure that the certificate is current and valid. If the signature is uploaded to the repository during the validity window of the Fulcio certificate, the repository MAY skip the Rekor timestamp verification. Most of these steps SHOULD be done automatically using a tool, to simplify operations for developers and minimise the risk of human errors. @@ -78,26 +78,28 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to ROOT_CERTIFICATE. -In addition, the repository SHOULD, and clients MAY additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was issued. To do so the user can directly query the transparency log for the Fulcio certificate. They can then verify that the certificate was uploaded to the Rekor, and use the timestamp in Rekor to verify that the key was valid at the time it was used to sign TUF metadata. The repository SHOULD skip this step if the Fulcio certificate was valid at the time it was uploaded to the repository. Clients MAY skip this step if they would like to rely on the repository to perform the timeliness check. If the client skips this check and the repository is compromised, an attacker could allow the use of expired Fulcio certificates. +In addition, the repository SHOULD, and clients MAY additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was issued. To do so the user can directly query the transparency log for the Fulcio certificate. They can then verify that the certificate was uploaded to Rekor, and use the timestamp in Rekor to verify that the key was valid at the time it was used to sign TUF metadata. The repository SHOULD skip this step if the Fulcio certificate was valid at the time it was uploaded to the repository. Clients MAY skip this step if they would like to rely on the repository to perform the timeliness check. If the client skips this check and the repository is compromised, an attacker could allow the use of expired Fulcio certificates. -In cases where online verification is not possible, stapled inclusion proofs (i.e., evidence gathered by the signer from the log) MAY be presented alongside the software and signature. The client MAY use these proofs instead of directly querying Rekor's transparecy log. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Rekor root. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). +In cases where online verification is not possible, stapled inclusion proofs (i.e., evidence gathered by the signer from the log) or SET bundles (promises of inclusion signed by the tlog signer) MAY be presented alongside the software and signature. The client MAY use these proofs instead of directly querying Rekor's transparecy log. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Rekor root. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). ## Auditors Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and ensure the security of their OIDC account. If the OIDC account cannot be recovered, the developer MUST contact the role that delegates to them to replace the delegation to their OIDC identity. -In addition to developer monitoring, the TL SHOULD have auditors that watch the log for any suspicious activity. If something bad is found in the TL, then auditors MUST indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using multi-role delegations before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. +In addition to developer monitoring, the TL SHOULD have auditors that watch the log for any suspicious activity. If something bad (such as a mutation in the log, a deviation from the append-only policy, or invalid inclusion proofs) is found in the TL, then auditors MUST indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. -If the bad certificates are due to a compromised Fulcio server, the Fulcio server MUST be revoked using the root of trust. +If the bad certificates are due to a compromised Fulcio server, Fulcio MUST revoke its certificate and distribute a new certificate in the TUF Sigstore root, and inform any affected clients of the compromise. # Security Analysis -This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds 2 additional services that may be compromised: the Fulcio server and the Rekor transparency log. In this section, we will analyze the impact and recovery in each of these cases. +This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds 3 additional services that may be compromised: the Fulcio server, the Rekor transparency log, and the identity provider. In this section, we will analyze the impact and recovery in each of these cases. If a developer's OIDC credentials are compromised, the developer SHOULD use existing TUF processes for revocation. Specifically they SHOULD ask the delegator to replace any metadata that includes the compromised OIDC account. If the developer's credentials were compromised, but later recovered, the developer may still use these credentials, but any metadata files that were created while the credentials were compromised should be replaced with a higher version of those metadata files so that the compromised files will not be downloaded (using the existing snapshot protection). -If the Fulcio server is compromised, it may issue certificates on behalf of any attacker who uses Fulcio to verify their identity. However, the Fulcio server is backed by offline keys that are signed by TUF root keys, and so it is possible to recover from any Fulcio server compromise. Additionally, all Fulcio certificates are published to a transparency log, so auditors will notice if the Fulcio server is misbehaving and indicate this to users, for example through the use of [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) to a threshold of both auditor-signed metadata and developer-signed metadata. +If the Fulcio server is compromised, it may issue certificates on behalf of any attacker who uses Fulcio to verify their identity. However, the Fulcio server is backed by keys that are signed by the offline TUF Sigstore root keys, and so it is possible to recover from any Fulcio server compromise using TUF's revocation process. Additionally, all Fulcio certificates are published to two transparency logs (Rekor and the Fulcio Certificate Transparency log), so auditors of either log will notice if the Fulcio server is misbehaving and indicate this to users, for example through the use of [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) to a threshold of both auditor-signed metadata and developer-signed metadata. -If only the transparency log is compromised, the attacker will not be able to do anything without cooperation from the Fulcio server. However, if the attacker compromises both the Fulcio server and the transparency log, they would be able to issue fake Fulcio certificates that also appear valid on the transparency log. If this happens, developers auditing the transparency log would notice the mis-issued certificates, and the Fulcio server and transparency log could both be recovered using offline root keys. Implementations using this TAP SHOULD ensure that there are active auditors watching the transparency log. +If only one of the transparency logs is compromised, the attacker will not be able to do anything without cooperation from the Fulcio server because the attack will not be able to create a valid certificate without a compromised Fulcio instance. However, if the attacker compromises both the Fulcio server and the transparency log, they would be able to issue fake Fulcio certificates that also appear valid on the transparency log. If this happens, developers auditing the transparency log would notice the mis-issued certificates, and the Fulcio server and transparency log could both securely replace their key material using offline root key from the TUF Sigstore root. Implementations using this TAP SHOULD ensure that there are active auditors watching both the transparency logs. + +If the identity provider used for OIDC is compromised, they may issue tokens with attacker controlled identities. Metadata signed by certificates from compromised identity providers can be revoked using the usual TUF process, and the identity providers can be removed from the delegating TUF metadata. # Backwards Compatibility From 4975dc54f55621a6c65a7bb93aa89fbf0949ca44 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Tue, 1 Nov 2022 12:29:59 -0400 Subject: [PATCH 22/33] Clarify fulcio certificates Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 3d060d57..90a03abd 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -17,7 +17,7 @@ Developer key management has been a major concern for TUF adoptions, especially Protecting a private key from loss or compromise is no simple matter. [Several](https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm) [attacks](https://jsoverson.medium.com/how-two-malicious-npm-packages-targeted-sabotaged-one-other-fed7199099c8) on software update systems have been achieved through the use of a compromised key, as securing private keys can be challenging and sometimes expensive (using hardware tokens such as Yubikeys etc), especially over a period of time. -This TAP proposes a way for developers to use their existing OpenID Connect (OIDC) accounts – such as an email account – to use identity instead of a key as part of a verification policy, so that they do not have to manage any additional keys or passwords. +This TAP proposes a way for developers to use their existing OpenID Connect (OIDC) accounts – such as an email account – as an identity instead of using a key. This means that they do not have to manage any additional keys or passwords. # Rationale In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://www.minilock.io) – a tool which derives ed25519 keys from a user-chosen passphrase – to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is [no longer maintained](https://github.com/kaepora/miniLock) and has been archived. @@ -36,31 +36,32 @@ In order to facilitate use of Fulcio, delegations may list an OIDC identity, suc “scheme”: "Fulcio", “keyval”: { “identity”: IDENTITY, - “issuer”: ISSUER, - "root-cert": ROOT_CERTIFICATE + “issuer”: ISSUER } } ``` -Where IDENTITY is the OIDC identity of the party who is authorized to sign, ISSUER is the OIDC entity used by Fulcio for verification, and ROOT_CERTIFICATE is the root certificate or certificate chain for this Fulcio server. +Where IDENTITY is the OIDC identity of the party who is authorized to sign and ISSUER is the OIDC entity used by Fulcio for verification. + +The root certificate or certificate chain for the Fulcio server MUST be obtained using the Sigstore root of trust. Using this mechanism, the developer requests a certificate from Fulcio, Fulcio verifies the developer's identity using OIDC, the developer uses the signing key listed in the certificate to sign their targets metadata, and finally the developer uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Rekor root keys using a secure offline method prior to verifying the signature and associated certificate. ## Signature format -A signature using a Fulcio key MUST include the Fulcio certificate for use in verification. For this verification, this TAP adds a ‘cert’ field to ‘signatures’. With this field, signatures would look like: +A signature using a Fulcio key MUST include the Fulcio certificate for use in verification. For this verification, this TAP adds a ‘bundle’ field to ‘signatures’ to replace `sig` for this key type. With this field, signatures would look like: ``` "signatures" : [ { "keyid" : KEYID, - "sig" : SIGNATURE, - “cert”: CERTIFICATE } + “bundle”: BUNDLE } , ... ] ``` -Where CERTIFICATE is a Fulcio X.509 signing certificate in PEM format. CERTIFICATE MUST be uploaded to a timestamped transparency log upon creation. +Where BUNDLE is an object that contains the proof of inclusion in the transparency log, signed tree head, and Fulcio X.509 signing certificate in PEM format, conforming to the [format defined by Sigstore](https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_bundle.proto). ## Signing In order to sign metadata using Fulcio, a developer would: + * Generate a key pair locally * Initiate an OIDC session to obtain a signed identity token containing an identity such as an email from an OIDC provider * Perform a challenge by signing the subjest of the identity token with the public key @@ -76,11 +77,9 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification -While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to ROOT_CERTIFICATE. - -In addition, the repository SHOULD, and clients MAY additionally query the Rekor transparency log to ensure that the Fulcio certificate is valid at the time that it was issued. To do so the user can directly query the transparency log for the Fulcio certificate. They can then verify that the certificate was uploaded to Rekor, and use the timestamp in Rekor to verify that the key was valid at the time it was used to sign TUF metadata. The repository SHOULD skip this step if the Fulcio certificate was valid at the time it was uploaded to the repository. Clients MAY skip this step if they would like to rely on the repository to perform the timeliness check. If the client skips this check and the repository is compromised, an attacker could allow the use of expired Fulcio certificates. +While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to the root certificate and verify the inclusion proof to ensure that the key was valid at the time it was used to sign TUF metadata. -In cases where online verification is not possible, stapled inclusion proofs (i.e., evidence gathered by the signer from the log) or SET bundles (promises of inclusion signed by the tlog signer) MAY be presented alongside the software and signature. The client MAY use these proofs instead of directly querying Rekor's transparecy log. Verification material for these stapled inclusion proofs MUST be distributed out of band alongside the Rekor root. Documentation about querying Rekor is available [here](https://docs.sigstore.dev/rekor/CLI). +In addition, the repository SHOULD, and clients MAY additionally query the Rekor transparency log to ensure that the Fulcio certificate is included in the current signed tree head. To do so the user can directly query the transparency log for the signed tree head and inclusion proof. They can then verify that the certificate is in the current Rekor log. ## Auditors Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and ensure the security of their OIDC account. If the OIDC account cannot be recovered, the developer MUST contact the role that delegates to them to replace the delegation to their OIDC identity. From 9e8dbb38b141061ec89700bcc97f6738c42e2da9 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 3 Nov 2022 14:31:04 -0400 Subject: [PATCH 23/33] [Fulcio TAP] Simplify the explanation of signing and verifying Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 34 ++++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 8 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 90a03abd..b38623e1 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -45,8 +45,6 @@ Where IDENTITY is the OIDC identity of the party who is authorized to sign and I The root certificate or certificate chain for the Fulcio server MUST be obtained using the Sigstore root of trust. -Using this mechanism, the developer requests a certificate from Fulcio, Fulcio verifies the developer's identity using OIDC, the developer uses the signing key listed in the certificate to sign their targets metadata, and finally the developer uploads the signed metadata. This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user by verifying the certificate through Fulcio and the timestamp through Rekor. The verifier MUST obtain the Rekor root keys using a secure offline method prior to verifying the signature and associated certificate. - ## Signature format A signature using a Fulcio key MUST include the Fulcio certificate for use in verification. For this verification, this TAP adds a ‘bundle’ field to ‘signatures’ to replace `sig` for this key type. With this field, signatures would look like: @@ -67,9 +65,10 @@ In order to sign metadata using Fulcio, a developer would: * Perform a challenge by signing the subjest of the identity token with the public key * Request a short-lived certificate from Fulcio * Fulcio will upload the certificate to a Certificate Transparency log -* Use the generated private key to sign targets metadata, then include the certificate in ‘signatures’ as indicated above -* Upload the metadata to the repository -* Upload the certificate to the timestamped Fulcio transparency log. +* Use the generated private key to create signature over targets metadata +* Upload the certificate to the timestamped Rekor transparency log. Rekor will return a proof of inclusion and a signed tre head. +* Create a bundle that contains the signature, Fulcio certificate, proof of inclusion, and signed tree head +* Upload the metadata, including the bundle to the repository The repository would automatically perform verification (see below) with Fulcio and the transparency log to ensure that the certificate is current and valid. If the signature is uploaded to the repository during the validity window of the Fulcio certificate, the repository MAY skip the Rekor timestamp verification. @@ -77,9 +76,28 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification -While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST verify the certificate chain up to the root certificate and verify the inclusion proof to ensure that the key was valid at the time it was used to sign TUF metadata. +This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user. The verifier MUST obtain the Rekor root keys using a secure offline method prior to verifying the signature and associated certificate. + +A repository should perform the following verification: + +* Verify the signature, and ensure that the signature chains up to the trusted Fulcio root. +* Verify the proof of inclusion using the signed tree head to ensure that the certificate was included in the Rekor transparency log. +* If the Fulcio certificate is valid at the time it is verified (ie it was uploaded within the short validity period), stop here. +* Otherwise, query the Rekor transparancy log for the current signed tree head and a proof of inclusion of the signed tree head included in the signature. +* Verify this inclusion proof. + + +While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST perform the following verification: + +* Verify the signature, and ensure that the signature chains up to the trusted Fulcio root. +* Verify the proof of inclusion using the signed tree head to ensure that the certificate was included in the Rekor transparency log. + +Online client MAY additionally perform the following verification: + +* Query the Rekor transparancy log for the current signed tree head and a proof of inclusion of the signed tree head included in the signature. Verify this inclusion proof. + +Clients that skip the online verification rely on the repository to ensure that the Fulcio certificate was valid at the time it was used to sign TUF metadata. -In addition, the repository SHOULD, and clients MAY additionally query the Rekor transparency log to ensure that the Fulcio certificate is included in the current signed tree head. To do so the user can directly query the transparency log for the signed tree head and inclusion proof. They can then verify that the certificate is in the current Rekor log. ## Auditors Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and ensure the security of their OIDC account. If the OIDC account cannot be recovered, the developer MUST contact the role that delegates to them to replace the delegation to their OIDC identity. @@ -105,7 +123,7 @@ If the identity provider used for OIDC is compromised, they may issue tokens wit Clients that do not recognize Fulcio certs will not be able to validate signatures from Fulcio certs, but they will be able to parse the metadata. -‘Cert’ is a new field added to ‘signatures’. Clients that do not recognize Fulcio certs will ignore this field by default. +‘Bundle’ is a new field added to ‘signatures’. Clients that do not recognize Fulcio certs will ignore this field by default. # Augmented Reference Implementation From 50564bd9552507cf52f43cf285fdaaa0c4b0170b Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 3 Nov 2022 16:05:38 -0400 Subject: [PATCH 24/33] [Fulcio TAP] Update signing and verification Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 61 +++++++++++++++++++++-------------------- 1 file changed, 31 insertions(+), 30 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index b38623e1..2d19cead 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -55,22 +55,20 @@ A signature using a Fulcio key MUST include the Fulcio certificate for use in ve “bundle”: BUNDLE } , ... ] ``` -Where BUNDLE is an object that contains the proof of inclusion in the transparency log, signed tree head, and Fulcio X.509 signing certificate in PEM format, conforming to the [format defined by Sigstore](https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_bundle.proto). +Where BUNDLE is an object that contains the transparency log verification information, Fulcio X.509 signing certificate, and a signature over targets metadata, conforming to the [format defined by Sigstore](https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_bundle.proto). The transparency log verification information includes a signed timestamp (SET) from Rekor promising inclusion in the Rekor transparency log. ## Signing -In order to sign metadata using Fulcio, a developer would: - -* Generate a key pair locally -* Initiate an OIDC session to obtain a signed identity token containing an identity such as an email from an OIDC provider -* Perform a challenge by signing the subjest of the identity token with the public key -* Request a short-lived certificate from Fulcio - * Fulcio will upload the certificate to a Certificate Transparency log -* Use the generated private key to create signature over targets metadata -* Upload the certificate to the timestamped Rekor transparency log. Rekor will return a proof of inclusion and a signed tre head. -* Create a bundle that contains the signature, Fulcio certificate, proof of inclusion, and signed tree head -* Upload the metadata, including the bundle to the repository - -The repository would automatically perform verification (see below) with Fulcio and the transparency log to ensure that the certificate is current and valid. If the signature is uploaded to the repository during the validity window of the Fulcio certificate, the repository MAY skip the Rekor timestamp verification. +In order to sign metadata using Fulcio, a developer MUST: + +* Initiate an OIDC session to obtain an identity token signed by the OIDC identity provider's public key containing the developer's IDENTITY. +* Generate a key pair locally. +* Create a certificate signing request containing the subject of the identity token. Sign this certificate with the generated private key. +* Request a short-lived certificate from Fulcio by sending the certificate signing request along with the identity token. + * Fulcio will upload the certificate to a Certificate Transparency log. +* Use the generated private key to create signature over targets metadata. +* Upload the certificate, signature, and hash of the targets metadata to the timestamped Rekor transparency log. Rekor will return an SET with a timestampe that indicates that Rekor recieved the request and will include it in the log. +* Create a bundle that contains the signature, Fulcio certificate, SET. +* Upload the metadata, including the bundle to the repository. Most of these steps SHOULD be done automatically using a tool, to simplify operations for developers and minimise the risk of human errors. @@ -78,31 +76,32 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user. The verifier MUST obtain the Rekor root keys using a secure offline method prior to verifying the signature and associated certificate. -A repository should perform the following verification: - -* Verify the signature, and ensure that the signature chains up to the trusted Fulcio root. -* Verify the proof of inclusion using the signed tree head to ensure that the certificate was included in the Rekor transparency log. -* If the Fulcio certificate is valid at the time it is verified (ie it was uploaded within the short validity period), stop here. -* Otherwise, query the Rekor transparancy log for the current signed tree head and a proof of inclusion of the signed tree head included in the signature. -* Verify this inclusion proof. +While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST perform the verification. In addition, the repository MUST perform verifcation. +Verification includes the following steps: -While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST perform the following verification: +* Verify the signature on the certificate to ensure that the signature chains up to the trusted Fulcio root. +* Verify the signature on the TUF metadata using the key from the Fulcio certificate. +* Verify the SET to ensure that the certificate was included in the Rekor transparency log. -* Verify the signature, and ensure that the signature chains up to the trusted Fulcio root. -* Verify the proof of inclusion using the signed tree head to ensure that the certificate was included in the Rekor transparency log. +Periodically the repository SHOULD perform online verification of all Rekor uses. +Online clients MAY additionally perform online verification. This process is described in the auditors section below. -Online client MAY additionally perform the following verification: +## Auditors and Monitoring -* Query the Rekor transparancy log for the current signed tree head and a proof of inclusion of the signed tree head included in the signature. Verify this inclusion proof. +Online verification requires the following steps: -Clients that skip the online verification rely on the repository to ensure that the Fulcio certificate was valid at the time it was used to sign TUF metadata. +* Obtain the most recent Rekor signed tree head. + * Query the Rekor transparancy log for a consistency proof against your current signed tree head. + * Verify this consistency proof. +* Query the Rekor transparency log for a proof of inclusion against the certificate included in the TUF metadata +* Verify this inclusion proof. +Online verification SHOULD be performed periodically by repositories and MAY be performed by clients. -## Auditors -Developers SHOULD monitor the transparency log (TL) for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and ensure the security of their OIDC account. If the OIDC account cannot be recovered, the developer MUST contact the role that delegates to them to replace the delegation to their OIDC identity. +Developers SHOULD monitor the transparency log (TL) and look for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and ensure the security of their OIDC account. If the OIDC account cannot be recovered, the developer MUST contact the role that delegates to them to replace the delegation to their OIDC identity. -In addition to developer monitoring, the TL SHOULD have auditors that watch the log for any suspicious activity. If something bad (such as a mutation in the log, a deviation from the append-only policy, or invalid inclusion proofs) is found in the TL, then auditors MUST indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. +In addition to developer monitoring, the TL SHOULD have auditors that watch the log by performing online verification for all uses in TUF metadata for any suspicious activity. If something bad (such as a mutation in the log, a deviation from the append-only policy, or invalid inclusion proofs) is found in the TL, then auditors MUST indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. The repository SHOULD be an auditor of the log. If the bad certificates are due to a compromised Fulcio server, Fulcio MUST revoke its certificate and distribute a new certificate in the TUF Sigstore root, and inform any affected clients of the compromise. @@ -118,6 +117,8 @@ If only one of the transparency logs is compromised, the attacker will not be ab If the identity provider used for OIDC is compromised, they may issue tokens with attacker controlled identities. Metadata signed by certificates from compromised identity providers can be revoked using the usual TUF process, and the identity providers can be removed from the delegating TUF metadata. +By default, clients will perform offline verification. They may choose to additionally perform online verification. In practice, exisiting uses of transparency logs use offline verification as it saves bandwidth and maximum merge delays on the transparency log mean that onlie verification is not immediately available. This is because the transparency log will batch additions to the log. Offline verification relies on a signature from the Rekor key that the entry will be included. This is the same key that signs the Rekor signed tree head in online verification. If the Rekor key is compromised, both of these verification types could be tricked. However, monitors are able to detect bad behavior once entries are added to the log, and monitor signatures can be used to provide additional assurance. + # Backwards Compatibility From 7b315fb3bf6b522e82499fabce1dd3ada8106d72 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Fri, 4 Nov 2022 13:44:06 -0400 Subject: [PATCH 25/33] Apply suggestions from code review Co-authored-by: asraa Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 2d19cead..2d541532 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -55,7 +55,7 @@ A signature using a Fulcio key MUST include the Fulcio certificate for use in ve “bundle”: BUNDLE } , ... ] ``` -Where BUNDLE is an object that contains the transparency log verification information, Fulcio X.509 signing certificate, and a signature over targets metadata, conforming to the [format defined by Sigstore](https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_bundle.proto). The transparency log verification information includes a signed timestamp (SET) from Rekor promising inclusion in the Rekor transparency log. +Where BUNDLE is an object that contains the verification information (transparency log references or timestamps), Fulcio X.509 signing certificate, and a signature over targets metadata, conforming to the [format defined by Sigstore](https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_bundle.proto). The transparency log verification information includes a signed timestamp (SET) from Rekor promising inclusion in the Rekor transparency log. ## Signing In order to sign metadata using Fulcio, a developer MUST: @@ -66,7 +66,7 @@ In order to sign metadata using Fulcio, a developer MUST: * Request a short-lived certificate from Fulcio by sending the certificate signing request along with the identity token. * Fulcio will upload the certificate to a Certificate Transparency log. * Use the generated private key to create signature over targets metadata. -* Upload the certificate, signature, and hash of the targets metadata to the timestamped Rekor transparency log. Rekor will return an SET with a timestampe that indicates that Rekor recieved the request and will include it in the log. +* Upload the certificate, signature, and hash of the targets metadata to the timestamped Rekor transparency log. Rekor will return an SET with a timestamp that indicates that Rekor received the request and will include it in the log. * Create a bundle that contains the signature, Fulcio certificate, SET. * Upload the metadata, including the bundle to the repository. @@ -82,7 +82,7 @@ Verification includes the following steps: * Verify the signature on the certificate to ensure that the signature chains up to the trusted Fulcio root. * Verify the signature on the TUF metadata using the key from the Fulcio certificate. -* Verify the SET to ensure that the certificate was included in the Rekor transparency log. +* Verify the SET to ensure that the signature was signed during certificate validity Periodically the repository SHOULD perform online verification of all Rekor uses. Online clients MAY additionally perform online verification. This process is described in the auditors section below. @@ -94,8 +94,10 @@ Online verification requires the following steps: * Obtain the most recent Rekor signed tree head. * Query the Rekor transparancy log for a consistency proof against your current signed tree head. * Verify this consistency proof. -* Query the Rekor transparency log for a proof of inclusion against the certificate included in the TUF metadata + * Persist the newest signed tree head +* Query the Rekor transparency log for a proof of inclusion against the certificate and TUF metadata * Verify this inclusion proof. +* Verify that the root hash of the inclusion proof is consistent with the signed tree head verified in step 1 Online verification SHOULD be performed periodically by repositories and MAY be performed by clients. @@ -117,7 +119,7 @@ If only one of the transparency logs is compromised, the attacker will not be ab If the identity provider used for OIDC is compromised, they may issue tokens with attacker controlled identities. Metadata signed by certificates from compromised identity providers can be revoked using the usual TUF process, and the identity providers can be removed from the delegating TUF metadata. -By default, clients will perform offline verification. They may choose to additionally perform online verification. In practice, exisiting uses of transparency logs use offline verification as it saves bandwidth and maximum merge delays on the transparency log mean that onlie verification is not immediately available. This is because the transparency log will batch additions to the log. Offline verification relies on a signature from the Rekor key that the entry will be included. This is the same key that signs the Rekor signed tree head in online verification. If the Rekor key is compromised, both of these verification types could be tricked. However, monitors are able to detect bad behavior once entries are added to the log, and monitor signatures can be used to provide additional assurance. +By default, clients will perform offline verification. They may choose to additionally perform online verification. In practice, exisiting uses of transparency logs use offline verification as it saves bandwidth and maximum merge delays on the transparency log mean that onlie verification is not immediately available. This is because the transparency log will batch additions to the log. Offline verification relies on a signature from the Rekor key that the entry will be included and that the entry was seen at a certain time. This is the same key that signs the Rekor signed tree head in online verification. If the Rekor key is compromised, both of these verification types could be tricked. However, monitors are able to detect bad behavior once entries are added to the log, and monitor signatures can be used to provide additional assurance. # Backwards Compatibility From ec67d7d378f83166ae346c41fa043206ce87a08e Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Fri, 4 Nov 2022 13:48:06 -0400 Subject: [PATCH 26/33] Clarify use of single Fulcio instance Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 2d541532..0b255389 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -43,7 +43,7 @@ In order to facilitate use of Fulcio, delegations may list an OIDC identity, suc Where IDENTITY is the OIDC identity of the party who is authorized to sign and ISSUER is the OIDC entity used by Fulcio for verification. -The root certificate or certificate chain for the Fulcio server MUST be obtained using the Sigstore root of trust. +The root certificate or certificate chain for the Fulcio server MUST be obtained using the Sigstore root of trust. The client MUST use a single Fulcio instance. ## Signature format @@ -74,7 +74,7 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification -This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user. The verifier MUST obtain the Rekor root keys using a secure offline method prior to verifying the signature and associated certificate. +This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user. The verifier MUST obtain the Rekor root keys using a secure out of band method prior to verifying the signature and associated certificate. While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST perform the verification. In addition, the repository MUST perform verifcation. From 9893ba1991afa313840b10301ace652752417a4a Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Fri, 4 Nov 2022 14:25:27 -0400 Subject: [PATCH 27/33] add in the Fulcio CT log Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 0b255389..9afc1d7f 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -74,13 +74,14 @@ Most of these steps SHOULD be done automatically using a tool, to simplify opera ## Verification -This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user. The verifier MUST obtain the Rekor root keys using a secure out of band method prior to verifying the signature and associated certificate. +This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user. The verifier MUST obtain the Rekor root keys and the certificate log public key using a secure out of band method prior to verifying the signature and associated certificate. While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST perform the verification. In addition, the repository MUST perform verifcation. Verification includes the following steps: * Verify the signature on the certificate to ensure that the signature chains up to the trusted Fulcio root. +* Verify the Fulcio certificate's inclusion in the CT log with the trusted certificate log public key * Verify the signature on the TUF metadata using the key from the Fulcio certificate. * Verify the SET to ensure that the signature was signed during certificate validity From 13c52660c50872aa523058280c3868dae445e78b Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Fri, 13 Jan 2023 11:29:48 -0500 Subject: [PATCH 28/33] Add link to threat model doc Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 9afc1d7f..541f3877 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -110,9 +110,9 @@ If the bad certificates are due to a compromised Fulcio server, Fulcio MUST revo # Security Analysis -This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds 3 additional services that may be compromised: the Fulcio server, the Rekor transparency log, and the identity provider. In this section, we will analyze the impact and recovery in each of these cases. +Our [threat modelling](https://docs.google.com/document/d/1fkz8zO35zAIXlvTNSQYyLSK_T6n0G8STGxCoxB3RNQo/edit#) has found that using Fulcio with TUF namespacing is mostly security neutral with the existing TUF specification as long as different accounts are used for login and for the OIDC-backed signatures. This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds additional services that may be compromised: the developer's OIDC credentials, the Fulcio server, the Rekor transparency log, and the identity provider. In this section, we will analyze the impact and recovery in each of these cases. -If a developer's OIDC credentials are compromised, the developer SHOULD use existing TUF processes for revocation. Specifically they SHOULD ask the delegator to replace any metadata that includes the compromised OIDC account. If the developer's credentials were compromised, but later recovered, the developer may still use these credentials, but any metadata files that were created while the credentials were compromised should be replaced with a higher version of those metadata files so that the compromised files will not be downloaded (using the existing snapshot protection). +If a developer's OIDC credentials are compromised, the developer SHOULD use existing TUF processes for revocation. Specifically they SHOULD ask the delegator to replace any metadata that includes the compromised OIDC account. If the developer's credentials were compromised, but later recovered through the OIDC provider, the developer may still use these credentials, but any metadata files that were created while the credentials were compromised should be replaced with a higher version of those metadata files so that the compromised files will not be downloaded (using the existing snapshot protection). If the Fulcio server is compromised, it may issue certificates on behalf of any attacker who uses Fulcio to verify their identity. However, the Fulcio server is backed by keys that are signed by the offline TUF Sigstore root keys, and so it is possible to recover from any Fulcio server compromise using TUF's revocation process. Additionally, all Fulcio certificates are published to two transparency logs (Rekor and the Fulcio Certificate Transparency log), so auditors of either log will notice if the Fulcio server is misbehaving and indicate this to users, for example through the use of [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) to a threshold of both auditor-signed metadata and developer-signed metadata. @@ -120,7 +120,7 @@ If only one of the transparency logs is compromised, the attacker will not be ab If the identity provider used for OIDC is compromised, they may issue tokens with attacker controlled identities. Metadata signed by certificates from compromised identity providers can be revoked using the usual TUF process, and the identity providers can be removed from the delegating TUF metadata. -By default, clients will perform offline verification. They may choose to additionally perform online verification. In practice, exisiting uses of transparency logs use offline verification as it saves bandwidth and maximum merge delays on the transparency log mean that onlie verification is not immediately available. This is because the transparency log will batch additions to the log. Offline verification relies on a signature from the Rekor key that the entry will be included and that the entry was seen at a certain time. This is the same key that signs the Rekor signed tree head in online verification. If the Rekor key is compromised, both of these verification types could be tricked. However, monitors are able to detect bad behavior once entries are added to the log, and monitor signatures can be used to provide additional assurance. +By default, clients will perform offline verification. They may choose to additionally perform online verification. In practice, exisiting uses of transparency logs use offline verification as it saves bandwidth and maximum merge delays on the transparency log mean that online verification is not immediately available. This is because the transparency log will batch additions to the log. Offline verification relies on a signature from the Rekor key that the entry will be included and that the entry was seen at a certain time. This is the same key that signs the Rekor signed tree head in online verification. If the Rekor key is compromised, both of these verification types could be tricked. However, monitors are able to detect bad behavior once entries are added to the log, and monitor signatures can be used to provide additional assurance. # Backwards Compatibility From d7f086ea55558a9c27a49db83d9d90ff52c2b505 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Tue, 17 Jan 2023 16:25:58 -0500 Subject: [PATCH 29/33] [Fulcio TAP] minor clarifications Highlight that existing Sigstore tooling should be used Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 541f3877..149cc1b9 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -13,7 +13,7 @@ In order to achieve end-to-end software update security, TUF requires developers to sign updates with a private key. However, this has proven challenging for some implementers as developers then have to create, store, and secure these private keys in order to ensure they remain private. This TAP proposes using sigstore’s Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. TUF "targets" roles may delegate to Fulcio identities instead of private keys, and these identities (and the corresponding certificates) may be used for verification. # Motivation -Developer key management has been a major concern for TUF adoptions, especially for projects with a small number of developers or limited resources. TUF currently requires that every targets metadata signer creates and manages a private key. However, many developers that upload packages to large TUF adoptions, including the Python Package Index (PyPI), manage small or under-resourced projects and do not want the extra burden of having to store and protect a private key for use in deployment. +Developer key management has been a major concern for TUF adoptions, especially for projects with a small number of developers or limited resources. TUF currently requires that every targets metadata signer creates and manages a private key, including secure storage of the key over a long period of time to prevent it leaking to an attacker. However, many developers that upload packages to large TUF adoptions, including the Python Package Index (PyPI), manage small or under-resourced projects and do not want the extra burden of having to protect a private key for use in deployment. Protecting a private key from loss or compromise is no simple matter. [Several](https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm) [attacks](https://jsoverson.medium.com/how-two-malicious-npm-packages-targeted-sabotaged-one-other-fed7199099c8) on software update systems have been achieved through the use of a compromised key, as securing private keys can be challenging and sometimes expensive (using hardware tokens such as Yubikeys etc), especially over a period of time. @@ -70,7 +70,7 @@ In order to sign metadata using Fulcio, a developer MUST: * Create a bundle that contains the signature, Fulcio certificate, SET. * Upload the metadata, including the bundle to the repository. -Most of these steps SHOULD be done automatically using a tool, to simplify operations for developers and minimise the risk of human errors. +Most of these steps SHOULD be done automatically using a tool (such as Sigstore), to simplify operations for developers and minimise the risk of human errors. ## Verification @@ -85,6 +85,7 @@ Verification includes the following steps: * Verify the signature on the TUF metadata using the key from the Fulcio certificate. * Verify the SET to ensure that the signature was signed during certificate validity +Similar to signing, this verification SHOULD be done with existing Sigstore tooling. Periodically the repository SHOULD perform online verification of all Rekor uses. Online clients MAY additionally perform online verification. This process is described in the auditors section below. From 033e5443deb80a7263a9f11688706ac201177e47 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Fri, 27 Jan 2023 13:14:50 -0500 Subject: [PATCH 30/33] formatting fixes and typos Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 42 ++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 149cc1b9..1388fdf0 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -10,7 +10,7 @@ * TUF-Version: # Abstract -In order to achieve end-to-end software update security, TUF requires developers to sign updates with a private key. However, this has proven challenging for some implementers as developers then have to create, store, and secure these private keys in order to ensure they remain private. This TAP proposes using sigstore’s Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. TUF "targets" roles may delegate to Fulcio identities instead of private keys, and these identities (and the corresponding certificates) may be used for verification. +In order to achieve end-to-end software update security, TUF requires developers to sign updates with a private key. However, this has proven challenging for some implementers as developers then have to create, store, and secure these private keys in order to ensure they remain private. This TAP proposes using sigstore's Fulcio project to simplify developer key management by allowing developers to use existing accounts to verify their identity when signing updates. TUF "targets" roles may delegate to Fulcio identities instead of private keys, and these identities (and the corresponding certificates) may be used for verification. # Motivation Developer key management has been a major concern for TUF adoptions, especially for projects with a small number of developers or limited resources. TUF currently requires that every targets metadata signer creates and manages a private key, including secure storage of the key over a long period of time to prevent it leaking to an attacker. However, many developers that upload packages to large TUF adoptions, including the Python Package Index (PyPI), manage small or under-resourced projects and do not want the extra burden of having to protect a private key for use in deployment. @@ -28,15 +28,15 @@ In this TAP, we instead propose use of the sigstore project. Sigstore has a grow In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to any OIDC identity, including developer email addresses, to be verified by Fulcio. These delegations MAY replace public keys for developers (such as ed25519 keys) in order to simplify their key management. Fulcio generates short-lived signing keys and uses certificates to bind these keys to an identity backed by OIDC authentication. Because the ephemeral keys listed in the certificates are short-lived, the developer will not be responsible for protecting signing keys in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. ## Delegation format -In order to facilitate use of Fulcio, delegations may list an OIDC identity, such as an email address, and location of a Fulcio server instead of a public key. To do so, this TAP adds a “sigstore-oidc" keytype for a KEY with the following format: +In order to facilitate use of Fulcio, delegations may list an OIDC identity, such as an email address, and location of a Fulcio server instead of a public key. To do so, this TAP adds a "sigstore-oidc" keytype for a KEY with the following format: ``` { - “keytype”: “sigstore-oidc", - “scheme”: "Fulcio", - “keyval”: { - “identity”: IDENTITY, - “issuer”: ISSUER + "keytype": "sigstore-oidc", + "scheme": "Fulcio", + "keyval": { + "identity": IDENTITY, + "issuer": ISSUER } } ``` @@ -47,12 +47,12 @@ The root certificate or certificate chain for the Fulcio server MUST be obtained ## Signature format -A signature using a Fulcio key MUST include the Fulcio certificate for use in verification. For this verification, this TAP adds a ‘bundle’ field to ‘signatures’ to replace `sig` for this key type. With this field, signatures would look like: +A signature using a Fulcio key MUST include the Fulcio certificate for use in verification. For this verification, this TAP adds a 'bundle' field to 'signatures' to replace `sig` for this key type. With this field, signatures would look like: ``` "signatures" : [ { "keyid" : KEYID, - “bundle”: BUNDLE } + "bundle": BUNDLE } , ... ] ``` Where BUNDLE is an object that contains the verification information (transparency log references or timestamps), Fulcio X.509 signing certificate, and a signature over targets metadata, conforming to the [format defined by Sigstore](https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_bundle.proto). The transparency log verification information includes a signed timestamp (SET) from Rekor promising inclusion in the Rekor transparency log. @@ -76,14 +76,14 @@ Most of these steps SHOULD be done automatically using a tool (such as Sigstore) ## Verification This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user. The verifier MUST obtain the Rekor root keys and the certificate log public key using a secure out of band method prior to verifying the signature and associated certificate. -While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST perform the verification. In addition, the repository MUST perform verifcation. +While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST perform the verification. In addition, the repository MUST perform verification. Verification includes the following steps: * Verify the signature on the certificate to ensure that the signature chains up to the trusted Fulcio root. -* Verify the Fulcio certificate's inclusion in the CT log with the trusted certificate log public key +* Verify the Fulcio certificate's inclusion in the CT log with the trusted certificate log public key. * Verify the signature on the TUF metadata using the key from the Fulcio certificate. -* Verify the SET to ensure that the signature was signed during certificate validity +* Verify the SET to ensure that the signature was signed during certificate validity. Similar to signing, this verification SHOULD be done with existing Sigstore tooling. Periodically the repository SHOULD perform online verification of all Rekor uses. @@ -93,19 +93,19 @@ Online clients MAY additionally perform online verification. This process is des Online verification requires the following steps: -* Obtain the most recent Rekor signed tree head. - * Query the Rekor transparancy log for a consistency proof against your current signed tree head. +1. Obtain the most recent Rekor signed tree head. + * Query the Rekor transparency log for a consistency proof against your current signed tree head. * Verify this consistency proof. - * Persist the newest signed tree head -* Query the Rekor transparency log for a proof of inclusion against the certificate and TUF metadata -* Verify this inclusion proof. -* Verify that the root hash of the inclusion proof is consistent with the signed tree head verified in step 1 + * Persist the newest signed tree head. +1. Query the Rekor transparency log for a proof of inclusion against the certificate and TUF metadata. +1. Verify this inclusion proof. +1. Verify that the root hash of the inclusion proof is consistent with the signed tree head verified in step 1. Online verification SHOULD be performed periodically by repositories and MAY be performed by clients. Developers SHOULD monitor the transparency log (TL) and look for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and ensure the security of their OIDC account. If the OIDC account cannot be recovered, the developer MUST contact the role that delegates to them to replace the delegation to their OIDC identity. -In addition to developer monitoring, the TL SHOULD have auditors that watch the log by performing online verification for all uses in TUF metadata for any suspicious activity. If something bad (such as a mutation in the log, a deviation from the append-only policy, or invalid inclusion proofs) is found in the TL, then auditors MUST indicate this to clients to ensure they don’t use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. The repository SHOULD be an auditor of the log. +In addition to developer monitoring, the TL SHOULD have auditors that watch the log by performing online verification for all uses in TUF metadata for any suspicious activity. If something bad (such as a mutation in the log, a deviation from the append-only policy, or invalid inclusion proofs) is found in the TL, then auditors MUST indicate this to clients to ensure they don't use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. The repository SHOULD be an auditor of the log. If the bad certificates are due to a compromised Fulcio server, Fulcio MUST revoke its certificate and distribute a new certificate in the TUF Sigstore root, and inform any affected clients of the compromise. @@ -121,14 +121,14 @@ If only one of the transparency logs is compromised, the attacker will not be ab If the identity provider used for OIDC is compromised, they may issue tokens with attacker controlled identities. Metadata signed by certificates from compromised identity providers can be revoked using the usual TUF process, and the identity providers can be removed from the delegating TUF metadata. -By default, clients will perform offline verification. They may choose to additionally perform online verification. In practice, exisiting uses of transparency logs use offline verification as it saves bandwidth and maximum merge delays on the transparency log mean that online verification is not immediately available. This is because the transparency log will batch additions to the log. Offline verification relies on a signature from the Rekor key that the entry will be included and that the entry was seen at a certain time. This is the same key that signs the Rekor signed tree head in online verification. If the Rekor key is compromised, both of these verification types could be tricked. However, monitors are able to detect bad behavior once entries are added to the log, and monitor signatures can be used to provide additional assurance. +By default, clients will perform offline verification. They may choose to additionally perform online verification. In practice, existing uses of transparency logs use offline verification as it saves bandwidth and maximum merge delays on the transparency log mean that online verification is not immediately available. This is because the transparency log will batch additions to the log. Offline verification relies on a signature from the Rekor key that the entry will be included and that the entry was seen at a certain time. This is the same key that signs the Rekor signed tree head in online verification. If the Rekor key is compromised, both of these verification types could be tricked. However, monitors are able to detect bad behavior once entries are added to the log, and monitor signatures can be used to provide additional assurance. # Backwards Compatibility Clients that do not recognize Fulcio certs will not be able to validate signatures from Fulcio certs, but they will be able to parse the metadata. -‘Bundle’ is a new field added to ‘signatures’. Clients that do not recognize Fulcio certs will ignore this field by default. +'Bundle' is a new field added to 'signatures'. Clients that do not recognize Fulcio certs will ignore this field by default. # Augmented Reference Implementation From 8dda4e2c21b4230d26521e5c088bb7a7e3e17e70 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Fri, 27 Jan 2023 14:48:26 -0500 Subject: [PATCH 31/33] Clarifications from review Especially this: * generalized the "repository" * generalized the "developer" * fixes links Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 48 ++++++++++++++++++++--------------------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 1388fdf0..38a76d89 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -17,15 +17,15 @@ Developer key management has been a major concern for TUF adoptions, especially Protecting a private key from loss or compromise is no simple matter. [Several](https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm) [attacks](https://jsoverson.medium.com/how-two-malicious-npm-packages-targeted-sabotaged-one-other-fed7199099c8) on software update systems have been achieved through the use of a compromised key, as securing private keys can be challenging and sometimes expensive (using hardware tokens such as Yubikeys etc), especially over a period of time. -This TAP proposes a way for developers to use their existing OpenID Connect (OIDC) accounts – such as an email account – as an identity instead of using a key. This means that they do not have to manage any additional keys or passwords. +This TAP proposes a way for signers to use their existing OpenID Connect (OIDC) accounts – such as an email account – as an identity instead of using a key. This means that they do not have to manage any additional keys or passwords. # Rationale -In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://www.minilock.io) – a tool which derives ed25519 keys from a user-chosen passphrase – to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is [no longer maintained](https://github.com/kaepora/miniLock) and has been archived. +In a previous draft of [PEP 480](https://www.python.org/dev/peps/pep-0480/), the authors proposed using [MiniLock](https://web.archive.org/web/20221207042405/http://www.minilock.io/) – a tool which derives ed25519 keys from a user-chosen passphrase – to simplify developer key management. However, this requires developers to remember a new and additional passphrase for use when uploading packages. Furthermore, the MiniLock project is [no longer maintained](https://web.archive.org/web/20191106011621/http://github.com/kaepora/miniLock) and has been archived. -In this TAP, we instead propose use of the sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for developers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides a few services, including [Fulcio](https://github.com/sigstore/fulcio) (a CA) and [Rekor](https://github.com/sigstore/rekor) (a transparency log). With sigstore, long-term efforts to keep private keys secure are not necessary, as signing keys are ephemeral and only used for a single signing event. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. +In this TAP, we instead propose use of the sigstore project. Sigstore has a growing number of adoptions, and provides a simple mechanism for signers to verify their identity using short-lived keys and ad-hoc certificates issued on the basis of OIDC. Sigstore provides a few services, including [Fulcio](https://github.com/sigstore/fulcio) (a CA) and [Rekor](https://github.com/sigstore/rekor) (a transparency log). With sigstore, long-term efforts to keep private keys secure are not necessary, as signing keys are ephemeral and only used for a single signing event. Fulcio certificates and client generated signatures are published to a timestamped transparency log managed by Rekor so that verifiers can ensure that the certificates were valid at the time of the signature. # Specification -In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to any OIDC identity, including developer email addresses, to be verified by Fulcio. These delegations MAY replace public keys for developers (such as ed25519 keys) in order to simplify their key management. Fulcio generates short-lived signing keys and uses certificates to bind these keys to an identity backed by OIDC authentication. Because the ephemeral keys listed in the certificates are short-lived, the developer will not be responsible for protecting signing keys in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. +In addition to supporting existing TUF targets delegations, this TAP adds support for delegations to any OIDC identity, including signer email addresses, to be verified by Fulcio. These delegations MAY replace public keys for signers (such as ed25519 keys) in order to simplify their key management. Fulcio generates short-lived signing keys and uses certificates to bind these keys to an identity backed by OIDC authentication. Because the ephemeral keys listed in the certificates are short-lived, the signer will not be responsible for protecting signing keys in the long term and in practice SHOULD discard them immediately after signing. Fulcio certificates are automatically uploaded to the timestamped Rekor transparency log, so repositories and clients can verify that the certificate was valid at the time of signing. ## Delegation format In order to facilitate use of Fulcio, delegations may list an OIDC identity, such as an email address, and location of a Fulcio server instead of a public key. To do so, this TAP adds a "sigstore-oidc" keytype for a KEY with the following format: @@ -50,17 +50,17 @@ The root certificate or certificate chain for the Fulcio server MUST be obtained A signature using a Fulcio key MUST include the Fulcio certificate for use in verification. For this verification, this TAP adds a 'bundle' field to 'signatures' to replace `sig` for this key type. With this field, signatures would look like: ``` -"signatures" : [ - { "keyid" : KEYID, - "bundle": BUNDLE } - , ... ] +{ + "keyid" : KEYID, + "bundle": BUNDLE + } ``` Where BUNDLE is an object that contains the verification information (transparency log references or timestamps), Fulcio X.509 signing certificate, and a signature over targets metadata, conforming to the [format defined by Sigstore](https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_bundle.proto). The transparency log verification information includes a signed timestamp (SET) from Rekor promising inclusion in the Rekor transparency log. ## Signing -In order to sign metadata using Fulcio, a developer MUST: +In order to sign metadata using Fulcio, a signer MUST: -* Initiate an OIDC session to obtain an identity token signed by the OIDC identity provider's public key containing the developer's IDENTITY. +* Initiate an OIDC session to obtain an identity token signed by the OIDC identity provider's public key containing the signer's IDENTITY. * Generate a key pair locally. * Create a certificate signing request containing the subject of the identity token. Sign this certificate with the generated private key. * Request a short-lived certificate from Fulcio by sending the certificate signing request along with the identity token. @@ -68,17 +68,17 @@ In order to sign metadata using Fulcio, a developer MUST: * Use the generated private key to create signature over targets metadata. * Upload the certificate, signature, and hash of the targets metadata to the timestamped Rekor transparency log. Rekor will return an SET with a timestamp that indicates that Rekor received the request and will include it in the log. * Create a bundle that contains the signature, Fulcio certificate, SET. -* Upload the metadata, including the bundle to the repository. -Most of these steps SHOULD be done automatically using a tool (such as Sigstore), to simplify operations for developers and minimise the risk of human errors. +Most of these steps SHOULD be done automatically using a tool (such as Sigstore), to simplify operations for signers and minimise the risk of human errors. After the +signature is created, the TUF metadata SHOULD be uploaded as ususal. ## Verification -This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by the repository and MAY be verified by the end user. The verifier MUST obtain the Rekor root keys and the certificate log public key using a secure out of band method prior to verifying the signature and associated certificate. +This signature, and the associated Rekor timestamp obtained by querying the Rekor server, MUST be verified by a centralized authority and MAY be verified by the end user. This centralized authority MAY be a repository, or MAY be a separate service. The verifier MUST obtain the Rekor root keys and the certificate log public key using a secure out of band method prior to verifying the signature and associated certificate. -While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST perform the verification. In addition, the repository MUST perform verification. +While performing the steps in the [TUF client workflow](https://theupdateframework.github.io/specification/latest/#detailed-client-workflow), if the client encounters a signature that uses a Fulcio certificate, the client MUST perform the offline verification. In addition, a centralized entity (such as the repository) MUST perform offline verification. -Verification includes the following steps: +Offline verification includes the following steps: * Verify the signature on the certificate to ensure that the signature chains up to the trusted Fulcio root. * Verify the Fulcio certificate's inclusion in the CT log with the trusted certificate log public key. @@ -86,8 +86,8 @@ Verification includes the following steps: * Verify the SET to ensure that the signature was signed during certificate validity. Similar to signing, this verification SHOULD be done with existing Sigstore tooling. -Periodically the repository SHOULD perform online verification of all Rekor uses. -Online clients MAY additionally perform online verification. This process is described in the auditors section below. +Periodically the centralized authority SHOULD perform online verification (described below) of all Rekor uses. +Online clients MAY additionally perform online verification. Offline clients rely on the centralized authority for all online checks. Online verification is described in the auditors section below. ## Auditors and Monitoring @@ -101,23 +101,23 @@ Online verification requires the following steps: 1. Verify this inclusion proof. 1. Verify that the root hash of the inclusion proof is consistent with the signed tree head verified in step 1. -Online verification SHOULD be performed periodically by repositories and MAY be performed by clients. +Online verification SHOULD be performed periodically by a centralized entity with the ability to remove compromised metadata from the repository and MAY be performed by clients. -Developers SHOULD monitor the transparency log (TL) and look for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the developer SHOULD replace any compromised metadata (creating new Fulcio certificate), and ensure the security of their OIDC account. If the OIDC account cannot be recovered, the developer MUST contact the role that delegates to them to replace the delegation to their OIDC identity. +Signers SHOULD monitor the transparency log (TL) and look for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the signer SHOULD replace any compromised metadata (creating new Fulcio certificate), and ensure the security of their OIDC account. If the OIDC account cannot be recovered, the signer MUST contact the role that delegates to them to replace the delegation to their OIDC identity. -In addition to developer monitoring, the TL SHOULD have auditors that watch the log by performing online verification for all uses in TUF metadata for any suspicious activity. If something bad (such as a mutation in the log, a deviation from the append-only policy, or invalid inclusion proofs) is found in the TL, then auditors MUST indicate this to clients to ensure they don't use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. The repository SHOULD be an auditor of the log. +In addition to signer monitoring, the TL SHOULD have auditors that watch the log by performing online verification for all uses in TUF metadata for any suspicious activity. If something bad (such as a mutation in the log, a deviation from the append-only policy, or invalid inclusion proofs) is found in the TL, then auditors MUST indicate this to clients to ensure they don't use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. The repository SHOULD be an auditor of the log. If the bad certificates are due to a compromised Fulcio server, Fulcio MUST revoke its certificate and distribute a new certificate in the TUF Sigstore root, and inform any affected clients of the compromise. # Security Analysis -Our [threat modelling](https://docs.google.com/document/d/1fkz8zO35zAIXlvTNSQYyLSK_T6n0G8STGxCoxB3RNQo/edit#) has found that using Fulcio with TUF namespacing is mostly security neutral with the existing TUF specification as long as different accounts are used for login and for the OIDC-backed signatures. This TAP improves security by eliminating the risk of developers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds additional services that may be compromised: the developer's OIDC credentials, the Fulcio server, the Rekor transparency log, and the identity provider. In this section, we will analyze the impact and recovery in each of these cases. +Our [threat modelling](https://docs.google.com/document/d/1fkz8zO35zAIXlvTNSQYyLSK_T6n0G8STGxCoxB3RNQo/edit#) has found that using Fulcio with TUF namespacing is mostly security neutral with the existing TUF specification as long as different accounts are used for login and for the OIDC-backed signatures. This TAP improves security by eliminating the risk of signers losing their keys if they chose to use Fulcio instead of a traditional public key cryptosystem. However, it adds additional services that may be compromised: the signer's OIDC credentials, the Fulcio server, the Rekor transparency log, and the identity provider. In this section, we will analyze the impact and recovery in each of these cases. -If a developer's OIDC credentials are compromised, the developer SHOULD use existing TUF processes for revocation. Specifically they SHOULD ask the delegator to replace any metadata that includes the compromised OIDC account. If the developer's credentials were compromised, but later recovered through the OIDC provider, the developer may still use these credentials, but any metadata files that were created while the credentials were compromised should be replaced with a higher version of those metadata files so that the compromised files will not be downloaded (using the existing snapshot protection). +If a signer's OIDC credentials are compromised, the signer SHOULD use existing TUF processes for revocation. Specifically they SHOULD ask the delegator to replace any metadata that includes the compromised OIDC account. If the signer's credentials were compromised, but later recovered through the OIDC provider, the signer may still use these credentials, but any metadata files that were created while the credentials were compromised should be replaced with a higher version of those metadata files so that the compromised files will not be downloaded (using the existing snapshot protection). If the Fulcio server is compromised, it may issue certificates on behalf of any attacker who uses Fulcio to verify their identity. However, the Fulcio server is backed by keys that are signed by the offline TUF Sigstore root keys, and so it is possible to recover from any Fulcio server compromise using TUF's revocation process. Additionally, all Fulcio certificates are published to two transparency logs (Rekor and the Fulcio Certificate Transparency log), so auditors of either log will notice if the Fulcio server is misbehaving and indicate this to users, for example through the use of [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) to a threshold of both auditor-signed metadata and developer-signed metadata. -If only one of the transparency logs is compromised, the attacker will not be able to do anything without cooperation from the Fulcio server because the attack will not be able to create a valid certificate without a compromised Fulcio instance. However, if the attacker compromises both the Fulcio server and the transparency log, they would be able to issue fake Fulcio certificates that also appear valid on the transparency log. If this happens, developers auditing the transparency log would notice the mis-issued certificates, and the Fulcio server and transparency log could both securely replace their key material using offline root key from the TUF Sigstore root. Implementations using this TAP SHOULD ensure that there are active auditors watching both the transparency logs. +If only one of the transparency logs is compromised, the attacker will not be able to do anything without cooperation from the Fulcio server because the attack will not be able to create a valid certificate without a compromised Fulcio instance. However, if the attacker compromises both the Fulcio server and the transparency log, they would be able to issue fake Fulcio certificates that also appear valid on the transparency log. If this happens, signers auditing the transparency log would notice the mis-issued certificates, and the Fulcio server and transparency log could both securely replace their key material using offline root key from the TUF Sigstore root. Implementations using this TAP SHOULD ensure that there are active auditors watching both the transparency logs. If the identity provider used for OIDC is compromised, they may issue tokens with attacker controlled identities. Metadata signed by certificates from compromised identity providers can be revoked using the usual TUF process, and the identity providers can be removed from the delegating TUF metadata. @@ -128,7 +128,7 @@ By default, clients will perform offline verification. They may choose to additi Clients that do not recognize Fulcio certs will not be able to validate signatures from Fulcio certs, but they will be able to parse the metadata. -'Bundle' is a new field added to 'signatures'. Clients that do not recognize Fulcio certs will ignore this field by default. +As `sig` was removed from `signatures`, parsing of the signatures will fail for old clients. # Augmented Reference Implementation From 98f5d0fa271c877a5dd4fcc5345a51851ee05cf9 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 2 Feb 2023 10:41:48 -0800 Subject: [PATCH 32/33] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Lukas Pühringer Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 38a76d89..81f01eda 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -52,7 +52,7 @@ A signature using a Fulcio key MUST include the Fulcio certificate for use in ve ``` { "keyid" : KEYID, - "bundle": BUNDLE + "bundle": BUNDLE } ``` Where BUNDLE is an object that contains the verification information (transparency log references or timestamps), Fulcio X.509 signing certificate, and a signature over targets metadata, conforming to the [format defined by Sigstore](https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_bundle.proto). The transparency log verification information includes a signed timestamp (SET) from Rekor promising inclusion in the Rekor transparency log. @@ -103,7 +103,7 @@ Online verification requires the following steps: Online verification SHOULD be performed periodically by a centralized entity with the ability to remove compromised metadata from the repository and MAY be performed by clients. -Signers SHOULD monitor the transparency log (TL) and look for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the signer SHOULD replace any compromised metadata (creating new Fulcio certificate), and ensure the security of their OIDC account. If the OIDC account cannot be recovered, the signer MUST contact the role that delegates to them to replace the delegation to their OIDC identity. +Signers SHOULD monitor the transparency log (TL) and look for certificates associated with their OIDC accounts to look for unauthorized activity. If they see a certificate on the TL that they did not issue, the signer SHOULD replace any compromised metadata (creating new Fulcio certificate), and ensure the security of their OIDC account. If the OIDC account cannot be recovered, the signer MUST contact the role that delegates to them to replace the delegation to their OIDC identity. In addition to signer monitoring, the TL SHOULD have auditors that watch the log by performing online verification for all uses in TUF metadata for any suspicious activity. If something bad (such as a mutation in the log, a deviation from the append-only policy, or invalid inclusion proofs) is found in the TL, then auditors MUST indicate this to clients to ensure they don't use bad certificates. Clients SHOULD have a way to ensure that the transparency log has been audited. For example, auditors may upload signed targets metadata to the repository upon valid completion of an audit. Clients can look for the auditor signature on targets metadata using [multi-role delegations](https://github.com/theupdateframework/taps/blob/master/tap3.md) before verifying any Fulcio-signed delegated targets. The auditor MUST only sign metadata if all signatures in the TL look good. If the auditor detects a problem, they SHOULD revoke the auditor-signed metadata. The repository SHOULD be an auditor of the log. From 8d60a51f09673df47aaa52181d2668e7bd6863db Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 2 Feb 2023 11:22:52 -0800 Subject: [PATCH 33/33] clarifications based on code review Signed-off-by: Marina Moore --- candidate-fulcio-tap.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/candidate-fulcio-tap.md b/candidate-fulcio-tap.md index 81f01eda..07ab4bc8 100644 --- a/candidate-fulcio-tap.md +++ b/candidate-fulcio-tap.md @@ -69,8 +69,7 @@ In order to sign metadata using Fulcio, a signer MUST: * Upload the certificate, signature, and hash of the targets metadata to the timestamped Rekor transparency log. Rekor will return an SET with a timestamp that indicates that Rekor received the request and will include it in the log. * Create a bundle that contains the signature, Fulcio certificate, SET. -Most of these steps SHOULD be done automatically using a tool (such as Sigstore), to simplify operations for signers and minimise the risk of human errors. After the -signature is created, the TUF metadata SHOULD be uploaded as ususal. +Most of these steps SHOULD be done automatically using a tool (such as Sigstore), to simplify operations for signers and minimise the risk of human errors. ## Verification @@ -81,7 +80,7 @@ While performing the steps in the [TUF client workflow](https://theupdateframewo Offline verification includes the following steps: * Verify the signature on the certificate to ensure that the signature chains up to the trusted Fulcio root. -* Verify the Fulcio certificate's inclusion in the CT log with the trusted certificate log public key. +* Verify the Fulcio certificate's bundled CT inclusion proof with the trusted certificate log public key. * Verify the signature on the TUF metadata using the key from the Fulcio certificate. * Verify the SET to ensure that the signature was signed during certificate validity.