Subject: [woes] New WOES charter proposal

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jul 2011 13:44:07 -0700

Greetings again. After discussion with our ADs about having a much more limited charter than what was initially proposed, Richard Barnes and I have come up with the following. We would like this discussed as much as possible on the list before the Quebec meeting so that the meeting can be about finalizing the charter. Thus, comments are welcome.

We also note that the WG might want to change its name to JOES (JavaScript Object Encryption and Signing) to make its work clearer to people who don't read the first paragraph of the charter.

Web Object Encryption and Signing (woes) 
========================================

Background 
----------

JSON is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used for serializing and transmitting structured data over a network connection. With the increased usage of JSON in protocols in the IETF and elsewhere, there is now a desire to offer security services such as object encryption and message signing for data that is being carried in JSON format.

Different proposals for providing such security services have already been defined and implemented. This Working Group's task is to standardize two security services, encrypting and digitally signing, in order to increase interoperability of security features between protocols that use JSON. The Working Group will base its work on the Cryptographic Message Syntax (CMS), and will solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is correct.

This group is chartered to work on one or two documents:

1) A Standards Track document specifying how to apply a JSON-structured digital signature to data, including (but not limited to) JSON data structures.

2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures.

The working group may decide to address both of these goals in a single document, in which case the concrete milestones for signing/encryption below will both be satisfied by the single document.

Goals and Milestones 
--------------------

Aug 2011    Submit JSON object signing document as a WG item.

Aug 2011    Submit JSON object encryption document as a WG item.

Jan 2012    Start Working Group Last Call on JSON object signing document.

Jan 2012    Start Working Group Last Call on JSON object encryption document.

Feb 2012    Submit JSON object signing document to IESG for consideration as 
Standards Track document.

Feb 2012    Submit JSON object encryption document to IESG for consideration 
as Standards Track document.

--Paul Hoffman

---

From: Mike Jones <[email-masked]>
Date: Tue, 5 Jul 2011 21:55:21 +0000

I'm still going to hold out for inclusion of the third document or capability needed for end-to-end JSON-based signing and encryption:

3) A Standards Track document specifying how to represent public keys as JSON data structures.

I know, for instance that the JSON Web Signature (JWS) doc needs to contain a reference to the JSON Web Key (JWK) format, so that also needs to be defined.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Tuesday, July 05, 2011 1:44 PM
To: [email-masked]
Subject: [woes] New WOES charter proposal

Web Object Encryption and Signing (woes) ========================================

Background
----------

Goals and Milestones
--------------------

--Paul Hoffman

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jul 2011 10:55:00 -0700

More comments, please.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jul 2011 10:58:29 -0700

> I know, for instance that the JSON Web Signature (JWS) doc needs to contain a reference to the JSON Web Key (JWK) format, so that also needs to be defined.

The question is what is the value of defining it in this WG. Why is the key format important for interoperability with the signing and encrypting specs? If we have a strong answer for that, the ADs might be more amenable to adding it; otherwise, it probably falls into the "might be nice to have in the future" category.

--Paul Hoffman

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 7 Jul 2011 21:17:38 +0000

Why do we need to base this on CMS, that should be an open.

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Thursday, July 07, 2011 10:55 AM
To: [email-masked]
Subject: Re: [woes] New WOES charter proposal

More comments, please.

--Paul Hoffman

---

From: Matt Miller <[email-masked]>
Date: Thu, 7 Jul 2011 15:49:40 -0600

> The question is what is the value of defining it in this WG. Why is the key format important for interoperability with the signing and encrypting specs? If we have a strong answer for that, the ADs…

I agree with Mike Jones.  Without a common key format, distributing keys becomes much more difficult, which makes implementation and deployment much more difficult.

- m&m

Matt Miller - <[email-masked]>
Collaboration Software Group - Cisco Systems, Inc.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Jul 2011 02:06:22 +0300

And what does it mean to "base it on CMS"? 

It could, for example, mean that 
1) the same functionality as CMS has to be provided (but with a JSON encoding)
2) folks should look at CMS to get inspired
3) for a chosen subset of CMS that the JSON-based realization must be semantically equivalent (for example, to make translation easy or so)
4) re-use of parts is encouraged (such as registries, etc.) 

What did you had in mind, Paul?

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jul 2011 16:17:59 -0700

I was reflecting an earlier message from our AD. On Jun 14, 2011, at 9:31 AM, Sean Turner wrote:

