Subject: [woes] Proposed charter, post-Quebec edition

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Aug 2011 16:13:53 -0700

Here is a proposal for the charter based on the discussion in the BoF last week and later discussion with Sean Turner. Comments, praise, scorn, etc., are welcome.

--Paul and Richard

Javascript Object Signing and Encrypting (jose)
===============================================

Background 
----------

Javascript Object Notation (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 encryption and digital signatures 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 well-known message security primitives (e.g., 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 four 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. "Digital signature" is defined as a hash operation followed by a signature operation using asymmetric keys.

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

3) A Standards Track document specifying how to encode public keys as JSON-structured objects.

4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents.

The working group may decide to address one or more 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.

Aug 2011    Submit JSON key format document as a WG item.

Aug 2011    Submit JSON algoritm 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.

Jan 2012    Start Working Group Last Call on JSON key format document.

Jan 2012    Start Working Group Last Call on JSON algorithm 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.

Feb 2012    Submit JSON key format document to IESG for consideration 
as Standards Track document.

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Aug 2011 20:23:07 -0600

Looks good, although the dates seem a mite aggressive, especially since
it's doubtful that the WG would be approved this month (given the need
for internal IESG review, external review, and an IESG decision).

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Aug 2011 06:45:03 -0700

> for internal IESG review, external review, and an IESG decision).

There is nothing stopping the two sets of authors from working together pre-WG. :-)

--Paul Hoffman

---

From: Matt Miller <[email-masked]>
Date: Wed, 3 Aug 2011 14:17:09 -0600

I think it looks good, too.  I also think the schedule might be a bit too aggressive.  Given my interactions with one of the authors of one of the existing specs, I have doubts much will get done before the end of the month (-:

Also, I'd like to thank Paul and Richard for chairing the BoF.

- m&m
On Aug 2, 2011, at 17:13, Paul Hoffman wrote:

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

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 3 Aug 2011 16:33:55 -0400

Paul,

Looks good.

Just my clarification, looking at 1) and 2) does it mean that the
resulting JOSE WG specifications can be applied to non-JSON data
structures? (I'm ok with this).

Also, will RFC4627 be "upgraded" to standards track?

Thanks.

/thomas/

__________________________________________

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Paul Hoffman
> Sent: Tuesday, August 02, 2011 7:14 PM
> To: [email-masked]
> Subject: [woes] Proposed charter, post-Quebec edition
> 
> Here is a proposal for the charter based on the discussion in the
BoF
> last week and later discussion with Sean Turner. Comments, praise,
> scorn, etc., are welcome.
> 
> --Paul and Richard
> 
> Javascript Object Notation (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 encryption and digital signatures 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
well-
> known message security primitives (e.g., 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.
> 
> 1) A Standards Track document specifying how to apply a
JSON-structured
> digital signature to data, including (but not limited to) JSON data
> structures. "Digital signature" is defined as a hash operation
followed
> by a signature operation using asymmetric keys.
> 
> 2) A Standards Track document specifying how to apply a
JSON-structured
> encryption to data, including (but not limited to) JSON data
> structures.
> 
> 3) A Standards Track document specifying how to encode public keys
as
> JSON-structured objects.
> 
> 4) A Standards Track document specifying mandatory-to-implement
> algorithms for the other three documents.
> 
> The working group may decide to address one or more 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.

---

From: Matt Miller <[email-masked]>
Date: Wed, 3 Aug 2011 14:35:42 -0600

