Subject: Re: [jose] First draft of JSON Web Encryption (JWE) spec published

From: Mike Jones <[email-masked]>
Date: Fri, 7 Oct 2011 19:01:59 +0000

Thanks for your useful comments, Martin.  Replies inline...

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]]
Sent: Tuesday, September 06, 2011 11:17 PM
To: Mike Jones; [email-masked]
Cc: Nat Sakimura
Subject: RE: First draft of JSON Web Encryption (JWE) spec published

Or to add another link for the rest of us:

http://tools.ietf.org/html/draft-jones-json-web-encryption

Thanks

I found the presentation to be a little sketchy.  The table is difficult to parse.  I think that the table is constraining how you describe the parameters, and I'm concerned that underspecification here will hurt.  The second and third columns don't seem to add much over the description (the second column is all "string").  I'd suggest that you give each parameter a numbered section.  That way, they appear in the TOC.

Please compare this to the parameter table at http://tools.ietf.org/html/draft-jones-json-web-token-05#section-4.1, which this was modeled after (and in which all the JSON types are not "string").  That being said, I agree that this tabular presentation may be overly constraining.  I believe there is merit in your suggestion to give each parameter a numbered section so that it appears in the TOC.  I will plan to do so the next time the spec suite is updated.

The x5u parameter identifies what exactly?  Is it the URI for a resource that, upon retrieval (e.g., HTTP GET), produces an X.509 certificate (chain)?  I think that's what you mean.  The example seems to use base64url encoding, which seems pointless.

It provides an HTTPS address where a PEM-encoded certificate can be retrieved.  An example document that could be retrieved from such a URL follows:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

A certificate chain can also be provided at this site.  An example of such a chain is:

-----BEGIN CERTIFICATE-----

MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVM

xITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR2

8gRGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExM

TYwMTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UE

CBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWR

keS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYW

RkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlc

nRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJ

KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTt

wY6vj3D3HKrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqV

Tr9vcyOdQmVZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aL

GbqGmu75RpRSgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo

7RJlbmr2EkRTcDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgW

JCJjPOq8lh8BJ6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAw

EAAaOCATIwggEuMB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVH

SMEGDAWgBTSxLDSkdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEA

MDMGCCsGAQUFBwEBBCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWR

keS5jb20wRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2

RhZGR5LmNvbS9yZXBvc2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVH

SAAMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j

b20vcmVwb3NpdG9yeTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggE

BANKGwOy9+aG2Z+5mC6IGOgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPI

UyIXvJxwqoJKSQ3kbTJSMUA2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL

5CkKSkB2XIsKd83ASe8T+5o0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9

p0iRFEUOOjZv2kWzRaJBydTXRE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsx

uxN89txJx9OjxUUAiKEngHUuHqDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZ

EjYx8WnM25sgVjOuH0aBsXBTWVU+4=

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

MIIE+zCCBGSgAwIBAgICAQ0wDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1Z

hbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIE

luYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb

24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8x

IDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTA0MDYyOTE3MDY

yMFoXDTI0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRoZS

BHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3MgM

iBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN

ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XC

APVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux

6wwdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLO

tXiEqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWo

riMYavx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZ

Eewo+YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjggHhMIIB3TAdBgNVHQ

4EFgQU0sSw0pHUTBFxs2HLPaH+3ahq1OMwgdIGA1UdIwSByjCBx6GBwaSBvjCBu

zEkMCIGA1UEBxMbVmFsaUNlcnQgVmFsaWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQK

Ew5WYWxpQ2VydCwgSW5jLjE1MDMGA1UECxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2x

pY3kgVmFsaWRhdGlvbiBBdXRob3JpdHkxITAfBgNVBAMTGGh0dHA6Ly93d3cudm

FsaWNlcnQuY29tLzEgMB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5jb22CA

QEwDwYDVR0TAQH/BAUwAwEB/zAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGG

F2h0dHA6Ly9vY3NwLmdvZGFkZHkuY29tMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA

6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS9yb290LmNybD

BLBgNVHSAERDBCMEAGBFUdIAAwODA2BggrBgEFBQcCARYqaHR0cDovL2NlcnRpZ

mljYXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MA4GA1UdDwEB/wQEAwIBBjAN

BgkqhkiG9w0BAQUFAAOBgQC1QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PrxeNYiY+

Sn1eocSxI0YGyeR+sBjUZsE4OWBsUs5iB0QQeyAfJg594RAoYC5jcdnplDQ1tgM

QLARzLrUc+cb53S8wGd9D0VmsfSxOaFIqII6hR8INMqzW/Rn453HWkrugp++85j

09VZw==

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

MIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ

0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNT

AzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0a

G9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkq

hkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE

5MDYyNjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTm

V0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZ

XJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQD

ExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9

AdmFsaWNlcnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOOnHK5a

vIWZJV16vYdA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SVCCSRrCl6zf

N1SLUzm1NZ9WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwb

P7RfZHM047QSv4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQU

AA4GBADt/UG9vUJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQ

C1u+mNr0HZDzTuIYEZoDJJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMM

j4QssxsodyamEwCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd

-----END CERTIFICATE-----

"Utilizing TLS" also needs to be expanded.  You obviously need to ensure that the authority providing the resource is authenticated and that the representation you retrieve is free from modification, so say that.

Agreed

The "typ" parameter seems a little underspecified.

Agreed.  I'd be interested in discussions on this topic in Taiwan.

The epk parameter isn't a string by its description, though the table indicates that it is.  ...unless you wanted to base64url encode the JSON object.

