Updates to signature specification #147

gokarnm · 2022-04-12T00:30:22Z

Moves signed attributes out of payload
Defines new signed attributes and marks them as critical/informational
Introduces signature scheme to support different trust models

Signed-off-by: Milind Gokarn [email protected]

cc: roywill for review.

Signed-off-by: Milind Gokarn <[email protected]>

roywill · 2022-04-12T23:39:51Z

signature-specification.md

+These attributes are considered unsigned with respect to the signing key that generates the signature. These attributes are typically signed by a third party (e.g. CA, TSA).
+
+- **Certificate Chain**: This property contains the list of X.509 certificate or certificate chain. This is a REQUIRED attribute. The certificate chain is authenticated using against a trust store as part of signature validation.
+- **TSA counter signature** : The time stamp token generated for a given signature. Only [RFC3161](ietf-rfc3161) compliant TimeStampToken are supported. This is an OPTIONAL attribute.


I wonder if you should call out the work by the IETF to formulate a new standard here and though this may be the future it is not standardized at this time.

Were you referring to the COSE x.509 or some standard related to TSA signature? I intended this spec to be signature format agnostic, we'll cover JWS/COSE specific mapping of these attributes in their specific doc - e.g. Notary v2 COSE.

roywill · 2022-04-12T23:42:02Z

signature-specification.md

+
+### Signing time
+
+The signing time denotes the time at which the signature was generated. A X509 certificate has a defined lifetime during which it can be used to generate signatures. Signatures generated after the certificate expires are considered invalid. A trusted timestamp allows a verifier to determine if the signature was generated when the certificate was valid. It also allows a verifier to determine if a signature be treated as valid when a certificate is revoked, if the certificate was revoked after the signature was generated. In the absence of a trusted timestamp, signatures are considered invalid after certificate expires, and all signatures are considered revoked when a certificate is revoked.


This means that the signing time must be greater than the expiration date of the certificate or do we support greater than or equal to symantics?

Updated this section to be more explicit. Let me know if more details are required.

Suggested change

The signing time denotes the time at which the signature was generated. A X509 certificate has a defined lifetime during which it can be used to generate signatures. Signatures generated after the certificate expires are considered invalid. A trusted timestamp allows a verifier to determine if the signature was generated when the certificate was valid. It also allows a verifier to determine if a signature be treated as valid when a certificate is revoked, if the certificate was revoked after the signature was generated. In the absence of a trusted timestamp, signatures are considered invalid after certificate expires, and all signatures are considered revoked when a certificate is revoked.

The signing time denotes the time at which the signature was generated. A X509 certificate has a defined [validity](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.5) during which it can be used to generate signatures. The signing time must be greater than or equal to certificate's `notBefore` attribute, and signing time must be less than or equal to certificate's `notAfter` attribute. Signatures generated after the certificate expires are considered invalid. A trusted timestamp allows a verifier to determine if the signature was generated when the certificate was valid. It also allows a verifier to determine if a signature be treated as valid when a certificate is revoked, if the certificate was revoked after the signature was generated. In the absence of a trusted timestamp, signatures are considered invalid after certificate expires, and all signatures are considered revoked when a certificate is revoked.

shizhMSFT · 2022-04-14T12:28:15Z

signature-specification.md

 - Signed attributes `v`: The signature metadata that is integrity protected - e.g. signature expiration time, creation time, etc.
- Unsigned attributes `u`: This OPTIONAL property represents signature metadata that is not integrity protected by this envelope- e.g. timestamp, certificates, etc.
-  We anticipate all unsigned attributes contain signed content.
+- Unsigned attributes `u`: These attributes are considered unsigned with respect to the signing key that generates the signature. These attributes are typically signed by a third party (e.g. CA, TSA).


These attributes are typically signed by a third party (e.g. CA, TSA).

Third parties won't sign those attributes. Most likely, we will put counter signatures in those attributes.

I was trying to convey that these attributes are typically not "unsigned", they are signed by CA (for cert chain) and by TSA for TSA counter signature. I can change the wording. The previous version had the wording "We anticipate all unsigned attributes contain signed content"

Suggested change

- Unsigned attributes `u`: These attributes are considered unsigned with respect to the signing key that generates the signature. These attributes are typically signed by a third party (e.g. CA, TSA).

- Unsigned attributes `u`: These attributes are not signed by the signing key that generates the signature. We anticipate unsigned attributes contain content that may be signed by an different party e.g. Certificate chain signed by a CA, or TSA countersignature signed by the TSA.

shizhMSFT · 2022-04-14T12:29:25Z

signature-specification.md


 ## Signature Envelope

 The Signature Envelope is a standard data structure for creating a signed message.
 A signature envelope consists of the following components:

- Payload `m`: The data that is integrity protected - e.g. descriptor of the artifact being signed.
+- Payload `p`: The data that is integrity protected - e.g. descriptor of the artifact being signed.


Although p refers to payload, it is more common to use m for message in cryptography in terms of signature schemes.

BTW, p is usually stand for prime and \rho for policy.

Changed based on your feedback, readers not familiar with that convention were confused by it.