> structures? (I'm ok with this).

Yes; at least one of the desired uses is to sign/encrypt XMPP stanzas! (-:

- m&m

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

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 3 Aug 2011 16:40:11 -0400

Thanks Matt -- the broader use of JOSE, the better :)

/thomas/

> From: Matt Miller [mailto:[email-masked]]
> Sent: Wednesday, August 03, 2011 4:36 PM
> To: Thomas Hardjono
> Cc: Paul Hoffman; [email-masked]
> Subject: Re: [woes] Proposed charter, post-Quebec edition
> 
> Yes; at least one of the desired uses is to sign/encrypt XMPP
stanzas!
> (-:

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Aug 2011 14:49:16 -0600

> Also, will RFC4627 be "upgraded" to standards track?

There's no real need -- most of the media type registration RFCs are
informational. However, we might want to look at the entire "stack" of
JSON-related specs and move them all to standards track (media type,
schema, etc.).

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Aug 2011 14:50:11 -0600

> JSON-related specs and move them all to standards track (media type,

Clarification: by "we" I do *not* mean the (presumptive) JOSE WG.

/psa

---

From: "Paul C. Bryan" <[email-masked]>
Date: Wed, 03 Aug 2011 14:13:48 -0700

> Yes; at least one of the desired uses is to sign/encrypt XMPP stanzas! (-:

For my edification, why would JOSE want to concern itself with
representations of other media types, rather than allowing other
transformations to deal with this?

Put another way, if there were a method of encapsulating and encoding
non-JSON media types in a JSON structure, would JOSE seek to reinvent
such a thing, or merely defer to using it?

Paul

---

From: Matt Miller <[email-masked]>
Date: Wed, 3 Aug 2011 15:33:00 -0600

On Aug 3, 2011, at 15:13, Paul C. Bryan wrote:

> For my edification, why would JOSE want to concern itself with representations of other media types, rather than allowing other transformations to deal with this?
> 
> Put another way, if there were a method of encapsulating and encoding non-JSON media types in a JSON structure, would JOSE seek to reinvent such a thing, or merely defer to using it?
> 

I think there's real benefit to having JSON as the envelope, and serious problems forcing all other structures to encode/decode as JSON.  At least for XMPP, a JSON representation can turn out to be larger than the original XML.  I imagine there's other data formats this is the case.

- m&m

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Aug 2011 00:11:12 -0400

Is the object here to arrive at an RFC or to arrive at a standard with a broad base of support in the web services apps community?

If the latter the I suggest much more time so as to have the ability to get buy in from the relevant community.

Sent from my angry birds pad

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Aug 2011 08:24:18 -0400

Based on experience of DANE, I think that the whole process will go a lot
faster if there isn't an attempt to rush through a scheme.

I can't see any technical issues in this case but my experience of DANE has
been that we argue for several months on whether to consider an issue that
could be addressed in a couple of weeks if it was accepted as a technical
matter. And at the end the issue is still not resolved.

Trying to make a consensus building process go faster than consensus can be
built is a sure recipe for disaster.

These schedules are nonsense.

On Thu, Aug 4, 2011 at 12:11 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> Is the object here to arrive at an RFC or to arrive at a standard with a
> broad base of support in the web services apps community?
>
> > Here is a proposal for the charter based on the discussion in the BoF
> last week and later discussion with Sean Turner. Comments, praise, scorn,
> etc., are welcome.
> >
> > --Paul and Richard
> >
> > Javascript Object Notation (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 encryption and digital
> signatures 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 well-known message security
> primitives (e.g., 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.
> >
> > 1) A Standards Track document specifying how to apply a JSON-structured
> structures. "Digital signature" is defined as a hash operation followed by a
> signature operation using asymmetric keys.
> >
> > 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 one or more of these goals in a
> signing/encryption below will both be satisfied by the single document.
> >
> > Goals and Milestones
> > --------------------
> >

-- 
Website: http://hallambaker.com/

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2011 08:39:23 -0400

Yes I was getting some grief from one of the large venders about openID Connect being based on JSON because it is not a standard like XML.

They were just being general prats about IPR things.  

However at some point someone (not JOSE) should look at the overall status of the JSON stack.
It is not a prerequisite for any JOSE work however.

John Bradley

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2011 08:52:54 -0400

In the JWS/JWE drafts the goal was to provide JSON envelopes for base64url encoded blobs.   

In most cased we intend for those to be JSON, but nothing prevents this from being used with XML similar to the failed SAML simple sign.

With JSON payloads we really wanted to avoid touching the payload.  Inserting elements, canonicalization  and other things that touch the payload are highly problematic.

John B.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Aug 2011 08:52:48 -0400

On Thu, Aug 4, 2011 at 8:39 AM, John Bradley <[email-masked]> wrote:

> Yes I was getting some grief from one of the large venders about openID
> Connect being based on JSON because it is not a standard like XML.
>

This might be the reason for the concern:

http://www.virginiaiplaw.com/2011/03/articles/patent-litigation/judge-brinkema-grants-summary-judgment-to-defendants-in-tecsec-v-ibm-patent-case/

I can't go into the details of the case as I was a defense expert for
another defendant.

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2011 09:02:48 -0400

Good info.

This particular company is currently more on the asserting there IPR portfolio end of the spectrum at the moment.  
That perhaps makes them more aware of the risks.

Thanks
John B.
On 2011-08-04, at 8:52 AM, Phillip Hallam-Baker wrote:

> I can't go into the details of the case as I was a defense expert for another defendant.
>  
> --

---

From: Sean Turner <[email-masked]>
Date: Thu, 04 Aug 2011 09:03:01 -0400

> Javascript Object Signing and Encrypting (jose)

I just want to make sure that we agree now that a digital signature is a 
hash followed by a signature algorithm (e.g., RSA with SHA-256).  I've 
seen a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256) 
was a digital signature; one called it a symmetric key based digital 
signature algorithm (note this phrase didn't get through the IESG).

> 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents.

I think this addition is good.  In the past we've bundled the MTI 
algorithms with the protocol and then reving the MTI algorithms caused 
unnecessary churn on the protocol even if the protocol is stable.

I also think this draft need not only include MTI algorithms, but the 
draft definitely needs to say which ones are the MTI algorithms.

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

The dates are little ambitious.  Just based on the process, I doubt this 
can be charter by the end of August.  I'd swap Aug->Oct, Jan->Mar, and 
leave Feb as-is.

spt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Aug 2011 09:03:31 -0400

On Thu, Aug 4, 2011 at 8:52 AM, John Bradley <[email-masked]> wrote:

> In most cased we intend for those to be JSON, but nothing prevents this
> from being used with XML similar to the failed SAML simple sign.
>
> With JSON payloads we really wanted to avoid touching the payload.
>  Inserting elements, canonicalization  and other things that touch the
> payload are highly problematic.
>

I really want to avoid C18N as well. The problem is how to do it.

If the data object is small it is no big deal base64 encoding it and storing
it as an attribute.

But if the data object is larger (XML document, image, etc.) then some form
of indirection is going to be necessary. For example take the digest of the
data and sign that or if multiple objects are involved some sort of manifest
scheme.

I really don't want to have to BASE64 a multimedia stream. So I think I am
going to need some MIME like packaging scheme that allows us to send a JSON
structure with attachments. I think that is going to be a very common
requirement for others as well and I would like that to be a part of the
standards toolkit rather than have to re-invent it for each protocol.

Another very common corner case that is related is how to take a standard
data object such as a JPEG, sign it and then attach the signature inside the
data object.

The blunder committed in XML Signature was to use XPath for that which
introduced a mechanism for arbitrary transformations - yuk!

I really don't want to specify the precise means of embedding signatures in
various media types but I certainly need an approach that makes it possible
to use the spec as a basis for doing that.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Aug 2011 09:12:57 -0400

On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email-masked]> wrote:

>> Here is a proposal for the charter based on the discussion in the BoF last
>> week and later discussion with Sean Turner. Comments, praise, scorn, etc.,
>> are welcome.
>>
>> --Paul and Richard
>>
>> ==============================**=================
>>
>> Background
>> ----------
>>
>> 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 well-known message security primitives
>> (e.g., 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.
>>
> hash followed by a signature algorithm (e.g., RSA with SHA-256).  I've seen
> a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256) was a
> digital signature; one called it a symmetric key based digital signature
> algorithm (note this phrase didn't get through the IESG).

An HMAC is not a digital signature, but the spec definitely needs to be able
to cover MAC based authentication.

I know that public key is getting easier as far as computation goes. But for
many applications the non-repudiation you get in digital signatures is
actually undesirable.

There are interesting tricks you can do with symmetric crypto that are much
harder to do in public key and end up with some scheme that only 50
academics in the world can follow and has a security proof that rest on
rather esoteric assumptions.

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2011 09:25:17 -0400

XPath is NOT the way to go.  No argument from me.

The JWS spec has admittedly been focused on allowing JSON to be used as tokens for OAuth and openID.

Those need to be passed around in a URL safe way,  so we need a serialization that supports that.

In Quebec we did touch on alternate serializations that may be more suitable for other use cases.

I suspect that signing a manifest/reference is something we should be able to support in the JOSE spec.  

Finding the best way to accommodate they without complicating the simpler cases is something that should be explored.

John B.
On 2011-08-04, at 9:03 AM, Phillip Hallam-Baker wrote:

> If the data object is small it is no big deal base64 encoding it and storing it as an attribute.
> 
> But if the data object is larger (XML document, image, etc.) then some form of indirection is going to be necessary. For example take the digest of the data and sign that or if multiple objects are involved some sort of manifest scheme.
> 
> 
> I really don't want to have to BASE64 a multimedia stream. So I think I am going to need some MIME like packaging scheme that allows us to send a JSON structure with attachments. I think that is going to be a very common requirement for others as well and I would like that to be a part of the standards toolkit rather than have to re-invent it for each protocol. 
> 
> 
> Another very common corner case that is related is how to take a standard data object such as a JPEG, sign it and then attach the signature inside the data object. 
> 
> The blunder committed in XML Signature was to use XPath for that which introduced a mechanism for arbitrary transformations - yuk!
> 
> I really don't want to specify the precise means of embedding signatures in various media types but I certainly need an approach that makes it possible to use the spec as a basis for doing that. 
> 
> 
> --

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2011 09:29:46 -0400

HMAC is requirement for adoption in the JWS use cases.

If we want to describe it as something other than a "Qualified Digital Signature",  that is fine as long as it is MTI:)

John B.

On 2011-08-04, at 9:12 AM, Phillip Hallam-Baker wrote:

> I just want to make sure that we agree now that a digital signature is a hash followed by a signature algorithm (e.g., RSA with SHA-256).  I've seen a couple of drafts that tried to say an HMAC (e.g., HMAC-SHA256) was a digital signature; one called it a symmetric key based digital signature algorithm (note this phrase didn't get through the IESG).
> 
> An HMAC is not a digital signature, but the spec definitely needs to be able to cover MAC based authentication.
> 
> 
> I know that public key is getting easier as far as computation goes. But for many applications the non-repudiation you get in digital signatures is actually undesirable.
> 
> There are interesting tricks you can do with symmetric crypto that are much harder to do in public key and end up with some scheme that only 50 academics in the world can follow and has a security proof that rest on rather esoteric assumptions.
> 
> --

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Aug 2011 09:38:42 -0400

Since we are doing encryption as well, there are two problems needing a
common solution.

Let us say we are encrypting a blob of data - 200K or so. Do we really want
to have a JSON structure with the data blob JSON encoded?

For that and for the signing case I think we are going to want a structure
that is something like:

Package
    [Type=JSON Length=203 bytes]
        <Encryption stuff>
    [ID=2as9uas9u9 Length=293939933 bytes]
        <Binary blob>

Ascii encoding for control data is good, it helps debugging etc. But Ascii
encoding JPEG bytes does not really help me much.

The package could even be as simple as a JSON control block that gives the
length of a data blob that is to follow immediately.

On Thu, Aug 4, 2011 at 9:25 AM, John Bradley <[email-masked]> wrote:

> Finding the best way to accommodate they without complicating the simpler
> cases is something that should be explored.
>
> John B.
>

---

From: Matt Miller <[email-masked]>
Date: Thu, 4 Aug 2011 08:03:33 -0600

On Aug 4, 2011, at 07:38, Phillip Hallam-Baker wrote:

> Since we are doing encryption as well, there are two problems needing a common solution. 
> 
> 
> Let us say we are encrypting a blob of data - 200K or so. Do we really want to have a JSON structure with the data blob JSON encoded?
> 
> For that and for the signing case I think we are going to want a structure that is something like:
> 
> Package
> Ascii encoding for control data is good, it helps debugging etc. But Ascii encoding JPEG bytes does not really help me much.
> 
> The package could even be as simple as a JSON control block that gives the length of a data blob that is to follow immediately.
> 
> 

We need to be *VERY* careful if the data ends up outside of the envelope.  There are lots and lots of use cases where the data to be transferred is somewhat small (<1k), and there isn't a good mechanism for holding onto that outside data.

We can't make the assumption that the only transport is HTTP!

- m&m

---

From: John Bradley <[email-masked]>
Date: Thu, 4 Aug 2011 10:07:39 -0400

The URL safe serialization in JWS/JWE is period separated base64url encoded strings.
Envalope.payload.signature  as an example.

For JWE the encryption is performed on the raw object, and the result of that is base64 encoded.

One of the requirements for signing is to avoid double base64 encoding.   That is why the body is separate from the envelope and signature.

We seem to be keen to get on with the work, and that is good.  

However for the moment we should probably concentrate on the charter.

So are there specific things you want in the charter to be able to address a proposed use case?

John B.

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 04 Aug 2011 08:41:27 -0700

> signature algorithm (note this phrase didn't get through the IESG).

I don't agree. I believe we should be able to use this useful plumbing
to ensure integrity/authenticity without having to rely exclusively on
public key cryptography.

> can be charter by the end of August.  I'd swap Aug->Oct, Jan->Mar, and 

I agree, though IMO the sooner we can get strawman drafts out to start
taking shots at, the better.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Aug 2011 08:48:56 -0700

On Aug 4, 2011, at 8:41 AM, Paul C. Bryan wrote:

> I don't agree.

You don't agree with his definition? Where do you see HMACs defined as "digital signatures"?

> I believe we should be able to use this useful plumbing to ensure integrity/authenticity without having to rely exclusively on public key cryptography.

That is a separate issue. Are you asking that a fifth item be added to the charter, to define HMAC'd content?

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Aug 2011 08:52:32 -0700

IMO, symmetric integrity protection is a useful primitive, and it's
already part of the
JWT spec. I think all that's required here in the charter is to
wordsmith it to separate
out symmetric from asymmetric integrity algorithms,

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Aug 2011 09:02:51 -0700

> out symmetric from asymmetric integrity algorithms,

Current:

It sounds like you would prefer something like:
1) A Standards Track document specifying how to apply integrity protection to data, including (but not limited to) JSON data structures. This integrity protection can be achieved with both symmetric and asymmetric algorithms.

Is that right?

--Paul Hoffman

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 04 Aug 2011 09:19:10 -0700

> 1) A Standards Track document specifying how to apply integrity protection to data, including (but not limited to) JSON data structures. This integrity protection can be achieved with both symmetri…

+1, or even possibly:

1) A Standards Track document specifying how to ensure the integrity
and/or authenticity of data, including (but not limited to) JSON data
structures. This can be achieved with both symmetric and asymmetric
cryptographic algorithms.

---

From: Jeremy Laurenson <[email-masked]>
Date: Thu, 4 Aug 2011 14:18:34 -0400

Agree - I would think the ADs would agree and push back.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 4 Aug 2011 15:25:28 -0400

My understanding was that a JOSE data structure would protect a sequence of octets, which could be whatever the signer/encryptor desires.  

JOSE:JSON::CMS:ASN.1

--Richard

---

From: Hal Lockhart <[email-masked]>
Date: Thu, 4 Aug 2011 13:41:54 -0700 (PDT)

+1

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Thursday, August 04, 2011 12:03 PM
> To: Eric Rescorla
> Cc: [email-masked]
> JSON-structured digital signature to data, including (but not 
> limited to) JSON data structures. "Digital signature" is 
> defined as a hash operation followed by a signature operation 
> using asymmetric keys.
> 
> 1) A Standards Track document specifying how to apply 
> integrity protection to data, including (but not limited to) 
> JSON data structures. This integrity protection can be 
> achieved with both symmetric and asymmetric algorithms.
> 
> Is that right?
> 
> --Paul Hoffman
>