Actually, the ephemeral public key is represented as a string containing a JSON object in JWK format.  An example such string value follows:

    "{\"algorithm\":\"EC\",

      \"curve\":\"P-256\",

      \"x\":\"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4\",

      \"y\":\"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM\",

      \"use\":\"encryption\",

      \"keyid\":\"1\"}"

The alg and enc parameters use StringOrURI as their definition.  There are no URIs defined for either.  I suspect that there is something in there you are wanting to get at, but I recommend that just "String" is sufficient.  After all, someone is going to have to decide if "alg": "http://foo" is equal to "alg": "HTTP://FOO" and I don't want to have to be that guy.

See Section 9.2 on additional algorithms http://tools.ietf.org/html/draft-jones-json-web-encryption-00#section-9.2.  Some possible URIs are referenced there.

Saying that you character-wise compare the strings for equality is really, really good.

Thanks

That doesn't preclude the definition of a scheme where URIs are used to prevent collisions in the namespace, but I suspect that your existing text on public/private use of codes is sufficient.

Thanks

BTW, I like your decision to make all parameters mandatory.  This is less a concern with encryption as it is with signature, but it seems like it's better to be consistent across the two.

Thanks

--Martin

                                                            Thanks again,
                                                            -- Mike

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 10 Oct 2011 07:43:41 +0800

Hi Mike,

You know, the document does not contain a complete example.  That is, an example that includes header+key+ciphertext (and the corresponding plain text).  Until I read it again, I didn't realize that you were using base64url on each part and concatenating with '.' as a separator.

I was previously under the impression that this was one big JSON object.  But then I couldn't find the "ciphertext" parameter.

A few more replies inline.

On 2011-10-08 at 06:01:59, Mike Jones wrote:
> {MT} The x5u parameter identifies what exactly?  Is it the URI for a 
> resource that, upon retrieval (e.g., HTTP GET), produces an X.509 
> certificate (chain)?  I think that's what you mean.  The example seems 
> to use base64url encoding, which seems pointless.
> 
> It provides an HTTPS address where a PEM-encoded certificate can be 
> retrieved.  An example document that could be retrieved from such a 
> URL
> follows:

I should have been clearer.  *I* understand what x5u means, but the text is a little ambiguous.

OLD:
   The "x5u" (X.509 URL) header parameter is a URL utilizing TLS (as defined in RFC 5785 [RFC5785]) that points to an X.509 public key certificate or certificate chain that that corresponds to the key that was used to encrypt the JWE.  This certificate or certificate chain MUST use the PEM encoding (per RFC 1421 [RFC1421]) and MUST conform to RFC 5280 [RFC5280].  This header parameter is OPTIONAL.  

SUGGEST:
   The "x5u" (X.509 URL) header parameter is a URL that refers to a resource for the X.509 public key certificate or certificate chain corresponding to the key used to encrypt the object.

   The identified resource MUST provide a representation of the certificate or certificate chain that conforms to RFC 5280 [RFC5280] in PEM encoded form [RFC 1421].   [TBD: determine correct MIME type for PEM-encoded certificate chain]

   The protocol used to acquire the resource MUST provide integrity protection.  An HTTP GET request [RFC2616] to retrieve the certificate MUST use TLS [RFC2818][RFC5246] with server authentication [RFC6125].

Notes:
 - The TLS stuff has far less impact for encryption than it does for signing, but it might be good to get the text right and then reuse it.
 - Using RFC 5785 as a reference here is strange.
 - The implicit assumption here is that we're using HTTP over TLS [RFC2818], but that doesn't mean that another protocol cannot provide secure access to the certificate.
 - This doesn't constrain the resource from using content negotiation to provide an alternative form if that suits.  For instance, I might like to retrieve a java keystore, but that's my business :)
 - I'm not sure that describing optionality on each parameter is a great approach because of the way that each parameter interacts.  It might be better to say that a JWE MUST contain (a+b+c OR a+b+d OR b+e) and MAY contain any other parameter.  Then for each of the optional parameter, describe why it might be included or provide enough information in the description to make this obvious.

> {MT} The "typ" parameter seems a little underspecified.

It seems like MIME would work here.  You might also like to discuss the possibility of revealing something about the payload through its content type.  This should very much be optional.

> {MT} The epk parameter isn't a string by its description, though the table 
> indicates that it is.  ...unless you wanted to base64url encode the 
> JSON object.
>
> Actually, the ephemeral public key is represented as a string 
> containing a JSON object in JWK format.  

Why not make "epk" a JSON object directly?  Does it need to be quoted for any particular reason?
 
> {MT} The alg and enc parameters use StringOrURI as their definition.  There 
> See Section 9.2 on additional algorithms

Ahh.   That might be a good addition to the description, I missed it there.

Cheers,
Martin

---

From: Mike Jones <[email-masked]>
Date: Thu, 13 Oct 2011 14:06:34 +0000

All great clarifying input - thanks!  I'll work on incorporating this and plan on publishing an updated draft within the next few weeks.

				-- Mike

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Sunday, October 09, 2011 4:44 PM
To: Mike Jones; [email-masked]
Cc: Nat Sakimura
Subject: RE: First draft of JSON Web Encryption (JWE) spec published

Hi Mike,

OLD:

SUGGEST:

Notes:

> {MT} The epk parameter isn't a string by its description, though the 
> table indicates that it is.  ...unless you wanted to base64url encode 
> the JSON object.
>

> {MT} The alg and enc parameters use StringOrURI as their definition.  
> There See Section 9.2 on additional algorithms

Cheers,
Martin