Subject: [jose] Proposal - Create a SignTime Header

From: "Jim Schaad" <[email-masked]>
Date: Tue, 9 Oct 2012 11:33:42 -0700

I propose that we create a header entry that is optional and contains a time
that the signer claims that they signed at.

There are two different types of times that can found in signed statements.
The first is going to be a time field associated with the data.  This is the
current approach that is used for the JWT in that part of the claims about
the token itself is the time that the claims in the token are created.  The
second time field is associated with the signing operation and is a claim
not about the content but about the signature.  This is a signing time.  The
claims may be attested to at a different time that the signature was
created.

Having a signing time is not an important issue for the JWT specification;
however I believe that it will become an issue for cases where multiple
people will be signing a single document.  These signatures may be either
made in parallel or serialized but as they occur at different times knowing
a claimed signing time may be of interest.

Side note - I believe that the nonce question should be dropped until
somebody makes a case for it that is related to signatures and not to
protocols which is where I generally see nonces being used.  (That is for
freshness checking or associating multiple documents in a single dialog.)

Jim

---

From: Bob Wyman <[email-masked]>
Date: Tue, 9 Oct 2012 15:19:52 -0400

Time of signing would be valuable in many contexts. However, there are many
other attributes that can be associated with the signature that would also
be valuable -- depending on the specific context. Exhaustively listing all
these attributes in advance is not going to work.

So, I'd like to suggest again that the JWT format be extended to four parts
rather than three. The added part would be "signature header" and would
contain, in addition to those signature-specific elements now in JWS
Header, arbitrary JSON content which is associated with the signature.

Thus, instead of:
<JWS Header>.<payload>.<signature>
we would have:
<payload_header>.<payload>.<signature_header>.<signature>

Such a four-part structure, by isolating signature-specific data from
payload-specific data also makes it very easy to support multiple
signatures for the same payload (since all signatures would be applied to
the same base <payload_header>.<payload> bytes.) Additionally, the ability
to associate metadata with each signature allows a broad range of
application requirements to be addressed. For instance, I might define a
"signature purpose" attribute that allowed signers to distinguish between
various intents such as "claiming authorship," "approving," "denying,"
"have read," etc. Other applications might want to support signatures that
not only were created on a certain date but should be considered to
"expire" after some time or upon some other event described in the
signature header. There are all sorts of things that folk might want to do
and each signer of any particular piece of payload is likely to have some
different intent in mind when signing.

The four-part structure is vastly more flexible than the existing
three-part structure and introduces very little complexity or added bits to
the protocol. Why not use it?

bob wyman

On Tue, Oct 9, 2012 at 2:33 PM, Jim Schaad <[email-masked]> wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 10 Oct 2012 01:39:53 +0000

What is the use case here? I really hate to bring in time requirements.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Tuesday, October 9, 2012 11:34 AM
To: [email-masked]
Subject: [jose] Proposal - Create a SignTime Header

I propose that we create a header entry that is optional and contains a time that the signer claims that they signed at.

There are two different types of times that can found in signed statements.
The first is going to be a time field associated with the data.  This is the current approach that is used for the JWT in that part of the claims about the token itself is the time that the claims in the token are created.  The second time field is associated with the signing operation and is a claim not about the content but about the signature.  This is a signing time.  The claims may be attested to at a different time that the signature was created.

Having a signing time is not an important issue for the JWT specification; however I believe that it will become an issue for cases where multiple people will be signing a single document.  These signatures may be either made in parallel or serialized but as they occur at different times knowing a claimed signing time may be of interest.

Side note - I believe that the nonce question should be dropped until somebody makes a case for it that is related to signatures and not to protocols which is where I generally see nonces being used.  (That is for freshness checking or associating multiple documents in a single dialog.)

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 10 Oct 2012 10:17:46 -0700

I do not have a current use case in terms of a specific application.  I just
note that having a time that things are signed is common practice in many
documents that are used today.   As such I believe it will be a common
attribute on signatures that will be needed in the future.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Anthony Nadalin
> Sent: Tuesday, October 09, 2012 6:40 PM
> To: Jim Schaad; [email-masked]
> Subject: Re: [jose] Proposal - Create a SignTime Header
> 
the
> token itself is the time that the claims in the token are created.  The
second
> time field is associated with the signing operation and is a claim not
about the
> content but about the signature.  This is a signing time.  The claims may
be
> attested to at a different time that the signature was created.
> 
> 
> made in parallel or serialized but as they occur at different times
knowing a
> claimed signing time may be of interest.
> 
> 
>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 10 Oct 2012 17:38:21 +0000

Really think we should not be adding things w/o the proper use case, as we have a ton of nice to have things but we also have no use cases so we have not burdened the group with these

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, October 10, 2012 10:18 AM
To: Anthony Nadalin; [email-masked]
Subject: Re: [jose] Proposal - Create a SignTime Header

I do not have a current use case in terms of a specific application.  I just note that having a time that things are signed is common practice in many
documents that are used today.   As such I believe it will be a common
attribute on signatures that will be needed in the future.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Anthony Nadalin
> I propose that we create a header entry that is optional and contains 
> a
time
> The first is going to be a time field associated with the data.  This 
> is
the
the
second
about the
be
> Having a signing time is not an important issue for the JWT 
> specification; however I believe that it will become an issue for 
> cases where multiple people will be signing a single document.  These 
> signatures may be either made in parallel or serialized but as they 
> occur at different times
knowing a
> protocols which is where I generally see nonces being used.  (That is 
> for freshness checking or associating multiple documents in a single 
> dialog.)
> 
> Jim
> 
>

---

From: Daniel Holth <[email-masked]>
Date: Wed, 10 Oct 2012 13:43:50 -0400

I have a use case. I am using JSON-JWS derived signatures for code
signing. The payload is just a hash of a manifest that in turn
contains hashes of the rest of the files in the archive.

I would use a "sat" header field with the same symantics as "iat". A
signature from the publisher (with no timestamp) combined with a
signature from the package index (that only means "this package is at
least this old") would be used to make a trust decision.

Header:

{
 "sat":1349890320,
 "alg": "Ed25519",
 "key": {
 "alg": "Ed25519",
 "vk": "tmAYCrSfj8gtJ10v3VkvW7jOndKmQIYE12hgnFu3cvk"
 }
}

Payload:

{ "hash": "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" }

(http://www.python.org/dev/peps/pep-0427/#signed-wheel-files)

Apologies if this is double-posted.

Daniel Holth

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 11 Oct 2012 09:45:05 +1100

Jim said:
>> I do not have a current use case in terms of a specific application.  I
>> just note that having a time that things are signed is common practice
>> in many documents that are used today.   As such I believe it will be a
>> common attribute on signatures that will be needed in the future.

Anthony responded:
> Really think we should not be adding things w/o the proper use case, as
> we have a ton of nice to have things but we also have no use cases so
> we have not burdened the group with these

It will be much much harder to define & deploy something like signing time
in the future as it will break all existing clients (as they will see a
field they don't understand and reject the message).

If we want to postpone lots of nice-to-have features to later, then
we need to change the MUST-understand-everything rule so there is not
such a high penalty for postponing.

--
James Manger

>> Of Jim Schaad
>> a time that the signer claims that they signed at.
...