---

From: Hal Lockhart <[email-masked]>
Date: Thu, 4 Aug 2011 13:48:08 -0700 (PDT)

> keys as JSON-structured objects.

I would like to push back on the idea of only supporting naked public keys. It is my understanding that common cryto libraries, e.g. OpenSSL, expect public keys to be in certificates and the coding to get them to accept a naked key as input is ugly. I don't think they care if the cert is self signed or even signed at all, its just a format issue.

Hal

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Aug 2011 13:50:43 -0700

This is true for TLS, but in general you can get OpenSSL to accept keys that are
in PKCS #1 format.

Best,
-Ekr

---

From: Joe Hildebrand <[email-masked]>
Date: Fri, 05 Aug 2011 00:32:34 -0400

That was the original intent, yes.  Any octets, including UTF-8 serialized
JSON, XML, or a picture of a cat.  A *very secure* picture of a cat.

On 8/4/11 3:25 PM, "Richard L. Barnes" <[email-masked]> wrote:

> My understanding was that a JOSE data structure would protect a sequence of
> octets, which could be whatever the signer/encryptor desires.
> 
> JOSE:JSON::CMS:ASN.1
> 
> --Richard 
> 
> 
>> non-JSON media types in a JSON structure, would JOSE seek to reinvent such a
>> thing, or merely defer to using it?
>> 
>> Paul

-- 
Joe Hildebrand

---

From: Joe Hildebrand <[email-masked]>
Date: Fri, 05 Aug 2011 00:34:32 -0400

On 8/4/11 4:48 PM, "Hal Lockhart" <[email-masked]> wrote:

> I would like to push back on the idea of only supporting naked public keys. It
> is my understanding that common cryto libraries, e.g. OpenSSL, expect public
> keys to be in certificates and the coding to get them to accept a naked key as
> input is ugly. I don't think they care if the cert is self signed or even
> signed at all, its just a format issue.

Just doing the math yourself, from scratch, is pretty easy if you have the
bare key.  It's nigh-on trivial if you have a bigint library.  Solution:
don't use OpenSSL.  I propose we don't get bogged down in the certificate
problem for the moment.

-- 
Joe Hildebrand

---

From: Leif Johansson <[email-masked]>
Date: Fri, 05 Aug 2011 10:26:55 +0200

> I would like to push back on the idea of only supporting naked public keys. It is my understanding that common cryto libraries, e.g. OpenSSL, expect public keys to be in certificates and the coding…

There is a huge difference between a crypto library and a PKIX stack.

Libraries like OpenSSL are mostly about implementing PKIX, the crypto
being a comparatively small part.

Carrying something like OpenSSL just to be able to sign stuff when
you don't require the semantics of a PKIX stack is an unnecessary
requirement.

Having the ability to do raw keys is useful.

	Cheers Leif

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Aug 2011 08:11:02 -0400

Support for naked keys is useful.

Lack of support for certificates where needed would be unacceptable and
render the format unsuited for many of the applications we need it for.

Certificates are pretty simple to deal with. The problems that they are used
to address are not simple.

Whatever you thought of the 'Trust Router' proposal made at last IETF, it is
certainly no simpler than the PKI based approach and that is before they
have put it in operation and found the operational requirements.