Suggested change

- Payload `p`: The data that is integrity protected - e.g. descriptor of the artifact being signed.

- Payload/Message `m`: The data that is integrity protected - e.g. descriptor of the artifact being signed.

shizhMSFT · 2022-04-14T12:31:06Z

signature-specification.md

-Notary v2 supports multiple envelope formats, including:
+This specification defines the set of signed and unsigned attributes that make up a valid The Notary v2 signature. This specification aims to be be agnostic of signature envelope format (e.g. COSE, JWS), details of encoding the envelope in a specific signature envelope format are covered in in separate specs.
+
+Notary v2 supports the following envelope formats:

 - [COSE Sign1](./signature-envelope-cose.md)
 - [JWT](./signature-envelope-jwt.md)


nit: It is actually JWS.

Agreed, I made that feedback on the last version by Steve and it got missed, I'll address in next update.

shizhMSFT · 2022-04-14T12:47:59Z

signature-specification.md

+`notary.signer.x509` - This signature scheme defines the trust model that uses traditional X509 based PKI. Users owns signing keys and use CA issued certificates to represent identity.
+
+`notary.signingservice.x509` - This signature scheme defines the trust model for a signing service that uses X509 based PKI. In this model, a trusted signing service manages the keys of behalf of the user, and generates signatures. The end user does not have direct access to signing keys.


Could we replace the term trust model with security model, which is a more appropriate academic term?

From the Standard attributes section, it seems that the signing time is trusted if it is from a signing service, not from a signer.

Then I am confused. It seems notary.signer.x509 is a subset of notary.signingservice.x509 as a signer can be a signing service.

For example, Alice is a signer. The signing time of her signatures are not trusted. However, Alice can set up a signing service and pretends to be a signing service. Then the signing time of her signatures are trusted. It does not make sense.

Readers may argue that signer and signing service are distinguished by the pinned trust by verifier-side policies. This is actually a paradox. If we trust the signing time using verifier-side policies based on the signer identity, why should we bother the signer type (i.e. signer or signing service)?

We can change trust model to security model, I preferred trust model as each model deals with how we establish trust (mainly authenticity), security model seemed much broader, maybe including other things like signing algorithm which are addressed by other part of the spec.

You are right, Alice a signer can generate a signature that includes trusted signing time, but it's not a valid attribute for notary.signer.x509 scheme. Alice may try to impersonate a signing service by generating the signature with notary.signingservice.x509 schema attribute, but the signature will not validate. The trust store distinguishes between trusted roots for CAs (used for notary.signer.x509) and Signing service (used for notary.signingservice.x509), these roots are stored under different location. I'm plan to propose trust_store\x509\ca_roots and trust_store\x509\signing_service_roots in trust store, trust policy PR.

Having some samples values and/or a scenario description in using these might be helpful as per discussion with @shizhMSFT.

shizhMSFT · 2022-04-14T13:13:10Z

signature-specification.md

+
+### Signing time
+
+The signing time denotes the time at which the signature was generated. A X509 certificate has a defined lifetime during which it can be used to generate signatures. Signatures generated after the certificate expires are considered invalid. A trusted timestamp allows a verifier to determine if the signature was generated when the certificate was valid. It also allows a verifier to determine if a signature be treated as valid when a certificate is revoked, if the certificate was revoked after the signature was generated. In the absence of a trusted timestamp, signatures are considered invalid after certificate expires, and all signatures are considered revoked when a certificate is revoked.


It also allows a verifier to determine if a signature be treated as valid when a certificate is revoked, if the certificate was revoked after the signature was generated.

If the certificate is revoked, the signature should also be revoked even if it is generated before the revocation.

Here's a typical scenario: Eve hacks Alice's computer and get Alice's private key. Eve uses Alice's key to generate a signature. After a few hours, Alice detects the intrusion and revoked her certificate. Apparently, Alice wants the signatures generated by Eve to be revoked, even with the cost of revoking Alice's genuine signatures.

This is usually the signer's choice. Alice may request the CA to revoke the certificate outright (all signatures are considered invalid), or from a particular date (e.g. X.509 cert InvalidityDate). This allows the signer to dictate which behavior they want, InvalidityDate may not be widely supported in verification environments, I've seen few examples which honor it.

Signed-off-by: Milind Gokarn <[email protected]>

gokarnm · 2022-04-17T19:35:00Z

@roywill @shizhMSFT made minor changes to address your feedback. Let me know if more changes are required.

SteveLasker

LGTM to merge and continue iteration

