Subject: [woes] Preparation for the WOES meeting

From: Paul Hoffman <[email-masked]>
Date: Fri, 18 Mar 2011 18:08:19 -0700

Greetings. We would like to set the tone for the WOES meeting-that-is-not-a-BoF that will happen on Monday, March 28, in Prague. The meeting will be from 2000 to 2130 in the Karlin I room. Sean Turner has asked us (Lucy and Paul) to be the co-chairs for this meeting, and in turn we have assured him that neither of us want to chair an eventual WG, if it is chartered.

We believe that a reasonable schedule might be:

10 min introduction by Lucy and Paul
20 min discussion / presentation on draft-rescorla-jsms
20 min discussion / presentation on draft-jones-json-web-token
40 min discussion on what the rest of the community wants
      and how it wants to proceed

For this meeting, we would like to talk almost exclusively about the format, not the many different places where such formatted objects might be used. This is based on an assumption that as long as the eventual format has just enough building blocks plus some well-scoped and well-designed extensibility, the discussion of where it can be used is actually better had in the respective WGs, not here.

We note that the two proposed formats should probably be called "the first two proposed formats": it is possible that there are others. The group needs to decide over time whether the desired outcome is one format or more than one format; history in the IETF indicates that this will not be an easy decision. Another discussion topic is what kinds of documents are needed other than format documents: is a requirements document (and possibly other non-format documents) needed?

We note that this is not a formal BoF, and we will not be the eventual leaders, so we are keeping this "agenda" informal as well. Please let us know what you think of this.

-- Lucy Lynch and Paul Hoffman

---

From: Joe Hildebrand <[email-masked]>
Date: Sat, 19 Mar 2011 14:42:39 -0600

Paul, this is a very helpful starting point - thanks.

>From my perspective (ekr can chime in on his own) there is nothing about the
JSMS format that we need to "win".  There are some things I'd like to to see
in the eventual format(s):

- implementable easily from scratch in multiple different languages
- both signing and encryption specified
- algorithm agility, but *one* (or as close to one as possible) algorithm
defined for each agile point to start with
- no canonicalization of platonic ideals into octet streams
- multiple recipients for a single encrypted payload
- easy discoverability by new implementers (view source approach)
- very limited extensibility

Things that I don't see as priorities:
- multiple signers on the same plaintext (one signature can wrap another)
- optimistic signing
- backward compatibility with existing standards
- compatibility between instantiations of the format (e.g. XML, JSON, BSON)
- mimimized wire size
- minimized memory 
- minimized CPU

On 3/18/11 7:08 PM, "Paul Hoffman" <[email-masked]> wrote:

> Greetings. We would like to set the tone for the WOES
> meeting-that-is-not-a-BoF that will happen on Monday, March 28, in Prague. The
> meeting will be from 2000 to 2130 in the Karlin I room. Sean Turner has asked
> us (Lucy and Paul) to be the co-chairs for this meeting, and in turn we have
> assured him that neither of us want to chair an eventual WG, if it is
> chartered.
> 
> For this meeting, we would like to talk almost exclusively about the format,
> not the many different places where such formatted objects might be used. This
> is based on an assumption that as long as the eventual format has just enough
> building blocks plus some well-scoped and well-designed extensibility, the
> discussion of where it can be used is actually better had in the respective
> WGs, not here.
> 
> We note that the two proposed formats should probably be called "the first two
> proposed formats": it is possible that there are others. The group needs to
> decide over time whether the desired outcome is one format or more than one
> format; history in the IETF indicates that this will not be an easy decision.
> Another discussion topic is what kinds of documents are needed other than
> format documents: is a requirements document (and possibly other non-format
> documents) needed?
> 
> We note that this is not a formal BoF, and we will not be the eventual
> leaders, so we are keeping this "agenda" informal as well. Please let us know
> what you think of this.
> 
> _______________________________________________
> woes mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/woes

-- 
Joe Hildebrand

---

From: Mike Jones <[email-masked]>
Date: Tue, 22 Mar 2011 18:23:51 +0000

Thanks, Paul and Joe, for helping frame the discussions.  I thought I'd add the perspective of those working on the JSON Web Token (JWT) format in the way that Joe did for the JSMS format:

Goals:
- minimized wire size - enabling use in space-constrained environments, such as mobile browser query strings
- implementable easily from scratch in multiple different languages
- both signing and encryption specified
- algorithm agility, but a small set of standard algorithms defined for each agile point to start with
- no canonicalization of platonic ideals into octet streams
- easy discoverability by new implementers (view source approach)
- very limited extensibility

Anticipated extensions:
- multiple signers on the same plaintext

Non-Goals:
- optimistic signing
- backward compatibility with existing standards
- compatibility between instantiations of the format (e.g. XML, JSON, BSON)
- minimized memory
- minimized CPU
- multiple recipients for a single encrypted payload
- self-describing type structure for data structures

The primary difference is that using a compact representation is a key goal of the JWT spec.

Looking forward to talking with many of you next week!

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Hildebrand
Sent: Saturday, March 19, 2011 1:43 PM
To: Paul Hoffman; [email-masked]
Subject: Re: [woes] Preparation for the WOES meeting

>From my perspective (ekr can chime in on his own) there is nothing about the JSMS format that we need to "win".  There are some things I'd like to to see in the eventual format(s):

- algorithm agility, but *one* (or as close to one as possible) algorithm defined for each agile point to start with

On 3/18/11 7:08 PM, "Paul Hoffman" <[email-masked]> wrote:

> meeting-that-is-not-a-BoF that will happen on Monday, March 28, in 
> Prague. The meeting will be from 2000 to 2130 in the Karlin I room. 
> Sean Turner has asked us (Lucy and Paul) to be the co-chairs for this 
> meeting, and in turn we have assured him that neither of us want to 
> chair an eventual WG, if it is chartered.
> 
> For this meeting, we would like to talk almost exclusively about the 
> format, not the many different places where such formatted objects 
> might be used. This is based on an assumption that as long as the 
> eventual format has just enough building blocks plus some well-scoped 
> and well-designed extensibility, the discussion of where it can be 
> used is actually better had in the respective WGs, not here.
> 
> We note that the two proposed formats should probably be called "the 
> first two proposed formats": it is possible that there are others. The 
> group needs to decide over time whether the desired outcome is one 
> format or more than one format; history in the IETF indicates that this will not be an easy decision.
> Another discussion topic is what kinds of documents are needed other 
> than format documents: is a requirements document (and possibly other 
> non-format
> documents) needed?
> 
> leaders, so we are keeping this "agenda" informal as well. Please let 
> us know what you think of this.
> 

--
Joe Hildebrand

---

From: Dick Hardt <[email-masked]>
Date: Tue, 22 Mar 2011 14:07:43 -0700

I'd add URL safe encoding as a goal. Alleviates mismatched encoding / decoding bugs.

---

From: Mike Jones <[email-masked]>
Date: Tue, 22 Mar 2011 21:09:59 +0000

Agreed