For my application I need certificates and will use them. The question then
is not whether the spec will use them, it is whether the way in which they
are used is standardized or not.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 05 Aug 2011 14:43:33 +0200

> to address are not simple.

I also think you need both. Sometimes you need to use a key for both
signing and TLS for instance.

> have put it in operation and found the operational requirements.

I don't think that proposal is targeted for anything that comes even
remotely close to signed objects. Lets not go there.

	Cheers Leif

---

From: John Bradley <[email-masked]>
Date: Fri, 5 Aug 2011 09:33:38 -0400

JWS and JWE specified both.   I agree both need to be supported.

John B.
On 2011-08-05, at 8:43 AM, Leif Johansson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk475XUACgkQ8Jx8FtbMZndQEwCeNnyVkj0xpDRhvDuSNSH4/Mig
> GH8An3R2UeKcGxUzpZhuUG8/Hakfx5z0
> =XbMB
> -----END PGP SIGNATURE-----

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 Aug 2011 07:07:43 -0700

> don't use OpenSSL.  I propose we don't get bogged down in the certificate

Cryptographer's warning: do not do this. Hard hat area ahead.

-Ekr

---

From: Leif Johansson <[email-masked]>
Date: Fri, 05 Aug 2011 16:42:32 +0200

> Cryptographer's warning: do not do this. Hard hat area ahead.

That is advice for implementors and not for spec writers, right?

	Cheers Leif

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Aug 2011 12:10:13 -0400

> remotely close to signed objects. Lets not go there.

Which is exactly what I am arguing for.

If the group decided it is 'only' going to do raw key it would inevitably
end up going there because the problems are going to take it there.

The way to avoid going there is to build on the infrastructure already
designed to go there and let people hook into that infrastructure where it
is useful.

Otherwise we are like the office that decides not to build a loading dock
because handling deliveries of office supplies requires too much manual
effort. If you need the office supplies you are going to be dealing with the
deliveries.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Aug 2011 12:27:36 -0400

Question: What exactly is a 'raw key' in any case?

Anything that the group does is going to require some commitment to a
specific serialization of the key information. A public key is an abstract
data structure and you can't put an abstract structure on the wire. There
has to be some mapping from the abstract structure to the bits.

Eric and myself are not trying to be difficult here. OK, I can't speak for
Eric, maybe he is. But we have both tried to do what is being presented as
the 'easy' case and it wasn't.

Raw key can simplify things if offered as an option. If it is the only
option it is going to make things harder, not easier in my view.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 Aug 2011 09:43:37 -0700

> That is advice for implementors and not for spec writers, right?

Correct. Getting the implementation right is tricky.

-Ekr

---

From: Sean Turner <[email-masked]>
Date: Fri, 05 Aug 2011 14:13:23 -0400

> Question: What exactly is a 'raw key' in any case?

I believe the people that want this are trying to avoid X.509.  I'd bet 
a $1 it won't end up just being the 'raw key' there's going to be 
parameters, etc.  If you look at what Mike's proposing in 
http://datatracker.ietf.org/doc/draft-jones-json-web-key/ which I 
believe is one draft on offer as input, it already includes more than 
just the key - as it should.

> specific serialization of the key information. A public key is an
> abstract data structure and you can't put an abstract structure on the
> wire. There has to be some mapping from the abstract structure to the bits.
>
>
> Eric and myself are not trying to be difficult here. OK, I can't speak
> for Eric, maybe he is. But we have both tried to do what is being
> presented as the 'easy' case and it wasn't.
>

I have never assumed that the charter item for a 'raw key' implied that 
it was *the* way to convey the public key in the resulting 
JSON-structures for signatures/encryption.  I have always assumed there 
would be some faction that would want an option to refer to|point 
to|include a certificate.

We can fight about what the required mechanism is when we actually write 
the spec.  I've gotten the impression that regardless of the choice that 
wins a 'bare key' JSON format is needed - hence the charter item.

spt

> On Fri, Aug 5, 2011 at 10:07 AM, Eric Rescorla <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Thu, Aug 4, 2011 at 9:34 PM, Joe Hildebrand
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      > On 8/4/11 4:48 PM, "Hal Lockhart" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>     [email-masked] <mailto:[email-masked]>

---

From: Sean Turner <[email-masked]>
Date: Fri, 05 Aug 2011 14:16:30 -0400

So I'll bite on this ;)

I think we can write the spec to require a particular algorithm choice, 
but it might make more sense to define the options and then allow the 
environment in which the solution will be used to specify it's 
requirements.  But, I believe that is a discussion we'll have while 
writing the spec.

spt

On 8/4/11 9:29 AM, John Bradley wrote:
> If we want to describe it as something other than a "Qualified Digital
> Signature", that is fine as long as it is MTI:)
>
> John B.
>
>
>> On Thu, Aug 4, 2011 at 9:03 AM, Sean Turner <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>         Here is a proposal for the charter based on the discussion in
>>         the BoF last week and later discussion with Sean Turner.
>>         Comments, praise, scorn, etc., are welcome.
>>
>>         --Paul and Richard
>>
>>         ==============================__=================
>>
>>         Background
>>         ----------
>>
>>         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 encryption and
>>         digital signatures for data that is being carried in JSON format.
>>
>>         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 well-known message security
>>         primitives (e.g., CMS), and will solicit input from the rest
>>         of the IETF Security Area to be sure that the security
>>     I just want to make sure that we agree now that a digital
>>     signature is a hash followed by a signature algorithm (e.g., RSA
>>     with SHA-256). I've seen a couple of drafts that tried to say an
>>     HMAC (e.g., HMAC-SHA256) was a digital signature; one called it a
>>     symmetric key based digital signature algorithm (note this phrase
>>     didn't get through the IESG).
>>
>>
>> An HMAC is not a digital signature, but the spec definitely needs to
>> be able to cover MAC based authentication.
>>
>>
>> I know that public key is getting easier as far as computation goes.
>> But for many applications the non-repudiation you get in digital
>> signatures is actually undesirable.
>>
>> There are interesting tricks you can do with symmetric crypto that are
>> much harder to do in public key and end up with some scheme that only
>> 50 academics in the world can follow and has a security proof that
>> rest on rather esoteric assumptions.
>>
>> --

---

From: Sean Turner <[email-masked]>
Date: Fri, 05 Aug 2011 14:26:54 -0400

The AD did push back on the dates ;)

Part of the process to get buy-in is progressing the charter.  It'll go 
out for two weeks internally to the IETF and then probably another two 
externally (W3C, etc.).  I'll make sure to bring it up with the W3C 
liaison (shocked if he's not on this list).  We (Stpehen and I) are also 
keeping the Apps ADs in the loop (both Pete and Peter were at the 
WOES/JOSE session).  There's also other IETF areas monitoring what's 
going on.

As to the deliverable dates, I think we should try to be somewhat 
aggressive.  I'd rather not build in 'wait time.'  Getting something 
through the IESG by March (as I suggested) is going to be a challenge.

spt

On 8/4/11 2:18 PM, Jeremy Laurenson wrote:
>> On Aug 2, 2011, at 19:13, Paul Hoffman<[email-masked]>  wrote:
>>

---

From: Sean Turner <[email-masked]>
Date: Fri, 05 Aug 2011 14:45:09 -0400

>> achieved with both symmetric and asymmetric algorithms.

I'm liking what Paul B. suggested but tweaked ever so slightly:

1) A Standards Track document specifying how to ensure the integrity 
and/or authenticity of data, including (but not limited to) JSON data 
structures.  HMAC-based (RFC 2104) and Asymmetric cryptographic 
algorithms both need to be supported.

I'd like to not just call out integrity - and we should just call out 
the HMAC-based algs because that's what folks really want to use (or 
have I gotten this wrong?).

Any violent objections to this?