* Updates to signature specification (#147) * Moves signed attributes out of payload * Defines new signed attributes and marks them as critical/informational * Introduces signature scheme to support different trust models * Baseline for signature spec update. * Updated JWS signature envelope payload and headers. * Addressed PR feedback. Updated EC512 to EC521. * Renamed `io.cncf.notary.timestamptoken` to `io.cncf.notary.timestampSignature` * RFC 3339 time formatting * Define Base64Url encoding for JWS Signed-off-by: Milind Gokarn <[email protected]> Co-authored-by: Shiwei Zhang <[email protected]> Co-authored-by: Steve Lasker <[email protected]>

Updates to signature specification * Moves signed attributes out of payload * Defines new signed attributes and marks them as critical/informational * Introduces signature scheme to support different trust models * cbor payload * cose envelope * finalize payload * refine notations * refine datetime * Align COSE spec with JWS * update CBOR spec * spec: update data type of signingTime to data/time * Update signature-envelope-cose.md * Update signature-envelope-cose.md * update to RFC for the fields of the sig_structure * update description for field context * COSE Signature Envelope (#139) * Support for JWT and COSE envelopes (#145) * Updates to signature specification (#147) * Update COSE spec (#179) * Update signature-envelope-cose.md (#153) * `cose-envelope`: merge changes from `main` (#177) * spec: update data type of signingTime to date/time (#199) * spec: update cose and signature spec according to review comments (#204) Co-authored-by: letmaik <[email protected]> Co-authored-by: Quim Muntal <[email protected]> Co-authored-by: Milind Gokarn <[email protected]> Co-authored-by: Shiwei Zhang <[email protected]> Co-authored-by: Pritesh Bandi <[email protected]> Co-authored-by: Sajay Antony <[email protected]> Co-authored-by: Brian Krell <[email protected]> Co-authored-by: Maik Riechert <[email protected]> Co-authored-by: Thomas Fossati <[email protected]> Co-authored-by: David Tesar <[email protected]> Co-authored-by: Yi Zha <[email protected]> Signed-off-by: Steve Lasker <[email protected]>

Updates to signature specification

56e072a

Signed-off-by: Milind Gokarn <[email protected]>

gokarnm requested review from SteveLasker and shizhMSFT April 12, 2022 00:30

roywill reviewed Apr 12, 2022

View reviewed changes

shizhMSFT reviewed Apr 14, 2022

View reviewed changes

Addressed review feedback.

1786df8

Signed-off-by: Milind Gokarn <[email protected]>

SteveLasker approved these changes Apr 19, 2022

View reviewed changes

gokarnm merged commit 3e93835 into notaryproject:cose-envelope Apr 19, 2022

gokarnm mentioned this pull request Jul 14, 2022

Support for Signing scheme #175

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Updates to signature specification #147

Updates to signature specification #147

gokarnm commented Apr 12, 2022 •

edited

Loading

roywill Apr 12, 2022

gokarnm Apr 13, 2022

roywill Apr 12, 2022

gokarnm Apr 13, 2022

shizhMSFT Apr 14, 2022

gokarnm Apr 14, 2022

shizhMSFT Apr 14, 2022

shizhMSFT Apr 14, 2022

gokarnm Apr 14, 2022

shizhMSFT Apr 14, 2022

gokarnm Apr 14, 2022 •

edited

Loading

shizhMSFT Apr 14, 2022

shizhMSFT Apr 14, 2022

gokarnm Apr 14, 2022 •

edited

Loading

sajayantony Apr 19, 2022

shizhMSFT Apr 14, 2022

gokarnm Apr 14, 2022

gokarnm commented Apr 17, 2022

SteveLasker left a comment


		### Signing time

		The signing time denotes the time at which the signature was generated. A X509 certificate has a defined lifetime during which it can be used to generate signatures. Signatures generated after the certificate expires are considered invalid. A trusted timestamp allows a verifier to determine if the signature was generated when the certificate was valid. It also allows a verifier to determine if a signature be treated as valid when a certificate is revoked, if the certificate was revoked after the signature was generated. In the absence of a trusted timestamp, signatures are considered invalid after certificate expires, and all signatures are considered revoked when a certificate is revoked.

	- Unsigned attributes `u`: These attributes are considered unsigned with respect to the signing key that generates the signature. These attributes are typically signed by a third party (e.g. CA, TSA).
	- Unsigned attributes `u`: These attributes are not signed by the signing key that generates the signature. We anticipate unsigned attributes contain content that may be signed by an different party e.g. Certificate chain signed by a CA, or TSA countersignature signed by the TSA.

	- Payload `p`: The data that is integrity protected - e.g. descriptor of the artifact being signed.
	- Payload/Message `m`: The data that is integrity protected - e.g. descriptor of the artifact being signed.

		`notary.signer.x509` - This signature scheme defines the trust model that uses traditional X509 based PKI. Users owns signing keys and use CA issued certificates to represent identity.

		`notary.signingservice.x509` - This signature scheme defines the trust model for a signing service that uses X509 based PKI. In this model, a trusted signing service manages the keys of behalf of the user, and generates signatures. The end user does not have direct access to signing keys.

Updates to signature specification #147

Updates to signature specification #147

Conversation

gokarnm commented Apr 12, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gokarnm Apr 14, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gokarnm Apr 14, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gokarnm commented Apr 17, 2022

SteveLasker left a comment

Choose a reason for hiding this comment

gokarnm commented Apr 12, 2022 •

edited

Loading

gokarnm Apr 14, 2022 •

edited

Loading

gokarnm Apr 14, 2022 •

edited

Loading