-----Original Message-----
From: Dick Hardt [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2011 2:08 PM
To: Mike Jones
Cc: Joe Hildebrand; Paul Hoffman; [email-masked]
Subject: Re: [woes] Preparation for the WOES meeting

On 2011-03-22, at 11:23 AM, Mike Jones wrote:

> - minimized wire size - enabling use in space-constrained 
> environments, such as mobile browser query strings
> - algorithm agility, but *one* (or as close to one as possible) 
> algorithm defined for each agile point to start with
>> first two proposed formats": it is possible that there are others. 
>> The group needs to decide over time whether the desired outcome is 
>> one format or more than one format; history in the IETF indicates that this will not be an easy decision.
>> We note that this is not a formal BoF, and we will not be the 
>> eventual leaders, so we are keeping this "agenda" informal as well. 
>> Please let us know what you think of this.
>>

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 22 Mar 2011 15:13:59 -0600

> - multiple signers on the same plaintext

Would you be ok with multiple signers being sign(sign(plaintext)), rather
than plaintext, signature, signature?  That allows us to stick with a single
signer in each operation, and not have to worry as much about
canonicalization.

-- 
Joe Hildebrand

---

From: Mike Jones <[email-masked]>
Date: Tue, 22 Mar 2011 21:19:17 +0000

The use case for this comes from the OpenID Contract Exchange specification, where they want multiple parties to have signed the same plaintext in no particular order.  This occurs in real life, for instance, when both parties have to sign the same business or real estate contract.

This is being move to an extension, rather than being in the core spec, because we don't believe it's a predominant use case.

I also understand the value of sign(sign(plaintext)), which is also achievable.

				-- Mike

-----Original Message-----
From: Joe Hildebrand [mailto:[email-masked]] 
Sent: Tuesday, March 22, 2011 2:14 PM
To: Mike Jones; Paul Hoffman; [email-masked]
Subject: Re: [woes] Preparation for the WOES meeting

> - multiple signers on the same plaintext

Would you be ok with multiple signers being sign(sign(plaintext)), rather than plaintext, signature, signature?  That allows us to stick with a single signer in each operation, and not have to worry as much about canonicalization.

--
Joe Hildebrand

---

From: Dick Hardt <[email-masked]>
Date: Tue, 22 Mar 2011 14:28:53 -0700

> The use case for this comes from the OpenID Contract Exchange specification, where they want multiple parties to have signed the same plaintext in no particular order.  This occurs in real life, fo…

Why not solve this infrequent use case with multiple identical messages signed separately?

---

From: Mike Jones <[email-masked]>
Date: Tue, 22 Mar 2011 21:32:05 +0000

That is a potential representation for the concept.  I believe that its advocates would argue that repeating the payload in each message is redundant and not space-efficient, but I'm not personally taking a position on this use case either way.

				-- Mike

---

From: Bryan Geraghty <[email-masked]>
Date: Sat, 26 Mar 2011 13:10:13 -0500

I'm one of these "advocates". The use case has been defined and
acknowledged. Having to duplicate a document merely because the engineers of
the signing protocol decided that multiple signatures isn't a common enough
use case seems ridiculous.

The best security concepts are simple. So requiring the implementor to come
up with an external strategy for verifying that the signed documents are
identical, and managing the relationships between copies of the document
signed *by n* signers sounds like an implementation nightmare. If it were
me, I'd be hard-pressed to chose this system.

Doesn't a single copy of a document with multiple signatures attached seem
like a much simpler and more elegant solution?

Bryan

On Tue, Mar 22, 2011 at 4:32 PM, Mike Jones <[email-masked]>wrote:

> That is a potential representation for the concept.  I believe that its
> advocates would argue that repeating the payload in each message is
> redundant and not space-efficient, but I'm not personally taking a position
> on this use case either way.
>
>                                -- Mike
>
> > The use case for this comes from the OpenID Contract Exchange
> specification, where they want multiple parties to have signed the same
> plaintext in no particular order.  This occurs in real life, for instance,
> when both parties have to sign the same business or real estate contract.
>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 26 Mar 2011 14:23:12 -0700

I'd be interested to see your simple and elegant approach to having multiple signatures that provides nominal additional complexity for the single signature use case.

-- Dick

On 2011-03-26, at 11:10 AM, Bryan Geraghty wrote:

> I'm one of these "advocates". The use case has been defined and acknowledged. Having to duplicate a document merely because the engineers of the signing protocol decided that multiple signatures isn't a common enough use case seems ridiculous.
> 
> The best security concepts are simple. So requiring the implementor to come up with an external strategy for verifying that the signed documents are identical, and managing the relationships between copies of the document signed by n signers sounds like an implementation nightmare. If it were me, I'd be hard-pressed to chose this system.
> 
> Doesn't a single copy of a document with multiple signatures attached seem like a much simpler and more elegant solution?
> 
> Bryan
> 
> On Tue, Mar 22, 2011 at 4:32 PM, Mike Jones <[email-masked]> wrote:

---

From: Joe Hildebrand <[email-masked]>
Date: Sat, 26 Mar 2011 18:24:28 -0600

Keep in mind, there's always sign(sign(plaintext)), which means that signing
can still be a simple operation.

We're still at the point of seeing if there are enough people interested in
having the discussion, so it's way to early to assume that there have been
any decisions made about what is a common use case or not.

-- 
Joe Hildebrand