spt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Aug 2011 14:49:37 -0400

On Fri, Aug 5, 2011 at 2:13 PM, Sean Turner <[email-masked]> wrote:

> I believe the people that want this are trying to avoid X.509.  I'd bet a
> $1 it won't end up just being the 'raw key' there's going to be parameters,
> etc.  If you look at what Mike's proposing in http://datatracker.ietf.org/
> **doc/draft-jones-json-web-key/<http://datatracker.ietf.org/doc/draft-jones-json-web-key/>which I believe is one draft on offer as input, it already includes more
> than just the key - as it should.

At some point he will add a criticality flag but call it something else.
Like Conditions. There was some guy who did that in SAML...

I am not even opposed to eventually creating a whole new cert format. Just
as long as we don't fool ourselves into thinking that this is the easy
option, its not.

> I have never assumed that the charter item for a 'raw key' implied that it
> was *the* way to convey the public key in the resulting JSON-structures for
> signatures/encryption.  I have always assumed there would be some faction
> that would want an option to refer to|point to|include a certificate.
>

Given the way certain charters have been used to lay claim to 'own' certain
issues in the recent past I would like this to be explicit in the charter. I
don't want to end up having a four month argument as to whether to do it.

> wins a 'bare key' JSON format is needed - hence the charter item.

No, I don't think that there should be a required mechanism as I don't think
this is going to be used on its own.

Specifically for my protocol, Web Confirmation Protocol (WCP) support for
certificates is definitely going to be a MUST for authenticating inbound
confirmation requests. But support for raw keys is going to be a MUST for
interaction between the service and the client.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Aug 2011 15:03:06 -0400

I would also strongly urge talking to the OASIS people on this.

OASIS has a big dog in this fight, OK they are a bit XML centric, but they
are responsible for a very significant fraction of actual Web Services
applications.

I am much less worried about how fast the boat travels as how many people
are on board when it sails.

On Fri, Aug 5, 2011 at 2:26 PM, Sean Turner <[email-masked]> wrote:

> Part of the process to get buy-in is progressing the charter.  It'll go out
> for two weeks internally to the IETF and then probably another two
> externally (W3C, etc.).  I'll make sure to bring it up with the W3C liaison
> (shocked if he's not on this list).  We (Stpehen and I) are also keeping the
> Apps ADs in the loop (both Pete and Peter were at the WOES/JOSE session).
>  There's also other IETF areas monitoring what's going on.
>
> aggressive.  I'd rather not build in 'wait time.'  Getting something through
> the IESG by March (as I suggested) is going to be a challenge.
>
> spt
>
>
>>>> ______________________________**_________________
>>>> woes mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/woes<https://www.ietf.org/mailman/listinfo/woes>
>>>>
>>> ______________________________**_________________
>>> woes mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/woes<https://www.ietf.org/mailman/listinfo/woes>
>>>
>>
>> ______________________________**_________________
>> woes mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/woes<https://www.ietf.org/mailman/listinfo/woes>
>>
>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Aug 2011 15:04:49 -0400

Actually, I suspect that with AES in hand and having good MAC modes
specified we might well want to use one of those in preference to the
traditional HMAC.

On Fri, Aug 5, 2011 at 2:45 PM, Sean Turner <[email-masked]> wrote:

> 1) A Standards Track document specifying how to ensure the integrity and/or
> authenticity of data, including (but not limited to) JSON data structures.
>  HMAC-based (RFC 2104) and Asymmetric cryptographic algorithms both need to
> be supported.
>
> I'd like to not just call out integrity - and we should just call out the
> HMAC-based algs because that's what folks really want to use (or have I
> gotten this wrong?).
>

---

From: Sean Turner <[email-masked]>
Date: Fri, 05 Aug 2011 16:23:38 -0400

On 8/5/11 2:49 PM, Phillip Hallam-Baker wrote:
>
>
> On Fri, Aug 5, 2011 at 2:13 PM, Sean Turner <[email-masked]
>     I believe the people that want this are trying to avoid X.509.  I'd
>     bet a $1 it won't end up just being the 'raw key' there's going to
>     be parameters, etc.  If you look at what Mike's proposing in
>     http://datatracker.ietf.org/__doc/draft-jones-json-web-key/
>     <http://datatracker.ietf.org/doc/draft-jones-json-web-key/> which I
>     believe is one draft on offer as input, it already includes more

nothing like designing a protocol by committee ;)

> I am not even opposed to eventually creating a whole new cert format.
> Just as long as we don't fool ourselves into thinking that this is the
> easy option, its not.
>
>
>     I have never assumed that the charter item for a 'raw key' implied
>     that it was *the* way to convey the public key in the resulting
>     JSON-structures for signatures/encryption.  I have always assumed
>     there would be some faction that would want an option to refer
>     to|point to|include a certificate.
>
>
> Given the way certain charters have been used to lay claim to 'own'
> certain issues in the recent past I would like this to be explicit in
> the charter. I don't want to end up having a four month argument as to
> whether to do it.

I have no problem with adding something along the line of:

OLD:

The resulting solutions will support both JSON-encoded public keys and 
X.509 public key certificates.

I purposely choose "support" and didn't specify which is the MTI.  We 
can have that debate when writing the spec.

do others have an issue with this?

spt

>     We can fight about what the required mechanism is when we actually
>     write the spec.  I've gotten the impression that regardless of the
>     choice that wins a 'bare key' JSON format is needed - hence the
>     charter item.
>
>
> No, I don't think that there should be a required mechanism as I don't
> think this is going to be used on its own.
>
> Specifically for my protocol, Web Confirmation Protocol (WCP) support
> for certificates is definitely going to be a MUST for authenticating
> inbound confirmation requests. But support for raw keys is going to be a
> MUST for interaction between the service and the client.
> --

---

From: Sean Turner <[email-masked]>
Date: Fri, 05 Aug 2011 16:34:32 -0400