> In Prague, I thought the goal was pretty straightforward: JSONize CMS.

That seems clear to me. It's closer to your #1 above, but the rest of the proposed charter makes it clear that it is a subset of CMS, namely signing and encrypting.

--Paul Hoffman

---

From: Mike Jones <[email-masked]>
Date: Thu, 7 Jul 2011 23:21:40 +0000

There are other requirements not met by CMS for many of our use cases.  For instance, having a compact representation and having a URL-safe implementation.

I'm fine with CMS being *one* of the input documents, but I believe it's too strong a statement to say that we've decided up-front that the goal is to "JSONize CMS" or to have the charter reflect that narrowing of the mission.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Thursday, July 07, 2011 4:18 PM
To: Hannes Tschofenig
Cc: Anthony Nadalin; [email-masked]
Subject: Re: [woes] New WOES charter proposal

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 08 Jul 2011 00:42:13 +0100

> I'm fine with CMS being *one* of the input documents, but I believe it's too strong a statement to say that we've decided up-front that the goal is to "JSONize CMS" or to have the charter reflect t…

Can you say what is not in CMS that might be needed here?
I find it hard to think of anything myself, but if there
are things, (specific features, that is) that'd be good
to know.

S.

---

From: Sean Turner <[email-masked]>
Date: Thu, 07 Jul 2011 21:02:54 -0400

I'm always reminded by the warning found in RFC 5406:

   Security protocols are very hard to design;

Trying to get a new security protocol through the standardization hoops 
is much harder than starting with a known protocol profiling it down to 
what you want.  If you start from scratch, you end up in the whole let's 
pick from one of the competing options, but before you can do that you 
need to generate some requirements.

spt

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 8 Jul 2011 01:18:58 +0000

Concern is if folks think that the same formats have to be preserved and same algorithms, etc. If it is simply signing and encrypting and that can be done in any format and algorithms then I think we are fine, but it should be made a little clearer and say something like "similar signing and encrypting function that CMS provides"

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]] 
Sent: Thursday, July 07, 2011 4:18 PM
To: Hannes Tschofenig
Cc: Anthony Nadalin; [email-masked]
Subject: Re: [woes] New WOES charter proposal

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Jul 2011 10:37:42 -0400

<hat type="individual"/>

As I read that part of the charter, I understood it to suggest that there should be some sort of logical equivalence between the two encodings -- that the parts of the WOES object should correspond to some subset of the parts in a CMS object.  Kind of like the JSMS proposal does now.  

It seems like this gets around Sean's concern about re-designing a security protocol, and actually saves some design work, because you can push hard things off to RFC 5652.  At the same time, it keeps you free to make a compact encoding; you can use "s" instead of "Signer" as long as you say so in the spec.

--Richard

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 08 Jul 2011 08:02:50 -0700

On 7/5/2011 1:44 PM, Paul Hoffman wrote:
> 1) A Standards Track document specifying how to apply a JSON-structured
> digital signature to data, including (but not limited to) JSON data
> structures.
>
> 2) A Standards Track document specifying how to apply a JSON-structured
> encryption to data, including (but not limited to) JSON data structures.
>
> The working group may decide to address both of these goals in a single
> document, in which case the concrete milestones for signing/encryption below
> will both be satisfied by the single document.
>
> Goals and Milestones --------------------
>

The language "how to apply" is a bit odd.  It implies that the thing already
exists and that the current effort is an implementation effort.

I suggestion:

    A specification for JSON-based [digital signature / encryption] for JSON data.

I do note the "but not limited to" language, but it is not obvious what it
means.  This needs to be explained explicitly, since it implies a major
value-add and potential a significant bit of added work.  I'm not claiming it IS
a lot more work, but merely that the cryptic reference could imply all sorts of
things and needs to be constrained.

>>> protocols that use JSON. The Working Group will base its work on the
>>> Cryptographic Message Syntax (CMS), and will solicit input from the rest
>>> of the IETF Security Area to be sure that the security functionality in
>>> the JSON format is correct.

I share the question about requiring that the work start with CMS.  Perhaps it 
is the right decision, but there are arguments in other directions and I don't 
think I've seen the question resolved.

I'll echo Hannes' question too:  the meaning of "based on" needs to be stated 
more explicitly.  A variety of entirely reasonable meanings could apply, from 
conceptual through to installed base of code, so the specific meaning here needs 
to be provided.  (And then debated.)

