Skip to content

Remove redundant definitions. See #1311 #1312

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
richanna merged 4 commits into from
Dec 2, 2020
Merged

Remove redundant definitions. See #1311 #1312

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
e438c1a
Remove redundant definitions. See #1311
ioggstream Oct 25, 2020
0f37286
Removing circular dependency in definitions
richanna Dec 2, 2020
25c49c8
Merge branch 'master' into ioggstream-1311
richanna Dec 2, 2020
70d8898
Update draft-ietf-httpbis-message-signatures.md
richanna Dec 2, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 8 additions & 12 deletions draft-ietf-httpbis-message-signatures.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -142,14 +142,6 @@ For brevity, the term "signature" on its own is used in this document to refer t

In addition to those listed above, this document uses the following terms:

Decimal String
:
: An Integer String optionally concatenated with a period "." followed by a second Integer String, representing a positive real number expressed in base 10. The first Integer String represents the integral portion of the number, while the optional second Integer String represents the fractional portion of the number. (( Editor's note: There's got to be a definition for this that we can reference. ))

Integer String
:
: A US-ASCII string of one or more digits "0-9", representing a positive integer in base 10. (( Editor's note: There's got to be a definition for this that we can reference. ))

Signer
:
: The entity that is generating or has generated an HTTP Message Signature.
Expand Down Expand Up @@ -258,15 +250,17 @@ The following table shows example canonicalized values for different content ide

The signature's Creation Time ({{signature-metadata}}) is identified by the `*created` identifier.

Its canonicalized value is an Integer String containing the signature's Creation Time expressed as the number of seconds since the Epoch, as defined in [Section 4.16](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16) of {{POSIX.1}}.
Its canonicalized value is the `sf-integer` value of the `created` parameter (see {{params}})
containing the signature's Creation Time expressed as the number of seconds since the Epoch, as defined in [Section 4.16](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16) of {{POSIX.1}}.
Comment thread
richanna marked this conversation as resolved.
Outdated

> The use of seconds since the Epoch to canonicalize a timestamp simplifies processing and avoids timezone management required by specifications such as [RFC3339].

## Signature Expiration Time

The signature's Expiration Time ({{signature-metadata}}) is identified by the `*expires` identifier.

Its canonicalized value is a Decimal String containing the signature's Expiration Time expressed as the number of seconds since the Epoch, as defined in [Section 4.16](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16) of {{POSIX.1}}.
Its canonicalized value is the `sf-decimal` value of the `expires` parameter (see {{params}})
containing the signature's Expiration Time expressed as the number of seconds since the Epoch, as defined in [Section 4.16](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16) of {{POSIX.1}}.
Comment thread
richanna marked this conversation as resolved.
Outdated

## Target Endpoint

Expand Down Expand Up @@ -499,11 +493,13 @@ alg

created
:
: RECOMMENDED. The `created` parameter is a Decimal containing the signature's Creation Time, expressed as the canonicalized value of the `*created` content identifier, as defined in Section 2. If not specified, the signature's Creation Time is undefined. This parameter is useful when signers are not capable of controlling the Date HTTP Header such as when operating in certain web browser environments.
: RECOMMENDED. The `created` parameter is an `sf-integer` containing the signature's Creation Time,
expressed as the canonicalized value of the `*created` content identifier, as defined in Section 2. If not specified, the signature's Creation Time is undefined. This parameter is useful when signers are not capable of controlling the Date HTTP Header such as when operating in certain web browser environments.

expires
:
: OPTIONAL. The `expires` parameter is a Decimal containing the signature's Expiration Time, expressed as the canonicalized value of the `*expires` content identifier, as defined in Section 2. If the signature does not have an Expiration Time, this parameter MUST be omitted. If not specified, the signature's Expiration Time is undefined.
: OPTIONAL. The `expires` parameter is a `sf-decimal` containing the signature's Expiration Time,

@msporny msporny Oct 27, 2020

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
: OPTIONAL. The `expires` parameter is a `sf-decimal` containing the signature's Expiration Time,
: OPTIONAL. The `expires` parameter is a `sf-integer` containing the signature's Expiration Time,

I believe this was a decimal initially because I wanted to support millisecond and nanosecond precision... the use case was high frequency trading. In time, it became evident that if people want that sort of resolution, they can create their own X-Header (or the like... High-Precision-Expiration: 234.3342).