On 8/5/11 3:04 PM, Phillip Hallam-Baker wrote:
> On Fri, Aug 5, 2011 at 2:45 PM, Sean Turner <[email-masked]
>             From: Paul Hoffman [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             Cc: [email-masked] <mailto:[email-masked]>
>     and/or authenticity of data, including (but not limited to) JSON
>     data structures.  HMAC-based (RFC 2104) and Asymmetric cryptographic
>     I'd like to not just call out integrity - and we should just call
>     out the HMAC-based algs because that's what folks really want to use
>     (or have I gotten this wrong?).
>

Right after I sent this I remembered AES-CMAC.   Precise enough to say:

   MAC-based (e.g., HMAC-SHA256, AES-CMAC) and Asymmetric cryptographic
   algorithms both need to be supported.

spt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 5 Aug 2011 16:53:35 -0400

> X.509 public key certificates.

Works for me.

> I purposely choose "support" and didn't specify which is the MTI.  We can
> have that debate when writing the spec.
>

I would prefer not to specify an MTI at all.

One of the neat features of C# is that you can now specify List <Foo> and
get a strongly typed list of type Foo. Unlike in C where the list container
is generic, you can specify a structure with a List <foo> and know that
nothing else will be put in it.

What I would like to end up with with Woes is scheme where a specification
using Woes can specify Woes <PKIX> or Woes <Raw>.

I think it is a mistake for every IETF security WG to get into discussions
on which algorithms to make mandatory for the same reason. We should have
one set of algorithms that is the preferred IETF set across the board and
those should apply unless a particular WG has a very particular reason to do
otherwise.

In fact that is the reason I want WOES in the first place. I can write out a
way to sign this stuff in a few hours and make it work for my stuff. I can
even write up a spec. What I greatly dislike is a situation where we get
into a committee and spend two years making a series of design decisions
en-bank and then join another group and go through the whole set all over
again, often with many of the same people.

---

From: Jeremy Laurenson <[email-masked]>
Date: Sat, 6 Aug 2011 00:30:43 -0400

From a Javascript dev perspective, specifying an algorithm will make it a hell of of lot easier to implement, instead of having to potentially account for multiples.

Lets use the example of a web app that aggregates social media data - just for giggles - and uses WOES to secure the communications to well-defined interfaces

If multiple vendors' websites implement WOES/JOES/JOSE with different algorithms, it becomes more complex vs a single, consistent one.

On Aug 5, 2011, at 2:16 PM, Sean Turner wrote:

> So I'll bite on this ;)
> 
> I think we can write the spec to require a particular algorithm choice, but it might make more sense to define the options and then allow the environment in which the solution will be used to specify it's requirements.  But, I believe that is a discussion we'll have while writing the spec.
> 
> spt
>

---

From: Leif Johansson <[email-masked]>
Date: Sat, 06 Aug 2011 13:43:12 +0200

> Correct. Getting the implementation right is tricky.

So in that case I still support having the spec explain (very carefully)
how you do "raw keys" - i.e keys with no intrinsic semantics - and then
also adding the cryptographers caveat to that.

	Cheers Leif

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 6 Aug 2011 10:05:16 -0400

We absolutely need to make a choice on algorithms.

What I am saying is that I would like to make the choice once every three
years or so as an IETF-wide issue and not have to revisit it in every new WG
and have each WG go through the same discussion.

On Sat, Aug 6, 2011 at 12:30 AM, Jeremy Laurenson <[email-masked]>wrote:

> From a Javascript dev perspective, specifying an algorithm will make it a
> hell of of lot easier to implement, instead of having to potentially account
> for multiples.
>
> Lets use the example of a web app that aggregates social media data - just
> for giggles - and uses WOES to secure the communications to well-defined
> interfaces
>
> If multiple vendors' websites implement WOES/JOES/JOSE with different
> algorithms, it becomes more complex vs a single, consistent one.
>
>
>
>
> environment in which the solution will be used to specify it's requirements.
>  But, I believe that is a discussion we'll have while writing the spec.
> >
> > spt
> >

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 6 Aug 2011 10:58:47 -0400

How about one spec with two implementation profiles?

WOES-P  MUST implement PKIX key handling.
WOES-R  MUST implement raw key handling.

The reason I think we need both is that the WOES-R mechanism is going to be
much more appropriate for the applications for which self-signed certs are
generally used.

[I really can't see what benefit a self signed cert provides over a raw key
for any application. All you have is proof that the holder of the key
created a self-signed cert.]

So in my application I am going to want a stack that supports certs for the
Internet trust aspects and a stack that supports raw key for the handheld
device aspects. I don't want to implement the raw key in the Internet
request side of things and I definitely don't want to implement the cert
stuff in the handheld device. Mobile phones come with PKIX libraries but
thermocouple driver chips don't .

---

From: Joe Hildebrand <[email-masked]>
Date: Sat, 06 Aug 2011 13:30:08 -0400

> also adding the cryptographers caveat to that.

To be clear, when I was talking about raw keys, I didn't mean keys with no
intrinsic semantics.  I just meant something along the lines of PKCS1; a
modulus, an exponent, some algorithm info, and that's about it (I'd be ok
with defining private keys in the same format as well).  It would have
defined semantic, it just wouldn't be tied to an identity.

A definite goal for me that is NOT met by PKCS1 however, is to *limit* the
choices and extensibility in certain directions to reduce the overall
complexity.

Of course, once you've got primitives for sign and encrypt and you've got a
key format, doing something like PKIX is possible.  Perhaps we could sketch
that out as potential follow-on work in the charter, so we can make progress
on some of the shorter-term stuff first?

-- 
Joe Hildebrand

---

From: John Bradley <[email-masked]>
Date: Sat, 6 Aug 2011 16:40:04 -0400

Short term stuff first. 

Boil ocean stage 2. 

Replacing PKIX may be a noble goal,  but is out of scope for phase 1. 

John B. 

Sent from my iPhone

---

From: Leif Johansson <[email-masked]>
Date: Sun, 07 Aug 2011 11:59:18 +0200

> defined semantic, it just wouldn't be tied to an identity.

OK that was more or less what I was trying to say aswell.

> on some of the shorter-term stuff first?

indeed

	Cheers Leif

---

From: Hal Lockhart <[email-masked]>
Date: Mon, 8 Aug 2011 08:28:04 -0700 (PDT)

Given the state of the art in integrity protection is in flux (e.g. new attacks, authenticated encryption modes) it seems foolish to limit integrity protection to two specific technologies.

Although there may be no intent to cover anything more than asymmetric key signatures and HMACs during the initial phase, the JSON metadata should be capable of representing other, present and future methods, at least to the extent we currently understand their requirements.

Hal

> From: Sean Turner [mailto:[email-masked]]
> Sent: Friday, August 05, 2011 2:45 PM
> To: [email-masked]
> Cc: Hal Lockhart; Paul Hoffman; Eric Rescorla

---

From: Hal Lockhart <[email-masked]>
Date: Mon, 8 Aug 2011 08:36:02 -0700 (PDT)

> Cryptographer's warning: do not do this. Hard hat area ahead.

I am with Eric here. I would like to explicitly state that I think it is NOT desirable to do anything which encourages people to do new implementations of crypto operations. The corollary is that the spec should specify objects in formats which make them easy to be passed as arguments to existing libraries, especially libraries which are likely to be present in the target environment.

Hal

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 08 Aug 2011 09:02:24 -0700

On Mon, 2011-08-08 at 08:36 -0700, Hal Lockhart wrote:

> I would like to explicitly state that I think it is NOT desirable to
> do anything which encourages people to do new implementations of
> crypto operations. The corollary is that the spec should specify
> objects in formats which make them easy to be passed as arguments to
> existing libraries, especially libraries which are likely to be
> present in the target environment.

+1

Paul

---

From: Ben Adida <[email-masked]>
Date: Mon, 08 Aug 2011 09:41:48 -0700

On 8/8/11 8:36 AM, Hal Lockhart wrote:
>
> I am with Eric here. I would like to explicitly state that I think it
> is NOT desirable to do anything which encourages people to do new
> implementations of crypto operations. The corollary is that the spec
> should specify objects in formats which make them easy to be passed
> as arguments to existing libraries, especially libraries which are
> likely to be present in the target environment.

I think this may miss some important use cases. We're using JWT/JWS at 
https://browserid.org, and we need to do all of the crypto in 
JavaScript. JavaScript-based crypto, and crypto in other programming 
languages in general, is likely to be a growing need. So, "no new 
implementations" is unrealistic. There will be new implementations. 
There have to be.

If we force these new implementations to bear the full complexity of 
X.509, then we're introducing security risk. It would be much better if 
we had a simpler, JSON-focused certificate format.

We don't get to choose whether there will be new implementations. We 
only get to choose how simple those have to be.

-Ben

---

From: John Bradley <[email-masked]>
Date: Mon, 8 Aug 2011 13:07:40 -0400

+1  For openID Connect forcing x.509 processing in all environments is not practical, or desirable.

Not all environments can call out to openSSL.  We will need to create new native libraries for some environments.  Having a simple JSON container for key information is important to our developers.

John Bradley
On 2011-08-08, at 12:41 PM, Ben Adida wrote:

> I think this may miss some important use cases. We're using JWT/JWS at https://browserid.org, and we need to do all of the crypto in JavaScript. JavaScript-based crypto, and crypto in other programming languages in general, is likely to be a growing need. So, "no new implementations" is unrealistic. There will be new implementations. There have to be.
> 
> If we force these new implementations to bear the full complexity of X.509, then we're introducing security risk. It would be much better if we had a simpler, JSON-focused certificate format.
> 
> We don't get to choose whether there will be new implementations. We only get to choose how simple those have to be.
> 
> -Ben

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 08 Aug 2011 10:09:24 -0700