As an example of the debate:

    *  What is the Internet-scale momentum that justifies using CMS as the 
starting point?

    *  What are the negatives about CMS that could argue against using it?

    *  How is CMS better than alternatives that could be used as the basis?

> On 7/5/2011 2:55 PM, Mike Jones wrote:
>> I'm still going to hold out for inclusion of the third document or
>> capability needed for end-to-end JSON-based signing and encryption:
>>

A standardized mobile key format could be helpful, since transporting these
these is an essential function for OA&M.  Even within a single-administration
environment, keys need to be shuttled among applications and systems.

This issue came up in the background for DKIM.  I have not heard a huge
community outcry demanding it, but I have repeatedly heard background grumbles
wishing for it.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 08 Jul 2011 08:02:56 -0700

> are things, (specific features, that is) that'd be good

Stephen,

 From the standpoint of argumentation process, your question is literally out of 
order.  That is, out of sequence.

It calls for criticizing details that have not been stated.

The first requirement is for proponents to provide much more explicit details 
about what is being proposed in the use of CMS.  After that, critics can point 
to missing details or details that they believe should not apply here, or 
alternatives with better details, or...

Richard's response is along the lines of what is first needed, but there needs 
to be agreement on whatever is meant.

I think there should be some explicit debate about the choices for conceptual, 
semantic, syntactic, software, whatever highest point of departure that will be 
used.  There are choices and the differences are meaningful.

d/

-- 

   Dave Crocker

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 8 Jul 2011 16:15:52 +0000

So I don't expect that equivalence would have to be ASN.1 structures or DER/BER encodings. I would also not to have to support full objects like SignedData.

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]] 
Sent: Friday, July 08, 2011 7:38 AM
To: Anthony Nadalin
Cc: Paul Hoffman; Hannes Tschofenig; [email-masked]
Subject: Re: [woes] New WOES charter proposal

<hat type="individual"/>

--Richard

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Jul 2011 21:45:51 +0100

Hi Dave,

(Sorry for the slow response, I've been offline for
a week.)

On 08/07/11 16:02, Dave CROCKER wrote:
>>> There are other requirements not met by CMS for many of our use
>>> cases.  For instance, having a compact representation and having a
>>> URL-safe implementation.
>>>
>>> I'm fine with CMS being *one* of the input documents, but I believe
>>> it's too strong a statement to say that we've decided up-front that
>>> the goal is to "JSONize CMS" or to have the charter reflect that
>>> narrowing of the mission.
>>
> From the standpoint of argumentation process, your question is literally
> out of order.  That is, out of sequence.
> 
> The first requirement is for proponents to provide much more explicit
> details about what is being proposed in the use of CMS.  After that,
> critics can point to missing details or details that they believe should
> not apply here, or alternatives with better details, or...

Well, I don't really follow your logic there, but we're not
aiming to do a new thing here.

A few years ago, we did the CMS->XML thing as Paul pointed
out. Before that there were a number of other formats (X.400
security, EDIFACT/ANSI X9.42, MOSS, PGP, PEM) some aspects
of which influenced CMS as I recall. (But didn't check back
so the failing memory excuse may be needed in a bit:-)

Anyway the path for developing yet another crypto format
is a pretty well trodden one and IMO CMS is the best current
starting point for that process, so I think its entirely
reasonable to ask people why they disagree with that.

It does of course presume familiarity with CMS, but then
that should be a prerequisite for working on woes, really.

S.

> Richard's response is along the lines of what is first needed, but there
> needs to be agreement on whatever is meant.
> 
> I think there should be some explicit debate about the choices for
> conceptual, semantic, syntactic, software, whatever highest point of
> departure that will be used.  There are choices and the differences are
> meaningful.
> 
> d/
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 16 Jul 2011 01:36:27 +0100

On 16/07/11 01:23, Dave CROCKER wrote:
> 
> On 7/14/2011 1:45 PM, Stephen Farrell wrote:
>>> details about what is being proposed in the use of CMS.
> ...
> ...
> Steve,
> Oh.  This working group is merely a CMS encoding exercise?  That was not
> at all clear previously.
>  
> I suspect I am not the only one who missed this as the anchoring and
> inflexible premise to the work.  (For reference, that requires even
> stronger language than is in the current draft.)

Maybe you could put [] around the sarcasm, given that
this is JSON related? :-)