@ioggstream ioggstream Oct 27, 2020 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@msporny thanks! we are discussing create/expires here #1280

In this PR I just wanted to get rid of duplicate definitions leaving the semantic discussion to other issues. Specifically, there are other parts defining expires as a decimal. Probably we should - in other PRs - address the definition of those parameters in a one-and-only place.

@llorllale llorllale Nov 1, 2020

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1305

I believe this was a decimal initially because I wanted to support millisecond and nanosecond precision... the use case was high frequency trading. In time, it became evident that if people want that sort of resolution, they can create their own X-Header (or the like... High-Precision-Expiration: 234.3342).

Thanks for sharing the historic reasons behind this!

@richanna richanna Nov 13, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A non-standard High-Precision-Expiration header field doesn't enable sub-second expiration precision. The signature's expiration time is defined by the *expires parameter. Profiling specs can't change that, they can only add additional expiration semantics on top of that. We should not encourage that though, as it introduces confusion – which expiration rules apply? Do they both have to pass, or just one? etc.

If we want to eliminate decimals, let's express both *created and *expires in milliseconds.

@martinthomson martinthomson Nov 13, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm amazed. Is the implication here that signers and verifiers have clocks synchronized with sub-second precision?

@ioggstream ioggstream Nov 13, 2020

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@martinthomson

1- I agree with your consideration
2- In this PR I just wanted to get rid of duplicate definitions leaving the semantic discussion to other issues. Specifically, there are other parts defining expires as a decimal.
3- We should - in other PRs - discuss the precision of *created and *expires which imho should be expressed with seconds precision, but I don't think should be discussed in this PR :D

this PR is mostly an editorial one which just removes redundant definitions.

Once we agree we can delegate definitions

@msporny msporny Nov 13, 2020

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@martinthomson wrote:

I'm amazed. Is the implication here that signers and verifiers have clocks synchronized with sub-second precision?

Yes, this is true in high-frequency trading systems (for example)... some of which have highly tuned HTTP stacks and are looking at QUIC + HTTP/3 with interest. The legal implications here are that, in some of those systems, that you're supposed to execute orders as you receive them and sometimes the digital signature time matters (from a contractual basis). Here's what a couple of hundred milliseconds in a high-frequency trading system looked like back in 2013 (when we started on this spec):

https://youtu.be/B_k_elbBz8c?t=103

Things move much more quickly now, which is why we might want to drop this use case and get them to create and sign over their own header that has nanosecond (or better) precision.

All that to say, we could probably back off on the millisecond precision and go to second-based precision if we wanted to support constrained devices that may not be able to do 64-bit integers?

Also, agree with @ioggstream -- all of this is for another PR.

@msporny msporny Nov 13, 2020

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@richanna wrote:

A non-standard High-Precision-Expiration header field doesn't enable sub-second expiration precision. The signature's expiration time is defined by the *expires parameter. Profiling specs can't change that, they can only add additional expiration semantics on top of that. We should not encourage that though, as it introduces confusion – which expiration rules apply? Do they both have to pass, or just one?

Hmm, I wish things worked like that. :)

For example, the high frequency traders won't create a profiling spec, they'll do whatever they want to with this spec as it's base. Notably, they won't sign over expires (since it's optional) and will instead add their own header with nanosecond precision, sign over that, and use the standard signature verification thing PLUS their own verification algorithm that takes their header into account.

That's not necessarily a bad thing, per se... and I admit that this is a corner case... but we should be careful to not prevent this sort of usage of the specification.

@richanna richanna Nov 13, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the implication here that signers and verifiers have clocks synchronized with sub-second precision?

Yes. In addition to @msporny's high-frequency trading example, this level of clock synchronization is not uncommon within distributed systems.

For example, the high frequency traders won't create a profiling spec, they'll do whatever they want to with this spec as it's base. Notably, they won't sign over expires (since it's optional) and will instead add their own header with nanosecond precision, sign over that, and use the standard signature verification thing PLUS their own verification algorithm that takes their header into account.

Yes, and that results in a non-standard, non-interoperable implementation. That's what I want to avoid by including support for sub-second expiration times in the spec.

expressed as the canonicalized value of the `*expires` content identifier, as defined in Section 2. If the signature does not have an Expiration Time, this parameter MUST be omitted. If not specified, the signature's Expiration Time is undefined.

keyId
:
Expand Down