> implementations" is unrealistic. There will be new implementations. 

I think the point is that one should use existing, proven software
libraries to implement the cryptography wherever possible—JOSE should
not necessitate a novel application of cryptography to achieve the
charter objectives. If no such library exists in a particular
programming/runtime environment, then obviously one would need to be
developed. That said, I would suggest that such a new implementation
focus on implementing the cryptographic functions much the way they are
implemented in other environments, and allow JOSE implementations to
build upon that.

---

From: John Bradley <[email-masked]>
Date: Mon, 8 Aug 2011 13:38:03 -0400

No argument on that.

We just can't assume that it is trivial to reemployment PKIX X.509 processing in all new environments.  Using public keys without PKIX, is a simpler task.

Where we need to develop new libraries, using establishd cryptographic methods should be the goal.

JWE/JWS had no intention of deviating from those norms and inventing new algorithms.

John B.
On 2011-08-08, at 1:09 PM, Paul C. Bryan wrote:

> I think the point is that one should use existing, proven software libraries to implement the cryptography wherever possible—JOSE should not necessitate a novel application of cryptography to achieve the charter objectives. If no such library exists in a particular programming/runtime environment, then obviously one would need to be developed. That said, I would suggest that such a new implementation focus on implementing the cryptographic functions much the way they are implemented in other environments, and allow JOSE implementations to build upon that. 
>

---

From: Ben Adida <[email-masked]>
Date: Mon, 08 Aug 2011 10:42:59 -0700

On 8/8/11 10:38 AM, John Bradley wrote:
> We just can't assume that it is trivial to reemployment PKIX X.509
> processing in all new environments. Using public keys without PKIX, is a
> simpler task.

Exactly. And even the certificate format world could use a *much* 
simpler, more webby approach than X.509.

-Ben

---

From: John Bradley <[email-masked]>
Date: Mon, 8 Aug 2011 13:57:05 -0400

That is a larger issue, that I prefer to leave for a later charter.

We both have specs (arguably competing ones) that require JOSE in a timely manner.  

Tide and the Web wait for no SDO:)

John

On 2011-08-08, at 1:42 PM, Ben Adida wrote:

> Exactly. And even the certificate format world could use a *much* simpler, more webby approach than X.509.
> 
> -Ben

---

From: Hal Lockhart <[email-masked]>
Date: Mon, 8 Aug 2011 11:07:23 -0700 (PDT)

I think people are reading more into my comment about raw keys than I said.

The specific historical use case was that we needed to verify a signature with a specific PK. There was no certificate chain, no PKI processing of any kind required. The key was explicitly trusted. Revocation was out of scope. Therefore we (SAML TC) decided to specify the use of a PK as a binary value, not imbedded in a cert. 

When implementations were done, it was discovered that common libraries, OpenSSL for example, expected the key to be contained in something that looked like an ASN.1 formatted certificate. It would not accept a binary value. In order to use such a library, it was necessary to gin up an ASN.1 certificate structure and stuff in the key value, simply to comply with the requirements of the method signature.

I am not talking about doing PKI. I am not talking about doing X.509. I am not talking about processing any other part of the cert except the PK.

I am talking about defining something that is practical to implement. I agree with those who believe both forms should be specified. 

There seems to be a distinct argument about the generality of the spec, which I will address in a separate message.

Hal
  -----Original Message-----
  From: Paul C. Bryan [mailto:[email-masked]]
  Sent: Monday, August 08, 2011 1:09 PM
  To: [email-masked]
  Subject: Re: [woes] Naked Public Key, was: RE: Proposed charter, post-Quebec edition

-Ben

---

From: Hal Lockhart <[email-masked]>
Date: Mon, 8 Aug 2011 11:28:46 -0700 (PDT)

There seems to be a position forming around the idea that woes/joes/jose should specify (perhaps even design) a single algorithm (perhaps one for sign and one for encrypt). I presume that means that if in future it was necessary to use a different algorithm we would just start over and write a new spec.

I am not in favor of this, but I concede that it would simplify things in this group a lot.

If there was only one algorithm, there is no need for any JSON metadata about what the algorithm is being used.
All we need is a way to indicate what is signed or encrypted and something that says this is a JOES signature (or encryption) and perhaps some kind of indication of what key was used.

If we were to specify only one algorithm, but provide metadata to indicate the algorithm, others will use additional, unspecified algorithms, just as people used 3-DES and AES in Kerberos while continuing to cite RFC 1510 which only includes DES.

I won't bother to list the many (many, many) reasons why a single algorithm is unlikely to fly, unless it turns out a lot of people are really committed to that view. 

Instead, I suggest we say explicitly say that multiple algorithms will be possible, but one will be MTI. It wouldn't hurt to also say we are not going to design any new algorithms, but simply provide means to specify which existing one is being used.

Hal

> From: Jeremy Laurenson [mailto:[email-masked]]
> Sent: Saturday, August 06, 2011 12:31 AM
> To: [email-masked]
> From a Javascript dev perspective, specifying an algorithm 
> will make it a hell of of lot easier to implement, instead of 
> having to potentially account for multiples.
> 
> Lets use the example of a web app that aggregates social 
> media data - just for giggles - and uses WOES to secure the 
> communications to well-defined interfaces
> 
> If multiple vendors' websites implement WOES/JOES/JOSE with 
> different algorithms, it becomes more complex vs a single, 
> consistent one.
> 
> 
> 
> 
> > I think we can write the spec to require a particular 
> algorithm choice, but it might make more sense to define the 
> options and then allow the environment in which the solution 
> will be used to specify it's requirements.  But, I believe 
> that is a discussion we'll have while writing the spec.
> > 
> > spt
> >

---

From: John Bradley <[email-masked]>
Date: Mon, 8 Aug 2011 15:04:23 -0400

Hal,

JWE/JWS supports multiple algorithms.   I haven't seen any argument to not have algorithm ajility.

There was a mention of what algorithms should be MTI.   I expect that discussion will continue.  (It is still gong on for xmlenc/xmldeig over at W3C)

We clearly need multiple algorithms, in my opinion.

John B.

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 08 Aug 2011 12:21:01 -0700

On Mon, 2011-08-08 at 11:28 -0700, Hal Lockhart wrote:

> There seems to be a position forming around the idea that
> woes/joes/jose should specify (perhaps even design) a single algorithm
> (perhaps one for sign and one for encrypt). I presume that means that
> if in future it was necessary to use a different algorithm we would
> just start over and write a new spec.

If such a position is actually forming, I'd like to know why we'd want
to pre-bake obsolescence into the spec.

> I am not in favor of this, but I concede that it would simplify things

If by simplify you mean thinning out the number of people who will find
it useful, perhaps. ;-)

> If there was only one algorithm, there is no need for any JSON
> metadata about what the algorithm is being used.

True, but perhaps at the very least we'd need some kind of metadata
saying what version of JOSE is being used, if nothing more than to
determine what version of what cipher(s) it supports.

> All we need is a way to indicate what is signed or encrypted and
> something that says this is a JOES signature (or encryption) and
> perhaps some kind of indication of what key was used.

This may not be enough, especially when JOSE undergoes a revision.

> If we were to specify only one algorithm, but provide metadata to
> indicate the algorithm, others will use additional, unspecified
> algorithms, just as people used 3-DES and AES in Kerberos while
> continuing to cite RFC 1510 which only includes DES.

I think if we establish a minimum supported set, with extensibility
(i.e. cipher suite can be specified), we retain core interoperability
while not throwing out the standard when the core ciphers prove
unsuitable.

> I won't bother to list the many (many, many) reasons why a single
> algorithm is unlikely to fly, unless it turns out a lot of people are
> really committed to that view.

+1