I asked for examples of what's not covered by CMS but
is needed here. I did that actually wanting to get an
answer since I may well be missing something. (So far,
no substantive answer has been offered.) I was not
trying to score some rhetorical points.

S.

---

From: Mike Jones <[email-masked]>
Date: Sat, 16 Jul 2011 01:13:22 +0000

Some use cases require a compact, URL-safe data representation.  For instance, this is needed when the data is passed in a URL query parameter - particularly for feature phone browsers that may limit URLs to 1024 or sometimes even 256 characters.  That's one concrete example of something not covered by CMS.

Some end-to-end use cases require a JSON key representation and ways of referring to them.  That's another concrete example of something not covered in CMS.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Friday, July 15, 2011 5:36 PM
To: Dave CROCKER
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

On 16/07/11 01:23, Dave CROCKER wrote:
>>> The first requirement is for proponents to provide much more 
>>> explicit details about what is being proposed in the use of CMS.
> ...
>> Well, I don't really follow your logic there, but we're not aiming to 
>> do a new thing here.
> ...
>> Anyway the path for developing yet another crypto format is a pretty 
>> well trodden one and IMO CMS is the best current starting point for 
>> that process, so I think its entirely reasonable to ask people why 
>> they disagree with that.
>>
>> It does of course presume familiarity with CMS, but then that should 
>> be a prerequisite for working on woes, really.
> 
> 
> Steve,
> 
> Oh.  This working group is merely a CMS encoding exercise?  That was 
> not at all clear previously.
>  

Maybe you could put [] around the sarcasm, given that this is JSON related? :-)

I asked for examples of what's not covered by CMS but is needed here. I did that actually wanting to get an answer since I may well be missing something. (So far, no substantive answer has been offered.) I was not trying to score some rhetorical points.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 16 Jul 2011 02:56:09 +0100

Hi Mike,

> Some use cases require a compact, URL-safe data representation.  For instance, this is needed when the data is passed in a URL query parameter - particularly for feature phone browsers that may lim…

Note that no-one afaik is suggesting using ASN.1 encoding, so
any JSON specific payload encoding stuff has to be work for woes
to do. I would assume that that's up for debate all right, but
don't see that it has anything to do with CMS, same as CMS
doesn't itself say anything about MIME body parts which is
handled in another S/MIME RFC entirely.

So, unless I'm missing something this is not a missing bit
of CMS but rather an additional, payload-related (from the
crypto p-o-v) requirement that you're expressing.

> Some end-to-end use cases require a JSON key representation and ways of referring to them.  That's another concrete example of something not covered in CMS.

So some way to identify keys is clearly needed all right and I tend
to agree that that's an area where CMS is too X.509 specific in that
CMS dives inside the X.509 structure.

But there are well known choices, as I mentioned in a mail yesterday,
so I still don't see that there's a real need for a JSON
representation for keys, (though it might still be sensible), can
you clarify when you'd need to say refer to an RSA public exponent
specifically, or to an ECC parameter?

While I think XMLDSIG's KeyInfo is better than IssuerAndSerialNumber,
I'm not at all sure anyone really uses the <Exponent> element for
anything that wouldn't work just as well with the base64 encoding
of an X.509 blob. But its been a while, so maybe RSAKeyValue is more
useful than I recall.

If there's never a need to refer to the RSA public exponent or
equivalents for other algorithms, then you don't need a way to
represent keys in JSON, but rather a way to put some key
representation or key identifier inside square brackets in a
well defined way. The latter, done smartly, should take a whole
lot less effort to get right would be my guess.

S.

---

From: John Bradley <[email-masked]>
Date: Fri, 15 Jul 2011 22:09:41 -0400

In SAML meta-data using keyinfo is not uncommon in a number of federations.  

Some use self signed x.509 certs but that is recommended against by some federations.

If we look at existing examples of JSON encryption/signature they all avoid or provide options to having to parse a x.509 certificate.

The anti x.509 bias amongst some developer communities can be a real roadblock in my experience.

John Bradley

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 15 Jul 2011 17:23:58 -0700

...
...

Steve,

Oh.  This working group is merely a CMS encoding exercise?  That was not at all 
clear previously.

I suspect I am not the only one who missed this as the anchoring and inflexible 
premise to the work.  (For reference, that requires even stronger language than 
is in the current draft.)

d/