> Instead, I suggest we say explicitly say that multiple algorithms will
> be possible, but one will be MTI. It wouldn't hurt to also say we are
> not going to design any new algorithms, but simply provide means to
> specify which existing one is being used.

+1, though I suggest we may codify a handful of well-used suites while
possibly making one mandatory to implement. 

Paul

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 08 Aug 2011 13:48:08 -0600

Agree. Algorithm agility is a must, but large numbers of supported
algorithms out of the gate are not. Having a small set of algorithms
widely-implemented will increase interoperability drastically, particularly
considering that in some of the target operating environments, we'll need to
wait for people with adequate cryptographic skills to help.

I do really like the idea of splitting the MTI specification into a small
separate draft, so that it can be rev'd easily as needed.

On 8/8/11 1:04 PM, "John Bradley" <[email-masked]> wrote:

> There was a mention of what algorithms should be MTI.   I expect that
> discussion will continue.  (It is still gong on for xmlenc/xmldeig over at
> W3C)
> 
>> There seems to be a position forming around the idea that woes/joes/jose
>> should specify (perhaps even design) a single algorithm (perhaps one for sign
>> and one for encrypt). I presume that means that if in future it was necessary
>> to use a different algorithm we would just start over and write a new spec.
>> 
>> All we need is a way to indicate what is signed or encrypted and something
>> that says this is a JOES signature (or encryption) and perhaps some kind of
>> indication of what key was used.
>> 
>> If we were to specify only one algorithm, but provide metadata to indicate
>> the algorithm, others will use additional, unspecified algorithms, just as
>> people used 3-DES and AES in Kerberos while continuing to cite RFC 1510 which
>> only includes DES.
>> 
>> I won't bother to list the many (many, many) reasons why a single algorithm
>> is unlikely to fly, unless it turns out a lot of people are really committed
>> to that view. 
>> 
>> Instead, I suggest we say explicitly say that multiple algorithms will be
>> possible, but one will be MTI. It wouldn't hurt to also say we are not going
>> to design any new algorithms, but simply provide means to specify which
>> existing one is being used.
>> 
>> Hal
>> 

-- 
Joe Hildebrand

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 8 Aug 2011 17:11:25 -0400

+1

This is exactly what the  DNSSEC community has done.
<http://tools.ietf.org/html/rfc6014>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 9 Aug 2011 03:34:13 +0100

+1

And that way we can have two profiles (or more) to address different
implementation situations.

Web Services implementation constraints are frequently asymmetric. There is
one portion built on some all-singing/dancing platform like .NET or whatever
and that talks to a thin client embedded in Jscript or a mobile device or
what-have-you.

If we can avoid creating yet another crypto-registry (i.e. re-use the PEM or
whatever algorithm registry) then all the spec needs to say is that X is the
slot where the algorithm name goes and the MTI doc(s) specify how to get
interoperability.

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 9 Aug 2011 14:02:51 -0400

As far as I can remember, CMS (RFC3852 and RFC5652) does not choose any specific algorithm.

Therefore it make sense for JOSE to follow the same approach.

/thomas/

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Monday, August 08, 2011 10:34 PM
To: Joe Hildebrand
Cc: [email-masked]
Subject: Re: [woes] Support multiple Crypto algorithms? was RE: Proposed charter, post-Quebec edition

On Mon, Aug 8, 2011 at 8:48 PM, Joe Hildebrand <[email-masked]> wrote:

+1

And that way we can have two profiles (or more) to address different implementation situations.

Web Services implementation constraints are frequently asymmetric. There is one portion built on some all-singing/dancing platform like .NET or whatever and that talks to a thin client embedded in Jscript or a mobile device or what-have-you.

If we can avoid creating yet another crypto-registry (i.e. re-use the PEM or whatever algorithm registry) then all the spec needs to say is that X is the slot where the algorithm name goes and the MTI doc(s) specify how to get interoperability.

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 09 Aug 2011 12:34:10 -0600

One of the goals of JOSE is to increase the number of interoperable
implementations.  I don't think a lack of MTI algorithms will further that
goal.

-- 
Joe Hildebrand

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 9 Aug 2011 16:43:49 -0400

Hi Joe,

Its perfectly ok (and necessary for interop) for the implementers to agree beforehand about which cipher(s) are must implement. Support for multiple ciphers is a good thing. However, there is no need to call these out within the JOSE specification.

Perhaps the chairs can simply do a WG consensus call to ask which ciphers/algorithms to implement as part of the first WG deliverables.

/thomas/

> From: Joe Hildebrand [mailto:[email-masked]]
> Sent: Tuesday, August 09, 2011 2:34 PM
> To: Thomas Hardjono; [email-masked]
> implementations.  I don't think a lack of MTI algorithms will further
> that goal.
> 
> 
> > Of Phillip Hallam-Baker
> > On Mon, Aug 8, 2011 at 8:48 PM, Joe Hildebrand
> > <[email-masked]>
> > wrote:
> > widely-implemented will increase interoperability drastically,
> > particularly considering that in some of the target operating
> > environments, we'll need to wait for people with adequate
> cryptographic skills to help.
> >
> > I do really like the idea of splitting the MTI specification into a
> > small separate draft, so that it can be rev'd easily as needed.
> >
> > +1
> >
> > Web Services implementation constraints are frequently asymmetric.
> > There is one portion built on some all-singing/dancing platform like
> > .NET or whatever and that talks to a thin client embedded in Jscript
> > or a mobile device or what-have-you.
> >
> > If we can avoid creating yet another crypto-registry (i.e. re-use the
> > PEM or whatever algorithm registry) then all the spec needs to say is
> > that X is the slot where the algorithm name goes and the MTI doc(s)
> > specify how to get interoperability.
> >
> 
> --
> Joe Hildebrand

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 10 Aug 2011 08:56:32 -0600

On 8/9/11 2:43 PM, "Thomas Hardjono" <[email-masked]> wrote:

> Its perfectly ok (and necessary for interop) for the implementers to agree
> beforehand about which cipher(s) are must implement.

I'd phrase this "agree beforehand" as the mandatory-to-implement set of
algorithms.  I read your original message as saying that you didn't think
there should be *any* MTI algorithms.  If I misread, then we're on the same
page.

> Support for multiple
> ciphers is a good thing. However, there is no need to call these out within
> the JOSE specification.

The proposal on the table is for there to be a second draft which contains
the MTI algorithms.

> Perhaps the chairs can simply do a WG consensus call to ask which
> ciphers/algorithms to implement as part of the first WG deliverables.

We'd need to write that consensus down in a document so that folks who came
along later would know what we decided.  Drafts don't *have* to be long and
complicated. :)

-- 
Joe Hildebrand

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 10 Aug 2011 14:38:36 -0400

> Sent: Wednesday, August 10, 2011 10:57 AM
> > Its perfectly ok (and necessary for interop) for the implementers to
> > agree beforehand about which cipher(s) are must implement.
> 
> algorithms.  I read your original message as saying that you didn't
> think there should be *any* MTI algorithms.  If I misread, then we're
> on the same page.

Hi Joe,

Apologies if I miscommunicated -- I think we're on the same page :)

> 
> > Support for multiple
> > ciphers is a good thing. However, there is no need to call these out
> > within the JOSE specification.
> 
> The proposal on the table is for there to be a second draft which
> contains the MTI algorithms.

ok, great.

> We'd need to write that consensus down in a document so that folks who
> came along later would know what we decided.  Drafts don't *have* to be
> long and complicated. :)

Agree. Typically IETF WGs do not maintain 
strict meeting Minutes :(

So perhaps the next best thing would be for
the Charter to list the second draft (listing
the MTI ciphers/algorithms) as a WG deliverable,
with a delivery date.

/thomas/

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 10 Aug 2011 20:01:13 -0600

+1

-- 
Joe Hildebrand