-- 

   Dave Crocker

---

From: Mike Jones <[email-masked]>
Date: Sat, 16 Jul 2011 04:57:48 +0000

As John points out, there's a significant anti-X.509/ASN.1 bias among web developers at this point.  It may not be "reasonable" or "fair", but it's nonetheless in play - in part because essentially all modern development tools and languages can parse JSON, whereas the same can't be said of ASN.1 (or XML, for that matter).  For us to succeed in winning developer mindshare end-to-end, we need to address the need to represent keys in formats they're comfortable with.

Have a look at the JSON Web Key (JWK):  http://tools.ietf.org/html/draft-jones-json-web-key spec.  It's about as simple a JSON representation of public keys as you can get.  It doesn't do everything.  (But then, that's kind of the point!)

Looking forward to seeing most of you in Quebec!

				-- Mike

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Friday, July 15, 2011 7:10 PM
To: Stephen Farrell
Cc: Mike Jones; [email-masked]; Dave CROCKER
Subject: Re: [woes] New WOES charter proposal

John Bradley

On 2011-07-15, at 9:56 PM, Stephen Farrell wrote:

> Note that no-one afaik is suggesting using ASN.1 encoding, so any JSON 
> specific payload encoding stuff has to be work for woes to do. I would 
> assume that that's up for debate all right, but don't see that it has 
> anything to do with CMS, same as CMS doesn't itself say anything about 
> MIME body parts which is handled in another S/MIME RFC entirely.
> 
> So, unless I'm missing something this is not a missing bit of CMS but 
> rather an additional, payload-related (from the crypto p-o-v) 
> requirement that you're expressing.
> 
> So some way to identify keys is clearly needed all right and I tend to 
> agree that that's an area where CMS is too X.509 specific in that CMS 
> dives inside the X.509 structure.
> 
> representation for keys, (though it might still be sensible), can you 
> clarify when you'd need to say refer to an RSA public exponent 
> anything that wouldn't work just as well with the base64 encoding of 
> an X.509 blob. But its been a while, so maybe RSAKeyValue is more 
> useful than I recall.
> 
> representation or key identifier inside square brackets in a well 
> defined way. The latter, done smartly, should take a whole lot less 
> effort to get right would be my guess.
> 
> S.
> 
>> 
>> 				-- Mike
>> 
>>>> Well, I don't really follow your logic there, but we're not aiming 
>>>> to do a new thing here.
>>> ...
>>>> Anyway the path for developing yet another crypto format is a 
>>>> pretty well trodden one and IMO CMS is the best current starting 
>>>> point for that process, so I think its entirely reasonable to ask 
>>>> people why they disagree with that.
>>>> 
>>>> It does of course presume familiarity with CMS, but then that 
>>>> should be a prerequisite for working on woes, really.
>>> 
>>> 
>>> Steve,
>>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 25 Jul 2011 10:21:08 -0400

<hat type="individual"/>

It's not clear to me what practical difference this requirement makes.  I would expect that the DER encoding of CMS is probably more compact than a comparable JSON format, so you're not optimizing length by using JSON.  And JSON doesn't define a URL-safe encoding.  If minimizing the size of something in a URL is really your goal, it seems likely that size(base64(cms)) < size(urlencode(json)).

Or, if you're willing to take the JSON penalty in byte-efficiency, are you trying to argue that there are fields that should be left out relative to CMS?  Could you point to some examples?

--Richard

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 25 Jul 2011 09:59:58 -0700

I now find myself hoping this is not the beginning someone making a case
for ASN.1 encoding in WOES.

For my edification, can someone comment on how CMS would likely be
referenced in WOES? Would it likely be a normative reference (i.e. key
transport/wrapping, as it is in xmlenc-core), or otherwise would it
probably be just informational?

Paul

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Jul 2011 19:16:05 +0200

> probably be just informational?

We seem to be bike-shedding on the words "based on" in the charter.
Perhaps it helps if we say something to the effect that WOES draws
upon experience from CMS and XML-dsig/enc and leave it at that.

	Cheers Leif

---

From: Matt Miller <[email-masked]>
Date: Mon, 25 Jul 2011 13:18:16 -0400

On Jul 25, 2011, at 13:16, Leif Johansson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

+1

- m&m

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 25 Jul 2011 10:18:39 -0700

+1

Paul

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 25 Jul 2011 13:20:58 -0400

+1

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 25 Jul 2011 13:28:59 -0400

That works for me. Certainly when I talk about basing something on
CMS, what I mean
is that I'm imitating CMS, not that there is a normative dependency.

-Ekr

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Jul 2011 19:32:35 +0200

> is that I'm imitating CMS, not that there is a normative dependency.

I personally think that is the right way to think about this.

	Cheers Leif

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 25 Jul 2011 13:36:30 -0400

Basically, yeah, although it may be handy to incorporate some parts of CMS by reference (semantics/definitions of certain fields, say).  

--Richard

---

From: Mike Jones <[email-masked]>
Date: Mon, 25 Jul 2011 18:07:13 +0000

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Monday, July 25, 2011 10:29 AM
To: Matt Miller
Cc: [email-masked]
Subject: Re: [woes] New WOES charter proposal

That works for me. Certainly when I talk about basing something on CMS, what I mean is that I'm imitating CMS, not that there is a normative dependency.

-Ekr

On Mon, Jul 25, 2011 at 1:18 PM, Matt Miller <[email-masked]> wrote:
>>> I now find myself hoping this is not the beginning someone making a 
>>> case for ASN.1 encoding in WOES.
>>>
>>> referenced in WOES? Would it likely be a normative reference (i.e. 
>>> key transport/wrapping, as it is in xmlenc-core), or otherwise would 
>>> it probably be just informational?
>>

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Jul 2011 14:19:43 -0400

> upon experience from CMS and XML-dsig/enc and leave it at that.

1. There is considerably more than a bikeshedding difference between

    a) normative dependence on a protocol, where the new exercise is merely a 
syntactic re-coding"

vs, for example

    b) "take the ideas from the existing work and use them as a basis for 
writing a new protocol."

2. There is a significant constituency in the current topic that are using 
language that sounds very much like option a) above.

That is, I believe there is a meaningful split between an established security 
community view for this topic, versus the views of the json-oriented folk.

What is perhaps missing is a clear and shared understanding of the exact uses 
that are intended for the current work.

For example "must be able to encode it in a URL" is a rather meaningful and 
substantial constraint.

d/

-- 

   Dave Crocker

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Jul 2011 20:37:46 +0200

On 07/25/2011 08:19 PM, Dave CROCKER wrote:
>    a) normative dependence on a protocol, where the new exercise is
> merely a syntactic re-coding"
> 
> vs, for example
> 
> 2. There is a significant constituency in the current topic that are
> using language that sounds very much like option a) above.

The '+1's today seem to indicate there is significant support for (2)
but I'm not so sure the difference is all that big.

I propose that the asn.1->json technology change is big enough (if you
take things like tooling, development models etc into account) so as
to make a literal 1-1 translation unlikely.

WOES will (imho) have to make intelligent choices about what to keep
from cms and what it doesn't need. That to me sounds more like "drawing
experience from" rather than "basing on".

	Cheers Leif

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 25 Jul 2011 11:48:22 -0700

>     b) "take the ideas from the existing work and use them as a basis for 

I have serious doubts that we should accept a) on its face as the
objective of this working group. I suggest that building the charter on
b) will not negate actually implementing a) if it turns out—after
productive discussion—that it makes sense to take such a direction.

> that are intended for the current work.

Chicken, meet egg; requirements, meet charter. As I see it, the
objective is to get a reasonably succinct—yet not too restrictive—
charter adopted such that analysis and discussion can begin in earnest.

> For example "must be able to encode it in a URL" is a rather meaningful and 

Should we be diving into such details, making them critical path items
to getting the charter in place? If so, I project a significant
deviation from the proposed roadmap, time-wise. I would prefer to avoid
creating extra burdens to completing the charter.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 25 Jul 2011 20:42:13 +0100

> experience from" rather than "basing on".

FWIW, my understanding of "basing on" matches Leif's above.

The idea with "basing on" CMS as I understand it is to avoid
starting over with analysis of the basic concepts and features
(cutting things out is fine) and was not to say "use ASN.1
encoding".

Maybe "basing on" wasn't a good term. Whatever.

S.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Jul 2011 15:44:03 -0400

> (cutting things out is fine) and was not to say "use ASN.1

That was my understanding as well: "let's not define utterly new semantics".

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Jul 2011 22:04:19 +0200

> That was my understanding as well: "let's not define utterly new semantics".

OK so maybe we were bikesheding on the term after all ;-)