From ietf@augustcellars.com Sat Jun 1 09:21:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4115E21F9C63 for ; Sat, 1 Jun 2013 09:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fID2+Ju-Xd47 for ; Sat, 1 Jun 2013 09:21:07 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id DD2A021F9C88 for ; Sat, 1 Jun 2013 09:21:06 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id F16412CA08; Sat, 1 Jun 2013 09:21:04 -0700 (PDT) From: "Jim Schaad" To: Date: Sat, 1 Jun 2013 09:20:15 -0700 Message-ID: <002d01ce5ee3$e6a1beb0$b3e53c10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CE5EA9.3A43AA00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5eWthtGlW95v3WS1+ZAltJBFFmYw== Content-Language: en-us Cc: jose@ietf.org Subject: [jose] Comments on draft-ietf-jose-use-cases-02 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 16:21:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002E_01CE5EA9.3A43AA00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Richard, Here is my review 1. I think you should include the abbreviations for CMS and JSON following the full strings in the abstract 2. Introduction- Para #1 - You should not assume that people are going to recognize RFC numbers, esp. as they change over time. Please insert the names of the protocols as well as the references for 4301 and 5246. 3. Introduction - Para #2 - Please insert a protocol name along with RFC3207 - i.e. STARTTLS 4. The X.609 reference should be updated to the 2002 version It is the most current version 5. Introduction - Para #3 - please move the XML reference next to the XML text. It currently appears that the XML reference applies to JSON 6. Section #2 - s/JSON Web Algorithms (JWS)/JSON Web Algorithms (JWA)/ 7. Section 3 - bullet #3 - s/receiver share only a/receiver share a/ 8. Section 3 - The following sentence appears to be missing some words or punctuation vvvvvv However, in order to avoid confusing endpoints that lack the necessary context need to be able to recognize this and fail cleanly. 9. Section 5.2 - I have two comments in this section a) I don't understand the need for integrity protection from modifications from the resource owner - it is what is granting the permissions to start with b) You might want to note that using TLS does not protect confidentiality from the resource owner and client. 10. Section 5.4 - Is Alice sending the message to (Bob) or (B)? 11. Section 5.5 - There was also a discussion in the case of ALTO if the content should be encoded separately from the integrity (detached content). Thus the JSON would be carried in the HTTPS header and the body would be the HTTPS content. 12. Section 5.6 - What is a channel-based digital signature mechanism? 13. Section 5.6 - The document does not say if nested signatures are sufficient to satisfy the requirement - or if parallel signatures are required. Jim ------=_NextPart_000_002E_01CE5EA9.3A43AA00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Richard,

 

Here = is my review

 

1.  I think you should include the = abbreviations for CMS and JSON following the full strings in the = abstract

 

2.  Introduction-  Para #1 - You should = not assume that people are going to recognize RFC numbers, esp. as they = change over time.  Please insert the names of the protocols as well = as the references for 4301 and 5246.

 

3. = Introduction - Para #2 - Please insert a protocol name along with = RFC3207 - i.e. STARTTLS

 

4.  The X.609 reference should be updated to = the 2002 version  It is the most current version

 

5.  Introduction - Para #3 - please move the = XML reference next to the XML text.  It currently appears that the = XML reference applies to JSON

 

6.  Section #2 - s/JSON Web Algorithms = (JWS)/JSON Web Algorithms (JWA)/

 

7.  Section 3 - bullet #3 - s/receiver share = only a/receiver share a/

 

8.  Section 3 - The following sentence appears = to be missing some words or punctuation

        &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;         = vvvvvv

        &nbs= p;       However, in order to avoid = confusing endpoints that lack the necessary context need to be able to = recognize this and fail cleanly.

 

9.  Section 5.2 -  I have two comments in = this section

        &nbs= p;       a) I don’t understand the = need for integrity protection from modifications from the resource owner = – it is what is granting the permissions to start = with

        &nbs= p;       b) You might want to note that = using TLS does not protect confidentiality from the resource owner and = client.

 

10.  Section 5.4 – Is Alice sending the = message to (Bob) or (B)?

 

11.  Section 5.5 – There was also a = discussion in the case of ALTO if the content should be encoded = separately from the integrity (detached content).  Thus the JSON = would be carried in the HTTPS header and the body would be the HTTPS = content.

 

12.  Section 5.6 – What is a = channel-based digital signature mechanism?

 

13.  Section 5.6 – The document does not = say if nested signatures are sufficient to satisfy the requirement = – or if parallel signatures are required.

 

 

Jim

 

------=_NextPart_000_002E_01CE5EA9.3A43AA00-- From ludwig@sics.se Mon Jun 3 01:19:43 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0A321F93FB for ; Mon, 3 Jun 2013 01:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPVQzOwZOA7b for ; Mon, 3 Jun 2013 01:18:22 -0700 (PDT) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id 21DBF21F93D4 for ; Mon, 3 Jun 2013 01:18:17 -0700 (PDT) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id r538GJOK011591 for ; Mon, 3 Jun 2013 10:18:15 +0200 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1cr4a19376-1 for ; Mon, 03 Jun 2013 10:18:15 +0200 Received: from [192.168.1.135] (15.90.11.37.dynamic.jazztel.es [37.11.90.15]) (Authenticated sender: ludwig@sics.se) by letter.sics.se (Postfix) with ESMTPSA id DEDDC400E2 for ; Mon, 3 Jun 2013 10:18:14 +0200 (CEST) Message-ID: <1370247493.16652.6.camel@ubuntu.ubuntu-domain> From: Ludwig Seitz To: "jose@ietf.org" Date: Mon, 03 Jun 2013 10:18:13 +0200 Organization: SICS AB Content-Type: multipart/signed; micalg="sha256"; protocol="application/x-pkcs7-signature"; boundary="=-PhPFr7BpTMOCaYMcKBhD" X-Mailer: Evolution 3.2.3-0ubuntu6 Mime-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-06-03_02:2013-06-03, 2013-06-03, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1306030016 Subject: Re: [jose] Dealing with Issue #8 - Direct mode for key agreement X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 08:19:44 -0000 --=-PhPFr7BpTMOCaYMcKBhD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Mike and Jim, I'll gladly look at the small devices use case and write something about my own case, however I'm on a conference this week, so please be patient. Would you prefer that I extend the existing small devices use-case (which seems very specific and narrow to me on a casual glance) or should I create a new section? /Ludwig --=20 Ludwig Seitz, PhD SICS Swedish ICT AB Ideon Science Park Building Beta 2=20 Scheelev=C3=A4gen 17=20 SE-223 70 Lund Phone +46(0)70-349 92 51 http://www.sics.se --=-PhPFr7BpTMOCaYMcKBhD Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEnAw ggYYMIIFAKADAgECAgMFtYswDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQTAeFw0xMzAxMTUwMjA1MDZaFw0xNDAxMTUxNDM3NDhaMDgxFzAVBgNVBAMMDmx1ZHdpZ0Bz aWNzLnNlMR0wGwYJKoZIhvcNAQkBFg5sdWR3aWdAc2ljcy5zZTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAKpuRavr2swCQsYS7KxOsmeBXI39thxAjIYaB0AFVjLpOtVJxQMYoip7Bm9o ka8PXxQ9mWT/lVSoqI7jGjc5Z8q1C4fOFMCYZpJugG9qJS0OMV2ajQ7xXu3YzLTDIKg/BK39+Vri vJq0Y6hz1/4pgxMOFG+l7y+fq54QSkKMwpuRaCBznKJeRxGwDvheF2QN6YEBclFqVhpciDGd52vX 5AgbKbqVmevMrcrcYAdKaKm6iTEmbYHum5D/4GaOnnZ2wMnY5EpKhxxm6SszCVSNdk8iZSUze9GY PzheBDIHMDdLZib6zaoR96F5ZCpE1pPeKIz/DCd3kL+nXpe5gdbSXLsCAwEAAaOCAtQwggLQMAkG A1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQUwDv6gyc7uSHK/QBVIZiN86hjKW4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwGQYDVR0RBBIwEIEObHVkd2lnQHNpY3Muc2UwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQA4bagj yL3PLei2tbMELKOVOxRdyLObcVq0Fj83LbSTMj6NS83TU/4xxChfd5zqoipudDSEpgxZAUsSjk02 DxSeLYYBXE2X/iue7nL8S/3PjC49z5ZgjDZrXIgmvIMaZXWM+GqG+wk9NikGb1/shlJjk3R5KC3f RWsUatHouNxAMYxiLFO75YmgKCgkjtKUbHbUqzmDVd30nWQesXfCgYwCbAvD/0NgX3jE+fnyT71+ aX4/IfqshpCQj8dkR4ZH+bUiK5zgKGJL61GRZNSScR/r9Sq19kEQrt38ey/Q90tUDUgg93d5w3DN rF3bRoOvyspwbcN9TuGKkFoFPV0KfjaGMIIGGDCCBQCgAwIBAgIDBbWLMA0GCSqGSIb3DQEBCwUA MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwMTE1MDIwNTA2WhcNMTQwMTE1MTQz NzQ4WjA4MRcwFQYDVQQDDA5sdWR3aWdAc2ljcy5zZTEdMBsGCSqGSIb3DQEJARYObHVkd2lnQHNp Y3Muc2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCqbkWr69rMAkLGEuysTrJngVyN /bYcQIyGGgdABVYy6TrVScUDGKIqewZvaJGvD18UPZlk/5VUqKiO4xo3OWfKtQuHzhTAmGaSboBv aiUtDjFdmo0O8V7t2My0wyCoPwSt/fla4ryatGOoc9f+KYMTDhRvpe8vn6ueEEpCjMKbkWggc5yi XkcRsA74XhdkDemBAXJRalYaXIgxnedr1+QIGym6lZnrzK3K3GAHSmipuokxJm2B7puQ/+Bmjp52 dsDJ2ORKSoccZukrMwlUjXZPImUlM3vRmD84XgQyBzA3S2Ym+s2qEfeheWQqRNaT3iiM/wwnd5C/ p16XuYHW0ly7AgMBAAGjggLUMIIC0DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAU BggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMA7+oMnO7khyv0AVSGYjfOoYyluMB8GA1Ud IwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBkGA1UdEQQSMBCBDmx1ZHdpZ0BzaWNzLnNlMIIB TAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQg YWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBT dGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3Nl IGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQv MC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3Vi LmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t LzANBgkqhkiG9w0BAQsFAAOCAQEAOG2oI8i9zy3otrWzBCyjlTsUXcizm3FatBY/Ny20kzI+jUvN 01P+McQoX3ec6qIqbnQ0hKYMWQFLEo5NNg8Uni2GAVxNl/4rnu5y/Ev9z4wuPc+WYIw2a1yIJryD GmV1jPhqhvsJPTYpBm9f7IZSY5N0eSgt30VrFGrR6LjcQDGMYixTu+WJoCgoJI7SlGx21Ks5g1Xd 9J1kHrF3woGMAmwLw/9DYF94xPn58k+9fml+PyH6rIaQkI/HZEeGR/m1Iiuc4ChiS+tRkWTUknEf 6/UqtfZBEK7d/Hsv0PdLVA1IIPd3ecNwzaxd20aDr8rKcG3DfU7hipBaBT1dCn42hjCCBjQwggQc oAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNV BAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoXDTE3 MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xC GhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P 3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2Ub FqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2 JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGp MA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6W NU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywGXLhj jF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXltUfO4 n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+RHxkU CTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktvsv6h xHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+ssS5X MEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq+n6b 1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLp XDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/p Ny8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOg SF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMYIDfzCCA3sCAQEw gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbWLMA0GCWCGSAFlAwQCAQUAoIIBuzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA2MDMwODE4MTNaMC8G CSqGSIb3DQEJBDEiBCCtG3JxZ+knoADoqNy60XTiZoKeVa/Yl3S+70w3Rvrc8DCBpQYJKwYBBAGC NxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwW1izCBpwYLKoZIhvcNAQkQ AgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBbWLMA0GCSqGSIb3DQEBAQUA BIIBAEfzTmYZ2QL8p3XT4UWU36U2xfY1YNdiULN88WIT91dhgZEZ1compTm4orGUaZX1hgfBGULC mT0fdMuSaE4JiG7AexUFRmhzGbQGKkDM08GZCeMGwhcCKFswto5KpE0UCfykIsITWCJ3bCRwX1Py xxNV7DevVBdissvBm6GMi1OHJohllRyiNge61knzvpicA0F2nf9sjnD8CMRuQI4loBSuvIMU8Jfr 28zzAV1QtYcR4E5HeVWW5lEvD5gcPqJy/kWfhc+Eu4M14wJnf0RyznaMzgFKnYT1zUgd8ngo2Ed5 5BnfYi9Z5xJyQ3KA0UAtGGKn5hy6t1F425DERa3sLWAAAAAAAAA= --=-PhPFr7BpTMOCaYMcKBhD-- From rlb@ipv.sx Tue Jun 4 10:20:47 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3D621F9CD0 for ; Tue, 4 Jun 2013 10:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.178 X-Spam-Level: ** X-Spam-Status: No, score=2.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbp2+h4Ut0te for ; Tue, 4 Jun 2013 10:20:43 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9B89821E80A4 for ; Tue, 4 Jun 2013 08:28:58 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id v19so614876obq.35 for ; Tue, 04 Jun 2013 08:28:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=IiNpoxc81Z3ujJMRIRBN7YCMqnrqEYTJWx3V+RnP9oU=; b=gAGAHJG86sL/6ozmyN98sR9J7TO61H9B7fCgLVi1lm80OHFVkDvBNX1BXAsti2ZzS8 WJFoSTI3p+POL2NQsVGQNQGTvdW07YAmIROBGYT4wxwN40W9KYdjuP+2Pjy451eQQNlC r8obV2/zaufhGIicKxQSY7Kbb7oVuQ9viRtCK6bnYYdFN8momfqcxjqMg6Rp8wwduPyE 53aK8Of7uA6Jahz2XTF7+2MpnEg8FK/5kLIPxmnfypJ76+sk1q+EJz4lAQPhpXmpIHNU VskohcUZJAoyQCwId44OxilNRvPcrRiGoVlURx52QGaEN24phySs+Pq5hMvR8XT7EIAm mzIg== MIME-Version: 1.0 X-Received: by 10.182.236.104 with SMTP id ut8mr12169879obc.75.1370359738010; Tue, 04 Jun 2013 08:28:58 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Tue, 4 Jun 2013 08:28:57 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: References: <02b701ce5cb8$46ae77e0$d40b67a0$@augustcellars.com> <02f501ce5cc5$ec9a2200$c5ce6600$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943677C58C4@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C5C0A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C7399@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9B69@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9E95@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Tue, 4 Jun 2013 11:28:57 -0400 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11c3183866707c04de55bdd9 X-Gm-Message-State: ALoCoQmeYX8Cz852Y2P70vUcYtKGWhdI72prGRVY5ofn91qRo/1LqiDohi3TXga7GJOhb+IVrPZh Cc: Mike Jones , Nat Sakimura , Jim Schaad , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Should we delete the "typ" header field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:20:47 -0000 --001a11c3183866707c04de55bdd9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It would be a good point, if it were true :) In particular, this part: "[dropping 'typ'] is going to cause each and every application that uses JOSE to define their own field" So far, I've heard of exactly one application of JOSE that requires "typ" in the way it is currently specified, namely JWT. On the other hand, Dick's applications are apparently using it differently (and, IMO, properly) to distinguish JWE/JWS. Then there are all the applications out there that are OK using application context and "cty" to recognize what type of object they have. Apps using CMS have been doing this for ages. So it's not at all clear to me that there's any other application that would use "typ" besides JWT. And it's not clear to me that JWT needs it. --Richard On Fri, May 31, 2013 at 5:45 PM, Brian Campbell wrote: > Nat makes a good point here, I think. > > > On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura wrote: > >> From what I understand, both typ and cty are something to be consumed by >> the application and not JOSE processor. From the point of view of the JO= SE >> processor, they should be ignored. >> >> We could drop both fields from JOSE specs, but that is going to cause >> each and every application that uses JOSE to define their own field, whi= ch >> is a waste. That is why we are defining them here. >> >> I would rather drop them than define JOSE processing semantics to these >> fields. >> >> >> 2013/5/31 Mike Jones >> >>> No, =93cty=94 is used by the derived class to determine the type of th= e >>> encapsulated field. But that=92s not a complete description of the **e= ntire >>> object** - especially not the additional meaning imbued by the >>> additional parameters the derived type may add to the JOSE header. =93= typ=94 >>> is there to provide the type of the entire object, including what you= =92re >>> calling the wrapper parts.**** >>> >>> ** ** >>> >>> -- Mike**** >>> >>> ** ** >>> >>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>> *Sent:* Thursday, May 30, 2013 7:58 AM >>> >>> *To:* Mike Jones >>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt >>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>> >>> ** ** >>> >>> Isn't that requirement met by "cty"? The only thing JOSE adds is a >>> crypto wrapper around the real application content. If you're an >>> application, you know a JOSE object is the thing you want because it >>> contains the content you want -- it's a JWT because it contains JWT cla= ims. >>> **** >>> >>> ** ** >>> >>> Inheritance is the wrong metaphor. This is encapsulation of applicatio= n >>> data:**** >>> >>> if (jws.valid && jws.cty =3D=3D "application/jwt_claims") {**** >>> >>> jwtClaims =3D jws.content;**** >>> >>> }**** >>> >>> ** ** >>> >>> --Richard**** >>> >>> ** ** >>> >>> On Thu, May 30, 2013 at 10:43 AM, Mike Jones < >>> Michael.Jones@microsoft.com> wrote:**** >>> >>> Thanks for sharing the S/MIME details. Although I was actually making >>> the analogy to MIME =96 not S/MIME. Like many analogies, it=92s imperf= ect, but >>> I believe still illustrative.**** >>> >>> **** >>> >>> The reason that the analogy isn=92t perfect is that the JOSE data >>> structures are used to build application-specific data structures that = are >>> legal JOSE data structures but also have additional properties =96 incl= uding >>> additional header fields with specific semantics. (When we agreed to >>> ignore not-understood header fields we let that horse out of the barn.) >>> For instance, Dick Hardt uses JWEs with issuer and audience fields in t= he >>> headers, so they can be used by routing software.**** >>> >>> **** >>> >>> Think of JOSE as the base class and the application types built using i= t >>> as derived classes. JWT is a derived class. Dick=92s structures are a >>> derived class. These derived classes sometimes need names. That=92s w= hat >>> =93typ=94 is for.**** >>> >>> **** >>> >>> -- Mike**** >>> >>> **** >>> >>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>> *Sent:* Thursday, May 30, 2013 7:34 AM**** >>> >>> >>> *To:* Mike Jones >>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt >>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>> >>> **** >>> >>> You're mixing up "typ" and "cty". If you want to make the analogy to >>> S/MIME, "cty" is the equivalent to Content-Type inside the protected MI= ME >>> body; "typ" is the content-type on the outer MIME header. Pasting in a= n >>> example:**** >>> >>> **** >>> >>> -----BEGIN-----**** >>> >>> Content-Type: application/pkcs7-mime; smime-type=3Dsigned-data;**** >>> >>> name=3Dsmime.p7m**** >>> >>> Content-Transfer-Encoding: base64**** >>> >>> Content-Disposition: attachment; filename=3Dsmime.p7m**** >>> >>> **** >>> >>> 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7**** >>> >>> 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH**** >>> >>> HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh**** >>> >>> 6YT64V0GhIGfHfQbnj75**** >>> >>> -----END-----**** >>> >>> **** >>> >>> **** >>> >>> The outer Content-Type, which is analogous to "typ", MUST be >>> application/pkcs7-mime, with a parameter indicating the type of CMS obj= ect. >>> This is the same as requiring "typ" to be JWE or JWS. The inner >>> Content-Type (ASN.1/base64 encoded in the example) can be anything, jus= t >>> like "cty".**** >>> >>> **** >>> >>> --Richard**** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> On Thu, May 30, 2013 at 12:53 AM, Mike Jones < >>> Michael.Jones@microsoft.com> wrote:**** >>> >>> Requiring that the =93typ=94 value be only =93JWS=94 or =93JWE=94 would= be analogous >>> to the MIME spec requiring that the Content-Type: field be only >>> =93text/plain=94 or =93message/external-body=94. It would render it us= eless.*** >>> * >>> >>> **** >>> >>> -- Mike**** >>> >>> **** >>> >>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >>> Of *Richard Barnes >>> *Sent:* Wednesday, May 29, 2013 8:03 PM >>> *To:* Mike Jones >>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt**** >>> >>> >>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>> >>> **** >>> >>> If this is the level of "type" you're referring to, I think we should >>> drop it from the spec. It's an application-layer thing that the app ca= n >>> add or not according to its wishes.**** >>> >>> **** >>> >>> I'm with Dick on this. I think we should either have a mandatory >>> indicator of what type of JOSE object this, or nothing at all. If the >>> former, the allowable values are "JWE" and "JWS". The "+JSON" options = are >>> non-sensical -- the app needs to know what it's parsing before it gets = this >>> header. While I have a preference for the former (for clarity), the la= tter >>> approach is also OK with me, since the MIME types are specific to JWE/J= WS. >>> **** >>> >>> **** >>> >>> Another approach here would be to address the JSON and compact forms >>> separately. The JSON form has no need of "typ" at all, since the type = of >>> the object is completely clear from what fields are there, e.g., >>> "recipients" vs. "signatures". For the compact form, we could do somet= hing >>> like James's "E."/"S." prefix idea, which you need because the >>> dot-separated components have different meanings and no field names to >>> indicate this.**** >>> >>> **** >>> >>> --Richard**** >>> >>> **** >>> >>> On Wed, May 29, 2013 at 8:30 PM, Mike Jones >>> wrote:**** >>> >>> A standard library is unlikely to know the meanings of all possible >>> =93typ=94 values =96 and more to the point, *it doesn=92t have to*. It= =92s the >>> application=92s job to determine that =93this blob is a JOSE object=94 = and then >>> pass it to a standard library, which will then ignore the =93typ=94 val= ue.** >>> ** >>> >>> **** >>> >>> A standard JOSE library won=92t know what =93typ=94: =93JWT=94 means. = It won=92t >>> know what =93typ=94: =93BCGovToken=94 is, should the BC Government want= to declare >>> that it=92s using a token with particular characteristics. It won=92t = know >>> what =93typ=94: =93XMPP=94 is, should XMPP want to declare that it=92s = using a JOSE >>> data structure with particular characteristics. Etc.**** >>> >>> **** >>> >>> All these values can be registered in the registry and used by >>> applications that understand them. That=92s the application=92s job = =96 not the >>> library=92s job. The =93typ=94 field is just there so that application= s have a >>> standard place to make any such declarations that they may need.**** >>> >>> **** >>> >>> -- Mike= * >>> *** >>> >>> **** >>> >>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>> *Sent:* Wednesday, May 29, 2013 5:18 PM >>> *To:* Mike Jones >>> *Cc:* Jim Schaad; jose@ietf.org**** >>> >>> >>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>> >>> **** >>> >>> I'd prefer to be able to use standard libraries for creating and parsin= g >>> tokens, and not specialized libraries dependent on the use case.**** >>> >>> **** >>> >>> I strongly think we either drop "typ" or make it required.**** >>> >>> **** >>> >>> On Wed, May 29, 2013 at 5:03 PM, Mike Jones >>> wrote:**** >>> >>> It=92s fine for your application to specify that it=92s required for yo= ur >>> use case. Not applications need it, so they shouldn=92t be forced to p= ay the >>> space penalty of an unnecessary field.**** >>> >>> **** >>> >>> -- Mike= * >>> *** >>> >>> **** >>> >>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >>> Of *Dick Hardt >>> *Sent:* Wednesday, May 29, 2013 4:56 PM**** >>> >>> >>> *To:* Jim Schaad >>> *Cc:* jose@ietf.org >>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>> >>> **** >>> >>> I use it all the time and my code would barf if it was not there.**** >>> >>> **** >>> >>> I think it should be required rather than be a hint if it is going ot b= e >>> there.**** >>> >>> **** >>> >>> On Wed, May 29, 2013 at 4:40 PM, Jim Schaad >>> wrote:**** >>> >>> I think the values just changed**** >>> >>> **** >>> >>> However the way you are using it would be an argument to say that it >>> should be a required field. Are you just using it as a hint if it exis= ts >>> and then looking at the rest of the fields if it is not present?**** >>> >>> **** >>> >>> Jim**** >>> >>> **** >>> >>> **** >>> >>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>> *Sent:* Wednesday, May 29, 2013 3:49 PM >>> *To:* Jim Schaad >>> *Cc:* jose@ietf.org >>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>> >>> **** >>> >>> Well, I have been using, but now realize the spec changed or I was >>> confused.**** >>> >>> **** >>> >>> I had been setting "typ" to be either "JWE" or "JWS" depending on the >>> type of token I was creating or parsing as it was easier than looking a= t >>> "alg"**** >>> >>> **** >>> >>> As currently defined, I don't see value in "typ".**** >>> >>> **** >>> >>> -- Dick**** >>> >>> **** >>> >>> **** >>> >>> On Wed, May 29, 2013 at 3:02 PM, Jim Schaad >>> wrote:**** >>> >>> In reading the documents, I am trying to understand the justification >>> for having the =93typ=94 header parameter in the JOSE documents.**** >>> >>> **** >>> >>> The purpose of the field is to hold the type of the object. In the >>> past, I believe that values which should now be placed in the cty field >>> (such as =93JWT=94) were placed in this field as well. However the par= ameter >>> is optional and an implementation cannot rely on its being present. Th= is >>> means that for all practical purposes all of the code to determine the >>> value of the type field from the values of the alg and enc fields. If = the >>> field was mandatory then this code would disappear at a fairly small sp= ace >>> cost and I can understand why the parameter would be present.**** >>> >>> **** >>> >>> Can anybody justify why this field should be present in the document = =96 >>> or should it just disappear?**** >>> >>> **** >>> >>> Jim**** >>> >>> **** >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose**** >>> >>> >>> >>> **** >>> >>> **** >>> >>> -- >>> -- Dick **** >>> >>> >>> >>> **** >>> >>> **** >>> >>> -- >>> -- Dick **** >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose**** >>> >>> >>> >>> **** >>> >>> **** >>> >>> -- >>> -- Dick **** >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose**** >>> >>> **** >>> >>> **** >>> >>> ** ** >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > --001a11c3183866707c04de55bdd9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
It would be a good point, if it were true :) =A0In particu= lar, this part: "[dropping 'typ']=A0is going to cause each= and every application that uses JOSE to define their own field"= ;

So far, I've heard of exactly one application of JOSE th= at requires "typ" in the way it is currently specified, namely JW= T. =A0

On the other hand, Dick's applications = are apparently using it differently (and, IMO, properly) to distinguish JWE= /JWS. =A0Then there are all the applications out there that are OK using ap= plication context and "cty" to recognize what type of object they= have. =A0Apps using CMS have been doing this for ages.

So it's not at all clear to me that there's any= other application that would use "typ" besides JWT. =A0And it= 9;s not clear to me that JWT needs it.

--Richard





On Fri, May 31, 2013 at 5:45 PM, Bria= n Campbell <bcampbell@pingidentity.com> wrote:
Nat makes a good point here= , I think.


On Thu, May 30, 2013 at 9:31 AM, Nat Sak= imura <sakimura@gmail.com> wrote:
From what I understand, bot= h typ and cty are something to be consumed by the application and not JOSE = processor. From the point of view of the JOSE processor, they should be ign= ored.=A0

We could drop both fields from JOSE specs, but that is going to cause each = and every application that uses JOSE to define their own field, which is a = waste. That is why we are defining them here.=A0

I would rather drop them than define JOSE processing semantics to thes= e fields.=A0


2013/5/31 Mike Jones <Michael.Jones@microso= ft.com>

No, =93cty=94 is used by = the derived class to determine the type of the encapsulated field.=A0 But t= hat=92s not a complete description of the *entire object* - especially not the additional meaning imbued by the additional parameter= s the derived type may add to the JOSE header.=A0 =93typ=94 is there to pro= vide the type of the entire object, including what you=92re calling the wra= pper parts.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7:58 AM


To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

Isn't that requirement met by "cty"? = =A0The only thing JOSE adds is a crypto wrapper around the real application= content. =A0If you're an application, you know a JOSE object is the th= ing you want because it contains the content you want -- it's a JWT because it contains JWT claims.

=A0

Inheritance is the wrong metaphor. =A0This is encaps= ulation of application data:

if (jws.valid && jws.cty =3D=3D "applic= ation/jwt_claims") {

=A0 =A0 jwtClaims =3D jws.content;

}

=A0

--Richard

=A0

On Thu, May 30, 2013 at 10:43 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Thanks for sharing the S/= MIME details.=A0 Although I was actually making the analogy to MIME =96 not S/MIME.=A0 Like many analogies, it=92s imperfect, but I believe still illu= strative.

=A0<= /p>

The reason that the analo= gy isn=92t perfect is that the JOSE data structures are used to build appli= cation-specific data structures that are legal JOSE data structures but also have addition= al properties =96 including additional header fields with specific semantic= s.=A0 (When we agreed to ignore not-understood header fields we let that ho= rse out of the barn.)=A0 For instance, Dick Hardt uses JWEs with issuer and audience fields in the headers, so th= ey can be used by routing software.

=A0<= /p>

Think of JOSE as the base= class and the application types built using it as derived classes.=A0 JWT is a derived class.=A0 Dick=92s structures are a derived class.=A0 These d= erived classes sometimes need names.=A0 That=92s what =93typ=94 is for.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7:34 AM


To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

You're mixing up "typ" and "cty&q= uot;. =A0If you want to make the analogy to S/MIME, "cty" is the = equivalent to Content-Type inside the protected MIME body; "typ" = is the content-type on the outer MIME header. =A0Pasting in an example:

=A0

-----BEGIN-----

Content-Type: application/pkcs7-mime; smime-type=3Ds= igned-data;

=A0 =A0 =A0name=3Dsmime.p7m

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=3Dsmime.p7= m

=A0

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4V= Qbnj7

77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUuj= hJhjH

HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHG= ghyHh

6YT64V0GhIGfHfQbnj75

-----END-----

=A0

The outer Content-Type, which is analogous to "= typ", MUST be application/pkcs7-mime, with a parameter indicating the = type of CMS object. =A0This is the same as requiring "typ" to be JWE or JWS. =A0The inner Content-Type (ASN.1/base64 encoded in the exam= ple) can be anything, just like "cty".

=A0

--Richard

=A0

=A0

=A0

=A0

On Thu, May 30, 2013 at 12:53 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Requiring that the =93typ= =94 value be only =93JWS=94 or =93JWE=94 would be analogous to the MIME spe= c requiring that the Content-Type: field be only =93text/plain=94 or =93message/extern= al-body=94.=A0 It would render it useless.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, May 29, 2013 8:03 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org; Dick Hardt


Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

If this is the level of "type" you're = referring to, I think we should drop it from the spec. =A0It's an appli= cation-layer thing that the app can add or not according to its wishes.<= /u>

=A0

I'm with Dick on this. =A0I think we should eith= er have a mandatory indicator of what type of JOSE object this, or nothing = at all. =A0 If the former, the allowable values are "JWE" and "JWS". =A0The "+JSON" options are non-sensical -- = the app needs to know what it's parsing before it gets this header. =A0= While I have a preference for the former (for clarity), the latter approach= is also OK with me, since the MIME types are specific to JWE/JWS.

=A0

Another approach here would be to address the JSON a= nd compact forms separately. =A0The JSON form has no need of "typ"= ; at all, since the type of the object is completely clear from what fields are there, e.g., "recipients" vs. "signatures&q= uot;. =A0For the compact form, we could do something like James's "= ;E."/"S." prefix idea, which you need because the dot-separa= ted components have different meanings and no field names to indicate this.=

=A0

--Richard

=A0

On Wed, May 29, 2013 at 8:30 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

A standard library is unl= ikely to know the meanings of all possible =93typ=94 values =96 and more to= the point, it doesn=92t have to.=A0 It=92s the application=92s job to d= etermine that =93this blob is a JOSE object=94 and then pass it to a standa= rd library, which will then ignore the =93typ=94 value.

=A0<= /p>

A standard JOSE library w= on=92t know what =93typ=94: =93JWT=94 means.=A0 It won=92t know what =93typ= =94: =93BCGovToken=94 is, should the BC Government want to declare that it=92s using a token wit= h particular characteristics.=A0 It won=92t know what =93typ=94: =93XMPP=94= is, should XMPP want to declare that it=92s using a JOSE data structure wi= th particular characteristics.=A0 Etc.

=A0<= /p>

All these values can be r= egistered in the registry and used by applications that understand them.=A0 That=92s the application=92s job =96 not the library=92s job.=A0 The =93ty= p=94 field is just there so that applications have a standard place to make= any such declarations that they may need.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Wednesday, May 29, 2013 5:18 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org


Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

I'd prefer to be able to use standard libraries = for creating and parsing tokens, and not specialized libraries dependent on= the use case.

=A0

I strongly think we either drop "typ" or m= ake it required.

=A0

On Wed, May 29, 2013 at 5:03 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

It=92s fine for your appl= ication to specify that it=92s required for your use case.=A0 Not applicati= ons need it, so they shouldn=92t be forced to pay the space penalty of an unne= cessary field.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Wednesday, May 29, 2013 4:56 PM


To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

I use it all the time and my code would barf if it w= as not there.

=A0

I think it should be required rather than be a hint = if it is going ot be there.

=A0

On Wed, May 29, 2013 at 4:40 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

I think the values just c= hanged

=A0<= /p>

However the way you are u= sing it would be an argument to say that it should be a required field.=A0 Are you just using it as a hint if it exists and then looking at the rest = of the fields if it is not present?

=A0<= /p>

Jim<= /p>

=A0<= /p>

=A0<= /p>

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Wednesday, May 29, 2013 3:49 PM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

Well, I have been using, but now realize the spec ch= anged or I was confused.

=A0

I had been setting "typ" to be either &quo= t;JWE" or "JWS" depending on the type of token I was creatin= g or parsing as it was easier than looking at "alg"=

=A0

As currently defined, I don't see value in "= ;typ".

=A0

-- Dick

=A0

=A0

On Wed, May 29, 2013 at 3:02 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

In reading the documents, I am trying to understand = the justification for having the =93typ=94 header parameter in the JOSE doc= uments.

=A0

The purpose of the field is to hold the type of the = object. =A0In the past, I believe that values which should now be placed in= the cty field (such as =93JWT=94) were placed in this field as well.=A0 However the parameter is optional and an implementation cannot= rely on its being present.=A0 This means that for all practical purposes a= ll of the code to determine the value of the type field from the values of = the alg and enc fields. =A0If the field was mandatory then this code would disappear at a fairly small space cost = and I can understand why the parameter would be present.

=A0

Can anybody justify why this field should be present= in the document =96 or should it just disappear?

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick



=A0

--
-- Dick


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0

=A0

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_= nat_en

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--001a11c3183866707c04de55bdd9-- From rlb@ipv.sx Tue Jun 4 10:23:07 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C55921F9C38 for ; Tue, 4 Jun 2013 10:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nkKIAFTc3Uo for ; Tue, 4 Jun 2013 10:23:03 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 73A4421F9B35 for ; Tue, 4 Jun 2013 08:37:09 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id 16so633977obc.26 for ; Tue, 04 Jun 2013 08:37:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=LU0PM5D5UglP2g0QMsasgSUwxWB4NKBDvHqG5HI1A3U=; b=CW25X2xSprBnQ1NIVOU2hsZqCTi4Ju/f0Uduqql5vkHT9ABUMEyaJjl1Y3Z72gnWwG RsJJED1xYX2PspfYI8FflEm45JGuo/xQ9M/+6CZH+KMzUjCsSJBumMxWt98ZCZSDJTRV i6o17GqFamqWg1NsV+CDYBPkyT5Coy9m+15+SQhleb6oyHkuPYJ1ynRu4H7e4hEFsZBs zspn6KLSUxuUem+mgGLNAkTAAEKRpU7iq3+l+EEagnZb9El49480bzYn8MlsAmflX0Ri HChnfUlhNvc1AnUts+jZgD5qYlUvyBq81c69Pt3DF4mRdsHSWbmq6d3Jd/O/nCSaaiUE fOyQ== MIME-Version: 1.0 X-Received: by 10.182.78.41 with SMTP id y9mr12120294obw.69.1370360228877; Tue, 04 Jun 2013 08:37:08 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Tue, 4 Jun 2013 08:37:08 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: References: Date: Tue, 4 Jun 2013 11:37:08 -0400 Message-ID: From: Richard Barnes To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=047d7b2e4710a82ba604de55dac3 X-Gm-Message-State: ALoCoQlVz3KyjQFf5AQP4Sdzgz3xQsQH32gEIM/IVRwjPsZMjVdFCboUwgO0fB+3x2acSdfhM5Q5 Cc: "jose@ietf.org" Subject: Re: [jose] draft-ietf-jose-use-cases-02, bad references X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:23:07 -0000 --047d7b2e4710a82ba604de55dac3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Bjoern. I've gone through my draft copy and reviewed the references, so this should be better in -03 (to be released after I fix other LC comments). --Richard On Fri, May 31, 2013 at 12:51 PM, Bjoern Hoehrmann wrote= : > Hi, > > In http://tools.ietf.org/html/draft-ietf-jose-use-cases-02 some of the > references are outdated, for instance, "W3C.CR-xmldsig-core2-20120124" > is a Working Group Note now, not a Candidate Recommendation anymore, and > "W3C.REC-xml-1998" should probably reference the 5th Edition instead, or > it should be clarified why the 1998 version is used. Furthermore, some > of the references seem incorrectly classified, e.g. "W3C.REC-xml-1998" > is listed as Normative, but the only time it is used is as an example in > the Introduction. It should be non-normative, or be referenced with some > clear normative purpose. > > regards, > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --047d7b2e4710a82ba604de55dac3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, Bjoern. =A0I've gone through my draft copy and= reviewed the references, so this should be better in -03 (to be released a= fter I fix other LC comments).
--Richard
--047d7b2e4710a82ba604de55dac3-- From sakimura@gmail.com Wed Jun 5 05:54:01 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4159121F9A15 for ; Wed, 5 Jun 2013 05:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO5B4U-8fRxU for ; Wed, 5 Jun 2013 05:53:59 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 63F1521F8609 for ; Wed, 5 Jun 2013 05:53:58 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ec20so1359218lab.41 for ; Wed, 05 Jun 2013 05:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/tkIb+9XrmtX0DBs+2fbuLyE5nIQREepVEHngTOWuZc=; b=l/DGIPAOZhCjtosui5sCDHUBw4uY6kqGt6pgyjvKk6ruNbYvDVmIUMjl9hyTTW5hkW ZWHLQgaFfG/ITj3R6SZJz3A8UOL4wQvv5hGQsGjKmbMK6d53fZRg5tTtMUKt3jm/vbcn n9OYCJfCADDTjACvnUyRqedlsmmk0PJHABua1M+/C6c4gli1dysbYmFTBGczoonYMhfe 9lGRSXXTiR8nzAehdTiy7o6koocXvCWQpu9EZ7u88VdOF6+x5knOVl7Rguomw/XHexk8 iYl0xSoXHCyljFArQkF+lKHxD4GYSqFlCo12JtcRgSDspYqN3/AMt7Ld62gtZAnLaHW/ /t6w== MIME-Version: 1.0 X-Received: by 10.112.236.70 with SMTP id us6mr14733744lbc.121.1370436834709; Wed, 05 Jun 2013 05:53:54 -0700 (PDT) Received: by 10.112.4.99 with HTTP; Wed, 5 Jun 2013 05:53:54 -0700 (PDT) In-Reply-To: References: <02b701ce5cb8$46ae77e0$d40b67a0$@augustcellars.com> <02f501ce5cc5$ec9a2200$c5ce6600$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943677C58C4@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C5C0A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C7399@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9B69@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9E95@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 5 Jun 2013 21:53:54 +0900 Message-ID: From: Nat Sakimura To: Richard Barnes Content-Type: multipart/alternative; boundary=001a11c3c946b8584904de67b053 Cc: Mike Jones , Brian Campbell , Jim Schaad , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Should we delete the "typ" header field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 12:54:01 -0000 --001a11c3c946b8584904de67b053 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What about such as this? cty: original typ: timestamp 2013/6/5 Richard Barnes > It would be a good point, if it were true :) In particular, this part: > "[dropping 'typ'] is going to cause each and every application that uses > JOSE to define their own field" > > So far, I've heard of exactly one application of JOSE that requires "typ" > in the way it is currently specified, namely JWT. > > On the other hand, Dick's applications are apparently using it differentl= y > (and, IMO, properly) to distinguish JWE/JWS. Then there are all the > applications out there that are OK using application context and "cty" to > recognize what type of object they have. Apps using CMS have been doing > this for ages. > > So it's not at all clear to me that there's any other application that > would use "typ" besides JWT. And it's not clear to me that JWT needs it. > > --Richard > > > > > > On Fri, May 31, 2013 at 5:45 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Nat makes a good point here, I think. >> >> >> On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura wrote= : >> >>> From what I understand, both typ and cty are something to be consumed b= y >>> the application and not JOSE processor. From the point of view of the J= OSE >>> processor, they should be ignored. >>> >>> We could drop both fields from JOSE specs, but that is going to cause >>> each and every application that uses JOSE to define their own field, wh= ich >>> is a waste. That is why we are defining them here. >>> >>> I would rather drop them than define JOSE processing semantics to these >>> fields. >>> >>> >>> 2013/5/31 Mike Jones >>> >>>> No, =93cty=94 is used by the derived class to determine the type of t= he >>>> encapsulated field. But that=92s not a complete description of the **= entire >>>> object** - especially not the additional meaning imbued by the >>>> additional parameters the derived type may add to the JOSE header. = =93typ=94 >>>> is there to provide the type of the entire object, including what you= =92re >>>> calling the wrapper parts.**** >>>> >>>> ** ** >>>> >>>> -- Mike***= * >>>> >>>> ** ** >>>> >>>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>>> *Sent:* Thursday, May 30, 2013 7:58 AM >>>> >>>> *To:* Mike Jones >>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt >>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>> >>>> ** ** >>>> >>>> Isn't that requirement met by "cty"? The only thing JOSE adds is a >>>> crypto wrapper around the real application content. If you're an >>>> application, you know a JOSE object is the thing you want because it >>>> contains the content you want -- it's a JWT because it contains JWT cl= aims. >>>> **** >>>> >>>> ** ** >>>> >>>> Inheritance is the wrong metaphor. This is encapsulation of >>>> application data:**** >>>> >>>> if (jws.valid && jws.cty =3D=3D "application/jwt_claims") {**** >>>> >>>> jwtClaims =3D jws.content;**** >>>> >>>> }**** >>>> >>>> ** ** >>>> >>>> --Richard**** >>>> >>>> ** ** >>>> >>>> On Thu, May 30, 2013 at 10:43 AM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote:**** >>>> >>>> Thanks for sharing the S/MIME details. Although I was actually making >>>> the analogy to MIME =96 not S/MIME. Like many analogies, it=92s imper= fect, but >>>> I believe still illustrative.**** >>>> >>>> **** >>>> >>>> The reason that the analogy isn=92t perfect is that the JOSE data >>>> structures are used to build application-specific data structures that= are >>>> legal JOSE data structures but also have additional properties =96 inc= luding >>>> additional header fields with specific semantics. (When we agreed to >>>> ignore not-understood header fields we let that horse out of the barn.= ) >>>> For instance, Dick Hardt uses JWEs with issuer and audience fields in = the >>>> headers, so they can be used by routing software.**** >>>> >>>> **** >>>> >>>> Think of JOSE as the base class and the application types built using >>>> it as derived classes. JWT is a derived class. Dick=92s structures a= re a >>>> derived class. These derived classes sometimes need names. That=92s = what >>>> =93typ=94 is for.**** >>>> >>>> **** >>>> >>>> -- Mike***= * >>>> >>>> **** >>>> >>>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>>> *Sent:* Thursday, May 30, 2013 7:34 AM**** >>>> >>>> >>>> *To:* Mike Jones >>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt >>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>> >>>> **** >>>> >>>> You're mixing up "typ" and "cty". If you want to make the analogy to >>>> S/MIME, "cty" is the equivalent to Content-Type inside the protected M= IME >>>> body; "typ" is the content-type on the outer MIME header. Pasting in = an >>>> example:**** >>>> >>>> **** >>>> >>>> -----BEGIN-----**** >>>> >>>> Content-Type: application/pkcs7-mime; smime-type=3Dsigned-data;**** >>>> >>>> name=3Dsmime.p7m**** >>>> >>>> Content-Transfer-Encoding: base64**** >>>> >>>> Content-Disposition: attachment; filename=3Dsmime.p7m**** >>>> >>>> **** >>>> >>>> 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7**** >>>> >>>> 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH**** >>>> >>>> HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh**** >>>> >>>> 6YT64V0GhIGfHfQbnj75**** >>>> >>>> -----END-----**** >>>> >>>> **** >>>> >>>> **** >>>> >>>> The outer Content-Type, which is analogous to "typ", MUST be >>>> application/pkcs7-mime, with a parameter indicating the type of CMS ob= ject. >>>> This is the same as requiring "typ" to be JWE or JWS. The inner >>>> Content-Type (ASN.1/base64 encoded in the example) can be anything, ju= st >>>> like "cty".**** >>>> >>>> **** >>>> >>>> --Richard**** >>>> >>>> **** >>>> >>>> **** >>>> >>>> **** >>>> >>>> **** >>>> >>>> On Thu, May 30, 2013 at 12:53 AM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote:**** >>>> >>>> Requiring that the =93typ=94 value be only =93JWS=94 or =93JWE=94 woul= d be >>>> analogous to the MIME spec requiring that the Content-Type: field be o= nly >>>> =93text/plain=94 or =93message/external-body=94. It would render it u= seless.** >>>> ** >>>> >>>> **** >>>> >>>> -- Mike***= * >>>> >>>> **** >>>> >>>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On >>>> Behalf Of *Richard Barnes >>>> *Sent:* Wednesday, May 29, 2013 8:03 PM >>>> *To:* Mike Jones >>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt**** >>>> >>>> >>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>> >>>> **** >>>> >>>> If this is the level of "type" you're referring to, I think we should >>>> drop it from the spec. It's an application-layer thing that the app c= an >>>> add or not according to its wishes.**** >>>> >>>> **** >>>> >>>> I'm with Dick on this. I think we should either have a mandatory >>>> indicator of what type of JOSE object this, or nothing at all. If th= e >>>> former, the allowable values are "JWE" and "JWS". The "+JSON" options= are >>>> non-sensical -- the app needs to know what it's parsing before it gets= this >>>> header. While I have a preference for the former (for clarity), the l= atter >>>> approach is also OK with me, since the MIME types are specific to JWE/= JWS. >>>> **** >>>> >>>> **** >>>> >>>> Another approach here would be to address the JSON and compact forms >>>> separately. The JSON form has no need of "typ" at all, since the type= of >>>> the object is completely clear from what fields are there, e.g., >>>> "recipients" vs. "signatures". For the compact form, we could do some= thing >>>> like James's "E."/"S." prefix idea, which you need because the >>>> dot-separated components have different meanings and no field names to >>>> indicate this.**** >>>> >>>> **** >>>> >>>> --Richard**** >>>> >>>> **** >>>> >>>> On Wed, May 29, 2013 at 8:30 PM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote:**** >>>> >>>> A standard library is unlikely to know the meanings of all possible >>>> =93typ=94 values =96 and more to the point, *it doesn=92t have to*. I= t=92s the >>>> application=92s job to determine that =93this blob is a JOSE object=94= and then >>>> pass it to a standard library, which will then ignore the =93typ=94 va= lue.* >>>> *** >>>> >>>> **** >>>> >>>> A standard JOSE library won=92t know what =93typ=94: =93JWT=94 means. = It won=92t >>>> know what =93typ=94: =93BCGovToken=94 is, should the BC Government wan= t to declare >>>> that it=92s using a token with particular characteristics. It won=92t= know >>>> what =93typ=94: =93XMPP=94 is, should XMPP want to declare that it=92s= using a JOSE >>>> data structure with particular characteristics. Etc.**** >>>> >>>> **** >>>> >>>> All these values can be registered in the registry and used by >>>> applications that understand them. That=92s the application=92s job = =96 not the >>>> library=92s job. The =93typ=94 field is just there so that applicatio= ns have a >>>> standard place to make any such declarations that they may need.**** >>>> >>>> **** >>>> >>>> -- Mik= e >>>> **** >>>> >>>> **** >>>> >>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>>> *Sent:* Wednesday, May 29, 2013 5:18 PM >>>> *To:* Mike Jones >>>> *Cc:* Jim Schaad; jose@ietf.org**** >>>> >>>> >>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>> >>>> **** >>>> >>>> I'd prefer to be able to use standard libraries for creating and >>>> parsing tokens, and not specialized libraries dependent on the use cas= e. >>>> **** >>>> >>>> **** >>>> >>>> I strongly think we either drop "typ" or make it required.**** >>>> >>>> **** >>>> >>>> On Wed, May 29, 2013 at 5:03 PM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote:**** >>>> >>>> It=92s fine for your application to specify that it=92s required for y= our >>>> use case. Not applications need it, so they shouldn=92t be forced to = pay the >>>> space penalty of an unnecessary field.**** >>>> >>>> **** >>>> >>>> -- Mik= e >>>> **** >>>> >>>> **** >>>> >>>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On >>>> Behalf Of *Dick Hardt >>>> *Sent:* Wednesday, May 29, 2013 4:56 PM**** >>>> >>>> >>>> *To:* Jim Schaad >>>> *Cc:* jose@ietf.org >>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>> >>>> **** >>>> >>>> I use it all the time and my code would barf if it was not there.**** >>>> >>>> **** >>>> >>>> I think it should be required rather than be a hint if it is going ot >>>> be there.**** >>>> >>>> **** >>>> >>>> On Wed, May 29, 2013 at 4:40 PM, Jim Schaad >>>> wrote:**** >>>> >>>> I think the values just changed**** >>>> >>>> **** >>>> >>>> However the way you are using it would be an argument to say that it >>>> should be a required field. Are you just using it as a hint if it exi= sts >>>> and then looking at the rest of the fields if it is not present?**** >>>> >>>> **** >>>> >>>> Jim**** >>>> >>>> **** >>>> >>>> **** >>>> >>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>>> *Sent:* Wednesday, May 29, 2013 3:49 PM >>>> *To:* Jim Schaad >>>> *Cc:* jose@ietf.org >>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>> >>>> **** >>>> >>>> Well, I have been using, but now realize the spec changed or I was >>>> confused.**** >>>> >>>> **** >>>> >>>> I had been setting "typ" to be either "JWE" or "JWS" depending on the >>>> type of token I was creating or parsing as it was easier than looking = at >>>> "alg"**** >>>> >>>> **** >>>> >>>> As currently defined, I don't see value in "typ".**** >>>> >>>> **** >>>> >>>> -- Dick**** >>>> >>>> **** >>>> >>>> **** >>>> >>>> On Wed, May 29, 2013 at 3:02 PM, Jim Schaad >>>> wrote:**** >>>> >>>> In reading the documents, I am trying to understand the justification >>>> for having the =93typ=94 header parameter in the JOSE documents.**** >>>> >>>> **** >>>> >>>> The purpose of the field is to hold the type of the object. In the >>>> past, I believe that values which should now be placed in the cty fiel= d >>>> (such as =93JWT=94) were placed in this field as well. However the pa= rameter >>>> is optional and an implementation cannot rely on its being present. T= his >>>> means that for all practical purposes all of the code to determine the >>>> value of the type field from the values of the alg and enc fields. If= the >>>> field was mandatory then this code would disappear at a fairly small s= pace >>>> cost and I can understand why the parameter would be present.**** >>>> >>>> **** >>>> >>>> Can anybody justify why this field should be present in the document = =96 >>>> or should it just disappear?**** >>>> >>>> **** >>>> >>>> Jim**** >>>> >>>> **** >>>> >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose**** >>>> >>>> >>>> >>>> **** >>>> >>>> **** >>>> >>>> -- >>>> -- Dick **** >>>> >>>> >>>> >>>> **** >>>> >>>> **** >>>> >>>> -- >>>> -- Dick **** >>>> >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose**** >>>> >>>> >>>> >>>> **** >>>> >>>> **** >>>> >>>> -- >>>> -- Dick **** >>>> >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose**** >>>> >>>> **** >>>> >>>> **** >>>> >>>> ** ** >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>> >>>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >> > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c3c946b8584904de67b053 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
What about such as this?=A0

cty: original
typ: timestamp


2013/6/5 Richard Barnes <rlb@ipv.sx>=
It would be a good point, i= f it were true :) =A0In particular, this part: "[dropping 'typ'= ;]=A0is going to cause each and every application that uses JOSE to def= ine their own field"

So far, I've heard of exactly one application of JOSE th= at requires "typ" in the way it is currently specified, namely JW= T. =A0

On the other hand, Dick's applications = are apparently using it differently (and, IMO, properly) to distinguish JWE= /JWS. =A0Then there are all the applications out there that are OK using ap= plication context and "cty" to recognize what type of object they= have. =A0Apps using CMS have been doing this for ages.

So it's not at all clear to me that there's any= other application that would use "typ" besides JWT. =A0And it= 9;s not clear to me that JWT needs it.

--Richard





On Fri, May 31, 2013 at 5:45 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Nat makes a good point here= , I think.


On Thu, May 30, 2013 at 9:31 AM, Nat Sak= imura <sakimura@gmail.com> wrote:
From what I understand, bot= h typ and cty are something to be consumed by the application and not JOSE = processor. From the point of view of the JOSE processor, they should be ign= ored.=A0

We could drop both fields from JOSE specs, but that is going to cause each = and every application that uses JOSE to define their own field, which is a = waste. That is why we are defining them here.=A0

I would rather drop them than define JOSE processing semantics to thes= e fields.=A0


2013/5/31 Mike Jones <Michael.Jones@microso= ft.com>

No, =93cty=94 is used by = the derived class to determine the type of the encapsulated field.=A0 But t= hat=92s not a complete description of the *entire object* - especially not the additional meaning imbued by the additional parameter= s the derived type may add to the JOSE header.=A0 =93typ=94 is there to pro= vide the type of the entire object, including what you=92re calling the wra= pper parts.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7:58 AM


To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

Isn't that requirement met by "cty"? = =A0The only thing JOSE adds is a crypto wrapper around the real application= content. =A0If you're an application, you know a JOSE object is the th= ing you want because it contains the content you want -- it's a JWT because it contains JWT claims.

=A0

Inheritance is the wrong metaphor. =A0This is encaps= ulation of application data:

if (jws.valid && jws.cty =3D=3D "applic= ation/jwt_claims") {

=A0 =A0 jwtClaims =3D jws.content;

}

=A0

--Richard

=A0

On Thu, May 30, 2013 at 10:43 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Thanks for sharing the S/= MIME details.=A0 Although I was actually making the analogy to MIME =96 not S/MIME.=A0 Like many analogies, it=92s imperfect, but I believe still illu= strative.

=A0<= /p>

The reason that the analo= gy isn=92t perfect is that the JOSE data structures are used to build appli= cation-specific data structures that are legal JOSE data structures but also have addition= al properties =96 including additional header fields with specific semantic= s.=A0 (When we agreed to ignore not-understood header fields we let that ho= rse out of the barn.)=A0 For instance, Dick Hardt uses JWEs with issuer and audience fields in the headers, so th= ey can be used by routing software.

=A0<= /p>

Think of JOSE as the base= class and the application types built using it as derived classes.=A0 JWT is a derived class.=A0 Dick=92s structures are a derived class.=A0 These d= erived classes sometimes need names.=A0 That=92s what =93typ=94 is for.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7:34 AM


To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

You're mixing up "typ" and "cty&q= uot;. =A0If you want to make the analogy to S/MIME, "cty" is the = equivalent to Content-Type inside the protected MIME body; "typ" = is the content-type on the outer MIME header. =A0Pasting in an example:

=A0

-----BEGIN-----

Content-Type: application/pkcs7-mime; smime-type=3Ds= igned-data;

=A0 =A0 =A0name=3Dsmime.p7m

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=3Dsmime.p7= m

=A0

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4V= Qbnj7

77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUuj= hJhjH

HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHG= ghyHh

6YT64V0GhIGfHfQbnj75

-----END-----

=A0

The outer Content-Type, which is analogous to "= typ", MUST be application/pkcs7-mime, with a parameter indicating the = type of CMS object. =A0This is the same as requiring "typ" to be JWE or JWS. =A0The inner Content-Type (ASN.1/base64 encoded in the exam= ple) can be anything, just like "cty".

=A0

--Richard

=A0

=A0

=A0

=A0

On Thu, May 30, 2013 at 12:53 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Requiring that the =93typ= =94 value be only =93JWS=94 or =93JWE=94 would be analogous to the MIME spe= c requiring that the Content-Type: field be only =93text/plain=94 or =93message/extern= al-body=94.=A0 It would render it useless.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, May 29, 2013 8:03 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org; Dick Hardt


Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

If this is the level of "type" you're = referring to, I think we should drop it from the spec. =A0It's an appli= cation-layer thing that the app can add or not according to its wishes.<= /u>

=A0

I'm with Dick on this. =A0I think we should eith= er have a mandatory indicator of what type of JOSE object this, or nothing = at all. =A0 If the former, the allowable values are "JWE" and "JWS". =A0The "+JSON" options are non-sensical -- = the app needs to know what it's parsing before it gets this header. =A0= While I have a preference for the former (for clarity), the latter approach= is also OK with me, since the MIME types are specific to JWE/JWS.

=A0

Another approach here would be to address the JSON a= nd compact forms separately. =A0The JSON form has no need of "typ"= ; at all, since the type of the object is completely clear from what fields are there, e.g., "recipients" vs. "signatures&q= uot;. =A0For the compact form, we could do something like James's "= ;E."/"S." prefix idea, which you need because the dot-separa= ted components have different meanings and no field names to indicate this.=

=A0

--Richard

=A0

On Wed, May 29, 2013 at 8:30 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

A standard library is unl= ikely to know the meanings of all possible =93typ=94 values =96 and more to= the point, it doesn=92t have to.=A0 It=92s the application=92s job to d= etermine that =93this blob is a JOSE object=94 and then pass it to a standa= rd library, which will then ignore the =93typ=94 value.

=A0<= /p>

A standard JOSE library w= on=92t know what =93typ=94: =93JWT=94 means.=A0 It won=92t know what =93typ= =94: =93BCGovToken=94 is, should the BC Government want to declare that it=92s using a token wit= h particular characteristics.=A0 It won=92t know what =93typ=94: =93XMPP=94= is, should XMPP want to declare that it=92s using a JOSE data structure wi= th particular characteristics.=A0 Etc.

=A0<= /p>

All these values can be r= egistered in the registry and used by applications that understand them.=A0 That=92s the application=92s job =96 not the library=92s job.=A0 The =93ty= p=94 field is just there so that applications have a standard place to make= any such declarations that they may need.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Wednesday, May 29, 2013 5:18 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org


Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

I'd prefer to be able to use standard libraries = for creating and parsing tokens, and not specialized libraries dependent on= the use case.

=A0

I strongly think we either drop "typ" or m= ake it required.

=A0

On Wed, May 29, 2013 at 5:03 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

It=92s fine for your appl= ication to specify that it=92s required for your use case.=A0 Not applicati= ons need it, so they shouldn=92t be forced to pay the space penalty of an unne= cessary field.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Wednesday, May 29, 2013 4:56 PM


To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

I use it all the time and my code would barf if it w= as not there.

=A0

I think it should be required rather than be a hint = if it is going ot be there.

=A0

On Wed, May 29, 2013 at 4:40 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

I think the values just c= hanged

=A0<= /p>

However the way you are u= sing it would be an argument to say that it should be a required field.=A0 Are you just using it as a hint if it exists and then looking at the rest = of the fields if it is not present?

=A0<= /p>

Jim<= /p>

=A0<= /p>

=A0<= /p>

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Wednesday, May 29, 2013 3:49 PM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

Well, I have been using, but now realize the spec ch= anged or I was confused.

=A0

I had been setting "typ" to be either &quo= t;JWE" or "JWS" depending on the type of token I was creatin= g or parsing as it was easier than looking at "alg"=

=A0

As currently defined, I don't see value in "= ;typ".

=A0

-- Dick

=A0

=A0

On Wed, May 29, 2013 at 3:02 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

In reading the documents, I am trying to understand = the justification for having the =93typ=94 header parameter in the JOSE doc= uments.

=A0

The purpose of the field is to hold the type of the = object. =A0In the past, I believe that values which should now be placed in= the cty field (such as =93JWT=94) were placed in this field as well.=A0 However the parameter is optional and an implementation cannot= rely on its being present.=A0 This means that for all practical purposes a= ll of the code to determine the value of the type field from the values of = the alg and enc fields. =A0If the field was mandatory then this code would disappear at a fairly small space cost = and I can understand why the parameter would be present.

=A0

Can anybody justify why this field should be present= in the document =96 or should it just disappear?

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick



=A0

--
-- Dick


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0

=A0

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_= nat_en

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose






--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en
--001a11c3c946b8584904de67b053-- From jricher@mitre.org Wed Jun 5 06:41:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CE621F9AF9; Wed, 5 Jun 2013 06:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.255 X-Spam-Level: X-Spam-Status: No, score=-5.255 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lffP03vkqsXi; Wed, 5 Jun 2013 06:41:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 32A5421F9AFB; Wed, 5 Jun 2013 06:41:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 625AE1F04AF; Wed, 5 Jun 2013 09:41:10 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 422B31F0269; Wed, 5 Jun 2013 09:41:10 -0400 (EDT) Received: from [10.146.15.13] (129.83.31.56) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 5 Jun 2013 09:41:10 -0400 Message-ID: <51AF3FC6.7080501@mitre.org> Date: Wed, 5 Jun 2013 09:40:22 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: References: <2481701B-912B-4B5B-821C-D86721A4C4C6@adobe.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050000050409010803090807" X-Originating-IP: [129.83.31.56] Cc: asanso@adobe.com, oauth@ietf.org, "jose@ietf.org" Subject: Re: [jose] [OAUTH-WG] JWS encoding Appendix A X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:41:16 -0000 --------------050000050409010803090807 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Also, it's the JOSE working group, not OAuth, that's working on JWS. I've CC'd that group on this reply, further discussion (if needed) should probably take place there. -- Justin On 06/05/2013 09:37 AM, Axel.Nennker@telekom.de wrote: > > Antonio, > > Please have a look at this > > https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#104 > > The \r\n is the important. > > Please make sure you have this byte representation of the payload. > > The following octet sequence contains the UTF-8 representation of the > > JWS Header: > > [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32, > > 34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125] > > Best regards > > Axel > > *From:*oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Antonio Sanso > *Sent:* Wednesday, June 05, 2013 3:27 PM > *To:* oauth@ietf.org WG > *Subject:* [OAUTH-WG] JWS encoding Appendix A > > Hi *, > > while testing my encoding routine against JWS I spot a difference > between my encoding and the one in the spec. > > More specifically I am referring to Appendix A.1.1 [0] of the JWS spec. > > Now it could easily be that the library I wrote is wrong but it works > fine with the encoding in the JWT spec for example. > > If somebody would like to give a look just for the record the encoding > for the header in the spec looks like \ > > eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 > > while for me would look like > > eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 > > Same for the payload, spec > > eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ > > my library > > eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ > > Now the difference is probably given from the fact I did not take care > in consideration carriage return in my input. > > I am on a huge JSON expert but what is the correct way to handle it? > > Regards > > Antonio > > [0] > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#appendix-A.1 > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050000050409010803090807 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Also, it's the JOSE working group, not OAuth, that's working on JWS. I've CC'd that group on this reply, further discussion (if needed) should probably take place there.

 -- Justin

On 06/05/2013 09:37 AM, Axel.Nennker@telekom.de wrote:

Antonio,

Please have a look at this

https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#104

 

The \r\n is the important.

 

Please make sure you have this byte representation of the payload.

The following octet sequence contains the UTF-8 representation of the

   JWS Header:

 

   [123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,

   34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]

 

 

Best regards

Axel

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Antonio Sanso
Sent: Wednesday, June 05, 2013 3:27 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] JWS encoding Appendix A

 

Hi *,

 

while testing my encoding routine against JWS I spot a difference between my encoding and the one in the spec.

 

More specifically I am referring to Appendix A.1.1 [0] of the JWS spec.

Now it could easily be that the library I wrote is wrong but it works fine with the encoding in the JWT spec for example.

If somebody would like to give a look just for the record the encoding for the header in the spec looks like \

 

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9

while for me would look like

 

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

 

Same for the payload, spec

 

eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

 

my library

 

eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ

 

Now the difference is probably given from the fact I did not take care in consideration carriage return in my input.

I am on a huge JSON expert but what is the correct way to handle it? 

 

Regards

 

Antonio

 

 

 



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------050000050409010803090807-- From rlb@ipv.sx Wed Jun 5 07:14:27 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB0221F9952 for ; Wed, 5 Jun 2013 07:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.137 X-Spam-Level: * X-Spam-Status: No, score=1.137 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hmg1dx3tRuOs for ; Wed, 5 Jun 2013 07:14:23 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BF19821F957B for ; Wed, 5 Jun 2013 07:14:19 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wc20so2620127obb.4 for ; Wed, 05 Jun 2013 07:14:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=XbBpubfLBT0akdQUv+4hlgiOtHOecVN6+qhLwfcPzHE=; b=lhFommC5DYW2tCnBdk8dyJ+2wilhJoBBzw6Akd6izXjk3HYR74qah5pSAKjJ89Bw4w sNPAyI0dxSMiJ5ZrBP0XHCwhDHiqykjw6qsTkVnz8p4V+SPO1M5rj0zkb2XT1y5A7MqW QeRFezlJLC5m3AtRPDdgUZQ2vCTcp+i9xubIlHsrFtkEFdpsFVz2pWx6CUP0vmOxy+L2 q2bOOkFyWaVvfh4gpxi6VQTdrtbIBaA5110aJdOtT5BePELkgPp8lOdKm7u/+5+4JoC7 zwDtIPksZGnoyUMghE85tf+Pjioh8jeqUV7Y7LrhKcg05jg2hoyWxm+isJ+6vXLNVP3t zKXw== MIME-Version: 1.0 X-Received: by 10.60.134.236 with SMTP id pn12mr15537900oeb.4.1370441659196; Wed, 05 Jun 2013 07:14:19 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Wed, 5 Jun 2013 07:14:19 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: References: <02b701ce5cb8$46ae77e0$d40b67a0$@augustcellars.com> <02f501ce5cc5$ec9a2200$c5ce6600$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943677C58C4@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C5C0A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C7399@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9B69@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9E95@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 5 Jun 2013 10:14:19 -0400 Message-ID: From: Richard Barnes To: Nat Sakimura Content-Type: multipart/alternative; boundary=047d7b471f6a48360004de68d060 X-Gm-Message-State: ALoCoQn3O7Vydoa1hATEUFR4yGOhvEoOVBnBC/jFtfdZDI2hSLQuwaNCqOgSvyzTlEcxmho8Yk6g Cc: Mike Jones , Brian Campbell , Jim Schaad , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Should we delete the "typ" header field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:14:27 -0000 --047d7b471f6a48360004de68d060 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm not sure I understand the use case here. Let me look at a couple of options, and hopefully one of them will be what you meant :) If it's just a signed timestamp you're talking about, then that's adequately described by cty=3D"timestamp", typ=3D"JWS". If you want to sign something and add a timestamp in the header, then typ=3D"timestamp" isn't accurate according to the current specification. T= he type of the whole object would have to be something like "timestamped-content". And in that case, an application can easily recognized that it's timestamped content by looking for the timestamp field in the header, so the "typ" isn't really helpful. Moving from the example to the general question: I think we finally have some common understanding on this list as to what Mike means by "typ" in the current document -- a label for the application-layer type of the overall object. Thanks to Mike for clarifying that in this discussion. The question is whether this is a sufficiently useful thing to have in the core spec. Obviously, applications have to know what type of object they're dealing with when they get a JOSE object. That includes (1) what type of content is in the payload, and (2) what application-layer fields are required to be in the header. (1) is covered by "cty". So "typ" is only useful in the case where: A. The application is storing application-layer data in the JOSE header B. The required application-layer fields can be different for different objects C. The required application-layer fields can be different for different objects of the same content type D. The required application-layer fields are not indicated by other application-layer context Are there any known applications that meet these criteria? JWT does not, for several reasons. 1. (!A) JWT does not store application-layer data in the JOSE header, only in the claims in the body 2. (!C) A JWT object can indicate with "cty" that it contains JWT claims or another JWT, either of which makes it obvious that this is a JWT 3. (!D) In the OAuth context, the Token Type value indicates what type of token is being presented, e.g., JWT So there's not really any known use case for "typ" as currently specified. On the other hand, Dick and James have pointed out that it can be useful to have "typ" indicate whether the object at hand is a JWE or JWS. Which brings us back to: -- Change the definition of "typ" so that it indicates the JOSE-layer type (JWE/JWS) -- Remove "typ" altogether On Wed, Jun 5, 2013 at 8:53 AM, Nat Sakimura wrote: > What about such as this? > > cty: original > typ: timestamp > > > 2013/6/5 Richard Barnes > >> It would be a good point, if it were true :) In particular, this part: >> "[dropping 'typ'] is going to cause each and every application that uses >> JOSE to define their own field" >> >> So far, I've heard of exactly one application of JOSE that requires "typ= " >> in the way it is currently specified, namely JWT. >> >> On the other hand, Dick's applications are apparently using it >> differently (and, IMO, properly) to distinguish JWE/JWS. Then there are >> all the applications out there that are OK using application context and >> "cty" to recognize what type of object they have. Apps using CMS have b= een >> doing this for ages. >> >> So it's not at all clear to me that there's any other application that >> would use "typ" besides JWT. And it's not clear to me that JWT needs it= . >> >> --Richard >> >> >> >> >> >> On Fri, May 31, 2013 at 5:45 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> Nat makes a good point here, I think. >>> >>> >>> On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura wrote= : >>> >>>> From what I understand, both typ and cty are something to be consumed >>>> by the application and not JOSE processor. From the point of view of t= he >>>> JOSE processor, they should be ignored. >>>> >>>> We could drop both fields from JOSE specs, but that is going to cause >>>> each and every application that uses JOSE to define their own field, w= hich >>>> is a waste. That is why we are defining them here. >>>> >>>> I would rather drop them than define JOSE processing semantics to thes= e >>>> fields. >>>> >>>> >>>> 2013/5/31 Mike Jones >>>> >>>>> No, =93cty=94 is used by the derived class to determine the type of = the >>>>> encapsulated field. But that=92s not a complete description of the *= *entire >>>>> object** - especially not the additional meaning imbued by the >>>>> additional parameters the derived type may add to the JOSE header. = =93typ=94 >>>>> is there to provide the type of the entire object, including what you= =92re >>>>> calling the wrapper parts.**** >>>>> >>>>> ** ** >>>>> >>>>> -- Mike**= * >>>>> * >>>>> >>>>> ** ** >>>>> >>>>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>>>> *Sent:* Thursday, May 30, 2013 7:58 AM >>>>> >>>>> *To:* Mike Jones >>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt >>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>> >>>>> ** ** >>>>> >>>>> Isn't that requirement met by "cty"? The only thing JOSE adds is a >>>>> crypto wrapper around the real application content. If you're an >>>>> application, you know a JOSE object is the thing you want because it >>>>> contains the content you want -- it's a JWT because it contains JWT c= laims. >>>>> **** >>>>> >>>>> ** ** >>>>> >>>>> Inheritance is the wrong metaphor. This is encapsulation of >>>>> application data:**** >>>>> >>>>> if (jws.valid && jws.cty =3D=3D "application/jwt_claims") {**** >>>>> >>>>> jwtClaims =3D jws.content;**** >>>>> >>>>> }**** >>>>> >>>>> ** ** >>>>> >>>>> --Richard**** >>>>> >>>>> ** ** >>>>> >>>>> On Thu, May 30, 2013 at 10:43 AM, Mike Jones < >>>>> Michael.Jones@microsoft.com> wrote:**** >>>>> >>>>> Thanks for sharing the S/MIME details. Although I was actually makin= g >>>>> the analogy to MIME =96 not S/MIME. Like many analogies, it=92s impe= rfect, but >>>>> I believe still illustrative.**** >>>>> >>>>> **** >>>>> >>>>> The reason that the analogy isn=92t perfect is that the JOSE data >>>>> structures are used to build application-specific data structures tha= t are >>>>> legal JOSE data structures but also have additional properties =96 in= cluding >>>>> additional header fields with specific semantics. (When we agreed to >>>>> ignore not-understood header fields we let that horse out of the barn= .) >>>>> For instance, Dick Hardt uses JWEs with issuer and audience fields in= the >>>>> headers, so they can be used by routing software.**** >>>>> >>>>> **** >>>>> >>>>> Think of JOSE as the base class and the application types built using >>>>> it as derived classes. JWT is a derived class. Dick=92s structures = are a >>>>> derived class. These derived classes sometimes need names. That=92s= what >>>>> =93typ=94 is for.**** >>>>> >>>>> **** >>>>> >>>>> -- Mike**= * >>>>> * >>>>> >>>>> **** >>>>> >>>>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>>>> *Sent:* Thursday, May 30, 2013 7:34 AM**** >>>>> >>>>> >>>>> *To:* Mike Jones >>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt >>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>> >>>>> **** >>>>> >>>>> You're mixing up "typ" and "cty". If you want to make the analogy to >>>>> S/MIME, "cty" is the equivalent to Content-Type inside the protected = MIME >>>>> body; "typ" is the content-type on the outer MIME header. Pasting in= an >>>>> example:**** >>>>> >>>>> **** >>>>> >>>>> -----BEGIN-----**** >>>>> >>>>> Content-Type: application/pkcs7-mime; smime-type=3Dsigned-data;**** >>>>> >>>>> name=3Dsmime.p7m**** >>>>> >>>>> Content-Transfer-Encoding: base64**** >>>>> >>>>> Content-Disposition: attachment; filename=3Dsmime.p7m**** >>>>> >>>>> **** >>>>> >>>>> 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7**** >>>>> >>>>> 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH**** >>>>> >>>>> HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh**** >>>>> >>>>> 6YT64V0GhIGfHfQbnj75**** >>>>> >>>>> -----END-----**** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> The outer Content-Type, which is analogous to "typ", MUST be >>>>> application/pkcs7-mime, with a parameter indicating the type of CMS o= bject. >>>>> This is the same as requiring "typ" to be JWE or JWS. The inner >>>>> Content-Type (ASN.1/base64 encoded in the example) can be anything, j= ust >>>>> like "cty".**** >>>>> >>>>> **** >>>>> >>>>> --Richard**** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> On Thu, May 30, 2013 at 12:53 AM, Mike Jones < >>>>> Michael.Jones@microsoft.com> wrote:**** >>>>> >>>>> Requiring that the =93typ=94 value be only =93JWS=94 or =93JWE=94 wou= ld be >>>>> analogous to the MIME spec requiring that the Content-Type: field be = only >>>>> =93text/plain=94 or =93message/external-body=94. It would render it = useless.* >>>>> *** >>>>> >>>>> **** >>>>> >>>>> -- Mike**= * >>>>> * >>>>> >>>>> **** >>>>> >>>>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On >>>>> Behalf Of *Richard Barnes >>>>> *Sent:* Wednesday, May 29, 2013 8:03 PM >>>>> *To:* Mike Jones >>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt**** >>>>> >>>>> >>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>> >>>>> **** >>>>> >>>>> If this is the level of "type" you're referring to, I think we should >>>>> drop it from the spec. It's an application-layer thing that the app = can >>>>> add or not according to its wishes.**** >>>>> >>>>> **** >>>>> >>>>> I'm with Dick on this. I think we should either have a mandatory >>>>> indicator of what type of JOSE object this, or nothing at all. If t= he >>>>> former, the allowable values are "JWE" and "JWS". The "+JSON" option= s are >>>>> non-sensical -- the app needs to know what it's parsing before it get= s this >>>>> header. While I have a preference for the former (for clarity), the = latter >>>>> approach is also OK with me, since the MIME types are specific to JWE= /JWS. >>>>> **** >>>>> >>>>> **** >>>>> >>>>> Another approach here would be to address the JSON and compact forms >>>>> separately. The JSON form has no need of "typ" at all, since the typ= e of >>>>> the object is completely clear from what fields are there, e.g., >>>>> "recipients" vs. "signatures". For the compact form, we could do som= ething >>>>> like James's "E."/"S." prefix idea, which you need because the >>>>> dot-separated components have different meanings and no field names t= o >>>>> indicate this.**** >>>>> >>>>> **** >>>>> >>>>> --Richard**** >>>>> >>>>> **** >>>>> >>>>> On Wed, May 29, 2013 at 8:30 PM, Mike Jones < >>>>> Michael.Jones@microsoft.com> wrote:**** >>>>> >>>>> A standard library is unlikely to know the meanings of all possible >>>>> =93typ=94 values =96 and more to the point, *it doesn=92t have to*. = It=92s the >>>>> application=92s job to determine that =93this blob is a JOSE object= =94 and then >>>>> pass it to a standard library, which will then ignore the =93typ=94 v= alue. >>>>> **** >>>>> >>>>> **** >>>>> >>>>> A standard JOSE library won=92t know what =93typ=94: =93JWT=94 means.= It won=92t >>>>> know what =93typ=94: =93BCGovToken=94 is, should the BC Government wa= nt to declare >>>>> that it=92s using a token with particular characteristics. It won=92= t know >>>>> what =93typ=94: =93XMPP=94 is, should XMPP want to declare that it=92= s using a JOSE >>>>> data structure with particular characteristics. Etc.**** >>>>> >>>>> **** >>>>> >>>>> All these values can be registered in the registry and used by >>>>> applications that understand them. That=92s the application=92s job = =96 not the >>>>> library=92s job. The =93typ=94 field is just there so that applicati= ons have a >>>>> standard place to make any such declarations that they may need.**** >>>>> >>>>> **** >>>>> >>>>> -- Mi= ke >>>>> **** >>>>> >>>>> **** >>>>> >>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>>>> *Sent:* Wednesday, May 29, 2013 5:18 PM >>>>> *To:* Mike Jones >>>>> *Cc:* Jim Schaad; jose@ietf.org**** >>>>> >>>>> >>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>> >>>>> **** >>>>> >>>>> I'd prefer to be able to use standard libraries for creating and >>>>> parsing tokens, and not specialized libraries dependent on the use ca= se. >>>>> **** >>>>> >>>>> **** >>>>> >>>>> I strongly think we either drop "typ" or make it required.**** >>>>> >>>>> **** >>>>> >>>>> On Wed, May 29, 2013 at 5:03 PM, Mike Jones < >>>>> Michael.Jones@microsoft.com> wrote:**** >>>>> >>>>> It=92s fine for your application to specify that it=92s required for = your >>>>> use case. Not applications need it, so they shouldn=92t be forced to= pay the >>>>> space penalty of an unnecessary field.**** >>>>> >>>>> **** >>>>> >>>>> -- Mi= ke >>>>> **** >>>>> >>>>> **** >>>>> >>>>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On >>>>> Behalf Of *Dick Hardt >>>>> *Sent:* Wednesday, May 29, 2013 4:56 PM**** >>>>> >>>>> >>>>> *To:* Jim Schaad >>>>> *Cc:* jose@ietf.org >>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>> >>>>> **** >>>>> >>>>> I use it all the time and my code would barf if it was not there.**** >>>>> >>>>> **** >>>>> >>>>> I think it should be required rather than be a hint if it is going ot >>>>> be there.**** >>>>> >>>>> **** >>>>> >>>>> On Wed, May 29, 2013 at 4:40 PM, Jim Schaad >>>>> wrote:**** >>>>> >>>>> I think the values just changed**** >>>>> >>>>> **** >>>>> >>>>> However the way you are using it would be an argument to say that it >>>>> should be a required field. Are you just using it as a hint if it ex= ists >>>>> and then looking at the rest of the fields if it is not present?**** >>>>> >>>>> **** >>>>> >>>>> Jim**** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>>>> *Sent:* Wednesday, May 29, 2013 3:49 PM >>>>> *To:* Jim Schaad >>>>> *Cc:* jose@ietf.org >>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>> >>>>> **** >>>>> >>>>> Well, I have been using, but now realize the spec changed or I was >>>>> confused.**** >>>>> >>>>> **** >>>>> >>>>> I had been setting "typ" to be either "JWE" or "JWS" depending on the >>>>> type of token I was creating or parsing as it was easier than looking= at >>>>> "alg"**** >>>>> >>>>> **** >>>>> >>>>> As currently defined, I don't see value in "typ".**** >>>>> >>>>> **** >>>>> >>>>> -- Dick**** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> On Wed, May 29, 2013 at 3:02 PM, Jim Schaad >>>>> wrote:**** >>>>> >>>>> In reading the documents, I am trying to understand the justification >>>>> for having the =93typ=94 header parameter in the JOSE documents.**** >>>>> >>>>> **** >>>>> >>>>> The purpose of the field is to hold the type of the object. In the >>>>> past, I believe that values which should now be placed in the cty fie= ld >>>>> (such as =93JWT=94) were placed in this field as well. However the p= arameter >>>>> is optional and an implementation cannot rely on its being present. = This >>>>> means that for all practical purposes all of the code to determine th= e >>>>> value of the type field from the values of the alg and enc fields. I= f the >>>>> field was mandatory then this code would disappear at a fairly small = space >>>>> cost and I can understand why the parameter would be present.**** >>>>> >>>>> **** >>>>> >>>>> Can anybody justify why this field should be present in the document = =96 >>>>> or should it just disappear?**** >>>>> >>>>> **** >>>>> >>>>> Jim**** >>>>> >>>>> **** >>>>> >>>>> >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>> >>>>> >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> -- >>>>> -- Dick **** >>>>> >>>>> >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> -- >>>>> -- Dick **** >>>>> >>>>> >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>> >>>>> >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> -- >>>>> -- Dick **** >>>>> >>>>> >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> ** ** >>>>> >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>> >>>> >>> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > --047d7b471f6a48360004de68d060 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I'm not sure I understand the use case here. =A0Let me= look at a couple of options, and hopefully one of them will be what you me= ant :) =A0

If it's just a signed timestamp you'r= e talking about, then that's adequately described by cty=3D"timest= amp", typ=3D"JWS".

If you want to sign something and add a timestamp in th= e header, then typ=3D"timestamp" isn't accurate according to = the current specification. =A0The type of the whole object would have to be= something like "timestamped-content". =A0And in that case, an ap= plication can easily recognized that it's timestamped content by lookin= g for the timestamp field in the header, so the "typ" isn't r= eally helpful.


Moving from the example to the general q= uestion:

I think we finally have some common under= standing on this list as to what Mike means by "typ" in the curre= nt document -- a label for the application-layer type of the overall object= . =A0Thanks to Mike for clarifying that in this discussion.

The question is whether this is a sufficiently useful t= hing to have in the core spec. =A0Obviously, applications have to know what= type of object they're dealing with when they get a JOSE object. =A0Th= at includes (1) what type of content is in the payload, and (2) what applic= ation-layer fields are required to be in the header. =A0(1) is covered by &= quot;cty". =A0So "typ" is only useful in the case where:
A. The application is storing application-layer data in the JOSE heade= r
B. The required application-layer fields can be different for d= ifferent objects
C. The required application-layer fields can be = different for different objects of the same content type
D. The required application-layer fields are not indicated by other ap= plication-layer context

Are there any known applic= ations that meet these criteria? =A0JWT does not, for several reasons.=A0
1. (!A) JWT does not store application-layer data in the JOSE header, = only in the claims in the body
2. (!C) A JWT object can indicate = with "cty" that it contains JWT claims or another JWT, either of = which makes it obvious that this is a JWT
3. (!D) In the OAuth context, the Token Type value indicates what type= of token is being presented, e.g., JWT

So there&#= 39;s not really any known use case for "typ" as currently specifi= ed. =A0On the other hand, Dick and James have pointed out that it can be us= eful to have "typ" indicate whether the object at hand is a JWE o= r JWS. =A0Which brings us back to:
-- Change the definition of "typ" so that it indicates the J= OSE-layer type (JWE/JWS)
-- Remove "typ" altogether







O= n Wed, Jun 5, 2013 at 8:53 AM, Nat Sakimura <sakimura@gmail.com>= wrote:
What about such as thi= s?=A0

cty: original
typ: timestamp


2013/6/5 Richard Barnes <rlb@ipv.sx>
It would be a good point, i= f it were true :) =A0In particular, this part: "[dropping 'typ'= ;]=A0is going to cause each and every application that uses JOSE to def= ine their own field"

So far, I've heard of exactly one application of JOSE th= at requires "typ" in the way it is currently specified, namely JW= T. =A0

On the other hand, Dick's applications = are apparently using it differently (and, IMO, properly) to distinguish JWE= /JWS. =A0Then there are all the applications out there that are OK using ap= plication context and "cty" to recognize what type of object they= have. =A0Apps using CMS have been doing this for ages.

So it's not at all clear to me that there's any= other application that would use "typ" besides JWT. =A0And it= 9;s not clear to me that JWT needs it.
<= div>
--Richard



=


On Fri, May 3= 1, 2013 at 5:45 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Nat makes a good point here= , I think.


On Thu, May 30, 2013 at 9:31 AM, Nat Sak= imura <sakimura@gmail.com> wrote:
From what I understand, bot= h typ and cty are something to be consumed by the application and not JOSE = processor. From the point of view of the JOSE processor, they should be ign= ored.=A0

We could drop both fields from JOSE specs, but that is going to cause each = and every application that uses JOSE to define their own field, which is a = waste. That is why we are defining them here.=A0

I would rather drop them than define JOSE processing semantics to thes= e fields.=A0


2013/5/31 Mike Jones <Michael.Jones@microso= ft.com>

No, =93cty=94 is used by = the derived class to determine the type of the encapsulated field.=A0 But t= hat=92s not a complete description of the *entire object* - especially not the additional meaning imbued by the additional parameter= s the derived type may add to the JOSE header.=A0 =93typ=94 is there to pro= vide the type of the entire object, including what you=92re calling the wra= pper parts.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7:58 AM


To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

Isn't that requirement met by "cty"? = =A0The only thing JOSE adds is a crypto wrapper around the real application= content. =A0If you're an application, you know a JOSE object is the th= ing you want because it contains the content you want -- it's a JWT because it contains JWT claims.

=A0

Inheritance is the wrong metaphor. =A0This is encaps= ulation of application data:

if (jws.valid && jws.cty =3D=3D "applic= ation/jwt_claims") {

=A0 =A0 jwtClaims =3D jws.content;

}

=A0

--Richard

=A0

On Thu, May 30, 2013 at 10:43 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Thanks for sharing the S/= MIME details.=A0 Although I was actually making the analogy to MIME =96 not S/MIME.=A0 Like many analogies, it=92s imperfect, but I believe still illu= strative.

=A0<= /p>

The reason that the analo= gy isn=92t perfect is that the JOSE data structures are used to build appli= cation-specific data structures that are legal JOSE data structures but also have addition= al properties =96 including additional header fields with specific semantic= s.=A0 (When we agreed to ignore not-understood header fields we let that ho= rse out of the barn.)=A0 For instance, Dick Hardt uses JWEs with issuer and audience fields in the headers, so th= ey can be used by routing software.

=A0<= /p>

Think of JOSE as the base= class and the application types built using it as derived classes.=A0 JWT is a derived class.=A0 Dick=92s structures are a derived class.=A0 These d= erived classes sometimes need names.=A0 That=92s what =93typ=94 is for.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7:34 AM


To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

You're mixing up "typ" and "cty&q= uot;. =A0If you want to make the analogy to S/MIME, "cty" is the = equivalent to Content-Type inside the protected MIME body; "typ" = is the content-type on the outer MIME header. =A0Pasting in an example:

=A0

-----BEGIN-----

Content-Type: application/pkcs7-mime; smime-type=3Ds= igned-data;

=A0 =A0 =A0name=3Dsmime.p7m

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=3Dsmime.p7= m

=A0

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4V= Qbnj7

77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUuj= hJhjH

HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHG= ghyHh

6YT64V0GhIGfHfQbnj75

-----END-----

=A0

The outer Content-Type, which is analogous to "= typ", MUST be application/pkcs7-mime, with a parameter indicating the = type of CMS object. =A0This is the same as requiring "typ" to be JWE or JWS. =A0The inner Content-Type (ASN.1/base64 encoded in the exam= ple) can be anything, just like "cty".

=A0

--Richard

=A0

=A0

=A0

=A0

On Thu, May 30, 2013 at 12:53 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Requiring that the =93typ= =94 value be only =93JWS=94 or =93JWE=94 would be analogous to the MIME spe= c requiring that the Content-Type: field be only =93text/plain=94 or =93message/extern= al-body=94.=A0 It would render it useless.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, May 29, 2013 8:03 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org; Dick Hardt


Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

If this is the level of "type" you're = referring to, I think we should drop it from the spec. =A0It's an appli= cation-layer thing that the app can add or not according to its wishes.<= /u>

=A0

I'm with Dick on this. =A0I think we should eith= er have a mandatory indicator of what type of JOSE object this, or nothing = at all. =A0 If the former, the allowable values are "JWE" and "JWS". =A0The "+JSON" options are non-sensical -- = the app needs to know what it's parsing before it gets this header. =A0= While I have a preference for the former (for clarity), the latter approach= is also OK with me, since the MIME types are specific to JWE/JWS.

=A0

Another approach here would be to address the JSON a= nd compact forms separately. =A0The JSON form has no need of "typ"= ; at all, since the type of the object is completely clear from what fields are there, e.g., "recipients" vs. "signatures&q= uot;. =A0For the compact form, we could do something like James's "= ;E."/"S." prefix idea, which you need because the dot-separa= ted components have different meanings and no field names to indicate this.=

=A0

--Richard

=A0

On Wed, May 29, 2013 at 8:30 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

A standard library is unl= ikely to know the meanings of all possible =93typ=94 values =96 and more to= the point, it doesn=92t have to.=A0 It=92s the application=92s job to d= etermine that =93this blob is a JOSE object=94 and then pass it to a standa= rd library, which will then ignore the =93typ=94 value.

=A0<= /p>

A standard JOSE library w= on=92t know what =93typ=94: =93JWT=94 means.=A0 It won=92t know what =93typ= =94: =93BCGovToken=94 is, should the BC Government want to declare that it=92s using a token wit= h particular characteristics.=A0 It won=92t know what =93typ=94: =93XMPP=94= is, should XMPP want to declare that it=92s using a JOSE data structure wi= th particular characteristics.=A0 Etc.

=A0<= /p>

All these values can be r= egistered in the registry and used by applications that understand them.=A0 That=92s the application=92s job =96 not the library=92s job.=A0 The =93ty= p=94 field is just there so that applications have a standard place to make= any such declarations that they may need.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Wednesday, May 29, 2013 5:18 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org


Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

I'd prefer to be able to use standard libraries = for creating and parsing tokens, and not specialized libraries dependent on= the use case.

=A0

I strongly think we either drop "typ" or m= ake it required.

=A0

On Wed, May 29, 2013 at 5:03 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

It=92s fine for your appl= ication to specify that it=92s required for your use case.=A0 Not applicati= ons need it, so they shouldn=92t be forced to pay the space penalty of an unne= cessary field.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Wednesday, May 29, 2013 4:56 PM


To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

I use it all the time and my code would barf if it w= as not there.

=A0

I think it should be required rather than be a hint = if it is going ot be there.

=A0

On Wed, May 29, 2013 at 4:40 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

I think the values just c= hanged

=A0<= /p>

However the way you are u= sing it would be an argument to say that it should be a required field.=A0 Are you just using it as a hint if it exists and then looking at the rest = of the fields if it is not present?

=A0<= /p>

Jim<= /p>

=A0<= /p>

=A0<= /p>

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Wednesday, May 29, 2013 3:49 PM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

Well, I have been using, but now realize the spec ch= anged or I was confused.

=A0

I had been setting "typ" to be either &quo= t;JWE" or "JWS" depending on the type of token I was creatin= g or parsing as it was easier than looking at "alg"=

=A0

As currently defined, I don't see value in "= ;typ".

=A0

-- Dick

=A0

=A0

On Wed, May 29, 2013 at 3:02 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

In reading the documents, I am trying to understand = the justification for having the =93typ=94 header parameter in the JOSE doc= uments.

=A0

The purpose of the field is to hold the type of the = object. =A0In the past, I believe that values which should now be placed in= the cty field (such as =93JWT=94) were placed in this field as well.=A0 However the parameter is optional and an implementation cannot= rely on its being present.=A0 This means that for all practical purposes a= ll of the code to determine the value of the type field from the values of = the alg and enc fields. =A0If the field was mandatory then this code would disappear at a fairly small space cost = and I can understand why the parameter would be present.

=A0

Can anybody justify why this field should be present= in the document =96 or should it just disappear?

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick



=A0

--
-- Dick


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0

=A0

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_= nat_en

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose






--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en

--047d7b471f6a48360004de68d060-- From sakimura@gmail.com Wed Jun 5 17:32:23 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F42021F86FB for ; Wed, 5 Jun 2013 17:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.296 X-Spam-Level: *** X-Spam-Status: No, score=3.296 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, TRACKER_ID=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuJPTVNFiXlK for ; Wed, 5 Jun 2013 17:32:21 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1BD21F86D3 for ; Wed, 5 Jun 2013 17:32:01 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id fe20so2047095lab.34 for ; Wed, 05 Jun 2013 17:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kK0f2cf3z5D2/mAYxAQhkl6a9gR+HLaGKVDYP3xd2jA=; b=ThxeI6wqdz6YtaN6hGKR6Wk6uoE90SWKxnIyuGiINre69P+9o59TWVaYWIxGkvp0zU TUdD6p1jnMWQIMuTitwRF0K+rcIbGkRFHsZS0IdXyLmSYsGndPjpPBg5tRUuhvZ2VD1W LeeN3MgE3JyoL2pCW/qd3opRajBl5YoeV7B9Til6Qndnw7vGUtEqYuNUvXdgF1V+g/Ei RSPd9SPAvw3vV1xyZmF4JJFc0mK5rb+pC6nXdsnbQ6UyAYbizNF6p/fyyNbiQXmjbp5U d9XWPRtvjid0W1ognbjb3LtpK2DOujTUzHOR11n4vZ9iPElqvlpYGuP8amkbM7xPxhWb /q8g== MIME-Version: 1.0 X-Received: by 10.152.170.194 with SMTP id ao2mr16332899lac.48.1370478716169; Wed, 05 Jun 2013 17:31:56 -0700 (PDT) Received: by 10.112.4.99 with HTTP; Wed, 5 Jun 2013 17:31:55 -0700 (PDT) In-Reply-To: References: <02b701ce5cb8$46ae77e0$d40b67a0$@augustcellars.com> <02f501ce5cc5$ec9a2200$c5ce6600$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943677C58C4@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C5C0A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C7399@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9B69@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9E95@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Thu, 6 Jun 2013 09:31:55 +0900 Message-ID: From: Nat Sakimura To: Richard Barnes Content-Type: multipart/alternative; boundary=089e011615f20cb52a04de7171d6 Cc: Mike Jones , Brian Campbell , Jim Schaad , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Should we delete the "typ" header field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 00:32:23 -0000 --089e011615f20cb52a04de7171d6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What I was thinking as an example was to have 'datetime' as a public header parameter to be used generally, and then differentiate between two cases of 'agreement' and 'timestamp'. It is the same signing operation over the original (e.g., a MS word document), but from an application point of view, it is a bit different. Former constitute an agreement while the later does not. The type=3Dtimestamp just signifies that the original document existed at the time indicated. 2013/6/5 Richard Barnes > I'm not sure I understand the use case here. Let me look at a couple of > options, and hopefully one of them will be what you meant :) > > If it's just a signed timestamp you're talking about, then that's > adequately described by cty=3D"timestamp", typ=3D"JWS". > > If you want to sign something and add a timestamp in the header, then > typ=3D"timestamp" isn't accurate according to the current specification. = The > type of the whole object would have to be something like > "timestamped-content". And in that case, an application can easily > recognized that it's timestamped content by looking for the timestamp fie= ld > in the header, so the "typ" isn't really helpful. > > > Moving from the example to the general question: > > I think we finally have some common understanding on this list as to what > Mike means by "typ" in the current document -- a label for the > application-layer type of the overall object. Thanks to Mike for > clarifying that in this discussion. > > The question is whether this is a sufficiently useful thing to have in th= e > core spec. Obviously, applications have to know what type of object > they're dealing with when they get a JOSE object. That includes (1) what > type of content is in the payload, and (2) what application-layer fields > are required to be in the header. (1) is covered by "cty". So "typ" is > only useful in the case where: > A. The application is storing application-layer data in the JOSE header > B. The required application-layer fields can be different for different > objects > C. The required application-layer fields can be different for different > objects of the same content type > D. The required application-layer fields are not indicated by other > application-layer context > > Are there any known applications that meet these criteria? JWT does not, > for several reasons. > 1. (!A) JWT does not store application-layer data in the JOSE header, onl= y > in the claims in the body > 2. (!C) A JWT object can indicate with "cty" that it contains JWT claims > or another JWT, either of which makes it obvious that this is a JWT > 3. (!D) In the OAuth context, the Token Type value indicates what type of > token is being presented, e.g., JWT > > So there's not really any known use case for "typ" as currently specified= . > On the other hand, Dick and James have pointed out that it can be useful > to have "typ" indicate whether the object at hand is a JWE or JWS. Which > brings us back to: > -- Change the definition of "typ" so that it indicates the JOSE-layer typ= e > (JWE/JWS) > -- Remove "typ" altogether > > > > > > > > On Wed, Jun 5, 2013 at 8:53 AM, Nat Sakimura wrote: > >> What about such as this? >> >> cty: original >> typ: timestamp >> >> >> 2013/6/5 Richard Barnes >> >>> It would be a good point, if it were true :) In particular, this part: >>> "[dropping 'typ'] is going to cause each and every application that >>> uses JOSE to define their own field" >>> >>> So far, I've heard of exactly one application of JOSE that requires >>> "typ" in the way it is currently specified, namely JWT. >>> >>> On the other hand, Dick's applications are apparently using it >>> differently (and, IMO, properly) to distinguish JWE/JWS. Then there ar= e >>> all the applications out there that are OK using application context an= d >>> "cty" to recognize what type of object they have. Apps using CMS have = been >>> doing this for ages. >>> >>> So it's not at all clear to me that there's any other application that >>> would use "typ" besides JWT. And it's not clear to me that JWT needs i= t. >>> >>> --Richard >>> >>> >>> >>> >>> >>> On Fri, May 31, 2013 at 5:45 PM, Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>>> Nat makes a good point here, I think. >>>> >>>> >>>> On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura wrot= e: >>>> >>>>> From what I understand, both typ and cty are something to be consumed >>>>> by the application and not JOSE processor. From the point of view of = the >>>>> JOSE processor, they should be ignored. >>>>> >>>>> We could drop both fields from JOSE specs, but that is going to cause >>>>> each and every application that uses JOSE to define their own field, = which >>>>> is a waste. That is why we are defining them here. >>>>> >>>>> I would rather drop them than define JOSE processing semantics to >>>>> these fields. >>>>> >>>>> >>>>> 2013/5/31 Mike Jones >>>>> >>>>>> No, =93cty=94 is used by the derived class to determine the type of= the >>>>>> encapsulated field. But that=92s not a complete description of the = **entire >>>>>> object** - especially not the additional meaning imbued by the >>>>>> additional parameters the derived type may add to the JOSE header. = =93typ=94 >>>>>> is there to provide the type of the entire object, including what yo= u=92re >>>>>> calling the wrapper parts.**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> -- Mike*= * >>>>>> ** >>>>>> >>>>>> ** ** >>>>>> >>>>>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>>>>> *Sent:* Thursday, May 30, 2013 7:58 AM >>>>>> >>>>>> *To:* Mike Jones >>>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt >>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Isn't that requirement met by "cty"? The only thing JOSE adds is a >>>>>> crypto wrapper around the real application content. If you're an >>>>>> application, you know a JOSE object is the thing you want because it >>>>>> contains the content you want -- it's a JWT because it contains JWT = claims. >>>>>> **** >>>>>> >>>>>> ** ** >>>>>> >>>>>> Inheritance is the wrong metaphor. This is encapsulation of >>>>>> application data:**** >>>>>> >>>>>> if (jws.valid && jws.cty =3D=3D "application/jwt_claims") {**** >>>>>> >>>>>> jwtClaims =3D jws.content;**** >>>>>> >>>>>> }**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> --Richard**** >>>>>> >>>>>> ** ** >>>>>> >>>>>> On Thu, May 30, 2013 at 10:43 AM, Mike Jones < >>>>>> Michael.Jones@microsoft.com> wrote:**** >>>>>> >>>>>> Thanks for sharing the S/MIME details. Although I was actually >>>>>> making the analogy to MIME =96 not S/MIME. Like many analogies, it= =92s >>>>>> imperfect, but I believe still illustrative.**** >>>>>> >>>>>> **** >>>>>> >>>>>> The reason that the analogy isn=92t perfect is that the JOSE data >>>>>> structures are used to build application-specific data structures th= at are >>>>>> legal JOSE data structures but also have additional properties =96 i= ncluding >>>>>> additional header fields with specific semantics. (When we agreed t= o >>>>>> ignore not-understood header fields we let that horse out of the bar= n.) >>>>>> For instance, Dick Hardt uses JWEs with issuer and audience fields i= n the >>>>>> headers, so they can be used by routing software.**** >>>>>> >>>>>> **** >>>>>> >>>>>> Think of JOSE as the base class and the application types built usin= g >>>>>> it as derived classes. JWT is a derived class. Dick=92s structures= are a >>>>>> derived class. These derived classes sometimes need names. That=92= s what >>>>>> =93typ=94 is for.**** >>>>>> >>>>>> **** >>>>>> >>>>>> -- Mike*= * >>>>>> ** >>>>>> >>>>>> **** >>>>>> >>>>>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>>>>> *Sent:* Thursday, May 30, 2013 7:34 AM**** >>>>>> >>>>>> >>>>>> *To:* Mike Jones >>>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt >>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>> >>>>>> **** >>>>>> >>>>>> You're mixing up "typ" and "cty". If you want to make the analogy t= o >>>>>> S/MIME, "cty" is the equivalent to Content-Type inside the protected= MIME >>>>>> body; "typ" is the content-type on the outer MIME header. Pasting i= n an >>>>>> example:**** >>>>>> >>>>>> **** >>>>>> >>>>>> -----BEGIN-----**** >>>>>> >>>>>> Content-Type: application/pkcs7-mime; smime-type=3Dsigned-data;**** >>>>>> >>>>>> name=3Dsmime.p7m**** >>>>>> >>>>>> Content-Transfer-Encoding: base64**** >>>>>> >>>>>> Content-Disposition: attachment; filename=3Dsmime.p7m**** >>>>>> >>>>>> **** >>>>>> >>>>>> 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7**** >>>>>> >>>>>> 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH**** >>>>>> >>>>>> HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh**** >>>>>> >>>>>> 6YT64V0GhIGfHfQbnj75**** >>>>>> >>>>>> -----END-----**** >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> The outer Content-Type, which is analogous to "typ", MUST be >>>>>> application/pkcs7-mime, with a parameter indicating the type of CMS = object. >>>>>> This is the same as requiring "typ" to be JWE or JWS. The inner >>>>>> Content-Type (ASN.1/base64 encoded in the example) can be anything, = just >>>>>> like "cty".**** >>>>>> >>>>>> **** >>>>>> >>>>>> --Richard**** >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> On Thu, May 30, 2013 at 12:53 AM, Mike Jones < >>>>>> Michael.Jones@microsoft.com> wrote:**** >>>>>> >>>>>> Requiring that the =93typ=94 value be only =93JWS=94 or =93JWE=94 wo= uld be >>>>>> analogous to the MIME spec requiring that the Content-Type: field be= only >>>>>> =93text/plain=94 or =93message/external-body=94. It would render it= useless. >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> -- Mike*= * >>>>>> ** >>>>>> >>>>>> **** >>>>>> >>>>>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On >>>>>> Behalf Of *Richard Barnes >>>>>> *Sent:* Wednesday, May 29, 2013 8:03 PM >>>>>> *To:* Mike Jones >>>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt**** >>>>>> >>>>>> >>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>> >>>>>> **** >>>>>> >>>>>> If this is the level of "type" you're referring to, I think we shoul= d >>>>>> drop it from the spec. It's an application-layer thing that the app= can >>>>>> add or not according to its wishes.**** >>>>>> >>>>>> **** >>>>>> >>>>>> I'm with Dick on this. I think we should either have a mandatory >>>>>> indicator of what type of JOSE object this, or nothing at all. If = the >>>>>> former, the allowable values are "JWE" and "JWS". The "+JSON" optio= ns are >>>>>> non-sensical -- the app needs to know what it's parsing before it ge= ts this >>>>>> header. While I have a preference for the former (for clarity), the= latter >>>>>> approach is also OK with me, since the MIME types are specific to JW= E/JWS. >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> Another approach here would be to address the JSON and compact forms >>>>>> separately. The JSON form has no need of "typ" at all, since the ty= pe of >>>>>> the object is completely clear from what fields are there, e.g., >>>>>> "recipients" vs. "signatures". For the compact form, we could do so= mething >>>>>> like James's "E."/"S." prefix idea, which you need because the >>>>>> dot-separated components have different meanings and no field names = to >>>>>> indicate this.**** >>>>>> >>>>>> **** >>>>>> >>>>>> --Richard**** >>>>>> >>>>>> **** >>>>>> >>>>>> On Wed, May 29, 2013 at 8:30 PM, Mike Jones < >>>>>> Michael.Jones@microsoft.com> wrote:**** >>>>>> >>>>>> A standard library is unlikely to know the meanings of all possible >>>>>> =93typ=94 values =96 and more to the point, *it doesn=92t have to*. = It=92s >>>>>> the application=92s job to determine that =93this blob is a JOSE obj= ect=94 and >>>>>> then pass it to a standard library, which will then ignore the =93ty= p=94 value. >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> A standard JOSE library won=92t know what =93typ=94: =93JWT=94 means= . It won=92t >>>>>> know what =93typ=94: =93BCGovToken=94 is, should the BC Government w= ant to declare >>>>>> that it=92s using a token with particular characteristics. It won= =92t know >>>>>> what =93typ=94: =93XMPP=94 is, should XMPP want to declare that it= =92s using a JOSE >>>>>> data structure with particular characteristics. Etc.**** >>>>>> >>>>>> **** >>>>>> >>>>>> All these values can be registered in the registry and used by >>>>>> applications that understand them. That=92s the application=92s job= =96 not the >>>>>> library=92s job. The =93typ=94 field is just there so that applicat= ions have a >>>>>> standard place to make any such declarations that they may need.**** >>>>>> >>>>>> **** >>>>>> >>>>>> -- >>>>>> Mike**** >>>>>> >>>>>> **** >>>>>> >>>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>>>>> *Sent:* Wednesday, May 29, 2013 5:18 PM >>>>>> *To:* Mike Jones >>>>>> *Cc:* Jim Schaad; jose@ietf.org**** >>>>>> >>>>>> >>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>> >>>>>> **** >>>>>> >>>>>> I'd prefer to be able to use standard libraries for creating and >>>>>> parsing tokens, and not specialized libraries dependent on the use c= ase. >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> I strongly think we either drop "typ" or make it required.**** >>>>>> >>>>>> **** >>>>>> >>>>>> On Wed, May 29, 2013 at 5:03 PM, Mike Jones < >>>>>> Michael.Jones@microsoft.com> wrote:**** >>>>>> >>>>>> It=92s fine for your application to specify that it=92s required for= your >>>>>> use case. Not applications need it, so they shouldn=92t be forced t= o pay the >>>>>> space penalty of an unnecessary field.**** >>>>>> >>>>>> **** >>>>>> >>>>>> -- >>>>>> Mike**** >>>>>> >>>>>> **** >>>>>> >>>>>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On >>>>>> Behalf Of *Dick Hardt >>>>>> *Sent:* Wednesday, May 29, 2013 4:56 PM**** >>>>>> >>>>>> >>>>>> *To:* Jim Schaad >>>>>> *Cc:* jose@ietf.org >>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>> >>>>>> **** >>>>>> >>>>>> I use it all the time and my code would barf if it was not there.***= * >>>>>> >>>>>> **** >>>>>> >>>>>> I think it should be required rather than be a hint if it is going o= t >>>>>> be there.**** >>>>>> >>>>>> **** >>>>>> >>>>>> On Wed, May 29, 2013 at 4:40 PM, Jim Schaad >>>>>> wrote:**** >>>>>> >>>>>> I think the values just changed**** >>>>>> >>>>>> **** >>>>>> >>>>>> However the way you are using it would be an argument to say that it >>>>>> should be a required field. Are you just using it as a hint if it e= xists >>>>>> and then looking at the rest of the fields if it is not present?**** >>>>>> >>>>>> **** >>>>>> >>>>>> Jim**** >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>>>>> *Sent:* Wednesday, May 29, 2013 3:49 PM >>>>>> *To:* Jim Schaad >>>>>> *Cc:* jose@ietf.org >>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>> >>>>>> **** >>>>>> >>>>>> Well, I have been using, but now realize the spec changed or I was >>>>>> confused.**** >>>>>> >>>>>> **** >>>>>> >>>>>> I had been setting "typ" to be either "JWE" or "JWS" depending on th= e >>>>>> type of token I was creating or parsing as it was easier than lookin= g at >>>>>> "alg"**** >>>>>> >>>>>> **** >>>>>> >>>>>> As currently defined, I don't see value in "typ".**** >>>>>> >>>>>> **** >>>>>> >>>>>> -- Dick**** >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> On Wed, May 29, 2013 at 3:02 PM, Jim Schaad >>>>>> wrote:**** >>>>>> >>>>>> In reading the documents, I am trying to understand the justificatio= n >>>>>> for having the =93typ=94 header parameter in the JOSE documents.**** >>>>>> >>>>>> **** >>>>>> >>>>>> The purpose of the field is to hold the type of the object. In the >>>>>> past, I believe that values which should now be placed in the cty fi= eld >>>>>> (such as =93JWT=94) were placed in this field as well. However the = parameter >>>>>> is optional and an implementation cannot rely on its being present. = This >>>>>> means that for all practical purposes all of the code to determine t= he >>>>>> value of the type field from the values of the alg and enc fields. = If the >>>>>> field was mandatory then this code would disappear at a fairly small= space >>>>>> cost and I can understand why the parameter would be present.**** >>>>>> >>>>>> **** >>>>>> >>>>>> Can anybody justify why this field should be present in the document >>>>>> =96 or should it just disappear?**** >>>>>> >>>>>> **** >>>>>> >>>>>> Jim**** >>>>>> >>>>>> **** >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>>> >>>>>> >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> -- >>>>>> -- Dick **** >>>>>> >>>>>> >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> -- >>>>>> -- Dick **** >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>>> >>>>>> >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> -- >>>>>> -- Dick **** >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>>> >>>>>> **** >>>>>> >>>>>> **** >>>>>> >>>>>> ** ** >>>>>> >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Nat Sakimura (=3Dnat) >>>>> Chairman, OpenID Foundation >>>>> http://nat.sakimura.org/ >>>>> @_nat_en >>>>> >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>> >>>>> >>>> >>> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e011615f20cb52a04de7171d6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
What I was thinking as an example was to have 'datetim= e' as a public header parameter to be used generally, and then differen= tiate between two cases of 'agreement' and 'timestamp'. It = is the same signing operation over the original (e.g., a MS word document),= but from an application point of view, it is a bit different. Former const= itute an agreement while the later does not. The type=3Dtimestamp just sign= ifies that the original document existed at the time indicated.=A0


2013/6/5 Rich= ard Barnes <rlb@ipv.sx>
I'm not sure I understand the use case here. =A0Let me= look at a couple of options, and hopefully one of them will be what you me= ant :) =A0

If it's just a signed timestamp you'r= e talking about, then that's adequately described by cty=3D"timest= amp", typ=3D"JWS".

If you want to sign something and add a timestamp in th= e header, then typ=3D"timestamp" isn't accurate according to = the current specification. =A0The type of the whole object would have to be= something like "timestamped-content". =A0And in that case, an ap= plication can easily recognized that it's timestamped content by lookin= g for the timestamp field in the header, so the "typ" isn't r= eally helpful.


Moving from the example to the general q= uestion:

I think we finally have some common under= standing on this list as to what Mike means by "typ" in the curre= nt document -- a label for the application-layer type of the overall object= . =A0Thanks to Mike for clarifying that in this discussion.

The question is whether this is a sufficiently useful t= hing to have in the core spec. =A0Obviously, applications have to know what= type of object they're dealing with when they get a JOSE object. =A0Th= at includes (1) what type of content is in the payload, and (2) what applic= ation-layer fields are required to be in the header. =A0(1) is covered by &= quot;cty". =A0So "typ" is only useful in the case where:
A. The application is storing application-layer data in the JOSE heade= r
B. The required application-layer fields can be different for d= ifferent objects
C. The required application-layer fields can be = different for different objects of the same content type
D. The required application-layer fields are not indicated by other ap= plication-layer context

Are there any known applic= ations that meet these criteria? =A0JWT does not, for several reasons.=A0
1. (!A) JWT does not store application-layer data in the JOSE header, = only in the claims in the body
2. (!C) A JWT object can indicate = with "cty" that it contains JWT claims or another JWT, either of = which makes it obvious that this is a JWT
3. (!D) In the OAuth context, the Token Type value indicates what type= of token is being presented, e.g., JWT

So there&#= 39;s not really any known use case for "typ" as currently specifi= ed. =A0On the other hand, Dick and James have pointed out that it can be us= eful to have "typ" indicate whether the object at hand is a JWE o= r JWS. =A0Which brings us back to:
-- Change the definition of "typ" so that it indicates the J= OSE-layer type (JWE/JWS)
-- Remove "typ" altogether







On Wed, Jun 5, 2013 at 8:53 AM, Nat = Sakimura <sakimura@gmail.com> wrote:
What about such as thi= s?=A0

cty: original
typ: timestamp


2013/6/5= Richard Barnes <rlb@ipv.sx>
It would be a good point, i= f it were true :) =A0In particular, this part: "[dropping 'typ'= ;]=A0is going to cause each and every application that uses JOSE to def= ine their own field"

So far, I've heard of exactly one application of JOSE th= at requires "typ" in the way it is currently specified, namely JW= T. =A0

On the other hand, Dick's applications = are apparently using it differently (and, IMO, properly) to distinguish JWE= /JWS. =A0Then there are all the applications out there that are OK using ap= plication context and "cty" to recognize what type of object they= have. =A0Apps using CMS have been doing this for ages.

So it's not at all clear to me that there's any= other application that would use "typ" besides JWT. =A0And it= 9;s not clear to me that JWT needs it.
<= div>
--Richard



=


On Fri, May 3= 1, 2013 at 5:45 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Nat makes a good point here= , I think.


On Thu, May 30, 2013 at 9:31 AM, Nat Sak= imura <sakimura@gmail.com> wrote:
From what I understand, bot= h typ and cty are something to be consumed by the application and not JOSE = processor. From the point of view of the JOSE processor, they should be ign= ored.=A0

We could drop both fields from JOSE specs, but that is going to cause each = and every application that uses JOSE to define their own field, which is a = waste. That is why we are defining them here.=A0

I would rather drop them than define JOSE processing semantics to thes= e fields.=A0


2013/5/31 Mike Jones <Michael.Jones@microso= ft.com>

No, =93cty=94 is used by = the derived class to determine the type of the encapsulated field.=A0 But t= hat=92s not a complete description of the *entire object* - especially not the additional meaning imbued by the additional parameter= s the derived type may add to the JOSE header.=A0 =93typ=94 is there to pro= vide the type of the entire object, including what you=92re calling the wra= pper parts.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7:58 AM


To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

Isn't that requirement met by "cty"? = =A0The only thing JOSE adds is a crypto wrapper around the real application= content. =A0If you're an application, you know a JOSE object is the th= ing you want because it contains the content you want -- it's a JWT because it contains JWT claims.

=A0

Inheritance is the wrong metaphor. =A0This is encaps= ulation of application data:

if (jws.valid && jws.cty =3D=3D "applic= ation/jwt_claims") {

=A0 =A0 jwtClaims =3D jws.content;

}

=A0

--Richard

=A0

On Thu, May 30, 2013 at 10:43 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Thanks for sharing the S/= MIME details.=A0 Although I was actually making the analogy to MIME =96 not S/MIME.=A0 Like many analogies, it=92s imperfect, but I believe still illu= strative.

=A0<= /p>

The reason that the analo= gy isn=92t perfect is that the JOSE data structures are used to build appli= cation-specific data structures that are legal JOSE data structures but also have addition= al properties =96 including additional header fields with specific semantic= s.=A0 (When we agreed to ignore not-understood header fields we let that ho= rse out of the barn.)=A0 For instance, Dick Hardt uses JWEs with issuer and audience fields in the headers, so th= ey can be used by routing software.

=A0<= /p>

Think of JOSE as the base= class and the application types built using it as derived classes.=A0 JWT is a derived class.=A0 Dick=92s structures are a derived class.=A0 These d= erived classes sometimes need names.=A0 That=92s what =93typ=94 is for.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7:34 AM


To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

You're mixing up "typ" and "cty&q= uot;. =A0If you want to make the analogy to S/MIME, "cty" is the = equivalent to Content-Type inside the protected MIME body; "typ" = is the content-type on the outer MIME header. =A0Pasting in an example:

=A0

-----BEGIN-----

Content-Type: application/pkcs7-mime; smime-type=3Ds= igned-data;

=A0 =A0 =A0name=3Dsmime.p7m

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=3Dsmime.p7= m

=A0

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4V= Qbnj7

77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUuj= hJhjH

HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHG= ghyHh

6YT64V0GhIGfHfQbnj75

-----END-----

=A0

The outer Content-Type, which is analogous to "= typ", MUST be application/pkcs7-mime, with a parameter indicating the = type of CMS object. =A0This is the same as requiring "typ" to be JWE or JWS. =A0The inner Content-Type (ASN.1/base64 encoded in the exam= ple) can be anything, just like "cty".

=A0

--Richard

=A0

=A0

=A0

=A0

On Thu, May 30, 2013 at 12:53 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Requiring that the =93typ= =94 value be only =93JWS=94 or =93JWE=94 would be analogous to the MIME spe= c requiring that the Content-Type: field be only =93text/plain=94 or =93message/extern= al-body=94.=A0 It would render it useless.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, May 29, 2013 8:03 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org; Dick Hardt


Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

If this is the level of "type" you're = referring to, I think we should drop it from the spec. =A0It's an appli= cation-layer thing that the app can add or not according to its wishes.<= /u>

=A0

I'm with Dick on this. =A0I think we should eith= er have a mandatory indicator of what type of JOSE object this, or nothing = at all. =A0 If the former, the allowable values are "JWE" and "JWS". =A0The "+JSON" options are non-sensical -- = the app needs to know what it's parsing before it gets this header. =A0= While I have a preference for the former (for clarity), the latter approach= is also OK with me, since the MIME types are specific to JWE/JWS.

=A0

Another approach here would be to address the JSON a= nd compact forms separately. =A0The JSON form has no need of "typ"= ; at all, since the type of the object is completely clear from what fields are there, e.g., "recipients" vs. "signatures&q= uot;. =A0For the compact form, we could do something like James's "= ;E."/"S." prefix idea, which you need because the dot-separa= ted components have different meanings and no field names to indicate this.=

=A0

--Richard

=A0

On Wed, May 29, 2013 at 8:30 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

A standard library is unl= ikely to know the meanings of all possible =93typ=94 values =96 and more to= the point, it doesn=92t have to.=A0 It=92s the application=92s job to d= etermine that =93this blob is a JOSE object=94 and then pass it to a standa= rd library, which will then ignore the =93typ=94 value.

=A0<= /p>

A standard JOSE library w= on=92t know what =93typ=94: =93JWT=94 means.=A0 It won=92t know what =93typ= =94: =93BCGovToken=94 is, should the BC Government want to declare that it=92s using a token wit= h particular characteristics.=A0 It won=92t know what =93typ=94: =93XMPP=94= is, should XMPP want to declare that it=92s using a JOSE data structure wi= th particular characteristics.=A0 Etc.

=A0<= /p>

All these values can be r= egistered in the registry and used by applications that understand them.=A0 That=92s the application=92s job =96 not the library=92s job.=A0 The =93ty= p=94 field is just there so that applications have a standard place to make= any such declarations that they may need.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Wednesday, May 29, 2013 5:18 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org


Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

I'd prefer to be able to use standard libraries = for creating and parsing tokens, and not specialized libraries dependent on= the use case.

=A0

I strongly think we either drop "typ" or m= ake it required.

=A0

On Wed, May 29, 2013 at 5:03 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

It=92s fine for your appl= ication to specify that it=92s required for your use case.=A0 Not applicati= ons need it, so they shouldn=92t be forced to pay the space penalty of an unne= cessary field.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Wednesday, May 29, 2013 4:56 PM


To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

I use it all the time and my code would barf if it w= as not there.

=A0

I think it should be required rather than be a hint = if it is going ot be there.

=A0

On Wed, May 29, 2013 at 4:40 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

I think the values just c= hanged

=A0<= /p>

However the way you are u= sing it would be an argument to say that it should be a required field.=A0 Are you just using it as a hint if it exists and then looking at the rest = of the fields if it is not present?

=A0<= /p>

Jim<= /p>

=A0<= /p>

=A0<= /p>

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Wednesday, May 29, 2013 3:49 PM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

Well, I have been using, but now realize the spec ch= anged or I was confused.

=A0

I had been setting "typ" to be either &quo= t;JWE" or "JWS" depending on the type of token I was creatin= g or parsing as it was easier than looking at "alg"=

=A0

As currently defined, I don't see value in "= ;typ".

=A0

-- Dick

=A0

=A0

On Wed, May 29, 2013 at 3:02 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

In reading the documents, I am trying to understand = the justification for having the =93typ=94 header parameter in the JOSE doc= uments.

=A0

The purpose of the field is to hold the type of the = object. =A0In the past, I believe that values which should now be placed in= the cty field (such as =93JWT=94) were placed in this field as well.=A0 However the parameter is optional and an implementation cannot= rely on its being present.=A0 This means that for all practical purposes a= ll of the code to determine the value of the type field from the values of = the alg and enc fields. =A0If the field was mandatory then this code would disappear at a fairly small space cost = and I can understand why the parameter would be present.

=A0

Can anybody justify why this field should be present= in the document =96 or should it just disappear?

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick



=A0

--
-- Dick


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0

=A0

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_= nat_en

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose






--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en




--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en
--089e011615f20cb52a04de7171d6-- From dick.hardt@gmail.com Wed Jun 5 17:36:06 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CC921F882A for ; Wed, 5 Jun 2013 17:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.296 X-Spam-Level: *** X-Spam-Status: No, score=3.296 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, TRACKER_ID=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRrTqRs7TzEz for ; Wed, 5 Jun 2013 17:36:03 -0700 (PDT) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 08C1C21F86D3 for ; Wed, 5 Jun 2013 17:36:02 -0700 (PDT) Received: by mail-bk0-f53.google.com with SMTP id e11so663693bkh.40 for ; Wed, 05 Jun 2013 17:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Yz+nXPlQYMs+flK+lew9qQYmXwWL/cTKbXyAGrXBYvs=; b=WLORkWR7HXKPPu7KjRQuYFeKtsn5h399+5sZM1cISXd8iixJzL7fUsqsZIB61F561A eVQqsCizCUKGFUfLU6WAhUNwbdB24S2NC35DkGilYbYAviuZcLW1JffyJi0g5k4z+Vcl D1aTR8waRZEuO7cGdcgBMk6/8RWsSB9QPHe+m0Vw86md90JaWbi6tCfSCvqbf+/6Nvh9 D4LJgRsJgRvTMlQuxpxV+97geP3h0WwacKpvSfo/XYxObPS5ZdVR7UUgY0NIPWy+z6b2 aNiKx7mqfKSTwJXMSbv7zsxlp1YdBMrLGKT+tG+K4gt11dXnoWBmTHUSw7UU+y6c/QVP /A8w== MIME-Version: 1.0 X-Received: by 10.204.108.4 with SMTP id d4mr10421211bkp.176.1370478961972; Wed, 05 Jun 2013 17:36:01 -0700 (PDT) Received: by 10.204.228.8 with HTTP; Wed, 5 Jun 2013 17:36:01 -0700 (PDT) In-Reply-To: References: <02b701ce5cb8$46ae77e0$d40b67a0$@augustcellars.com> <02f501ce5cc5$ec9a2200$c5ce6600$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943677C58C4@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C5C0A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C7399@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9B69@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9E95@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Wed, 5 Jun 2013 17:36:01 -0700 Message-ID: From: Dick Hardt To: Nat Sakimura Content-Type: multipart/alternative; boundary=089e0122ecfab39cac04de717f87 Cc: Richard Barnes , Mike Jones , Brian Campbell , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Should we delete the "typ" header field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 00:36:06 -0000 --089e0122ecfab39cac04de717f87 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Why would you need that in the header? Why not in the payload? On Wed, Jun 5, 2013 at 5:31 PM, Nat Sakimura wrote: > What I was thinking as an example was to have 'datetime' as a public > header parameter to be used generally, and then differentiate between two > cases of 'agreement' and 'timestamp'. It is the same signing operation ov= er > the original (e.g., a MS word document), but from an application point of > view, it is a bit different. Former constitute an agreement while the lat= er > does not. The type=3Dtimestamp just signifies that the original document > existed at the time indicated. > > > 2013/6/5 Richard Barnes > >> I'm not sure I understand the use case here. Let me look at a couple of >> options, and hopefully one of them will be what you meant :) >> >> If it's just a signed timestamp you're talking about, then that's >> adequately described by cty=3D"timestamp", typ=3D"JWS". >> >> If you want to sign something and add a timestamp in the header, then >> typ=3D"timestamp" isn't accurate according to the current specification.= The >> type of the whole object would have to be something like >> "timestamped-content". And in that case, an application can easily >> recognized that it's timestamped content by looking for the timestamp fi= eld >> in the header, so the "typ" isn't really helpful. >> >> >> Moving from the example to the general question: >> >> I think we finally have some common understanding on this list as to wha= t >> Mike means by "typ" in the current document -- a label for the >> application-layer type of the overall object. Thanks to Mike for >> clarifying that in this discussion. >> >> The question is whether this is a sufficiently useful thing to have in >> the core spec. Obviously, applications have to know what type of object >> they're dealing with when they get a JOSE object. That includes (1) wha= t >> type of content is in the payload, and (2) what application-layer fields >> are required to be in the header. (1) is covered by "cty". So "typ" is >> only useful in the case where: >> A. The application is storing application-layer data in the JOSE header >> B. The required application-layer fields can be different for different >> objects >> C. The required application-layer fields can be different for different >> objects of the same content type >> D. The required application-layer fields are not indicated by other >> application-layer context >> >> Are there any known applications that meet these criteria? JWT does not= , >> for several reasons. >> 1. (!A) JWT does not store application-layer data in the JOSE header, >> only in the claims in the body >> 2. (!C) A JWT object can indicate with "cty" that it contains JWT claims >> or another JWT, either of which makes it obvious that this is a JWT >> 3. (!D) In the OAuth context, the Token Type value indicates what type o= f >> token is being presented, e.g., JWT >> >> So there's not really any known use case for "typ" as currently >> specified. On the other hand, Dick and James have pointed out that it c= an >> be useful to have "typ" indicate whether the object at hand is a JWE or >> JWS. Which brings us back to: >> -- Change the definition of "typ" so that it indicates the JOSE-layer >> type (JWE/JWS) >> -- Remove "typ" altogether >> >> >> >> >> >> >> >> On Wed, Jun 5, 2013 at 8:53 AM, Nat Sakimura wrote: >> >>> What about such as this? >>> >>> cty: original >>> typ: timestamp >>> >>> >>> 2013/6/5 Richard Barnes >>> >>>> It would be a good point, if it were true :) In particular, this part= : >>>> "[dropping 'typ'] is going to cause each and every application that >>>> uses JOSE to define their own field" >>>> >>>> So far, I've heard of exactly one application of JOSE that requires >>>> "typ" in the way it is currently specified, namely JWT. >>>> >>>> On the other hand, Dick's applications are apparently using it >>>> differently (and, IMO, properly) to distinguish JWE/JWS. Then there a= re >>>> all the applications out there that are OK using application context a= nd >>>> "cty" to recognize what type of object they have. Apps using CMS have= been >>>> doing this for ages. >>>> >>>> So it's not at all clear to me that there's any other application that >>>> would use "typ" besides JWT. And it's not clear to me that JWT needs = it. >>>> >>>> --Richard >>>> >>>> >>>> >>>> >>>> >>>> On Fri, May 31, 2013 at 5:45 PM, Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>>> Nat makes a good point here, I think. >>>>> >>>>> >>>>> On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura wro= te: >>>>> >>>>>> From what I understand, both typ and cty are something to be consume= d >>>>>> by the application and not JOSE processor. From the point of view of= the >>>>>> JOSE processor, they should be ignored. >>>>>> >>>>>> We could drop both fields from JOSE specs, but that is going to caus= e >>>>>> each and every application that uses JOSE to define their own field,= which >>>>>> is a waste. That is why we are defining them here. >>>>>> >>>>>> I would rather drop them than define JOSE processing semantics to >>>>>> these fields. >>>>>> >>>>>> >>>>>> 2013/5/31 Mike Jones >>>>>> >>>>>>> No, =93cty=94 is used by the derived class to determine the type o= f >>>>>>> the encapsulated field. But that=92s not a complete description of= the * >>>>>>> *entire object** - especially not the additional meaning imbued by >>>>>>> the additional parameters the derived type may add to the JOSE head= er. >>>>>>> =93typ=94 is there to provide the type of the entire object, includ= ing what >>>>>>> you=92re calling the wrapper parts.**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> -- Mike= * >>>>>>> *** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>>>>>> *Sent:* Thursday, May 30, 2013 7:58 AM >>>>>>> >>>>>>> *To:* Mike Jones >>>>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt >>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> Isn't that requirement met by "cty"? The only thing JOSE adds is a >>>>>>> crypto wrapper around the real application content. If you're an >>>>>>> application, you know a JOSE object is the thing you want because i= t >>>>>>> contains the content you want -- it's a JWT because it contains JWT= claims. >>>>>>> **** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> Inheritance is the wrong metaphor. This is encapsulation of >>>>>>> application data:**** >>>>>>> >>>>>>> if (jws.valid && jws.cty =3D=3D "application/jwt_claims") {**** >>>>>>> >>>>>>> jwtClaims =3D jws.content;**** >>>>>>> >>>>>>> }**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> --Richard**** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> On Thu, May 30, 2013 at 10:43 AM, Mike Jones < >>>>>>> Michael.Jones@microsoft.com> wrote:**** >>>>>>> >>>>>>> Thanks for sharing the S/MIME details. Although I was actually >>>>>>> making the analogy to MIME =96 not S/MIME. Like many analogies, it= =92s >>>>>>> imperfect, but I believe still illustrative.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> The reason that the analogy isn=92t perfect is that the JOSE data >>>>>>> structures are used to build application-specific data structures t= hat are >>>>>>> legal JOSE data structures but also have additional properties =96 = including >>>>>>> additional header fields with specific semantics. (When we agreed = to >>>>>>> ignore not-understood header fields we let that horse out of the ba= rn.) >>>>>>> For instance, Dick Hardt uses JWEs with issuer and audience fields = in the >>>>>>> headers, so they can be used by routing software.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> Think of JOSE as the base class and the application types built >>>>>>> using it as derived classes. JWT is a derived class. Dick=92s str= uctures >>>>>>> are a derived class. These derived classes sometimes need names. = That=92s >>>>>>> what =93typ=94 is for.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> -- Mike= * >>>>>>> *** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>>>>>> *Sent:* Thursday, May 30, 2013 7:34 AM**** >>>>>>> >>>>>>> >>>>>>> *To:* Mike Jones >>>>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt >>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> You're mixing up "typ" and "cty". If you want to make the analogy >>>>>>> to S/MIME, "cty" is the equivalent to Content-Type inside the prote= cted >>>>>>> MIME body; "typ" is the content-type on the outer MIME header. Pas= ting in >>>>>>> an example:**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> -----BEGIN-----**** >>>>>>> >>>>>>> Content-Type: application/pkcs7-mime; smime-type=3Dsigned-data;**** >>>>>>> >>>>>>> name=3Dsmime.p7m**** >>>>>>> >>>>>>> Content-Transfer-Encoding: base64**** >>>>>>> >>>>>>> Content-Disposition: attachment; filename=3Dsmime.p7m**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7**** >>>>>>> >>>>>>> 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH**** >>>>>>> >>>>>>> HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh**** >>>>>>> >>>>>>> 6YT64V0GhIGfHfQbnj75**** >>>>>>> >>>>>>> -----END-----**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> The outer Content-Type, which is analogous to "typ", MUST be >>>>>>> application/pkcs7-mime, with a parameter indicating the type of CMS= object. >>>>>>> This is the same as requiring "typ" to be JWE or JWS. The inner >>>>>>> Content-Type (ASN.1/base64 encoded in the example) can be anything,= just >>>>>>> like "cty".**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> --Richard**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> On Thu, May 30, 2013 at 12:53 AM, Mike Jones < >>>>>>> Michael.Jones@microsoft.com> wrote:**** >>>>>>> >>>>>>> Requiring that the =93typ=94 value be only =93JWS=94 or =93JWE=94 w= ould be >>>>>>> analogous to the MIME spec requiring that the Content-Type: field b= e only >>>>>>> =93text/plain=94 or =93message/external-body=94. It would render i= t useless. >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> -- Mike= * >>>>>>> *** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On >>>>>>> Behalf Of *Richard Barnes >>>>>>> *Sent:* Wednesday, May 29, 2013 8:03 PM >>>>>>> *To:* Mike Jones >>>>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt**** >>>>>>> >>>>>>> >>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> If this is the level of "type" you're referring to, I think we >>>>>>> should drop it from the spec. It's an application-layer thing that= the app >>>>>>> can add or not according to its wishes.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> I'm with Dick on this. I think we should either have a mandatory >>>>>>> indicator of what type of JOSE object this, or nothing at all. If= the >>>>>>> former, the allowable values are "JWE" and "JWS". The "+JSON" opti= ons are >>>>>>> non-sensical -- the app needs to know what it's parsing before it g= ets this >>>>>>> header. While I have a preference for the former (for clarity), th= e latter >>>>>>> approach is also OK with me, since the MIME types are specific to J= WE/JWS. >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> Another approach here would be to address the JSON and compact form= s >>>>>>> separately. The JSON form has no need of "typ" at all, since the t= ype of >>>>>>> the object is completely clear from what fields are there, e.g., >>>>>>> "recipients" vs. "signatures". For the compact form, we could do s= omething >>>>>>> like James's "E."/"S." prefix idea, which you need because the >>>>>>> dot-separated components have different meanings and no field names= to >>>>>>> indicate this.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> --Richard**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> On Wed, May 29, 2013 at 8:30 PM, Mike Jones < >>>>>>> Michael.Jones@microsoft.com> wrote:**** >>>>>>> >>>>>>> A standard library is unlikely to know the meanings of all possible >>>>>>> =93typ=94 values =96 and more to the point, *it doesn=92t have to*.= It=92s >>>>>>> the application=92s job to determine that =93this blob is a JOSE ob= ject=94 and >>>>>>> then pass it to a standard library, which will then ignore the =93t= yp=94 value. >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> A standard JOSE library won=92t know what =93typ=94: =93JWT=94 mean= s. It >>>>>>> won=92t know what =93typ=94: =93BCGovToken=94 is, should the BC Gov= ernment want to >>>>>>> declare that it=92s using a token with particular characteristics. = It won=92t >>>>>>> know what =93typ=94: =93XMPP=94 is, should XMPP want to declare tha= t it=92s using a >>>>>>> JOSE data structure with particular characteristics. Etc.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> All these values can be registered in the registry and used by >>>>>>> applications that understand them. That=92s the application=92s jo= b =96 not the >>>>>>> library=92s job. The =93typ=94 field is just there so that applica= tions have a >>>>>>> standard place to make any such declarations that they may need.***= * >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> -- >>>>>>> Mike**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>>>>>> *Sent:* Wednesday, May 29, 2013 5:18 PM >>>>>>> *To:* Mike Jones >>>>>>> *Cc:* Jim Schaad; jose@ietf.org**** >>>>>>> >>>>>>> >>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> I'd prefer to be able to use standard libraries for creating and >>>>>>> parsing tokens, and not specialized libraries dependent on the use = case. >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> I strongly think we either drop "typ" or make it required.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> On Wed, May 29, 2013 at 5:03 PM, Mike Jones < >>>>>>> Michael.Jones@microsoft.com> wrote:**** >>>>>>> >>>>>>> It=92s fine for your application to specify that it=92s required fo= r >>>>>>> your use case. Not applications need it, so they shouldn=92t be fo= rced to >>>>>>> pay the space penalty of an unnecessary field.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> -- >>>>>>> Mike**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On >>>>>>> Behalf Of *Dick Hardt >>>>>>> *Sent:* Wednesday, May 29, 2013 4:56 PM**** >>>>>>> >>>>>>> >>>>>>> *To:* Jim Schaad >>>>>>> *Cc:* jose@ietf.org >>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> I use it all the time and my code would barf if it was not there.**= * >>>>>>> * >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> I think it should be required rather than be a hint if it is going >>>>>>> ot be there.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> On Wed, May 29, 2013 at 4:40 PM, Jim Schaad >>>>>>> wrote:**** >>>>>>> >>>>>>> I think the values just changed**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> However the way you are using it would be an argument to say that i= t >>>>>>> should be a required field. Are you just using it as a hint if it = exists >>>>>>> and then looking at the rest of the fields if it is not present?***= * >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> Jim**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>>>>>> *Sent:* Wednesday, May 29, 2013 3:49 PM >>>>>>> *To:* Jim Schaad >>>>>>> *Cc:* jose@ietf.org >>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> Well, I have been using, but now realize the spec changed or I was >>>>>>> confused.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> I had been setting "typ" to be either "JWE" or "JWS" depending on >>>>>>> the type of token I was creating or parsing as it was easier than l= ooking >>>>>>> at "alg"**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> As currently defined, I don't see value in "typ".**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> -- Dick**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> On Wed, May 29, 2013 at 3:02 PM, Jim Schaad >>>>>>> wrote:**** >>>>>>> >>>>>>> In reading the documents, I am trying to understand the >>>>>>> justification for having the =93typ=94 header parameter in the JOSE= documents. >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> The purpose of the field is to hold the type of the object. In the >>>>>>> past, I believe that values which should now be placed in the cty f= ield >>>>>>> (such as =93JWT=94) were placed in this field as well. However the= parameter >>>>>>> is optional and an implementation cannot rely on its being present.= This >>>>>>> means that for all practical purposes all of the code to determine = the >>>>>>> value of the type field from the values of the alg and enc fields. = If the >>>>>>> field was mandatory then this code would disappear at a fairly smal= l space >>>>>>> cost and I can understand why the parameter would be present.**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> Can anybody justify why this field should be present in the documen= t >>>>>>> =96 or should it just disappear?**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> Jim**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>>>> >>>>>>> >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> -- >>>>>>> -- Dick **** >>>>>>> >>>>>>> >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> -- >>>>>>> -- Dick **** >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>>>> >>>>>>> >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> -- >>>>>>> -- Dick **** >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> **** >>>>>>> >>>>>>> ** ** >>>>>>> >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=3Dnat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> Nat Sakimura (=3Dnat) >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en >>> >> >> > > > -- > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > --=20 -- Dick --089e0122ecfab39cac04de717f87 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Why would you need that in the header? Why not in the payl= oad?


On = Wed, Jun 5, 2013 at 5:31 PM, Nat Sakimura <sakimura@gmail.com> wrote:
What I was thinking as an e= xample was to have 'datetime' as a public header parameter to be us= ed generally, and then differentiate between two cases of 'agreement= 9; and 'timestamp'. It is the same signing operation over the origi= nal (e.g., a MS word document), but from an application point of view, it i= s a bit different. Former constitute an agreement while the later does not.= The type=3Dtimestamp just signifies that the original document existed at = the time indicated.=A0


2013/6/5 Rich= ard Barnes <rlb@ipv.sx>
I'm not sure I understand the use case here. =A0Let me= look at a couple of options, and hopefully one of them will be what you me= ant :) =A0

If it's just a signed timestamp you'r= e talking about, then that's adequately described by cty=3D"timest= amp", typ=3D"JWS".

If you want to sign something and add a timestamp in th= e header, then typ=3D"timestamp" isn't accurate according to = the current specification. =A0The type of the whole object would have to be= something like "timestamped-content". =A0And in that case, an ap= plication can easily recognized that it's timestamped content by lookin= g for the timestamp field in the header, so the "typ" isn't r= eally helpful.


Moving from the example to the general q= uestion:

I think we finally have some common under= standing on this list as to what Mike means by "typ" in the curre= nt document -- a label for the application-layer type of the overall object= . =A0Thanks to Mike for clarifying that in this discussion.

The question is whether this is a sufficiently useful t= hing to have in the core spec. =A0Obviously, applications have to know what= type of object they're dealing with when they get a JOSE object. =A0Th= at includes (1) what type of content is in the payload, and (2) what applic= ation-layer fields are required to be in the header. =A0(1) is covered by &= quot;cty". =A0So "typ" is only useful in the case where:
A. The application is storing application-layer data in the JOSE heade= r
B. The required application-layer fields can be different for d= ifferent objects
C. The required application-layer fields can be = different for different objects of the same content type
D. The required application-layer fields are not indicated by other ap= plication-layer context

Are there any known applic= ations that meet these criteria? =A0JWT does not, for several reasons.=A0
1. (!A) JWT does not store application-layer data in the JOSE header, = only in the claims in the body
2. (!C) A JWT object can indicate = with "cty" that it contains JWT claims or another JWT, either of = which makes it obvious that this is a JWT
3. (!D) In the OAuth context, the Token Type value indicates what type= of token is being presented, e.g., JWT

So there&#= 39;s not really any known use case for "typ" as currently specifi= ed. =A0On the other hand, Dick and James have pointed out that it can be us= eful to have "typ" indicate whether the object at hand is a JWE o= r JWS. =A0Which brings us back to:
-- Change the definition of "typ" so that it indicates the J= OSE-layer type (JWE/JWS)
-- Remove "typ" altogether







On Wed, Jun 5, 2013 at 8:53 AM, Nat Sakimura <= ;sakimura@gmail.com= > wrote:
What about such as thi= s?=A0

cty: original
typ: timestamp


2013/6/5= Richard Barnes <rlb@ipv.sx>
It would be a good point, i= f it were true :) =A0In particular, this part: "[dropping 'typ'= ;]=A0is going to cause each and every application that uses JOSE to def= ine their own field"

So far, I've heard of exactly one application of JOSE th= at requires "typ" in the way it is currently specified, namely JW= T. =A0

On the other hand, Dick's applications = are apparently using it differently (and, IMO, properly) to distinguish JWE= /JWS. =A0Then there are all the applications out there that are OK using ap= plication context and "cty" to recognize what type of object they= have. =A0Apps using CMS have been doing this for ages.

So it's not at all clear to me that there's any= other application that would use "typ" besides JWT. =A0And it= 9;s not clear to me that JWT needs it.
<= div>
--Richard



=


On Fri, May 3= 1, 2013 at 5:45 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Nat makes a good point here= , I think.


On Thu, May 30, 2013 at 9:31 AM, Nat Sak= imura <sakimura@gmail.com> wrote:
From what I understand, bot= h typ and cty are something to be consumed by the application and not JOSE = processor. From the point of view of the JOSE processor, they should be ign= ored.=A0

We could drop both fields from JOSE specs, but that is going to cause each = and every application that uses JOSE to define their own field, which is a = waste. That is why we are defining them here.=A0

I would rather drop them than define JOSE processing semantics to thes= e fields.=A0


2013/5/31 Mike Jones <Michael.Jones@microso= ft.com>

No, =93cty=94 is used by = the derived class to determine the type of the encapsulated field.=A0 But t= hat=92s not a complete description of the *entire object* - especially not the additional meaning imbued by the additional parameter= s the derived type may add to the JOSE header.=A0 =93typ=94 is there to pro= vide the type of the entire object, including what you=92re calling the wra= pper parts.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7:58 AM


To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

Isn't that requirement met by "cty"? = =A0The only thing JOSE adds is a crypto wrapper around the real application= content. =A0If you're an application, you know a JOSE object is the th= ing you want because it contains the content you want -- it's a JWT because it contains JWT claims.

=A0

Inheritance is the wrong metaphor. =A0This is encaps= ulation of application data:

if (jws.valid && jws.cty =3D=3D "applic= ation/jwt_claims") {

=A0 =A0 jwtClaims =3D jws.content;

}

=A0

--Richard

=A0

On Thu, May 30, 2013 at 10:43 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Thanks for sharing the S/= MIME details.=A0 Although I was actually making the analogy to MIME =96 not S/MIME.=A0 Like many analogies, it=92s imperfect, but I believe still illu= strative.

=A0<= /p>

The reason that the analo= gy isn=92t perfect is that the JOSE data structures are used to build appli= cation-specific data structures that are legal JOSE data structures but also have addition= al properties =96 including additional header fields with specific semantic= s.=A0 (When we agreed to ignore not-understood header fields we let that ho= rse out of the barn.)=A0 For instance, Dick Hardt uses JWEs with issuer and audience fields in the headers, so th= ey can be used by routing software.

=A0<= /p>

Think of JOSE as the base= class and the application types built using it as derived classes.=A0 JWT is a derived class.=A0 Dick=92s structures are a derived class.=A0 These d= erived classes sometimes need names.=A0 That=92s what =93typ=94 is for.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7:34 AM


To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

You're mixing up "typ" and "cty&q= uot;. =A0If you want to make the analogy to S/MIME, "cty" is the = equivalent to Content-Type inside the protected MIME body; "typ" = is the content-type on the outer MIME header. =A0Pasting in an example:

=A0

-----BEGIN-----

Content-Type: application/pkcs7-mime; smime-type=3Ds= igned-data;

=A0 =A0 =A0name=3Dsmime.p7m

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=3Dsmime.p7= m

=A0

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4V= Qbnj7

77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUuj= hJhjH

HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHG= ghyHh

6YT64V0GhIGfHfQbnj75

-----END-----

=A0

The outer Content-Type, which is analogous to "= typ", MUST be application/pkcs7-mime, with a parameter indicating the = type of CMS object. =A0This is the same as requiring "typ" to be JWE or JWS. =A0The inner Content-Type (ASN.1/base64 encoded in the exam= ple) can be anything, just like "cty".

=A0

--Richard

=A0

=A0

=A0

=A0

On Thu, May 30, 2013 at 12:53 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Requiring that the =93typ= =94 value be only =93JWS=94 or =93JWE=94 would be analogous to the MIME spe= c requiring that the Content-Type: field be only =93text/plain=94 or =93message/extern= al-body=94.=A0 It would render it useless.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, May 29, 2013 8:03 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org; Dick Hardt


Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

If this is the level of "type" you're = referring to, I think we should drop it from the spec. =A0It's an appli= cation-layer thing that the app can add or not according to its wishes.<= /u>

=A0

I'm with Dick on this. =A0I think we should eith= er have a mandatory indicator of what type of JOSE object this, or nothing = at all. =A0 If the former, the allowable values are "JWE" and "JWS". =A0The "+JSON" options are non-sensical -- = the app needs to know what it's parsing before it gets this header. =A0= While I have a preference for the former (for clarity), the latter approach= is also OK with me, since the MIME types are specific to JWE/JWS.

=A0

Another approach here would be to address the JSON a= nd compact forms separately. =A0The JSON form has no need of "typ"= ; at all, since the type of the object is completely clear from what fields are there, e.g., "recipients" vs. "signatures&q= uot;. =A0For the compact form, we could do something like James's "= ;E."/"S." prefix idea, which you need because the dot-separa= ted components have different meanings and no field names to indicate this.=

=A0

--Richard

=A0

On Wed, May 29, 2013 at 8:30 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

A standard library is unl= ikely to know the meanings of all possible =93typ=94 values =96 and more to= the point, it doesn=92t have to.=A0 It=92s the application=92s job to d= etermine that =93this blob is a JOSE object=94 and then pass it to a standa= rd library, which will then ignore the =93typ=94 value.

=A0<= /p>

A standard JOSE library w= on=92t know what =93typ=94: =93JWT=94 means.=A0 It won=92t know what =93typ= =94: =93BCGovToken=94 is, should the BC Government want to declare that it=92s using a token wit= h particular characteristics.=A0 It won=92t know what =93typ=94: =93XMPP=94= is, should XMPP want to declare that it=92s using a JOSE data structure wi= th particular characteristics.=A0 Etc.

=A0<= /p>

All these values can be r= egistered in the registry and used by applications that understand them.=A0 That=92s the application=92s job =96 not the library=92s job.=A0 The =93ty= p=94 field is just there so that applications have a standard place to make= any such declarations that they may need.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Wednesday, May 29, 2013 5:18 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org


Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

I'd prefer to be able to use standard libraries = for creating and parsing tokens, and not specialized libraries dependent on= the use case.

=A0

I strongly think we either drop "typ" or m= ake it required.

=A0

On Wed, May 29, 2013 at 5:03 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

It=92s fine for your appl= ication to specify that it=92s required for your use case.=A0 Not applicati= ons need it, so they shouldn=92t be forced to pay the space penalty of an unne= cessary field.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Wednesday, May 29, 2013 4:56 PM


To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

I use it all the time and my code would barf if it w= as not there.

=A0

I think it should be required rather than be a hint = if it is going ot be there.

=A0

On Wed, May 29, 2013 at 4:40 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

I think the values just c= hanged

=A0<= /p>

However the way you are u= sing it would be an argument to say that it should be a required field.=A0 Are you just using it as a hint if it exists and then looking at the rest = of the fields if it is not present?

=A0<= /p>

Jim<= /p>

=A0<= /p>

=A0<= /p>

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Wednesday, May 29, 2013 3:49 PM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

Well, I have been using, but now realize the spec ch= anged or I was confused.

=A0

I had been setting "typ" to be either &quo= t;JWE" or "JWS" depending on the type of token I was creatin= g or parsing as it was easier than looking at "alg"=

=A0

As currently defined, I don't see value in "= ;typ".

=A0

-- Dick

=A0

=A0

On Wed, May 29, 2013 at 3:02 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

In reading the documents, I am trying to understand = the justification for having the =93typ=94 header parameter in the JOSE doc= uments.

=A0

The purpose of the field is to hold the type of the = object. =A0In the past, I believe that values which should now be placed in= the cty field (such as =93JWT=94) were placed in this field as well.=A0 However the parameter is optional and an implementation cannot= rely on its being present.=A0 This means that for all practical purposes a= ll of the code to determine the value of the type field from the values of = the alg and enc fields. =A0If the field was mandatory then this code would disappear at a fairly small space cost = and I can understand why the parameter would be present.

=A0

Can anybody justify why this field should be present= in the document =96 or should it just disappear?

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick



=A0

--
-- Dick


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0

=A0

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_= nat_en

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose






--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en




--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en



--
= -- Dick --089e0122ecfab39cac04de717f87-- From sakimura@gmail.com Wed Jun 5 18:03:59 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C1121F944C for ; Wed, 5 Jun 2013 18:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.296 X-Spam-Level: *** X-Spam-Status: No, score=3.296 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, TRACKER_ID=2.696] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDG7vNgGwAcb for ; Wed, 5 Jun 2013 18:03:57 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DF38B21F9425 for ; Wed, 5 Jun 2013 18:03:56 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id hu16so101976qab.8 for ; Wed, 05 Jun 2013 18:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XiGpHmur8t4ddeQr7KNqKR6p8uezUIL9+gqRwwDD7WI=; b=qZDckMxQkHErHZYPSsEJ6WhmkxF7EDtT391YzDu+x8wayaXGt0l71X0ut1cGd5olx6 w3Sd1te05gABQ/s26soBFKPdDa+UidHlR3q4NB9KgRSi2pEwuwvjy21+2Px4rGIRe7il EI7rFLHg6bFQjGfdsKrghIruYuZB2UXEiFabenjZ08RH1H3aKLN1IAt/mxRjwwg4h1tN LE4mytldgRu2E5/Yx1ntjQzG2cClViZcJqi2b3yeWByIvnI7sG7QEVLxkEecQyq8QYp9 mXi+dFKW8UykIS53FgRtryRMJUug9plChgbG1MMt10fTsl87ip+31EVMWoKCMPOsHcPf IcHw== MIME-Version: 1.0 X-Received: by 10.49.101.74 with SMTP id fe10mr6127853qeb.11.1370480636245; Wed, 05 Jun 2013 18:03:56 -0700 (PDT) Received: by 10.49.95.230 with HTTP; Wed, 5 Jun 2013 18:03:56 -0700 (PDT) In-Reply-To: References: <02b701ce5cb8$46ae77e0$d40b67a0$@augustcellars.com> <02f501ce5cc5$ec9a2200$c5ce6600$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943677C58C4@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C5C0A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C7399@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9B69@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9E95@TK5EX14MBXC285.redmond.corp.microsoft.com> Date: Thu, 6 Jun 2013 10:03:56 +0900 Message-ID: From: Nat Sakimura To: Dick Hardt Content-Type: multipart/alternative; boundary=001a11c2c6ce7f04f204de71e38e Cc: Richard Barnes , Mike Jones , Brian Campbell , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Should we delete the "typ" header field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 01:03:59 -0000 --001a11c2c6ce7f04f204de71e38e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It is giving the meaning to the signature - metadata about the signature, so I thought header would be more appropriate, besides, the payload is binary and I can avoid double base64 encoding that way. 2013/6/6 Dick Hardt > Why would you need that in the header? Why not in the payload? > > > On Wed, Jun 5, 2013 at 5:31 PM, Nat Sakimura wrote: > >> What I was thinking as an example was to have 'datetime' as a public >> header parameter to be used generally, and then differentiate between tw= o >> cases of 'agreement' and 'timestamp'. It is the same signing operation o= ver >> the original (e.g., a MS word document), but from an application point o= f >> view, it is a bit different. Former constitute an agreement while the la= ter >> does not. The type=3Dtimestamp just signifies that the original document >> existed at the time indicated. >> >> >> 2013/6/5 Richard Barnes >> >>> I'm not sure I understand the use case here. Let me look at a couple o= f >>> options, and hopefully one of them will be what you meant :) >>> >>> If it's just a signed timestamp you're talking about, then that's >>> adequately described by cty=3D"timestamp", typ=3D"JWS". >>> >>> If you want to sign something and add a timestamp in the header, then >>> typ=3D"timestamp" isn't accurate according to the current specification= . The >>> type of the whole object would have to be something like >>> "timestamped-content". And in that case, an application can easily >>> recognized that it's timestamped content by looking for the timestamp f= ield >>> in the header, so the "typ" isn't really helpful. >>> >>> >>> Moving from the example to the general question: >>> >>> I think we finally have some common understanding on this list as to >>> what Mike means by "typ" in the current document -- a label for the >>> application-layer type of the overall object. Thanks to Mike for >>> clarifying that in this discussion. >>> >>> The question is whether this is a sufficiently useful thing to have in >>> the core spec. Obviously, applications have to know what type of objec= t >>> they're dealing with when they get a JOSE object. That includes (1) wh= at >>> type of content is in the payload, and (2) what application-layer field= s >>> are required to be in the header. (1) is covered by "cty". So "typ" i= s >>> only useful in the case where: >>> A. The application is storing application-layer data in the JOSE header >>> B. The required application-layer fields can be different for different >>> objects >>> C. The required application-layer fields can be different for different >>> objects of the same content type >>> D. The required application-layer fields are not indicated by other >>> application-layer context >>> >>> Are there any known applications that meet these criteria? JWT does >>> not, for several reasons. >>> 1. (!A) JWT does not store application-layer data in the JOSE header, >>> only in the claims in the body >>> 2. (!C) A JWT object can indicate with "cty" that it contains JWT claim= s >>> or another JWT, either of which makes it obvious that this is a JWT >>> 3. (!D) In the OAuth context, the Token Type value indicates what type >>> of token is being presented, e.g., JWT >>> >>> So there's not really any known use case for "typ" as currently >>> specified. On the other hand, Dick and James have pointed out that it = can >>> be useful to have "typ" indicate whether the object at hand is a JWE or >>> JWS. Which brings us back to: >>> -- Change the definition of "typ" so that it indicates the JOSE-layer >>> type (JWE/JWS) >>> -- Remove "typ" altogether >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Jun 5, 2013 at 8:53 AM, Nat Sakimura wrote= : >>> >>>> What about such as this? >>>> >>>> cty: original >>>> typ: timestamp >>>> >>>> >>>> 2013/6/5 Richard Barnes >>>> >>>>> It would be a good point, if it were true :) In particular, this >>>>> part: "[dropping 'typ'] is going to cause each and every application >>>>> that uses JOSE to define their own field" >>>>> >>>>> So far, I've heard of exactly one application of JOSE that requires >>>>> "typ" in the way it is currently specified, namely JWT. >>>>> >>>>> On the other hand, Dick's applications are apparently using it >>>>> differently (and, IMO, properly) to distinguish JWE/JWS. Then there = are >>>>> all the applications out there that are OK using application context = and >>>>> "cty" to recognize what type of object they have. Apps using CMS hav= e been >>>>> doing this for ages. >>>>> >>>>> So it's not at all clear to me that there's any other application tha= t >>>>> would use "typ" besides JWT. And it's not clear to me that JWT needs= it. >>>>> >>>>> --Richard >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, May 31, 2013 at 5:45 PM, Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote: >>>>> >>>>>> Nat makes a good point here, I think. >>>>>> >>>>>> >>>>>> On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura wr= ote: >>>>>> >>>>>>> From what I understand, both typ and cty are something to be >>>>>>> consumed by the application and not JOSE processor. From the point = of view >>>>>>> of the JOSE processor, they should be ignored. >>>>>>> >>>>>>> We could drop both fields from JOSE specs, but that is going to >>>>>>> cause each and every application that uses JOSE to define their own= field, >>>>>>> which is a waste. That is why we are defining them here. >>>>>>> >>>>>>> I would rather drop them than define JOSE processing semantics to >>>>>>> these fields. >>>>>>> >>>>>>> >>>>>>> 2013/5/31 Mike Jones >>>>>>> >>>>>>>> No, =93cty=94 is used by the derived class to determine the type = of >>>>>>>> the encapsulated field. But that=92s not a complete description o= f the * >>>>>>>> *entire object** - especially not the additional meaning imbued by >>>>>>>> the additional parameters the derived type may add to the JOSE hea= der. >>>>>>>> =93typ=94 is there to provide the type of the entire object, inclu= ding what >>>>>>>> you=92re calling the wrapper parts.**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> -- Mik= e >>>>>>>> **** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>>>>>>> *Sent:* Thursday, May 30, 2013 7:58 AM >>>>>>>> >>>>>>>> *To:* Mike Jones >>>>>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt >>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> Isn't that requirement met by "cty"? The only thing JOSE adds is = a >>>>>>>> crypto wrapper around the real application content. If you're an >>>>>>>> application, you know a JOSE object is the thing you want because = it >>>>>>>> contains the content you want -- it's a JWT because it contains JW= T claims. >>>>>>>> **** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> Inheritance is the wrong metaphor. This is encapsulation of >>>>>>>> application data:**** >>>>>>>> >>>>>>>> if (jws.valid && jws.cty =3D=3D "application/jwt_claims") {**** >>>>>>>> >>>>>>>> jwtClaims =3D jws.content;**** >>>>>>>> >>>>>>>> }**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> --Richard**** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> On Thu, May 30, 2013 at 10:43 AM, Mike Jones < >>>>>>>> Michael.Jones@microsoft.com> wrote:**** >>>>>>>> >>>>>>>> Thanks for sharing the S/MIME details. Although I was actually >>>>>>>> making the analogy to MIME =96 not S/MIME. Like many analogies, i= t=92s >>>>>>>> imperfect, but I believe still illustrative.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> The reason that the analogy isn=92t perfect is that the JOSE data >>>>>>>> structures are used to build application-specific data structures = that are >>>>>>>> legal JOSE data structures but also have additional properties =96= including >>>>>>>> additional header fields with specific semantics. (When we agreed= to >>>>>>>> ignore not-understood header fields we let that horse out of the b= arn.) >>>>>>>> For instance, Dick Hardt uses JWEs with issuer and audience fields= in the >>>>>>>> headers, so they can be used by routing software.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> Think of JOSE as the base class and the application types built >>>>>>>> using it as derived classes. JWT is a derived class. Dick=92s st= ructures >>>>>>>> are a derived class. These derived classes sometimes need names. = That=92s >>>>>>>> what =93typ=94 is for.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> -- Mik= e >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>>>>>>> *Sent:* Thursday, May 30, 2013 7:34 AM**** >>>>>>>> >>>>>>>> >>>>>>>> *To:* Mike Jones >>>>>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt >>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> You're mixing up "typ" and "cty". If you want to make the analogy >>>>>>>> to S/MIME, "cty" is the equivalent to Content-Type inside the prot= ected >>>>>>>> MIME body; "typ" is the content-type on the outer MIME header. Pa= sting in >>>>>>>> an example:**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> -----BEGIN-----**** >>>>>>>> >>>>>>>> Content-Type: application/pkcs7-mime; smime-type=3Dsigned-data;***= * >>>>>>>> >>>>>>>> name=3Dsmime.p7m**** >>>>>>>> >>>>>>>> Content-Transfer-Encoding: base64**** >>>>>>>> >>>>>>>> Content-Disposition: attachment; filename=3Dsmime.p7m**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7**** >>>>>>>> >>>>>>>> 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH**** >>>>>>>> >>>>>>>> HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh**** >>>>>>>> >>>>>>>> 6YT64V0GhIGfHfQbnj75**** >>>>>>>> >>>>>>>> -----END-----**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> The outer Content-Type, which is analogous to "typ", MUST be >>>>>>>> application/pkcs7-mime, with a parameter indicating the type of CM= S object. >>>>>>>> This is the same as requiring "typ" to be JWE or JWS. The inner >>>>>>>> Content-Type (ASN.1/base64 encoded in the example) can be anything= , just >>>>>>>> like "cty".**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> --Richard**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> On Thu, May 30, 2013 at 12:53 AM, Mike Jones < >>>>>>>> Michael.Jones@microsoft.com> wrote:**** >>>>>>>> >>>>>>>> Requiring that the =93typ=94 value be only =93JWS=94 or =93JWE=94 = would be >>>>>>>> analogous to the MIME spec requiring that the Content-Type: field = be only >>>>>>>> =93text/plain=94 or =93message/external-body=94. It would render = it useless. >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> -- Mik= e >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On >>>>>>>> Behalf Of *Richard Barnes >>>>>>>> *Sent:* Wednesday, May 29, 2013 8:03 PM >>>>>>>> *To:* Mike Jones >>>>>>>> *Cc:* Jim Schaad; jose@ietf.org; Dick Hardt**** >>>>>>>> >>>>>>>> >>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> If this is the level of "type" you're referring to, I think we >>>>>>>> should drop it from the spec. It's an application-layer thing tha= t the app >>>>>>>> can add or not according to its wishes.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> I'm with Dick on this. I think we should either have a mandatory >>>>>>>> indicator of what type of JOSE object this, or nothing at all. I= f the >>>>>>>> former, the allowable values are "JWE" and "JWS". The "+JSON" opt= ions are >>>>>>>> non-sensical -- the app needs to know what it's parsing before it = gets this >>>>>>>> header. While I have a preference for the former (for clarity), t= he latter >>>>>>>> approach is also OK with me, since the MIME types are specific to = JWE/JWS. >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> Another approach here would be to address the JSON and compact >>>>>>>> forms separately. The JSON form has no need of "typ" at all, sinc= e the >>>>>>>> type of the object is completely clear from what fields are there,= e.g., >>>>>>>> "recipients" vs. "signatures". For the compact form, we could do = something >>>>>>>> like James's "E."/"S." prefix idea, which you need because the >>>>>>>> dot-separated components have different meanings and no field name= s to >>>>>>>> indicate this.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> --Richard**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> On Wed, May 29, 2013 at 8:30 PM, Mike Jones < >>>>>>>> Michael.Jones@microsoft.com> wrote:**** >>>>>>>> >>>>>>>> A standard library is unlikely to know the meanings of all possibl= e >>>>>>>> =93typ=94 values =96 and more to the point, *it doesn=92t have to*= . It=92s >>>>>>>> the application=92s job to determine that =93this blob is a JOSE o= bject=94 and >>>>>>>> then pass it to a standard library, which will then ignore the =93= typ=94 value. >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> A standard JOSE library won=92t know what =93typ=94: =93JWT=94 mea= ns. It >>>>>>>> won=92t know what =93typ=94: =93BCGovToken=94 is, should the BC Go= vernment want to >>>>>>>> declare that it=92s using a token with particular characteristics.= It won=92t >>>>>>>> know what =93typ=94: =93XMPP=94 is, should XMPP want to declare th= at it=92s using a >>>>>>>> JOSE data structure with particular characteristics. Etc.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> All these values can be registered in the registry and used by >>>>>>>> applications that understand them. That=92s the application=92s j= ob =96 not the >>>>>>>> library=92s job. The =93typ=94 field is just there so that applic= ations have a >>>>>>>> standard place to make any such declarations that they may need.**= * >>>>>>>> * >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> -- >>>>>>>> Mike**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>>>>>>> *Sent:* Wednesday, May 29, 2013 5:18 PM >>>>>>>> *To:* Mike Jones >>>>>>>> *Cc:* Jim Schaad; jose@ietf.org**** >>>>>>>> >>>>>>>> >>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> I'd prefer to be able to use standard libraries for creating and >>>>>>>> parsing tokens, and not specialized libraries dependent on the use= case. >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> I strongly think we either drop "typ" or make it required.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> On Wed, May 29, 2013 at 5:03 PM, Mike Jones < >>>>>>>> Michael.Jones@microsoft.com> wrote:**** >>>>>>>> >>>>>>>> It=92s fine for your application to specify that it=92s required f= or >>>>>>>> your use case. Not applications need it, so they shouldn=92t be f= orced to >>>>>>>> pay the space penalty of an unnecessary field.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> -- >>>>>>>> Mike**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On >>>>>>>> Behalf Of *Dick Hardt >>>>>>>> *Sent:* Wednesday, May 29, 2013 4:56 PM**** >>>>>>>> >>>>>>>> >>>>>>>> *To:* Jim Schaad >>>>>>>> *Cc:* jose@ietf.org >>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> I use it all the time and my code would barf if it was not there.*= * >>>>>>>> ** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> I think it should be required rather than be a hint if it is going >>>>>>>> ot be there.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> On Wed, May 29, 2013 at 4:40 PM, Jim Schaad >>>>>>>> wrote:**** >>>>>>>> >>>>>>>> I think the values just changed**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> However the way you are using it would be an argument to say that >>>>>>>> it should be a required field. Are you just using it as a hint if= it >>>>>>>> exists and then looking at the rest of the fields if it is not pre= sent? >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> Jim**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> *From:* Dick Hardt [mailto:dick.hardt@gmail.com] >>>>>>>> *Sent:* Wednesday, May 29, 2013 3:49 PM >>>>>>>> *To:* Jim Schaad >>>>>>>> *Cc:* jose@ietf.org >>>>>>>> *Subject:* Re: [jose] Should we delete the "typ" header field**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> Well, I have been using, but now realize the spec changed or I was >>>>>>>> confused.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> I had been setting "typ" to be either "JWE" or "JWS" depending on >>>>>>>> the type of token I was creating or parsing as it was easier than = looking >>>>>>>> at "alg"**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> As currently defined, I don't see value in "typ".**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> -- Dick**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> On Wed, May 29, 2013 at 3:02 PM, Jim Schaad >>>>>>>> wrote:**** >>>>>>>> >>>>>>>> In reading the documents, I am trying to understand the >>>>>>>> justification for having the =93typ=94 header parameter in the JOS= E documents. >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> The purpose of the field is to hold the type of the object. In th= e >>>>>>>> past, I believe that values which should now be placed in the cty = field >>>>>>>> (such as =93JWT=94) were placed in this field as well. However th= e parameter >>>>>>>> is optional and an implementation cannot rely on its being present= . This >>>>>>>> means that for all practical purposes all of the code to determine= the >>>>>>>> value of the type field from the values of the alg and enc fields.= If the >>>>>>>> field was mandatory then this code would disappear at a fairly sma= ll space >>>>>>>> cost and I can understand why the parameter would be present.**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> Can anybody justify why this field should be present in the >>>>>>>> document =96 or should it just disappear?**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> Jim**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> -- >>>>>>>> -- Dick **** >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> -- >>>>>>>> -- Dick **** >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> -- >>>>>>>> -- Dick **** >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose**** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> **** >>>>>>>> >>>>>>>> ** ** >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jose mailing list >>>>>>>> jose@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nat Sakimura (=3Dnat) >>>>>>> Chairman, OpenID Foundation >>>>>>> http://nat.sakimura.org/ >>>>>>> @_nat_en >>>>>>> >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Nat Sakimura (=3Dnat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>> >>> >>> >> >> >> -- >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> > > > > -- > -- Dick > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c2c6ce7f04f204de71e38e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
It is giving the meaning to the signature - metadata about= the signature, so I thought header would be more appropriate, besides, the= payload is binary and I can avoid double base64 encoding that way.=A0


2013/6/6 Dick= Hardt <dick.hardt@gmail.com>
Why would you need that in the header? Why not in the payl= oad?


On Wed, Jun 5, 2013 at 5:31 PM, Nat Sakimura <sakimu= ra@gmail.com> wrote:
What I was thinking as an e= xample was to have 'datetime' as a public header parameter to be us= ed generally, and then differentiate between two cases of 'agreement= 9; and 'timestamp'. It is the same signing operation over the origi= nal (e.g., a MS word document), but from an application point of view, it i= s a bit different. Former constitute an agreement while the later does not.= The type=3Dtimestamp just signifies that the original document existed at = the time indicated.=A0


2013/6/5 Rich= ard Barnes <rlb@ipv.sx>
I'm not sure I understand the use case here. =A0Let me= look at a couple of options, and hopefully one of them will be what you me= ant :) =A0

If it's just a signed timestamp you'r= e talking about, then that's adequately described by cty=3D"timest= amp", typ=3D"JWS".

If you want to sign something and add a timestamp in th= e header, then typ=3D"timestamp" isn't accurate according to = the current specification. =A0The type of the whole object would have to be= something like "timestamped-content". =A0And in that case, an ap= plication can easily recognized that it's timestamped content by lookin= g for the timestamp field in the header, so the "typ" isn't r= eally helpful.


Moving from the example to the general q= uestion:

I think we finally have some common under= standing on this list as to what Mike means by "typ" in the curre= nt document -- a label for the application-layer type of the overall object= . =A0Thanks to Mike for clarifying that in this discussion.

The question is whether this is a sufficiently useful t= hing to have in the core spec. =A0Obviously, applications have to know what= type of object they're dealing with when they get a JOSE object. =A0Th= at includes (1) what type of content is in the payload, and (2) what applic= ation-layer fields are required to be in the header. =A0(1) is covered by &= quot;cty". =A0So "typ" is only useful in the case where:
A. The application is storing application-layer data in the JOSE heade= r
B. The required application-layer fields can be different for d= ifferent objects
C. The required application-layer fields can be = different for different objects of the same content type
D. The required application-layer fields are not indicated by other ap= plication-layer context

Are there any known applic= ations that meet these criteria? =A0JWT does not, for several reasons.=A0
1. (!A) JWT does not store application-layer data in the JOSE header, = only in the claims in the body
2. (!C) A JWT object can indicate = with "cty" that it contains JWT claims or another JWT, either of = which makes it obvious that this is a JWT
3. (!D) In the OAuth context, the Token Type value indicates what type= of token is being presented, e.g., JWT

So there&#= 39;s not really any known use case for "typ" as currently specifi= ed. =A0On the other hand, Dick and James have pointed out that it can be us= eful to have "typ" indicate whether the object at hand is a JWE o= r JWS. =A0Which brings us back to:
-- Change the definition of "typ" so that it indicates the J= OSE-layer type (JWE/JWS)
-- Remove "typ" altogether







On Wed, Jun 5, 2013 at 8:53 AM, Nat Sakimura <= ;sakimura@gmail.com= > wrote:
What about such as thi= s?=A0

cty: original
typ: timestamp


2013/6/5= Richard Barnes <rlb@ipv.sx>
It would be a good point, i= f it were true :) =A0In particular, this part: "[dropping 'typ'= ;]=A0is going to cause each and every application that uses JOSE to def= ine their own field"

So far, I've heard of exactly one application of JOSE th= at requires "typ" in the way it is currently specified, namely JW= T. =A0

On the other hand, Dick's applications = are apparently using it differently (and, IMO, properly) to distinguish JWE= /JWS. =A0Then there are all the applications out there that are OK using ap= plication context and "cty" to recognize what type of object they= have. =A0Apps using CMS have been doing this for ages.

So it's not at all clear to me that there's any= other application that would use "typ" besides JWT. =A0And it= 9;s not clear to me that JWT needs it.
<= div>
--Richard



=


On Fri, May 3= 1, 2013 at 5:45 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Nat makes a good point here= , I think.


On Thu, May 30, 2013 at 9:31 AM, Nat Sak= imura <sakimura@gmail.com> wrote:
From what I understand, bot= h typ and cty are something to be consumed by the application and not JOSE = processor. From the point of view of the JOSE processor, they should be ign= ored.=A0

We could drop both fields from JOSE specs, but that is going to cause each = and every application that uses JOSE to define their own field, which is a = waste. That is why we are defining them here.=A0

I would rather drop them than define JOSE processing semantics to thes= e fields.=A0


2013/5/31 Mike Jones <Michael.Jones@microso= ft.com>

No, =93cty=94 is used by = the derived class to determine the type of the encapsulated field.=A0 But t= hat=92s not a complete description of the *entire object* - especially not the additional meaning imbued by the additional parameter= s the derived type may add to the JOSE header.=A0 =93typ=94 is there to pro= vide the type of the entire object, including what you=92re calling the wra= pper parts.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7:58 AM


To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

Isn't that requirement met by "cty"? = =A0The only thing JOSE adds is a crypto wrapper around the real application= content. =A0If you're an application, you know a JOSE object is the th= ing you want because it contains the content you want -- it's a JWT because it contains JWT claims.

=A0

Inheritance is the wrong metaphor. =A0This is encaps= ulation of application data:

if (jws.valid && jws.cty =3D=3D "applic= ation/jwt_claims") {

=A0 =A0 jwtClaims =3D jws.content;

}

=A0

--Richard

=A0

On Thu, May 30, 2013 at 10:43 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Thanks for sharing the S/= MIME details.=A0 Although I was actually making the analogy to MIME =96 not S/MIME.=A0 Like many analogies, it=92s imperfect, but I believe still illu= strative.

=A0<= /p>

The reason that the analo= gy isn=92t perfect is that the JOSE data structures are used to build appli= cation-specific data structures that are legal JOSE data structures but also have addition= al properties =96 including additional header fields with specific semantic= s.=A0 (When we agreed to ignore not-understood header fields we let that ho= rse out of the barn.)=A0 For instance, Dick Hardt uses JWEs with issuer and audience fields in the headers, so th= ey can be used by routing software.

=A0<= /p>

Think of JOSE as the base= class and the application types built using it as derived classes.=A0 JWT is a derived class.=A0 Dick=92s structures are a derived class.=A0 These d= erived classes sometimes need names.=A0 That=92s what =93typ=94 is for.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7:34 AM


To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org; Dick Hardt
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

You're mixing up "typ" and "cty&q= uot;. =A0If you want to make the analogy to S/MIME, "cty" is the = equivalent to Content-Type inside the protected MIME body; "typ" = is the content-type on the outer MIME header. =A0Pasting in an example:

=A0

-----BEGIN-----

Content-Type: application/pkcs7-mime; smime-type=3Ds= igned-data;

=A0 =A0 =A0name=3Dsmime.p7m

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=3Dsmime.p7= m

=A0

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4V= Qbnj7

77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUuj= hJhjH

HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHG= ghyHh

6YT64V0GhIGfHfQbnj75

-----END-----

=A0

The outer Content-Type, which is analogous to "= typ", MUST be application/pkcs7-mime, with a parameter indicating the = type of CMS object. =A0This is the same as requiring "typ" to be JWE or JWS. =A0The inner Content-Type (ASN.1/base64 encoded in the exam= ple) can be anything, just like "cty".

=A0

--Richard

=A0

=A0

=A0

=A0

On Thu, May 30, 2013 at 12:53 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Requiring that the =93typ= =94 value be only =93JWS=94 or =93JWE=94 would be analogous to the MIME spe= c requiring that the Content-Type: field be only =93text/plain=94 or =93message/extern= al-body=94.=A0 It would render it useless.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, May 29, 2013 8:03 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org; Dick Hardt


Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

If this is the level of "type" you're = referring to, I think we should drop it from the spec. =A0It's an appli= cation-layer thing that the app can add or not according to its wishes.<= /u>

=A0

I'm with Dick on this. =A0I think we should eith= er have a mandatory indicator of what type of JOSE object this, or nothing = at all. =A0 If the former, the allowable values are "JWE" and "JWS". =A0The "+JSON" options are non-sensical -- = the app needs to know what it's parsing before it gets this header. =A0= While I have a preference for the former (for clarity), the latter approach= is also OK with me, since the MIME types are specific to JWE/JWS.

=A0

Another approach here would be to address the JSON a= nd compact forms separately. =A0The JSON form has no need of "typ"= ; at all, since the type of the object is completely clear from what fields are there, e.g., "recipients" vs. "signatures&q= uot;. =A0For the compact form, we could do something like James's "= ;E."/"S." prefix idea, which you need because the dot-separa= ted components have different meanings and no field names to indicate this.=

=A0

--Richard

=A0

On Wed, May 29, 2013 at 8:30 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

A standard library is unl= ikely to know the meanings of all possible =93typ=94 values =96 and more to= the point, it doesn=92t have to.=A0 It=92s the application=92s job to d= etermine that =93this blob is a JOSE object=94 and then pass it to a standa= rd library, which will then ignore the =93typ=94 value.

=A0<= /p>

A standard JOSE library w= on=92t know what =93typ=94: =93JWT=94 means.=A0 It won=92t know what =93typ= =94: =93BCGovToken=94 is, should the BC Government want to declare that it=92s using a token wit= h particular characteristics.=A0 It won=92t know what =93typ=94: =93XMPP=94= is, should XMPP want to declare that it=92s using a JOSE data structure wi= th particular characteristics.=A0 Etc.

=A0<= /p>

All these values can be r= egistered in the registry and used by applications that understand them.=A0 That=92s the application=92s job =96 not the library=92s job.=A0 The =93ty= p=94 field is just there so that applications have a standard place to make= any such declarations that they may need.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Wednesday, May 29, 2013 5:18 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org


Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

I'd prefer to be able to use standard libraries = for creating and parsing tokens, and not specialized libraries dependent on= the use case.

=A0

I strongly think we either drop "typ" or m= ake it required.

=A0

On Wed, May 29, 2013 at 5:03 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

It=92s fine for your appl= ication to specify that it=92s required for your use case.=A0 Not applicati= ons need it, so they shouldn=92t be forced to pay the space penalty of an unne= cessary field.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Wednesday, May 29, 2013 4:56 PM


To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

I use it all the time and my code would barf if it w= as not there.

=A0

I think it should be required rather than be a hint = if it is going ot be there.

=A0

On Wed, May 29, 2013 at 4:40 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

I think the values just c= hanged

=A0<= /p>

However the way you are u= sing it would be an argument to say that it should be a required field.=A0 Are you just using it as a hint if it exists and then looking at the rest = of the fields if it is not present?

=A0<= /p>

Jim<= /p>

=A0<= /p>

=A0<= /p>

From: Dick Har= dt [mailto:dick.h= ardt@gmail.com]
Sent: Wednesday, May 29, 2013 3:49 PM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Should we delete the "typ" header fiel= d

=A0

Well, I have been using, but now realize the spec ch= anged or I was confused.

=A0

I had been setting "typ" to be either &quo= t;JWE" or "JWS" depending on the type of token I was creatin= g or parsing as it was easier than looking at "alg"=

=A0

As currently defined, I don't see value in "= ;typ".

=A0

-- Dick

=A0

=A0

On Wed, May 29, 2013 at 3:02 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

In reading the documents, I am trying to understand = the justification for having the =93typ=94 header parameter in the JOSE doc= uments.

=A0

The purpose of the field is to hold the type of the = object. =A0In the past, I believe that values which should now be placed in= the cty field (such as =93JWT=94) were placed in this field as well.=A0 However the parameter is optional and an implementation cannot= rely on its being present.=A0 This means that for all practical purposes a= ll of the code to determine the value of the type field from the values of = the alg and enc fields. =A0If the field was mandatory then this code would disappear at a fairly small space cost = and I can understand why the parameter would be present.

=A0

Can anybody justify why this field should be present= in the document =96 or should it just disappear?

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick



=A0

--
-- Dick


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0

=A0

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_= nat_en

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose






--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en




--
= Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_= en



<= /div>--
-- Dick



--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c2c6ce7f04f204de71e38e-- From James.H.Manger@team.telstra.com Wed Jun 5 19:19:12 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5346611E80E2 for ; Wed, 5 Jun 2013 19:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.698 X-Spam-Level: * X-Spam-Status: No, score=1.698 tagged_above=-999 required=5 tests=[HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIIHTu54ZTAo for ; Wed, 5 Jun 2013 19:19:06 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3F49911E80E4 for ; Wed, 5 Jun 2013 19:19:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,810,1363093200"; d="scan'208";a="139932565" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 06 Jun 2013 12:18:59 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7097"; a="136759411" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipccvi.tcif.telstra.com.au with ESMTP; 06 Jun 2013 12:18:59 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Thu, 6 Jun 2013 12:18:59 +1000 From: "Manger, James H" To: Nat Sakimura Date: Thu, 6 Jun 2013 12:18:57 +1000 Thread-Topic: [jose] Should we delete the "typ" header field Thread-Index: Ac5iTXXx3btvRzA5Q52SxQXmyk5oHAAA26UQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B105B2B@WSMSG3153V.srv.dir.telstra.com> References: <02b701ce5cb8$46ae77e0$d40b67a0$@augustcellars.com> <02f501ce5cc5$ec9a2200$c5ce6600$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943677C58C4@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C5C0A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C7399@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9B69@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9E95@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Should we delete the "typ" header field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 02:19:12 -0000 PiB0eXA6IHRpbWVzdGFtcA0KDQpCeSB2ZXJpZnlpbmcgYSBzaWduZWQgSk9TRSBtZXNzYWdlIHlv dSBrbm93IHRoYXQgdGhlIGhvbGRlciBvZiB0aGUgY29ycmVzcG9uZGluZyBwcml2YXRlIGtleSAi cHJvY2Vzc2VkIiB0aGUgYnl0ZXMgb2YgdGhlIGNvbnRlbnQuDQpXaGF0IGl0IGRvZXNuJ3QgdGVs bCB5b3UgaXMgd2hldGhlciB0aGUgc2lnbmVyIG1lYW50Og0KMS4gVGhleSBkaWRuJ3QgbG9vayBh dCB0aGUgY29udGVudCAoZWcgc2lnbmluZyBhbiBhdXRoZW50aWNhdGlvbiBjaGFsbGVuZ2U7IHRp bWVzdGFtcGluZyBhcmJpdHJhcnkgZGF0YSkNCjIuIFRoZXkgYXJlIHZvdWNoaW5nIGZvciB0aGUg c3ludGF4LCBub3QgbWVhbmluZywgb2YgdGhlIGNvbnRlbnQgKGVnIGFudGktbWFsd2FyZSBjaGVj azsgc3ludGF4IGNoZWNrZXIpDQozLiBUaGV5IGFyZSBjb21taXR0aW5nIHRvIHRoZSBjb250ZW50 IChlZyBzaWduaW5nIGEgY29udHJhY3Q7IHZvdWNoaW5nIGZvciBjbGFpbXMpDQoNCkl0IGlzIHBy b2JhYmx5IGJlc3QgZm9yIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRoZXNlIHRvIGJlIGJvdW5k IHRvIHRoZSB2ZXJpZmljYXRpb24gcHVibGljIGtleS4gRm9yIGluc3RhbmNlLCBpbmNsdWRpbmcg YSBjcml0aWNhbCBleHRlbmRlZEtleVVzYWdlIGV4dGVuc2lvbiBpbiB0aGUgcHVibGljIGtleSdz IGNlcnRpZmljYXRlIHdpdGggYSB2YWx1ZSBpZC1rcC10aW1lU3RhbXBpbmcgW1JGQzMxNjEgVGlt ZS1TdGFtcCBQcm90b2NvbF0uDQoNCk5leHQsIHRoZSBjb250ZW50IHR5cGUgKCdjdHknIGZpZWxk KSBzaG91bGQgZGlzdGluZ3Vpc2ggdGhlc2UgY2FzZXMuIFNpZ25pbmcgdGhlIHNhbWUgSldUIGNs YWltIHNldCwgYnV0IHdpdGggJ2N0eScgc2V0IHRvICdhcHBsaWNhdGlvbi9vY3RldC1zdHJlYW0n LCAnYXBwbGljYXRpb24vanNvbicsIG9yICdhcHBsaWNhdGlvbi9qd3QranNvbicoKikgY291bGQv c2hvdWxkIGltcGx5IGRpZmZlcmVudCBtZWFuaW5ncyAoMSwgMiwgYW5kIDMgcmVzcGVjdGl2ZWx5 KS4NCg0KRXZlbiBpZiB0aGVyZSBhcmUgY2FzZXMgd2hlcmUgYSBoZWFkZXIgcGFyYW1ldGVyIGlz IHVzZWZ1bCBmb3IgdGhpcyBwdXJwb3NlIChkZXNwaXRlIEpXRS9KV1Mgbm9yIEpXVCBiZWluZyBz dWNoIGEgdXNlIGNhc2UpLCAndHlwJyBhcyBjdXJyZW50bHkgZGVmaW5lZCBjYW5ub3QgYmUgdGhl IGFuc3dlciBhcyBpdCBpcyBvcHRpb25hbCBhbmQgaWdub3JhYmxlLiBBIHJlY2lwaWVudCByZWNl aXZpbmcgYSBKT1NFIG1lc3NhZ2Ugd2l0aCB7InR5cCI6InRpbWVzdGFtcCIuLi59IGNhbiBsZWdp dGltYXRlbHkgaWdub3JlICJ0eXAiIGFuZCBhc3N1bWUgdGhlIHNpZ25lciBpcyBjb21taXR0aW5n IHRvIHRoZSBjb250ZW50Lg0KDQoNCigqKSBJIGRvbid0IHRoaW5rIGFwcGxpY2F0aW9uL2p3dCtq c29uIGlzIGEgZGVmaW5lZCBtZWRpYSB0eXBlLiBJIGRpZG4ndCB1c2UgYXBwbGljYXRpb24vand0 IGFzIGl0IGlzIGRlZmluZWQgaW4gdGhlIEpXVCBkcmFmdCBhcyBhIG1lZGlhIHR5cGUgZm9yIEpP U0UgbWVzc2FnZXMgKHdoaWNoIGlzIGNyYXp5KSwgaW5zdGVhZCBvZiBhIG1lZGlhIHR5cGUgZm9y IGEgSlNPTiBvYmplY3QgaG9sZGluZyBjbGFpbXMgKHdoaWNoIGl0IHNob3VsZCBiZSkuDQoNCi0t DQpKYW1lcyBNYW5nZXINCg== From rlb@ipv.sx Thu Jun 6 14:43:57 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0127521F9955 for ; Thu, 6 Jun 2013 14:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I-lGfAsp3mU for ; Thu, 6 Jun 2013 14:43:52 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D49C921F8825 for ; Thu, 6 Jun 2013 14:43:51 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wc20so5523726obb.18 for ; Thu, 06 Jun 2013 14:43:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=zkzrTV6oc0fVY37Y8Y2BMvD9nCF1hP2tywFqrU5avvI=; b=pY0WqRTbR/K+16oZbR6etQLnxgXkkxkIBuu2YYK7KOjmkzJ/rH3VoholUQerGG6o5r 4L4hepHRF23CmgcW+dQsnblXmqNuAzbv0rehj8DL5idJmkrAHACsW1DVmuxkgp7tHrkj Bjp5zlr6kaCLLJ/Z8KE97foAELYyqmjmoTomLx0lZNbf2ImMUDi4j9J6C9kRkO2n5CMI jYYgUF9v9zJRyq8axN/uI5bQdyfDTCbmGVcuVdwW//BsULchUaR7ClX0eR/ES74LI/SN puSIy2Dr53+2pbIlubxOWwuZPtYW6vhTgLTmx09WwXuCAx6p7VCN/OCQwOba81mCbNN9 vQ8Q== MIME-Version: 1.0 X-Received: by 10.60.33.202 with SMTP id t10mr19636423oei.2.1370555031384; Thu, 06 Jun 2013 14:43:51 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Thu, 6 Jun 2013 14:43:51 -0700 (PDT) X-Originating-IP: [128.89.254.205] Date: Thu, 6 Jun 2013 17:43:51 -0400 Message-ID: From: Richard Barnes To: "jose@ietf.org" Content-Type: multipart/alternative; boundary=089e013c66b4ca843404de8335f0 X-Gm-Message-State: ALoCoQnLqqPkuDpnRyQNgsOzqvqkOSIi6sUG30mGthucNucWb7/HP/GxD0JMniUwf6opfzclHWbu Subject: [jose] What are we doing here? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 21:43:57 -0000 --089e013c66b4ca843404de8335f0 Content-Type: text/plain; charset=ISO-8859-1 The conversation about "typ" has brought us back to a familiar question for this working group -- what are we trying to do here? The current document is ambiguous on this topic. On the one hand, it mostly covers the crypto bases, with things like "alg" and "enc". On the other hand, it mixes in application design concepts like "typ" and "crit". The result is a spec that's ambiguous in purpose and complex. If I'm building an application with this, how do I decide what goes in the "crit" field, or what values to use for "typ"? The charter for this working group is not ambiguous on this topic. This group is chartered to do signing and encryption. The JOSE formats should carry the parameters needed to perform those operations. Anything else is extraneous, and in the spirit of "The perfect protocol is one from which nothing can be removed", should be removed. Now, I'm not going to be a hard-liner on this. I won't complain about "zip" and "cty", since they are clearly defined and have clear use cases. But "crit" and "typ" are so ambiguous and so little supported by use cases*, that they really should go. --Richard --089e013c66b4ca843404de8335f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The conversation about "typ" has brought us back= to a familiar question for this working group -- what are we trying to do = here?

The current document is ambiguous on this topic. = =A0On the one hand, it mostly covers the crypto bases, with things like &qu= ot;alg" and "enc". =A0On the other hand, it mixes in applica= tion design concepts like "typ" and "crit". =A0The resu= lt is a spec that's ambiguous in purpose and complex. =A0If I'm bui= lding an application with this, how do I decide what goes in the "crit= " field, or what values to use for "typ"? =A0 =A0
The charter for this working group is not ambiguous on this topic. =A0= This group is chartered to do signing and encryption. =A0The JOSE formats s= hould carry the parameters needed to perform those operations. =A0Anything = else is extraneous, and in the spirit of "The perfect protocol is one = from which nothing can be removed", should be removed.

Now, I'm not going to be a hard-liner on this. =A0I= won't complain about "zip" and "cty", since they a= re clearly defined and have clear use cases. =A0But "crit" and &q= uot;typ" are so ambiguous and so little supported by use cases*, that = they really should go.

</rant>

--Richard
<= /div> --089e013c66b4ca843404de8335f0-- From Michael.Jones@microsoft.com Thu Jun 6 22:22:25 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4409521F8ADF for ; Thu, 6 Jun 2013 22:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5s9aLVa6itCz for ; Thu, 6 Jun 2013 22:22:18 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id DF4F621F86F0 for ; Thu, 6 Jun 2013 22:22:17 -0700 (PDT) Received: from BN1BFFO11FD006.protection.gbl (10.58.52.200) by BN1BFFO11HUB015.protection.gbl (10.58.53.125) with Microsoft SMTP Server (TLS) id 15.0.707.0; Fri, 7 Jun 2013 05:20:59 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD006.mail.protection.outlook.com (10.58.53.66) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Fri, 7 Jun 2013 05:20:58 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.110]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0136.001; Fri, 7 Jun 2013 05:18:58 +0000 From: Mike Jones To: Richard Barnes , "jose@ietf.org" Thread-Topic: [jose] What are we doing here? Thread-Index: AQHOYv8CR0v9d+v7FEav765iFV2uepkps4Ew Date: Fri, 7 Jun 2013 05:18:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436780758E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436780758ETK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(377454002)(47446002)(74662001)(74706001)(56776001)(65816001)(47736001)(56816003)(33656001)(69226001)(80022001)(54356001)(46102001)(53806001)(76482001)(31966008)(74876001)(20776003)(74502001)(63696002)(77982001)(16406001)(15202345002)(16236675002)(49866001)(4396001)(76796001)(47976001)(79102001)(55846006)(71186001)(50986001)(59766001)(77096001)(66066001)(512954002)(81342001)(74366001)(54316002)(6806003)(51856001)(76786001)(81542001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB015; H:TK5EX14MLTC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0870212862 Subject: Re: [jose] What are we doing here? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 05:22:25 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436780758ETK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Excellent question, Richard, because it gets to the heart of why the JOSE s= pecs are already highly successful and widely adopted. - We are building useful tools that solve real problems for developers. - We are practically demonstrating the value of rough consensus and runni= ng code. - We are making simple things simple. - We are making complex things possible, when necessary (but not at the e= xpense of keeping simple things simple). - We are developing specs with an explicit goal of enabling ubiquitous ad= option. - We are developing specs guided by practical engineering tradeoffs to en= able commonly useful functionality in a straightforward manner. The level of adoption, with dozens of deployed implementations, is compelli= ng evidence that we've already achieved the goals above. It's time to "shi= p it", as making the JOSE specs actual standards will only increase their a= doption and value to the industry. That's what we're doing here. -- Mike P.S. I would be careful reasoning from the premise of "The perfect protoco= l is one from which nothing can be removed". By that logic, the perfect sp= ecification is the null specification, which leaves all possibilities open,= and solves no actual problems. ;-) From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Thursday, June 06, 2013 2:44 PM To: jose@ietf.org Subject: [jose] What are we doing here? The conversation about "typ" has brought us back to a familiar question for= this working group -- what are we trying to do here? The current document is ambiguous on this topic. On the one hand, it mostl= y covers the crypto bases, with things like "alg" and "enc". On the other = hand, it mixes in application design concepts like "typ" and "crit". The r= esult is a spec that's ambiguous in purpose and complex. If I'm building a= n application with this, how do I decide what goes in the "crit" field, or = what values to use for "typ"? The charter for this working group is not ambiguous on this topic. This gr= oup is chartered to do signing and encryption. The JOSE formats should car= ry the parameters needed to perform those operations. Anything else is ext= raneous, and in the spirit of "The perfect protocol is one from which nothi= ng can be removed", should be removed. Now, I'm not going to be a hard-liner on this. I won't complain about "zip= " and "cty", since they are clearly defined and have clear use cases. But = "crit" and "typ" are so ambiguous and so little supported by use cases*, th= at they really should go. --Richard --_000_4E1F6AAD24975D4BA5B16804296739436780758ETK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Excellent question, Richa= rd, because it gets to the heart of why the JOSE specs are already highly s= uccessful and widely adopted.

 <= /p>

  - We are building = useful tools that solve real problems for developers.

  - We are practical= ly demonstrating the value of rough consensus and running code.<= /span>

  - We are making si= mple things simple.

  - We are making co= mplex things possible, when necessary (but not at the expense of keeping si= mple things simple).

  - We are developin= g specs with an explicit goal of enabling ubiquitous adoption.

  - We are developin= g specs guided by practical engineering tradeoffs to enable commonly useful= functionality in a straightforward manner.

 <= /p>

The level of adoption, wi= th dozens of deployed implementations, is compelling evidence that we’= ;ve already achieved the goals above.  It’s time to “ship = it”, as making the JOSE specs actual standards will only increase their adoptio= n and value to the industry.

 <= /p>

That’s what we̵= 7;re doing here.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

P.S.  I would be car= eful reasoning from the premise of “The perfect protocol is on= e from which nothing can be removed”. = ; By that logic, the perfect specification is the null specification, which = leaves all possibilities open, and solves no actual problems. ;-)

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: jose@ietf.org
Subject: [jose] What are we doing here?

 

The conversation about "typ" has brought u= s back to a familiar question for this working group -- what are we trying = to do here?

 

The current document is ambiguous on this topic. &nb= sp;On the one hand, it mostly covers the crypto bases, with things like &qu= ot;alg" and "enc".  On the other hand, it mixes in appl= ication design concepts like "typ" and "crit".  Th= e result is a spec that's ambiguous in purpose and complex.  If I'm building an app= lication with this, how do I decide what goes in the "crit" field= , or what values to use for "typ"?    

The charter for this working group is not ambiguous = on this topic.  This group is chartered to do signing and encryption. =  The JOSE formats should carry the parameters needed to perform those = operations.  Anything else is extraneous, and in the spirit of "The perfect protocol is one from which nothing can = be removed", should be removed.

 

Now, I'm not going to be a hard-liner on this.  = ;I won't complain about "zip" and "cty", since they are= clearly defined and have clear use cases.  But "crit" and &= quot;typ" are so ambiguous and so little supported by use cases*, that= they really should go.

 

</rant>

 

--Richard

--_000_4E1F6AAD24975D4BA5B16804296739436780758ETK5EX14MBXC283r_-- From Axel.Nennker@telekom.de Fri Jun 7 02:53:46 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2F721F9402 for ; Fri, 7 Jun 2013 02:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTPC8fAfcIth for ; Fri, 7 Jun 2013 02:53:41 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCA821F86F4 for ; Fri, 7 Jun 2013 02:53:39 -0700 (PDT) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 07 Jun 2013 11:53:25 +0200 Received: from HE100024.emea1.cds.t-internal.com (10.125.65.200) by HE101250.emea1.cds.t-internal.com (10.125.92.153) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 7 Jun 2013 11:53:25 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.97]) by HE100024.emea1.cds.t-internal.com ([2002:769:410c::769:410c]) with mapi; Fri, 7 Jun 2013 11:53:24 +0200 From: To: , , Date: Fri, 7 Jun 2013 11:53:22 +0200 Thread-Topic: [jose] What are we doing here? Thread-Index: AQHOYv8CR0v9d+v7FEav765iFV2uepkps4EwgABM2/A= Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436780758E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436780758E@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF40255A5CA071CHE111541eme_" MIME-Version: 1.0 Subject: Re: [jose] What are we doing here? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 09:53:46 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF40255A5CA071CHE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 to Mike's comments. Usefulness of the standard is the important thing. From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mik= e Jones Sent: Friday, June 07, 2013 7:19 AM To: Richard Barnes; jose@ietf.org Subject: Re: [jose] What are we doing here? Excellent question, Richard, because it gets to the heart of why the JOSE s= pecs are already highly successful and widely adopted. - We are building useful tools that solve real problems for developers. - We are practically demonstrating the value of rough consensus and runni= ng code. - We are making simple things simple. - We are making complex things possible, when necessary (but not at the e= xpense of keeping simple things simple). - We are developing specs with an explicit goal of enabling ubiquitous ad= option. - We are developing specs guided by practical engineering tradeoffs to en= able commonly useful functionality in a straightforward manner. The level of adoption, with dozens of deployed implementations, is compelli= ng evidence that we've already achieved the goals above. It's time to "shi= p it", as making the JOSE specs actual standards will only increase their a= doption and value to the industry. That's what we're doing here. -- Mike P.S. I would be careful reasoning from the premise of "The perfect protoco= l is one from which nothing can be removed". By that logic, the perfect sp= ecification is the null specification, which leaves all possibilities open,= and solves no actual problems. ;-) From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Thursday, June 06, 2013 2:44 PM To: jose@ietf.org Subject: [jose] What are we doing here? The conversation about "typ" has brought us back to a familiar question for= this working group -- what are we trying to do here? The current document is ambiguous on this topic. On the one hand, it mostl= y covers the crypto bases, with things like "alg" and "enc". On the other = hand, it mixes in application design concepts like "typ" and "crit". The r= esult is a spec that's ambiguous in purpose and complex. If I'm building a= n application with this, how do I decide what goes in the "crit" field, or = what values to use for "typ"? The charter for this working group is not ambiguous on this topic. This gr= oup is chartered to do signing and encryption. The JOSE formats should car= ry the parameters needed to perform those operations. Anything else is ext= raneous, and in the spirit of "The perfect protocol is one from which nothi= ng can be removed", should be removed. Now, I'm not going to be a hard-liner on this. I won't complain about "zip= " and "cty", since they are clearly defined and have clear use cases. But = "crit" and "typ" are so ambiguous and so little supported by use cases*, th= at they really should go. --Richard --_000_CE8995AB5D178F44A2154F5C9A97CAF40255A5CA071CHE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 to Mik= e’s comments.

 

Usefulness of the stand= ard is the important thing.

 

 =

 

From: jose-bounces@ietf.org [mailto:jose-bounces@i= etf.org] On Behalf Of Mike Jones
Sent: Friday, June 07, 20= 13 7:19 AM
To: Richard Barnes; jose@ietf.org
Subject: R= e: [jose] What are we doing here?

 

Excellent que= stion, Richard, because it gets to the heart of why the JOSE specs are alre= ady highly successful and widely adopted.

 

&nb= sp; - We are building useful tools that solve real problems for developers.=

  - We are practical= ly demonstrating the value of rough consensus and running code.<= /span>

  - We are making simple things = simple.

  - We are ma= king complex things possible, when necessary (but not at the expense of kee= ping simple things simple).

  - We are developing specs with an explicit goal of enabling ubiqui= tous adoption.

  - We= are developing specs guided by practical engineering tradeoffs to enable c= ommonly useful functionality in a straightforward manner.=

 

The level of adoption, with dozens of deployed implementations= , is compelling evidence that we’ve already achieved the goals above.=   It’s time to “ship it”, as making the JOSE specs a= ctual standards will only increase their adoption and value to the industry= .

 =

That’s what we’re doing here.

 

       &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;  -- Mike

&nbs= p;

P.S.  I would be carefu= l reasoning from the premise of “The perfect protocol is one f= rom which nothing can be removed”.  By that logic, the pe= rfect specification is the null specification, which leaves all possibiliti= es open, and solves no actual problems. ;-)

 

From: jo= se-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Rich= ard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: jo= se@ietf.org
Subject: [jose] What are we doing here?

 

The conversation about "typ" has brought us back to a familiar q= uestion for this working group -- what are we trying to do here?=

 

The current document is ambiguous on this topic.  On the one h= and, it mostly covers the crypto bases, with things like "alg" an= d "enc".  On the other hand, it mixes in application design = concepts like "typ" and "crit".  The result is a s= pec that's ambiguous in purpose and complex.  If I'm building an appli= cation with this, how do I decide what goes in the "crit" field, = or what values to use for "typ"?    

The charter for this working group is not ambig= uous on this topic.  This group is chartered to do signing and encrypt= ion.  The JOSE formats should carry the parameters needed to perform t= hose operations.  Anything else is extraneous, and in the spirit of &q= uot;The perfect protocol is one from which nothing can be removed", sh= ould be removed.

 <= /o:p>

Now, I'm not going to be a hard-li= ner on this.  I won't complain about "zip" and "cty&quo= t;, since they are clearly defined and have clear use cases.  But &quo= t;crit" and "typ" are so ambiguous and so little supported b= y use cases*, that they really should go.

 

</rant= >

 

--Richard

= --_000_CE8995AB5D178F44A2154F5C9A97CAF40255A5CA071CHE111541eme_-- From Axel.Nennker@telekom.de Fri Jun 7 03:13:04 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C24121F8F15 for ; Fri, 7 Jun 2013 03:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=-1.302, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFTLMr-EWNJb for ; Fri, 7 Jun 2013 03:12:55 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0DA21F8F7B for ; Fri, 7 Jun 2013 03:12:39 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 07 Jun 2013 12:11:25 +0200 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.97]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Fri, 7 Jun 2013 12:11:24 +0200 From: To: Date: Fri, 7 Jun 2013 12:11:23 +0200 Thread-Topic: [jose] Should we delete the "typ" header field Thread-Index: Ac5iUeXwtS5j7F+KRBSkCLgEI73rjABEykrQ Message-ID: References: <02b701ce5cb8$46ae77e0$d40b67a0$@augustcellars.com> <02f501ce5cc5$ec9a2200$c5ce6600$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943677C58C4@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C5C0A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C7399@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9B69@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9E95@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF40255A5CA075AHE111541eme_" MIME-Version: 1.0 Cc: rlb@ipv.sx, ietf@augustcellars.com, Michael.Jones@microsoft.com, sakimura@gmail.com, bcampbell@pingidentity.com, dick.hardt@gmail.com Subject: Re: [jose] Should we delete the "typ" header field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 10:13:04 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF40255A5CA075AHE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My take on the "typ" header field: - "typ" must be optional because some application just knows what = it is dealing with. It is a waste of space in this case. - "typ" is reserved header name and the values SHOULD be JWS, JWE,= JWT. No MUST on the values. - For a general purpose JOSE library it makes sense to have "typ" = and I would write it so that it throws an exception on validateJWS( {"typ"= :"JWE", ...}) Especially if crit=3D["typ"]. I would like to keep (the first paragraph of) https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11#section-4= .1.8 as it is. -Axel From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Nat= Sakimura Sent: Thursday, June 06, 2013 3:04 AM To: Dick Hardt Cc: Richard Barnes; Mike Jones; Brian Campbell; Jim Schaad; jose@ietf.org Subject: Re: [jose] Should we delete the "typ" header field It is giving the meaning to the signature - metadata about the signature, s= o I thought header would be more appropriate, besides, the payload is binar= y and I can avoid double base64 encoding that way. 2013/6/6 Dick Hardt > Why would you need that in the header? Why not in the payload? On Wed, Jun 5, 2013 at 5:31 PM, Nat Sakimura > wrote: What I was thinking as an example was to have 'datetime' as a public header= parameter to be used generally, and then differentiate between two cases o= f 'agreement' and 'timestamp'. It is the same signing operation over the or= iginal (e.g., a MS word document), but from an application point of view, i= t is a bit different. Former constitute an agreement while the later does n= ot. The type=3Dtimestamp just signifies that the original document existed = at the time indicated. 2013/6/5 Richard Barnes > I'm not sure I understand the use case here. Let me look at a couple of op= tions, and hopefully one of them will be what you meant :) If it's just a signed timestamp you're talking about, then that's adequatel= y described by cty=3D"timestamp", typ=3D"JWS". If you want to sign something and add a timestamp in the header, then typ= =3D"timestamp" isn't accurate according to the current specification. The = type of the whole object would have to be something like "timestamped-conte= nt". And in that case, an application can easily recognized that it's time= stamped content by looking for the timestamp field in the header, so the "t= yp" isn't really helpful. Moving from the example to the general question: I think we finally have some common understanding on this list as to what M= ike means by "typ" in the current document -- a label for the application-l= ayer type of the overall object. Thanks to Mike for clarifying that in thi= s discussion. The question is whether this is a sufficiently useful thing to have in the = core spec. Obviously, applications have to know what type of object they'r= e dealing with when they get a JOSE object. That includes (1) what type of= content is in the payload, and (2) what application-layer fields are requi= red to be in the header. (1) is covered by "cty". So "typ" is only useful= in the case where: A. The application is storing application-layer data in the JOSE header B. The required application-layer fields can be different for different obj= ects C. The required application-layer fields can be different for different obj= ects of the same content type D. The required application-layer fields are not indicated by other applica= tion-layer context Are there any known applications that meet these criteria? JWT does not, f= or several reasons. 1. (!A) JWT does not store application-layer data in the JOSE header, only = in the claims in the body 2. (!C) A JWT object can indicate with "cty" that it contains JWT claims or= another JWT, either of which makes it obvious that this is a JWT 3. (!D) In the OAuth context, the Token Type value indicates what type of t= oken is being presented, e.g., JWT So there's not really any known use case for "typ" as currently specified. = On the other hand, Dick and James have pointed out that it can be useful t= o have "typ" indicate whether the object at hand is a JWE or JWS. Which br= ings us back to: -- Change the definition of "typ" so that it indicates the JOSE-layer type = (JWE/JWS) -- Remove "typ" altogether On Wed, Jun 5, 2013 at 8:53 AM, Nat Sakimura > wrote: What about such as this? cty: original typ: timestamp 2013/6/5 Richard Barnes > It would be a good point, if it were true :) In particular, this part: "[d= ropping 'typ'] is going to cause each and every application that uses JOSE = to define their own field" So far, I've heard of exactly one application of JOSE that requires "typ" i= n the way it is currently specified, namely JWT. On the other hand, Dick's applications are apparently using it differently = (and, IMO, properly) to distinguish JWE/JWS. Then there are all the applic= ations out there that are OK using application context and "cty" to recogni= ze what type of object they have. Apps using CMS have been doing this for = ages. So it's not at all clear to me that there's any other application that woul= d use "typ" besides JWT. And it's not clear to me that JWT needs it. --Richard On Fri, May 31, 2013 at 5:45 PM, Brian Campbell > wrote: Nat makes a good point here, I think. On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura > wrote: >From what I understand, both typ and cty are something to be consumed by th= e application and not JOSE processor. From the point of view of the JOSE pr= ocessor, they should be ignored. We could drop both fields from JOSE specs, but that is going to cause each = and every application that uses JOSE to define their own field, which is a = waste. That is why we are defining them here. I would rather drop them than define JOSE processing semantics to these fie= lds. 2013/5/31 Mike Jones > No, "cty" is used by the derived class to determine the type of the encapsu= lated field. But that's not a complete description of the *entire object* = - especially not the additional meaning imbued by the additional parameters= the derived type may add to the JOSE header. "typ" is there to provide th= e type of the entire object, including what you're calling the wrapper part= s. -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Thursday, May 30, 2013 7:58 AM To: Mike Jones Cc: Jim Schaad; jose@ietf.org; Dick Hardt Subject: Re: [jose] Should we delete the "typ" header field Isn't that requirement met by "cty"? The only thing JOSE adds is a crypto = wrapper around the real application content. If you're an application, you= know a JOSE object is the thing you want because it contains the content y= ou want -- it's a JWT because it contains JWT claims. Inheritance is the wrong metaphor. This is encapsulation of application da= ta: if (jws.valid && jws.cty =3D=3D "application/jwt_claims") { jwtClaims =3D jws.content; } --Richard On Thu, May 30, 2013 at 10:43 AM, Mike Jones > wrote: Thanks for sharing the S/MIME details. Although I was actually making the = analogy to MIME - not S/MIME. Like many analogies, it's imperfect, but I b= elieve still illustrative. The reason that the analogy isn't perfect is that the JOSE data structures = are used to build application-specific data structures that are legal JOSE = data structures but also have additional properties - including additional = header fields with specific semantics. (When we agreed to ignore not-under= stood header fields we let that horse out of the barn.) For instance, Dick= Hardt uses JWEs with issuer and audience fields in the headers, so they ca= n be used by routing software. Think of JOSE as the base class and the application types built using it as= derived classes. JWT is a derived class. Dick's structures are a derived= class. These derived classes sometimes need names. That's what "typ" is = for. -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Thursday, May 30, 2013 7:34 AM To: Mike Jones Cc: Jim Schaad; jose@ietf.org; Dick Hardt Subject: Re: [jose] Should we delete the "typ" header field You're mixing up "typ" and "cty". If you want to make the analogy to S/MIM= E, "cty" is the equivalent to Content-Type inside the protected MIME body; = "typ" is the content-type on the outer MIME header. Pasting in an example: -----BEGIN----- Content-Type: application/pkcs7-mime; smime-type=3Dsigned-data; name=3Dsmime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=3Dsmime.p7m 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh 6YT64V0GhIGfHfQbnj75 -----END----- The outer Content-Type, which is analogous to "typ", MUST be application/pk= cs7-mime, with a parameter indicating the type of CMS object. This is the = same as requiring "typ" to be JWE or JWS. The inner Content-Type (ASN.1/ba= se64 encoded in the example) can be anything, just like "cty". --Richard On Thu, May 30, 2013 at 12:53 AM, Mike Jones > wrote: Requiring that the "typ" value be only "JWS" or "JWE" would be analogous to= the MIME spec requiring that the Content-Type: field be only "text/plain" = or "message/external-body". It would render it useless. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Wednesday, May 29, 2013 8:03 PM To: Mike Jones Cc: Jim Schaad; jose@ietf.org; Dick Hardt Subject: Re: [jose] Should we delete the "typ" header field If this is the level of "type" you're referring to, I think we should drop = it from the spec. It's an application-layer thing that the app can add or = not according to its wishes. I'm with Dick on this. I think we should either have a mandatory indicator= of what type of JOSE object this, or nothing at all. If the former, the = allowable values are "JWE" and "JWS". The "+JSON" options are non-sensical= -- the app needs to know what it's parsing before it gets this header. Wh= ile I have a preference for the former (for clarity), the latter approach i= s also OK with me, since the MIME types are specific to JWE/JWS. Another approach here would be to address the JSON and compact forms separa= tely. The JSON form has no need of "typ" at all, since the type of the obj= ect is completely clear from what fields are there, e.g., "recipients" vs. = "signatures". For the compact form, we could do something like James's "E.= "/"S." prefix idea, which you need because the dot-separated components hav= e different meanings and no field names to indicate this. --Richard On Wed, May 29, 2013 at 8:30 PM, Mike Jones > wrote: A standard library is unlikely to know the meanings of all possible "typ" v= alues - and more to the point, it doesn't have to. It's the application's = job to determine that "this blob is a JOSE object" and then pass it to a st= andard library, which will then ignore the "typ" value. A standard JOSE library won't know what "typ": "JWT" means. It won't know = what "typ": "BCGovToken" is, should the BC Government want to declare that = it's using a token with particular characteristics. It won't know what "ty= p": "XMPP" is, should XMPP want to declare that it's using a JOSE data stru= cture with particular characteristics. Etc. All these values can be registered in the registry and used by applications= that understand them. That's the application's job - not the library's jo= b. The "typ" field is just there so that applications have a standard plac= e to make any such declarations that they may need. -- Mike From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Wednesday, May 29, 2013 5:18 PM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] Should we delete the "typ" header field I'd prefer to be able to use standard libraries for creating and parsing to= kens, and not specialized libraries dependent on the use case. I strongly think we either drop "typ" or make it required. On Wed, May 29, 2013 at 5:03 PM, Mike Jones > wrote: It's fine for your application to specify that it's required for your use c= ase. Not applications need it, so they shouldn't be forced to pay the spac= e penalty of an unnecessary field. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Dick Hardt Sent: Wednesday, May 29, 2013 4:56 PM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Should we delete the "typ" header field I use it all the time and my code would barf if it was not there. I think it should be required rather than be a hint if it is going ot be th= ere. On Wed, May 29, 2013 at 4:40 PM, Jim Schaad > wrote: I think the values just changed However the way you are using it would be an argument to say that it should= be a required field. Are you just using it as a hint if it exists and the= n looking at the rest of the fields if it is not present? Jim From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Wednesday, May 29, 2013 3:49 PM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Should we delete the "typ" header field Well, I have been using, but now realize the spec changed or I was confused= . I had been setting "typ" to be either "JWE" or "JWS" depending on the type = of token I was creating or parsing as it was easier than looking at "alg" As currently defined, I don't see value in "typ". -- Dick On Wed, May 29, 2013 at 3:02 PM, Jim Schaad > wrote: In reading the documents, I am trying to understand the justification for h= aving the "typ" header parameter in the JOSE documents. The purpose of the field is to hold the type of the object. In the past, I= believe that values which should now be placed in the cty field (such as "= JWT") were placed in this field as well. However the parameter is optional= and an implementation cannot rely on its being present. This means that f= or all practical purposes all of the code to determine the value of the typ= e field from the values of the alg and enc fields. If the field was mandat= ory then this code would disappear at a fairly small space cost and I can u= nderstand why the parameter would be present. Can anybody justify why this field should be present in the document - or s= hould it just disappear? Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- -- Dick -- -- Dick _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- -- Dick _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en -- -- Dick -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --_000_CE8995AB5D178F44A2154F5C9A97CAF40255A5CA075AHE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&nbs= p;

My take on the “typ= 221; header field:

&n= bsp;

-  &nbs= p;       “typ” must be optional because some application just knows wh= at it is dealing with. It is a waste of space in this case.

-<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp;    “typ= 221; is reserved header name and the values SHOULD be JWS, JWE, JWT. No MUS= T on the values.

-          For a general purpose JOSE library it makes sense to hav= e “typ” and I would write it so that it  throws an excepti= on on validateJWS( {“typ”:”JWE”, …})
Espec= ially if crit=3D[”typ”].

 

I would = like to keep (the first paragraph of)

https://tools.ietf.org/html/draft-ietf-jose-js= on-web-signature-11#section-4.1.8

as it is.

 

-Axel=

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf= Of Nat Sakimura
Sent: Thursday, June 06, 2013 3:04 AM
= To: Dick Hardt
Cc: Richard Barnes; Mike Jones; Brian Campbell= ; Jim Schaad; jose@ietf.org
Subject: Re: [jose] Should we delete = the "typ" header field

=  

It is giving the meaning to = the signature - metadata about the signature, so I thought header would be = more appropriate, besides, the payload is binary and I can avoid double bas= e64 encoding that way. 

 

2013/6/6 Dick Hardt <dick.hardt@gmail.com>

Why would you need that in the header? Why not in the payload?

 

On Wed, Jun 5, 2013 at= 5:31 PM, Nat Sakimura <sakimura@gmail.com> wrote:

What I was thinking as an example was to have 'datetime' as a public= header parameter to be used generally, and then differentiate between two = cases of 'agreement' and 'timestamp'. It is the same signing operation over= the original (e.g., a MS word document), but from an application point of = view, it is a bit different. Former constitute an agreement while the later= does not. The type=3Dtimestamp just signifies that the original document e= xisted at the time indicated. 

 

<= p class=3DMsoNormal>2013/6/5 Richard Barnes <rlb@ipv.sx>

I'm not sure I understand the use case here.  Let me look at a co= uple of options, and hopefully one of them will be what you meant :)  =

 

If it's just a signed timestamp you're talking about, th= en that's adequately described by cty=3D"timestamp", typ=3D"= JWS".

 <= /p>

If you want to sign something and add a = timestamp in the header, then typ=3D"timestamp" isn't accurate ac= cording to the current specification.  The type of the whole object wo= uld have to be something like "timestamped-content".  And in= that case, an application can easily recognized that it's timestamped cont= ent by looking for the timestamp field in the header, so the "typ"= ; isn't really helpful.

=  

 

=

Moving from the example to the general question:<= o:p>

 

I think we finally have some common understanding o= n this list as to what Mike means by "typ" in the current documen= t -- a label for the application-layer type of the overall object.  Th= anks to Mike for clarifying that in this discussion.

 

The question is whether this is a sufficiently useful thing to have in th= e core spec.  Obviously, applications have to know what type of object= they're dealing with when they get a JOSE object.  That includes (1) = what type of content is in the payload, and (2) what application-layer fiel= ds are required to be in the header.  (1) is covered by "cty"= ;.  So "typ" is only useful in the case where:

A. The application is storing application-= layer data in the JOSE header

B. The required application-layer fields can be different for different ob= jects

C. The required applica= tion-layer fields can be different for different objects of the same conten= t type

D. The required applic= ation-layer fields are not indicated by other application-layer context

 

=

Are there any known applications that meet these crite= ria?  JWT does not, for several reasons. 

1. (!A) JWT does not store application-layer data in= the JOSE header, only in the claims in the body

<= p class=3DMsoNormal>2. (!C) A JWT object can indicate with "cty" = that it contains JWT claims or another JWT, either of which makes it obviou= s that this is a JWT

3. (!D) = In the OAuth context, the Token Type value indicates what type of token is = being presented, e.g., JWT

 

So there's not really an= y known use case for "typ" as currently specified.  On the o= ther hand, Dick and James have pointed out that it can be useful to have &q= uot;typ" indicate whether the object at hand is a JWE or JWS.  Wh= ich brings us back to:

-- Cha= nge the definition of "typ" so that it indicates the JOSE-layer t= ype (JWE/JWS)

-- Remove "= ;typ" altogether

&n= bsp;

 

 

 

 

 

On Wed, Jun 5, 2013 at = 8:53 AM, Nat Sakimura <sakimura@gmail.com> wrote:

What about such as this? 

 

cty: origina= l

typ: timestamp

=  

2013/6/5 Richard Barnes <= rlb@ipv.sx>

It would be a good point, if it were true := )  In particular, this part: "[dropping 'typ'] is going= to cause each and every application that uses JOSE to define their own fie= ld"

 

So far, I've heard of exactly one applica= tion of JOSE that requires "typ" in the way it is currently speci= fied, namely JWT.  

 

On the other hand, Dick's = applications are apparently using it differently (and, IMO, properly) to di= stinguish JWE/JWS.  Then there are all the applications out there that= are OK using application context and "cty" to recognize what typ= e of object they have.  Apps using CMS have been doing this for ages.<= o:p>

 

So it's not at all clear to me that there's any oth= er application that would use "typ" besides JWT.  And it's n= ot clear to me that JWT needs it.

 

<= p class=3DMsoNormal>--Richard

&n= bsp;

 

 

=

 <= /p>

On Fri, May 31, 2013 at 5:45 PM, Brian Campbel= l <bcamp= bell@pingidentity.com> wrote:

Nat makes a good point here, I think.

=

 

On Thu, May 30, 2013 at 9:31 AM, Nat Sakimura <<= a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com> wrote:

From what I understan= d, both typ and cty are something to be consumed by the application and not= JOSE processor. From the point of view of the JOSE processor, they should = be ignored. 

 =

We could drop both fields from JOSE spe= cs, but that is going to cause each and every application that uses JOSE to= define their own field, which is a waste. That is why we are defining them= here. 

 

I would rather drop them than define J= OSE processing semantics to these fields. 

<= div>

&nbs= p;

2013/5/31 Mike Jones <Michael.Jones@microsof= t.com>

No, “cty” i= s used by the derived class to determine the type of the encapsulated field= .  But that’s not a complete description of the *entire objec= t* - especially not the additional meaning imbued by the additional par= ameters the derived type may add to the JOSE header.  “typ”= ; is there to provide the type of the entire object, including what youR= 17;re calling the wrapper parts.

 <= /span>

      &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   -- Mike

 

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Thursday, May 30, 2013 7= :58 AM


To: M= ike Jones
Cc: Jim Schaad; jose@ietf.org; Dick Hardt
Subject: Re: [jose] Sho= uld we delete the "typ" header field

 

Isn't that requirement met = by "cty"?  The only thing JOSE adds is a crypto wrapper arou= nd the real application content.  If you're an application, you know a= JOSE object is the thing you want because it contains the content you want= -- it's a JWT because it contains JWT claims.

&= nbsp;

Inheritance is the wrong metaphor. &n= bsp;This is encapsulation of application data:

if (jws.valid && jws.cty =3D=3D "application/jwt_claims&qu= ot;) {

    jwtClaims =3D jws.cont= ent;

}

&nbs= p;

--Richard

 

On Thu, May 30, 2013 at 10:43 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Thanks = for sharing the S/MIME details.  Although I was actually making the an= alogy to MIME – not S/MIME.  Like many analogies, it’s imp= erfect, but I believe still illustrative.

 

The reason that the analogy isn= ’t perfect is that the JOSE data structures are used to build applica= tion-specific data structures that are legal JOSE data structures but also = have additional properties – including additional header fields with = specific semantics.  (When we agreed to ignore not-understood header f= ields we let that horse out of the barn.)  For instance, Dick Hardt us= es JWEs with issuer and audience fields in the headers, so they can be used= by routing software.

 =

Think of JOSE as the base class and the application= types built using it as derived classes.  JWT is a derived class.&nbs= p; Dick’s structures are a derived class.  These derived classes= sometimes need names.  That’s what “typ” is for.

 

=             &nb= sp;            =             &nb= sp;            =           -- Mike<= /o:p>

 

From: Richard Barne= s [mailto:rlb@ipv.sx] <= br>Sent: Thursday, May 30, 2013 7:34 AM


To: Mike Jones
Cc: Jim Schaad; jose@ietf.org; Dick Hardt
S= ubject: Re: [jose] Should we delete the "typ" header field

 

Y= ou're mixing up "typ" and "cty".  If you want to m= ake the analogy to S/MIME, "cty" is the equivalent to Content-Typ= e inside the protected MIME body; "typ" is the content-type on th= e outer MIME header.  Pasting in an example:

 

-----BEGIN-----

Content-Type: application/pkcs7-mime; smime-type=3Dsigned= -data;

     name=3Dsmime.p7m=

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename=3Dsmime.p= 7m

 

5= 67GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7

77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH

HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H= 7n8HHGghyHh

6YT64V0GhIGfHfQbnj75=

-----END-----

 

The outer Conte= nt-Type, which is analogous to "typ", MUST be application/pkcs7-m= ime, with a parameter indicating the type of CMS object.  This is the = same as requiring "typ" to be JWE or JWS.  The inner Content= -Type (ASN.1/base64 encoded in the example) can be anything, just like &quo= t;cty".

 

--Richard

 

 

 

 

On Thu, May 30, 2013 a= t 12:53 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

<= div>

Requiring that the “typ” value be only &= #8220;JWS” or “JWE” would be analogous to the MIME spec r= equiring that the Content-Type: field be only “text/plain” or &= #8220;message/external-body”.  It would render it useless.

 

&nb= sp;            =             &nb= sp;            =             &nb= sp;         -- Mike

 

From: jose-bounces@ietf.org [mail= to:jose-bounces@= ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday,= May 29, 2013 8:03 PM
To: Mike Jones
Cc: Jim Schaad; jose@ietf.org; Dick Ha= rdt


Subject: Re: [jose] Sh= ould we delete the "typ" header field

<= div>

 

If this is the level of &q= uot;type" you're referring to, I think we should drop it from the spec= .  It's an application-layer thing that the app can add or not accordi= ng to its wishes.

 

I'm with Dick on this.  I think we should either have a mandat= ory indicator of what type of JOSE object this, or nothing at all.   I= f the former, the allowable values are "JWE" and "JWS".=  The "+JSON" options are non-sensical -- the app needs to k= now what it's parsing before it gets this header.  While I have a pref= erence for the former (for clarity), the latter approach is also OK with me= , since the MIME types are specific to JWE/JWS.

 

Another approach here would be = to address the JSON and compact forms separately.  The JSON form has n= o need of "typ" at all, since the type of the object is completel= y clear from what fields are there, e.g., "recipients" vs. "= signatures".  For the compact form, we could do something like Ja= mes's "E."/"S." prefix idea, which you need because the= dot-separated components have different meanings and no field names to ind= icate this.

 

--Richard

 

On Wed, May 29, 2013 at 8:30 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

A standard library is u= nlikely to know the meanings of all possible “typ” values ̵= 1; and more to the point, it doesn’t have to.  It’s= the application’s job to determine that “this blob is a JOSE o= bject” and then pass it to a standard library, which will then ignore= the “typ” value.

 

A standard JOSE library won’t know wh= at “typ”: “JWT” means.  It won’t know wh= at “typ”: “BCGovToken” is, should the BC Government= want to declare that it’s using a token with particular characterist= ics.  It won’t know what “typ”: “XMPP” i= s, should XMPP want to declare that it’s using a JOSE data structure = with particular characteristics.  Etc.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

All these values can be reg= istered in the registry and used by applications that understand them. = ; That’s the application’s job – not the library’s = job.  The “typ” field is just there so that applications h= ave a standard place to make any such declarations that they may need.

 

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ; -- Mike

 

= From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Wednesday, May 29, 2= 013 5:18 PM
To: Mike Jones
Cc: Jim Schaad; jose@ietf.org<= /p>


Subject: Re: [jose] Should we delete the &qu= ot;typ" header field

 =

I'd prefer to be able to use standard libraries = for creating and parsing tokens, and not specialized libraries dependent on= the use case.

 

I strongly think we either drop "typ" or make it required.

 

On Wed, May= 29, 2013 at 5:03 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:<= /o:p>

It’s fine for your application to sp= ecify that it’s required for your use case.  Not applications ne= ed it, so they shouldn’t be forced to pay the space penalty of an unn= ecessary field.

 =

         &nb= sp;            =             &nb= sp;            =             &nb= sp;    -- Mike

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of <= /b>Dick Hardt
Sent: Wednesday, May 29, 2013 4:56 PM


To: Jim Schaad
Cc: jose@ietf.org
Subject: Re: [jose] Should we delete the "typ" header field<= /p>

 

I use it a= ll the time and my code would barf if it was not there.

=

 

I think it should be required= rather than be a hint if it is going ot be there.

 

On Wed, May 29, 2013 at 4:40 PM, J= im Schaad <i= etf@augustcellars.com> wrote:

= I think the values just changed

 

However the way you are using it would be= an argument to say that it should be a required field.  Are you just = using it as a hint if it exists and then looking at the rest of the fields = if it is not present?

 =

Jim

 

 

From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Wednesday, May = 29, 2013 3:49 PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: Re: [j= ose] Should we delete the "typ" header field

 

Well, I have= been using, but now realize the spec changed or I was confused.=

 

I had been setting = "typ" to be either "JWE" or "JWS" depending o= n the type of token I was creating or parsing as it was easier than looking= at "alg"

 

As currently defined, I don't see value in "typ".=

 

-= - Dick

 

 

On Wed, May 29, 2013 at 3:02 PM, Jim Sc= haad <ietf@a= ugustcellars.com> wrote:

In reading t= he documents, I am trying to understand the justification for having the &#= 8220;typ” header parameter in the JOSE documents.

 

The purpose of the field is to hold the type = of the object.  In the past, I believe that values which should now be= placed in the cty field (such as “JWT”) were placed in this fi= eld as well.  However the parameter is optional and an implementation = cannot rely on its being present.  This means that for all practical p= urposes all of the code to determine the value of the type field from the v= alues of the alg and enc fields.  If the field was mandatory then this= code would disappear at a fairly small space cost and I can understand why= the parameter would be present.

 

Can anybody justify why this field should be present in the docume= nt – or should it just disappear?

 

Jim

 <= /span>


_____________________________________= __________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose



--
-- Dick



=

 

--
-- Dick


_______________________________________= ________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose<= o:p>



&= nbsp;

--
-- Dick

=


_______________________________________________
j= ose mailing list
jose= @ietf.org
https://www.ietf.org/mailman/listinfo/jose

 

 

 


_______________________________________= ________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose<= o:p>



 

= --

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________
jo= se mailing list
jose@= ietf.org
https://www.ietf.org/mailman/listinfo/jose

=

 

 



=  

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

 


<= br clear=3Dall>

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en<= o:p>



 

--
-- Dick



&nbs= p;

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/@_nat_en

= --_000_CE8995AB5D178F44A2154F5C9A97CAF40255A5CA075AHE111541eme_-- From ve7jtb@ve7jtb.com Fri Jun 7 04:24:04 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BC521F9408 for ; Fri, 7 Jun 2013 04:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vcJC7hSkrrE for ; Fri, 7 Jun 2013 04:24:01 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DC6BA21F8916 for ; Fri, 7 Jun 2013 04:23:46 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m19so2914251wev.22 for ; Fri, 07 Jun 2013 04:23:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=4VsFl9kGsfd59BzjEjEaRqNRJfWOmBZCYIqvaF3owEc=; b=jjJVv6zXV2HxbXvqJTKYDxKui2ktlkVMXpmgwQN2nSjpBC8Or9S7RY+ysrLYx1SqVk V/XPM8MqybS/1Yi+DnmDVqvmGcpiHnhhzueNxO0qYuGy7LtZ9vfV2aZr7G16kmPzcU9y HkxN7gBeqyNsHrkHxw5QoX+IB3Ea6Mjn9z4prBueh/oeBxhO+VT8PadU7BTPj2YMruwF mJE4tSFXXC9t1QX3yTYmPmOPmQdT6/xwcggLhFqkTu32qm611XeaJ1XHKlZz7q2NvwHx KxtU94Zg5rGKjr3zycKHhSsLXCGSA4gAKciiwQjkoS0m/QknEsjRCUyQEKEyrwU8wUF1 /9WA== X-Received: by 10.180.189.41 with SMTP id gf9mr1627529wic.32.1370604225815; Fri, 07 Jun 2013 04:23:45 -0700 (PDT) Received: from [192.168.0.93] ([87.213.45.202]) by mx.google.com with ESMTPSA id h8sm21931176wiz.9.2013.06.07.04.23.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Jun 2013 04:23:43 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_327D7355-3DBA-4569-ADBC-37ABCC85737D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: Date: Fri, 7 Jun 2013 13:23:40 +0200 Message-Id: <5086C9DA-68F6-4ECE-87B5-FA12E493E07D@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436780758E@TK5EX14MBXC283.redmond.corp.microsoft.com> To: X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkTR/24bm/vXqvs3zwbIZ6bAAX+I4SP5gz3IJekp6YF29bteiIlfWGFqaGne6DWR6jcJM84 Cc: rlb@ipv.sx, Michael.Jones@microsoft.com, jose@ietf.org Subject: Re: [jose] What are we doing here? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 11:24:04 -0000 --Apple-Mail=_327D7355-3DBA-4569-ADBC-37ABCC85737D Content-Type: multipart/alternative; boundary="Apple-Mail=_36A31F44-FB7C-4204-891D-731F01878F85" --Apple-Mail=_36A31F44-FB7C-4204-891D-731F01878F85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 crit was a relatively recent WG consensus that allowed for non critical = header parameters by default. =20 Richard holds the unrelenting position that headers should not have = integrity protection, and all header parameters should be optional = unless defined otherwise in the core spec. I don't want to rehash the argument, but the compromise allowed for non = critical to be the default and future extensions to use crit to mark = parameters that need to be understood by the recipient to securely = process the message. I understand the incremental edging towards the outcome you want, but = endlessly revisiting consensus decisions will never allow us to finish. As to "typ" I agree that it's main use is by JWT where it is described. = That is a result of splitting the specs into two workgroups. =20 It is an optional field, we should clarify its definition so that JWT = and other specs that need it have it available without potential = namespace issues. That is what I thought WG decided. On the topic of changes the clock is running down for projects with = dependencies on JOSE. At some point they will settle for what ever = draft is current and ship based on that. That would be an interoperability tragedy. I have no control over what = Mozzila and others decide, but at the moment we don't seem to be = instilling the confidence in others that we are capable of moving the = ball the last yard over the line (My attempt at a sports analogy). I agree with Axel and Mike on finishing. John B. On 2013-06-07, at 11:53 AM, wrote: > +1 to Mike=92s comments. > =20 > Usefulness of the standard is the important thing. > =20 > =20 > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Mike Jones > Sent: Friday, June 07, 2013 7:19 AM > To: Richard Barnes; jose@ietf.org > Subject: Re: [jose] What are we doing here? > =20 > Excellent question, Richard, because it gets to the heart of why the = JOSE specs are already highly successful and widely adopted. > =20 > - We are building useful tools that solve real problems for = developers. > - We are practically demonstrating the value of rough consensus and = running code. > - We are making simple things simple. > - We are making complex things possible, when necessary (but not at = the expense of keeping simple things simple). > - We are developing specs with an explicit goal of enabling = ubiquitous adoption. > - We are developing specs guided by practical engineering tradeoffs = to enable commonly useful functionality in a straightforward manner. > =20 > The level of adoption, with dozens of deployed implementations, is = compelling evidence that we=92ve already achieved the goals above. It=92s= time to =93ship it=94, as making the JOSE specs actual standards will = only increase their adoption and value to the industry. > =20 > That=92s what we=92re doing here. > =20 > -- Mike > =20 > P.S. I would be careful reasoning from the premise of =93The perfect = protocol is one from which nothing can be removed=94. By that logic, = the perfect specification is the null specification, which leaves all = possibilities open, and solves no actual problems. ;-) > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard Barnes > Sent: Thursday, June 06, 2013 2:44 PM > To: jose@ietf.org > Subject: [jose] What are we doing here? > =20 > The conversation about "typ" has brought us back to a familiar = question for this working group -- what are we trying to do here? > =20 > The current document is ambiguous on this topic. On the one hand, it = mostly covers the crypto bases, with things like "alg" and "enc". On = the other hand, it mixes in application design concepts like "typ" and = "crit". The result is a spec that's ambiguous in purpose and complex. = If I'm building an application with this, how do I decide what goes in = the "crit" field, or what values to use for "typ"? =20 > The charter for this working group is not ambiguous on this topic. = This group is chartered to do signing and encryption. The JOSE formats = should carry the parameters needed to perform those operations. = Anything else is extraneous, and in the spirit of "The perfect protocol = is one from which nothing can be removed", should be removed. > =20 > Now, I'm not going to be a hard-liner on this. I won't complain about = "zip" and "cty", since they are clearly defined and have clear use = cases. But "crit" and "typ" are so ambiguous and so little supported by = use cases*, that they really should go. > =20 > > =20 > --Richard > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_36A31F44-FB7C-4204-891D-731F01878F85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 crit was a relatively recent WG = consensus that allowed for non critical header parameters by default. =  

Richard holds the unrelenting position that = headers should not have integrity protection, and all header parameters = should be optional unless defined otherwise in the core = spec.

I don't want to rehash the argument, but = the compromise allowed for non critical to be the default and future = extensions to use crit to mark parameters that need to be understood by = the recipient to securely process the = message.

I understand the incremental edging = towards the outcome you want, but endlessly revisiting consensus = decisions will never allow us to finish.

As to = "typ" I agree that it's main use is by JWT where it is described. That = is a result of splitting the specs into two workgroups. =   
It is an optional field, we should clarify its = definition so that JWT and other specs that need it have it available = without potential namespace issues.

That is = what I thought WG decided.

On the topic of = changes the clock is running down for projects with dependencies on = JOSE.   At some point they will settle for what ever draft is = current and ship based on that.
That would be an = interoperability tragedy.   I have no control over what Mozzila and = others decide,  but at the moment we don't seem to be instilling = the confidence in others that we are capable of moving the ball the last = yard over the line (My attempt at a sports = analogy).

I agree with Axel and Mike on = finishing.

John B.
On = 2013-06-07, at 11:53 AM, <Axel.Nennker@telekom.de> = wrote:

+1 to Mike=92s = comments.
 
Usefulness of the standard is the important = thing.
 
 
 
From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Friday, June 07, 2013 7:19 = AM
To: Richard= Barnes; jose@ietf.org
Subject: Re: [jose] What are we = doing here?
Excellent question, Richard, because it gets to the = heart of why the JOSE specs are already highly successful and widely = adopted.
 
  - We are building useful tools that = solve real problems for developers.
  - We are = practically demonstrating the value of rough consensus and running = code.
  - We are making simple things = simple.
  - We are making complex things possible, when = necessary (but not at the expense of keeping simple things = simple).
  - We are developing specs with an explicit = goal of enabling ubiquitous adoption.
  - We are = developing specs guided by practical engineering tradeoffs to enable = commonly useful functionality in a straightforward = manner.
 
The level of adoption, with dozens of = deployed implementations, is compelling evidence that we=92ve already = achieved the goals above.  It=92s time to =93ship it=94, as making = the JOSE specs actual standards will only increase their adoption and = value to the industry.
 
That=92s what we=92re doing = here.
 
 
P.S.  I would be careful reasoning from = the premise of =93The perfect protocol is one from which nothing = can be removed=94.  By that logic, the = perfect specification is the null specification, which leaves all = possibilities open, and solves no actual problems. = ;-)
 
 jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Thursday, June 06, 2013 = 2:44 PM
To: jose@ietf.org
Subject: [jose] What are we doing = here?
The = conversation about "typ" has brought us back to a familiar question for = this working group -- what are we trying to do = here?
The = current document is ambiguous on this topic.  On the one hand, it = mostly covers the crypto bases, with things like "alg" and "enc". =  On the other hand, it mixes in application design concepts like = "typ" and "crit".  The result is a spec that's ambiguous in purpose = and complex.  If I'm building an application with this, how do I = decide what goes in the "crit" field, or what values to use for "typ"? =    
The = charter for this working group is not ambiguous on this topic. =  This group is chartered to do signing and encryption.  The = JOSE formats should carry the parameters needed to perform those = operations.  Anything else is extraneous, and in the spirit of "The = perfect protocol is one from which nothing can be removed", should be = removed.
Now, = I'm not going to be a hard-liner on this.  I won't complain about = "zip" and "cty", since they are clearly defined and have clear use = cases.  But "crit" and "typ" are so ambiguous and so little = supported by use cases*, that they really should = go.
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_36A31F44-FB7C-4204-891D-731F01878F85-- --Apple-Mail=_327D7355-3DBA-4569-ADBC-37ABCC85737D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjA3MTEyMzQxWjAjBgkqhkiG9w0BCQQxFgQUfhMuBzFx aNC2WEFeLYv8UBFE8BowgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAlZJny+NcIUWPBFJ2vrZ8H8jEkKcrsZ2mtEyvhnAO 5uyjyjBB/u+CfZRMezulsLHGPk8ffXv4SrasgC4NdqC+w+erle5I5R18bdxT+J+hC2xOQBrCPp+W ZzN97oOjtrA2Ti4AGKZZ2U4MGqJY3kVC75ujHdjprGRXJ0s4Jb5dwySXCLB9YXy4rqt+rW2H0J2r jnHfxn/APq3g5fMqr2qFl7b2QjoGvSkItGC1k4pLjm5rhc52DQQrRz6nbT3ZTIrfR3zEqe8bWWO6 NTIfEvF1FyLAqCkVnl3k89gZ6adpVdnQ+oEBNC0vQrxaN4rU/x2aLv8YwrnVKITRSRtTKpc5CgAA AAAAAA== --Apple-Mail=_327D7355-3DBA-4569-ADBC-37ABCC85737D-- From sal@idmachines.com Fri Jun 7 05:23:40 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6174021F885A for ; Fri, 7 Jun 2013 05:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.466 X-Spam-Level: * X-Spam-Status: No, score=1.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5fyhIrsGbOD for ; Fri, 7 Jun 2013 05:23:26 -0700 (PDT) Received: from atl4mhfb03.myregisteredsite.com (unknown [209.17.115.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7922D21F8BC0 for ; Fri, 7 Jun 2013 05:22:59 -0700 (PDT) Received: from atl4mhob05.myregisteredsite.com ([209.17.115.101]) by atl4mhfb03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r57CMvsO018493 for ; Fri, 7 Jun 2013 08:22:57 -0400 Received: from mailpod1.hostingplatform.com ([10.30.71.117]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r57CMrPd024768 for ; Fri, 7 Jun 2013 08:22:53 -0400 Received: (qmail 11538 invoked by uid 0); 7 Jun 2013 12:22:53 -0000 X-TCPREMOTEIP: 74.104.46.28 X-Authenticated-UID: sal@idmachines.com Received: from unknown (HELO salPC) (sal@idmachines.com@74.104.46.28) by 0 with ESMTPA; 7 Jun 2013 12:22:51 -0000 From: "Salvatore D'Agostino" To: , , , References: <4E1F6AAD24975D4BA5B16804296739436780758E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Date: Fri, 7 Jun 2013 08:22:45 -0400 Message-ID: <00d101ce6379$b7d22bc0$27768340$@com> X-Mailer: Microsoft Office Outlook 12.0 MIME-Version: 1.0 Thread-Index: Ac5jZNh42fm3NoNMRqGYhN4btH2nsAAE2Hzw Content-Language: en-us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C9_01CE6358.2CBED9A0" Subject: Re: [jose] What are we doing here? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 12:23:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C9_01CE6358.2CBED9A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00CA_01CE6358.2CBED9A0" ------=_NextPart_001_00CA_01CE6358.2CBED9A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We don't have as strong opinion on typ and crit. In general the effort has focused on flexibility and encouraging code and use meeting the needs for signing and encryption. I believe these are the spirit of Mike and Axel's comments an d +1 to both of these. Apologies if blocked, seems our domain got blacklisted (thanks Register..) From: Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] Sent: Friday, June 07, 2013 5:53 AM To: Michael.Jones@microsoft.com; rlb@ipv.sx; jose@ietf.org Subject: Re: [jose] What are we doing here? +1 to Mike's comments. Usefulness of the standard is the important thing. From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, June 07, 2013 7:19 AM To: Richard Barnes; jose@ietf.org Subject: Re: [jose] What are we doing here? Excellent question, Richard, because it gets to the heart of why the JOSE specs are already highly successful and widely adopted. - We are building useful tools that solve real problems for developers. - We are practically demonstrating the value of rough consensus and running code. - We are making simple things simple. - We are making complex things possible, when necessary (but not at the expense of keeping simple things simple). - We are developing specs with an explicit goal of enabling ubiquitous adoption. - We are developing specs guided by practical engineering tradeoffs to enable commonly useful functionality in a straightforward manner. The level of adoption, with dozens of deployed implementations, is compelling evidence that we've already achieved the goals above. It's time to "ship it", as making the JOSE specs actual standards will only increase their adoption and value to the industry. That's what we're doing here. -- Mike P.S. I would be careful reasoning from the premise of "The perfect protocol is one from which nothing can be removed". By that logic, the perfect specification is the null specification, which leaves all possibilities open, and solves no actual problems. ;-) From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Thursday, June 06, 2013 2:44 PM To: jose@ietf.org Subject: [jose] What are we doing here? The conversation about "typ" has brought us back to a familiar question for this working group -- what are we trying to do here? The current document is ambiguous on this topic. On the one hand, it mostly covers the crypto bases, with things like "alg" and "enc". On the other hand, it mixes in application design concepts like "typ" and "crit". The result is a spec that's ambiguous in purpose and complex. If I'm building an application with this, how do I decide what goes in the "crit" field, or what values to use for "typ"? The charter for this working group is not ambiguous on this topic. This group is chartered to do signing and encryption. The JOSE formats should carry the parameters needed to perform those operations. Anything else is extraneous, and in the spirit of "The perfect protocol is one from which nothing can be removed", should be removed. Now, I'm not going to be a hard-liner on this. I won't complain about "zip" and "cty", since they are clearly defined and have clear use cases. But "crit" and "typ" are so ambiguous and so little supported by use cases*, that they really should go. --Richard ------=_NextPart_001_00CA_01CE6358.2CBED9A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We don’t have as strong opinion on typ and = crit.

 

In general the effort has focused on flexibility  and = encouraging code and use meeting the needs for signing and = encryption.  I believe these are the spirit of Mike and = Axel’s comments an d  +1 to both of = these.

 

Apologies if blocked, seems our domain got blacklisted (thanks = Register..)

 

From:= = Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] =
Sent: Friday, June 07, 2013 5:53 AM
To: = Michael.Jones@microsoft.com; rlb@ipv.sx; = jose@ietf.org
Subject: Re: [jose] What are we doing = here?

 

+1 to Mike’s comments.

 

Usefulness of the standard is the important = thing.

 

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Mike Jones
Sent: Friday, June 07, 2013 = 7:19 AM
To: Richard Barnes; jose@ietf.org
Subject: Re: = [jose] What are we doing here?

 

Excellent question, Richard, because it gets to the heart of why the = JOSE specs are already highly successful and widely = adopted.

 

  - We are building useful tools that solve real problems for = developers.

  - We are practically demonstrating the value of rough = consensus and running code.

  - We are making simple things simple.

  - We are making complex things possible, when necessary (but = not at the expense of keeping simple things = simple).

  - We are developing specs with an explicit goal of enabling = ubiquitous adoption.

  - We are developing specs guided by practical engineering = tradeoffs to enable commonly useful functionality in a straightforward = manner.

 

The level of adoption, with dozens of deployed implementations, is = compelling evidence that we’ve already achieved the goals = above.  It’s time to “ship it”, as making the = JOSE specs actual standards will only increase their adoption and value = to the industry.

 

That’s what we’re doing here.

 

           &nbs= p;            = ;            =             &= nbsp;           -- = Mike

 

P.S.  I would be careful reasoning from the premise of = “The perfect protocol is one from which nothing can be = removed”.  By that logic, the perfect specification is the null = specification, which leaves all possibilities open, and solves no actual = problems. ;-)

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Richard Barnes
Sent: Thursday, June 06, = 2013 2:44 PM
To: jose@ietf.org
Subject: = [jose] What are we doing here?

 

The = conversation about "typ" has brought us back to a familiar = question for this working group -- what are we trying to do = here?

 

The current document is ambiguous on this topic. =  On the one hand, it mostly covers the crypto bases, with things = like "alg" and "enc".  On the other hand, it = mixes in application design concepts like "typ" and = "crit".  The result is a spec that's ambiguous in purpose = and complex.  If I'm building an application with this, how do I = decide what goes in the "crit" field, or what values to use = for "typ"?    

The charter for this working group is not ambiguous on = this topic.  This group is chartered to do signing and encryption. =  The JOSE formats should carry the parameters needed to perform = those operations.  Anything else is extraneous, and in the spirit = of "The perfect protocol is one from which nothing can be = removed", should be removed.

 

Now, I'm not going to be a hard-liner on this.  I = won't complain about "zip" and "cty", since they are = clearly defined and have clear use cases.  But "crit" and = "typ" are so ambiguous and so little supported by use cases*, = that they really should go.

 

</rant>

 

--Richard

------=_NextPart_001_00CA_01CE6358.2CBED9A0-- ------=_NextPart_000_00C9_01CE6358.2CBED9A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITIjCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIEnTCC A4WgAwIBAgIQND3pK6wnNP+PyzSU+8xwVDANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoX DTIwMDUzMDEwNDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk 8n2rQTtiRjeuzcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTE hb2FUTV5pE5okHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov 66yhs2qqty5nNYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8 goqOpA6l14lD/BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6h hX71R2XL+E1XKHTSNP8wtu72YjAUjCzrAgMBAAGjgfQwgfEwHwYDVR0jBBgwFoAUrb2YejS0Jvf6 xCZU7wO94CTLVBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MBEGA1UdIAQKMAgwBgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNo dHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYB BQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQABvJzjYyiw8zEBwt973WKgAZ0jMQ+cknNTUeofTPrWn8TKL2d+eDMPdBa5kYeR 9Yom+mRwANge+QsEYlCHk4HU2vUj2zS7hVa0cDRueIM3HoUcxREVkl+HF72sav3xwtHMiV+xfPA+ UfI183zsYJhrOivg79+zfYbrtRv1W+yifJgT1wBQudEtc94DeHThBYUxXsuauZ2UxrmUN3Vy3ET7 Z+jw+iUeUqfaJelH4KDHPKBOsQo2+3dIn++Xivu0/uOUFKiDvFwtP9JgcWDuwnGCDOmINuPaILSj oGyqlku4gI51ykkH9jsUut/cBdmf2+Cy5k2geCbn5y1uf1/GHogVMIIFGjCCBAKgAwIBAgIQbRnq pxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVU MRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmly c3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1 MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU 4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHff sReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kAB W0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJk JpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IB SzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4 Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQK MAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVu dF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcN AQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjB MCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8 H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5 OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUlMIIEDaADAgECAhAxNisl hAwmPFmhraHt/QtWMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt aXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTEyMTAyMjAwMDAwMFoXDTEzMTAyMjIzNTk1OVowIzEhMB8GCSqGSIb3DQEJARYS c2FsQGlkbWFjaGluZXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyMUItbfY tMuC9vO6iN41DxtnlxM682Fr96jQQGvpQzUrj4tNMHUlad9Fge5rCHPryqG2bEATpf/fCunOsV9C 9D5+khqCpZlQzk6vdKxnHgv4tFv7KAv+6DxS9GCqgbNSLo1WSh16FnlwRAZT4jUd59GB5uHjxvEZ E4eOAEKL+izQIEBzpMMDxDOS4J2wU3W88mCPLcuEESGKE5QUgRV2ARmyWMPdJhpFUpZGJv183zYf JLLa6+mgd+cWbfPp3GUs+/xdpSd3gRY64XCsyPmygWC+zrw2XJW+bL1Ge+m5sUJ5DJSGE1XENdvj 2z6j0q56G1Q8SJrAY76XrTrNnGrMiwIDAQABo4IB4jCCAd4wHwYDVR0jBBgwFoAUehNOAHRbxnhj ZCfBL+KgW7x5xXswHQYDVR0OBBYEFGSBNSyMTkmxv/++DoKmF05IEiYnMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5j b21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNy bDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHQYDVR0RBBYwFIESc2FsQGlkbWFjaGluZXMuY29t MA0GCSqGSIb3DQEBBQUAA4IBAQA+jYBRYaQc2qf+SipdyHuI7A9W76ZCWAqCmeez66TNECSjbcvA pw1HEKiehUGT4BiGSqTEBLnXM4pqsD5vUZLMiFnVAXhkgkNAOBZFq9G/bJSPW6pW9cNIjWifyAtn wdqYXakYWQIuws08lYfGM/751/DXPioEuFSv0pqfCm/r9ashpU9+qMSmX4+nmS5VuUtRrVsyujq9 lQ0Jic737mkW6iVDIJzg4oE2ujL7l6dJBM5VdbCJns4y/R2iBn5JfIcO8ZACDuw/If558mBvhRzI K5iBLkgqVKM6C/XTQ9Z+rc0YOaooiOn2CO4hILdhicFwr8M6V5cTBMltmrfOLqwyMYIEZTCCBGEC AQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8g Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDE2KyWEDCY8WaGtoe39 C1YwCQYFKw4DAhoFAKCCApEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMwNjA3MTIyMjM5WjAjBgkqhkiG9w0BCQQxFgQUV9ckXYYr/wnJ9t7Pe5tbL6/nZW4wgbcG CSqGSIb3DQEJDzGBqTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsG CWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI hvcNAwICASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEw CgYIKoZIhvcNAgUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQMTYrJYQMJjxZoa2h7f0LVjCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJ BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDE2KyWEDCY8WaGtoe39C1YwDQYJKoZIhvcN AQEBBQAEggEAqjbK0Aj8TIdHHVpPAU+KD2P6tEyrmlrxk3YDVTh+visSI91F+sfL5qd4395vd9XV AeuIxN1ehmQxn46H4aEukHDJeay9DXhKBhntVP1Bq7sw34rbj/SYEteFTJLH4zXn2FRGdN5f6HHl CjadlRVf8q/wE7YTxz+iZtS2SVcIHDIfGmsAOES5ha/l5OF7rfv5o3gXjM+eqky7lwLaQdTTScaV qZ3ung0GPSfjL5yUpWE1rs5U/52zgpNho4CqQ9Wne9wnzMumhSLgqtRRn1f/RBGivYL3l7uyZC/B jRfIDZUv94NnxcdS4d42J2l9qbb3DcvtBLBTTnAphpFHMn2vkAAAAAAAAA== ------=_NextPart_000_00C9_01CE6358.2CBED9A0-- From rlb@ipv.sx Fri Jun 7 07:23:09 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C27D21F98AD for ; Fri, 7 Jun 2013 07:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzcdK5BxiFXz for ; Fri, 7 Jun 2013 07:23:04 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF0821F9744 for ; Fri, 7 Jun 2013 07:23:03 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id o13so3288793oag.25 for ; Fri, 07 Jun 2013 07:23:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=7z8nw3g7bh5SL+sX+88cHcqXuMT813UUAyNE8m5ytog=; b=TPbSDRaKQsWHDeBdEqS9PMuz0W0kA+u9ZKAei8JYaQIW8POvOjE0LixcqMP/nE/Y1f o+eJPddJ9X6v26hc5oIHSrKkJstr6Jn8vMHY8suID+9iGw16StGbnykWvUmYXM3brXjo dMJ8S7dn/W1CqxivIEy8nCgU6i/dne2bEQXOunSS3SEg/GFXSlia54Z+KIkXDKjSMt3a vq0a/JxGqXwN0Fa/4i1t/tTckZlwzQULlmEMYJa69Jj1HLrm8+mGFhrIoqbRRzOb4a/Q ufvX2XdE0rAVhdF4VeZuTPwI25YBRrUH9BA6tEKMLYKxYZuyZkJcqtC+0Eioq5c3yTab bqog== MIME-Version: 1.0 X-Received: by 10.182.60.136 with SMTP id h8mr21554536obr.47.1370614983352; Fri, 07 Jun 2013 07:23:03 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Fri, 7 Jun 2013 07:23:03 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436780758E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436780758E@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 7 Jun 2013 10:23:03 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c1c42034f5a504de912bfe X-Gm-Message-State: ALoCoQn+JZvpu5YTp3U4T+YuCv94aLPbJ3fJCu2Yb5aTLkgpNeavJzFVCVfrUKFdMOqnfUefIDnf Cc: "jose@ietf.org" Subject: Re: [jose] What are we doing here? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:23:09 -0000 --001a11c1c42034f5a504de912bfe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Of course, motherhood, apple pie, etc. :) The question is what we're trying to help developers do. The developers I talk to want a simple tool to do crypto stuff, full stop. They don't want semantic validation, critical fields, etc. The adoption you're pointing to is not really relevant to the process here. The deployed implementations you're talking about are all in a limited space, covering one use case. And the current solution comes with baggage for that use case that adds complexity for everyone else. If you wanted to address that one use case, you should have chartered for that, not general signing and encryption. Nonetheless, on timing, I agree that I'm getting a little bored with fighting over this :) I'm working on a review of -11 that tries to package up all the remaining comments such that they can get resolved and we can move on with life. --Richard On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones wro= te: > Excellent question, Richard, because it gets to the heart of why the > JOSE specs are already highly successful and widely adopted.**** > > ** ** > > - We are building useful tools that solve real problems for developers.= * > *** > > - We are practically demonstrating the value of rough consensus and > running code.**** > > - We are making simple things simple.**** > > - We are making complex things possible, when necessary (but not at the > expense of keeping simple things simple).**** > > - We are developing specs with an explicit goal of enabling ubiquitous > adoption.**** > > - We are developing specs guided by practical engineering tradeoffs to > enable commonly useful functionality in a straightforward manner.**** > > ** ** > > The level of adoption, with dozens of deployed implementations, is > compelling evidence that we=92ve already achieved the goals above. It=92= s time > to =93ship it=94, as making the JOSE specs actual standards will only inc= rease > their adoption and value to the industry.**** > > ** ** > > That=92s what we=92re doing here.**** > > ** ** > > -- Mike**** > > ** ** > > P.S. I would be careful reasoning from the premise of =93The perfect > protocol is one from which nothing can be removed=94. By that logic, the > perfect specification is the null specification, which leaves all > possibilities open, and solves no actual problems. ;-)**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Thursday, June 06, 2013 2:44 PM > *To:* jose@ietf.org > *Subject:* [jose] What are we doing here?**** > > ** ** > > The conversation about "typ" has brought us back to a familiar question > for this working group -- what are we trying to do here?**** > > ** ** > > The current document is ambiguous on this topic. On the one hand, it > mostly covers the crypto bases, with things like "alg" and "enc". On the > other hand, it mixes in application design concepts like "typ" and "crit"= . > The result is a spec that's ambiguous in purpose and complex. If I'm > building an application with this, how do I decide what goes in the "crit= " > field, or what values to use for "typ"? **** > > The charter for this working group is not ambiguous on this topic. This > group is chartered to do signing and encryption. The JOSE formats should > carry the parameters needed to perform those operations. Anything else i= s > extraneous, and in the spirit of "The perfect protocol is one from which > nothing can be removed", should be removed.**** > > ** ** > > Now, I'm not going to be a hard-liner on this. I won't complain about > "zip" and "cty", since they are clearly defined and have clear use cases. > But "crit" and "typ" are so ambiguous and so little supported by use > cases*, that they really should go.**** > > ** ** > > **** > > ** ** > > --Richard**** > --001a11c1c42034f5a504de912bfe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Of course, motherhood, apple pie, etc. :)

The question is what we're trying to help developers do. =A0The deve= lopers I talk to want a simple tool to do crypto stuff, full stop. =A0They = don't want semantic validation, critical fields, etc. =A0

The adoption you're pointing to is not really relev= ant to the process here. =A0The deployed implementations you're talking= about are all in a limited space, covering one use case. =A0And the curren= t solution comes with baggage for that use case that adds complexity for ev= eryone else. =A0If you wanted to address that one use case, you should have= chartered for that, not general signing and encryption.

Nonetheless, on timing, I agree that I'm getting a = little bored with fighting over this :) =A0I'm working on a review of -= 11 that tries to package up all the remaining comments such that they can g= et resolved and we can move on with life.

--Richard

On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Excellent question, Richa= rd, because it gets to the heart of why the JOSE specs are already highly s= uccessful and widely adopted.

=A0<= /p>

=A0 - We are building use= ful tools that solve real problems for developers.

=A0 - We are practically = demonstrating the value of rough consensus and running code.<= /span>

=A0 - We are making simpl= e things simple.

=A0 - We are making compl= ex things possible, when necessary (but not at the expense of keeping simpl= e things simple).

=A0 - We are developing s= pecs with an explicit goal of enabling ubiquitous adoption.

=A0 - We are developing s= pecs guided by practical engineering tradeoffs to enable commonly useful fu= nctionality in a straightforward manner.

=A0<= /p>

The level of adoption, wi= th dozens of deployed implementations, is compelling evidence that we=92ve = already achieved the goals above.=A0 It=92s time to =93ship it=94, as making the JOSE specs actual standards will only increase their adoptio= n and value to the industry.

=A0<= /p>

That=92s what we=92re doi= ng here.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

P.S.=A0 I would be carefu= l reasoning from the premise of =93The perfect protocol is one from = which nothing can be removed=94.=A0 By that logic, the perfect specification is the null specification, which = leaves all possibilities open, and solves no actual problems. ;-)=

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: jose@ietf.org=
Subject: [jose] What are we doing here?

=A0

The conversation about "typ" has brought u= s back to a familiar question for this working group -- what are we trying = to do here?

=A0

The current document is ambiguous on this topic. =A0= On the one hand, it mostly covers the crypto bases, with things like "= alg" and "enc". =A0On the other hand, it mixes in applicatio= n design concepts like "typ" and "crit". =A0The result = is a spec that's ambiguous in purpose and complex. =A0If I'm building a= n application with this, how do I decide what goes in the "crit" = field, or what values to use for "typ"? =A0 =A0

The charter for this working group is not ambiguous = on this topic. =A0This group is chartered to do signing and encryption. =A0= The JOSE formats should carry the parameters needed to perform those operat= ions. =A0Anything else is extraneous, and in the spirit of "The perfect protocol is one from which nothing can = be removed", should be removed.

=A0

Now, I'm not going to be a hard-liner on this. = =A0I won't complain about "zip" and "cty", since th= ey are clearly defined and have clear use cases. =A0But "crit" an= d "typ" are so ambiguous and so little supported by use cases*, t= hat they really should go.

=A0

</rant>

=A0

--Richard


--001a11c1c42034f5a504de912bfe-- From dick.hardt@gmail.com Fri Jun 7 07:33:13 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F45921F9285 for ; Fri, 7 Jun 2013 07:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[AWL=2.947, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYd65jutr6F0 for ; Fri, 7 Jun 2013 07:33:12 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id BC7DB21F85EB for ; Fri, 7 Jun 2013 07:33:11 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id d7so1887029bkh.25 for ; Fri, 07 Jun 2013 07:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ae05E4rJtx48SyY8D7P1GX+pbA0rKtoOxe0wzq0cJIE=; b=vp8ilZD9F5ezhk2nQE0VJAy9hKjSyDZTDrbOqkHzAgd3JjLk20BCr1rgvFUtzNuXfp xeIWcTTigZpA2j+VB8yPrK6JV8QOmhjelIEMK0O83dwff5laKx1s/YrFC+SccGG/TxWe BKUewYBfCzShHliDfTQb8mtctyqVzPjlNNClynATcV4GPWduO0A/kTI0JpllddNoNJ7u JEt0aAr3dWF+vuPqKL2v8pDdfjjEb0EgAqzafdTWZnCfaDra1Mwuxu3qVRszJ+CL/ktM xy2CPYHdVZRwa1l1u2+m0dDLOhZ7df5DIm8MlSFkCx4EoVLaM/UuejNd+aYnAOvQ8RnD PY4A== MIME-Version: 1.0 X-Received: by 10.204.163.130 with SMTP id a2mr12401101bky.62.1370615590558; Fri, 07 Jun 2013 07:33:10 -0700 (PDT) Received: by 10.204.168.12 with HTTP; Fri, 7 Jun 2013 07:33:10 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739436780758E@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 7 Jun 2013 07:33:10 -0700 Message-ID: From: Dick Hardt To: Richard Barnes Content-Type: multipart/alternative; boundary=bcaec52d5531664e0604de914f32 Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] What are we doing here? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:33:13 -0000 --bcaec52d5531664e0604de914f32 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable MIke: I don't find your response very useful for understanding the question Richard proposed. I find the spec confusing as to what I am supposed to do when as an implementer. It seems that it is clear to all the people associated with OpenID Connect, but without that context, it is confusing, and frankly, some of the parameters seem like hacks to me. Perhaps some additional clarification on what the parameters are intended for would assist? -- Dick On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes wrote: > Of course, motherhood, apple pie, etc. :) > > The question is what we're trying to help developers do. The developers = I > talk to want a simple tool to do crypto stuff, full stop. They don't wan= t > semantic validation, critical fields, etc. > > The adoption you're pointing to is not really relevant to the process > here. The deployed implementations you're talking about are all in a > limited space, covering one use case. And the current solution comes wit= h > baggage for that use case that adds complexity for everyone else. If you > wanted to address that one use case, you should have chartered for that, > not general signing and encryption. > > Nonetheless, on timing, I agree that I'm getting a little bored with > fighting over this :) I'm working on a review of -11 that tries to packa= ge > up all the remaining comments such that they can get resolved and we can > move on with life. > > --Richard > > > On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones w= rote: > >> Excellent question, Richard, because it gets to the heart of why the >> JOSE specs are already highly successful and widely adopted.**** >> >> ** ** >> >> - We are building useful tools that solve real problems for developers= . >> **** >> >> - We are practically demonstrating the value of rough consensus and >> running code.**** >> >> - We are making simple things simple.**** >> >> - We are making complex things possible, when necessary (but not at th= e >> expense of keeping simple things simple).**** >> >> - We are developing specs with an explicit goal of enabling ubiquitous >> adoption.**** >> >> - We are developing specs guided by practical engineering tradeoffs to >> enable commonly useful functionality in a straightforward manner.**** >> >> ** ** >> >> The level of adoption, with dozens of deployed implementations, is >> compelling evidence that we=92ve already achieved the goals above. It= =92s time >> to =93ship it=94, as making the JOSE specs actual standards will only in= crease >> their adoption and value to the industry.**** >> >> ** ** >> >> That=92s what we=92re doing here.**** >> >> ** ** >> >> -- Mike**** >> >> ** ** >> >> P.S. I would be careful reasoning from the premise of =93The perfect >> protocol is one from which nothing can be removed=94. By that logic, th= e >> perfect specification is the null specification, which leaves all >> possibilities open, and solves no actual problems. ;-)**** >> >> ** ** >> >> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >> Of *Richard Barnes >> *Sent:* Thursday, June 06, 2013 2:44 PM >> *To:* jose@ietf.org >> *Subject:* [jose] What are we doing here?**** >> >> ** ** >> >> The conversation about "typ" has brought us back to a familiar question >> for this working group -- what are we trying to do here?**** >> >> ** ** >> >> The current document is ambiguous on this topic. On the one hand, it >> mostly covers the crypto bases, with things like "alg" and "enc". On th= e >> other hand, it mixes in application design concepts like "typ" and "crit= ". >> The result is a spec that's ambiguous in purpose and complex. If I'm >> building an application with this, how do I decide what goes in the "cri= t" >> field, or what values to use for "typ"? **** >> >> The charter for this working group is not ambiguous on this topic. This >> group is chartered to do signing and encryption. The JOSE formats shoul= d >> carry the parameters needed to perform those operations. Anything else = is >> extraneous, and in the spirit of "The perfect protocol is one from which >> nothing can be removed", should be removed.**** >> >> ** ** >> >> Now, I'm not going to be a hard-liner on this. I won't complain about >> "zip" and "cty", since they are clearly defined and have clear use cases= . >> But "crit" and "typ" are so ambiguous and so little supported by use >> cases*, that they really should go.**** >> >> ** ** >> >> **** >> >> ** ** >> >> --Richard**** >> > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --=20 -- Dick --bcaec52d5531664e0604de914f32 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
MIke: I don't find your response very useful for under= standing the question Richard proposed. I find the spec confusing as to wha= t I am supposed to do when as an implementer. It seems that it is clear to = all the people associated with OpenID Connect, but without that context, it= is confusing, and frankly, some of the parameters seem like hacks to me. P= erhaps some additional clarification on what the parameters are intended fo= r would assist?

-- Dick


=
On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes <= span dir=3D"ltr"><rlb@ip= v.sx> wrote:
Of course, motherhood, appl= e pie, etc. :)

The question is what we're trying to = help developers do. =A0The developers I talk to want a simple tool to do cr= ypto stuff, full stop. =A0They don't want semantic validation, critical= fields, etc. =A0

The adoption you're pointing to is not really relev= ant to the process here. =A0The deployed implementations you're talking= about are all in a limited space, covering one use case. =A0And the curren= t solution comes with baggage for that use case that adds complexity for ev= eryone else. =A0If you wanted to address that one use case, you should have= chartered for that, not general signing and encryption.

Nonetheless, on timing, I agree that I'm getting a = little bored with fighting over this :) =A0I'm working on a review of -= 11 that tries to package up all the remaining comments such that they can g= et resolved and we can move on with life.

--Richard


On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

Excellent question, Richa= rd, because it gets to the heart of why the JOSE specs are already highly s= uccessful and widely adopted.

=A0<= /p>

=A0 - We are building use= ful tools that solve real problems for developers.

=A0 - We are practically = demonstrating the value of rough consensus and running code.<= /span>

=A0 - We are making simpl= e things simple.

=A0 - We are making compl= ex things possible, when necessary (but not at the expense of keeping simpl= e things simple).

=A0 - We are developing s= pecs with an explicit goal of enabling ubiquitous adoption.

=A0 - We are developing s= pecs guided by practical engineering tradeoffs to enable commonly useful fu= nctionality in a straightforward manner.

=A0<= /p>

The level of adoption, wi= th dozens of deployed implementations, is compelling evidence that we=92ve = already achieved the goals above.=A0 It=92s time to =93ship it=94, as making the JOSE specs actual standards will only increase their adoptio= n and value to the industry.

=A0<= /p>

That=92s what we=92re doi= ng here.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

P.S.=A0 I would be carefu= l reasoning from the premise of =93The perfect protocol is one from = which nothing can be removed=94.=A0 By that logic, the perfect specification is the null specification, which = leaves all possibilities open, and solves no actual problems. ;-)=

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: jose@ietf.org=
Subject: [jose] What are we doing here?

=A0

The conversation about "typ" has brought u= s back to a familiar question for this working group -- what are we trying = to do here?

=A0

The current document is ambiguous on this topic. =A0= On the one hand, it mostly covers the crypto bases, with things like "= alg" and "enc". =A0On the other hand, it mixes in applicatio= n design concepts like "typ" and "crit". =A0The result = is a spec that's ambiguous in purpose and complex. =A0If I'm building a= n application with this, how do I decide what goes in the "crit" = field, or what values to use for "typ"? =A0 =A0

The charter for this working group is not ambiguous = on this topic. =A0This group is chartered to do signing and encryption. =A0= The JOSE formats should carry the parameters needed to perform those operat= ions. =A0Anything else is extraneous, and in the spirit of "The perfect protocol is one from which nothing can = be removed", should be removed.

=A0

Now, I'm not going to be a hard-liner on this. = =A0I won't complain about "zip" and "cty", since th= ey are clearly defined and have clear use cases. =A0But "crit" an= d "typ" are so ambiguous and so little supported by use cases*, t= hat they really should go.

=A0

</rant>

=A0

--Richard



_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--
-- Dick --bcaec52d5531664e0604de914f32-- From Michael.Jones@microsoft.com Fri Jun 7 07:48:29 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94A721F8FDC for ; Fri, 7 Jun 2013 07:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbpvvnP6HNFB for ; Fri, 7 Jun 2013 07:48:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id EFEDA21F9050 for ; Fri, 7 Jun 2013 07:48:22 -0700 (PDT) Received: from BY2FFO11FD028.protection.gbl (10.1.15.203) by BY2FFO11HUB006.protection.gbl (10.1.14.164) with Microsoft SMTP Server (TLS) id 15.0.707.0; Fri, 7 Jun 2013 14:48:20 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Fri, 7 Jun 2013 14:48:20 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.110]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0136.001; Fri, 7 Jun 2013 14:48:10 +0000 From: Mike Jones To: Dick Hardt , Richard Barnes Thread-Topic: [jose] What are we doing here? Thread-Index: AQHOYv8CR0v9d+v7FEav765iFV2uepkps4EwgACbi4CAAALTAIAAAgeQ Date: Fri, 7 Jun 2013 14:48:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436780A27F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436780758E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436780A27FTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454002)(24454002)(199002)(189002)(31966008)(74502001)(74876001)(56776001)(512954002)(46102001)(51856001)(76796001)(79102001)(76786001)(80022001)(74706001)(69226001)(16406001)(65816001)(77982001)(66066001)(47446002)(63696002)(54356001)(74662001)(33656001)(49866001)(44976003)(54316002)(6806003)(15202345002)(76482001)(81342001)(77096001)(47736001)(56816003)(81542001)(16236675002)(4396001)(50986001)(55846006)(59766001)(47976001)(20776003)(71186001)(53806001)(74366001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB006; H:TK5EX14HUBC106.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0870212862 Cc: "jose@ietf.org" Subject: Re: [jose] What are we doing here? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:48:29 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436780A27FTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that we should provide some additional clarification on the intende= d purpose for the "typ" and "cty" parameters. We just did provide substant= ial additional clarification for "crit" in -11, based on the working group = decisions at the interim meeting. Are there other specific things that you= 'd suggest that we clarify, Dick? -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dic= k Hardt Sent: Friday, June 07, 2013 7:33 AM To: Richard Barnes Cc: Mike Jones; jose@ietf.org Subject: Re: [jose] What are we doing here? MIke: I don't find your response very useful for understanding the question= Richard proposed. I find the spec confusing as to what I am supposed to do= when as an implementer. It seems that it is clear to all the people associ= ated with OpenID Connect, but without that context, it is confusing, and fr= ankly, some of the parameters seem like hacks to me. Perhaps some additiona= l clarification on what the parameters are intended for would assist? -- Dick On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes > wrote: Of course, motherhood, apple pie, etc. :) The question is what we're trying to help developers do. The developers I = talk to want a simple tool to do crypto stuff, full stop. They don't want = semantic validation, critical fields, etc. The adoption you're pointing to is not really relevant to the process here.= The deployed implementations you're talking about are all in a limited sp= ace, covering one use case. And the current solution comes with baggage fo= r that use case that adds complexity for everyone else. If you wanted to a= ddress that one use case, you should have chartered for that, not general s= igning and encryption. Nonetheless, on timing, I agree that I'm getting a little bored with fighti= ng over this :) I'm working on a review of -11 that tries to package up al= l the remaining comments such that they can get resolved and we can move on= with life. --Richard On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones > wrote: Excellent question, Richard, because it gets to the heart of why the JOSE s= pecs are already highly successful and widely adopted. - We are building useful tools that solve real problems for developers. - We are practically demonstrating the value of rough consensus and runni= ng code. - We are making simple things simple. - We are making complex things possible, when necessary (but not at the e= xpense of keeping simple things simple). - We are developing specs with an explicit goal of enabling ubiquitous ad= option. - We are developing specs guided by practical engineering tradeoffs to en= able commonly useful functionality in a straightforward manner. The level of adoption, with dozens of deployed implementations, is compelli= ng evidence that we've already achieved the goals above. It's time to "shi= p it", as making the JOSE specs actual standards will only increase their a= doption and value to the industry. That's what we're doing here. -- Mike P.S. I would be careful reasoning from the premise of "The perfect protoco= l is one from which nothing can be removed". By that logic, the perfect sp= ecification is the null specification, which leaves all possibilities open,= and solves no actual problems. ;-) From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Thursday, June 06, 2013 2:44 PM To: jose@ietf.org Subject: [jose] What are we doing here? The conversation about "typ" has brought us back to a familiar question for= this working group -- what are we trying to do here? The current document is ambiguous on this topic. On the one hand, it mostl= y covers the crypto bases, with things like "alg" and "enc". On the other = hand, it mixes in application design concepts like "typ" and "crit". The r= esult is a spec that's ambiguous in purpose and complex. If I'm building a= n application with this, how do I decide what goes in the "crit" field, or = what values to use for "typ"? The charter for this working group is not ambiguous on this topic. This gr= oup is chartered to do signing and encryption. The JOSE formats should car= ry the parameters needed to perform those operations. Anything else is ext= raneous, and in the spirit of "The perfect protocol is one from which nothi= ng can be removed", should be removed. Now, I'm not going to be a hard-liner on this. I won't complain about "zip= " and "cty", since they are clearly defined and have clear use cases. But = "crit" and "typ" are so ambiguous and so little supported by use cases*, th= at they really should go. --Richard _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- -- Dick --_000_4E1F6AAD24975D4BA5B16804296739436780A27FTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that we should pr= ovide some additional clarification on the intended purpose for the “= typ” and “cty” parameters.  We just did provide subs= tantial additional clarification for “crit” in -11, based on the working group de= cisions at the interim meeting.  Are there other specific things that = you’d suggest that we clarify, Dick?

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =      -- Mike

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Friday, June 07, 2013 7:33 AM
To: Richard Barnes
Cc: Mike Jones; jose@ietf.org
Subject: Re: [jose] What are we doing here?

 

MIke: I don't find your response very useful for und= erstanding the question Richard proposed. I find the spec confusing as to w= hat I am supposed to do when as an implementer. It seems that it is clear t= o all the people associated with OpenID Connect, but without that context, it is confusing, and frankly, some of t= he parameters seem like hacks to me. Perhaps some additional clarification = on what the parameters are intended for would assist?

 

-- Dick

 

On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx> wrote:

Of course, motherhood, apple pie, etc. :)=

 

The question is what we're trying to help developers= do.  The developers I talk to want a simple tool to do crypto stuff, = full stop.  They don't want semantic validation, critical fields, etc.=  

 

The adoption you're pointing to is not really releva= nt to the process here.  The deployed implementations you're talking a= bout are all in a limited space, covering one use case.  And the curre= nt solution comes with baggage for that use case that adds complexity for everyone else.  If you wanted to addres= s that one use case, you should have chartered for that, not general signin= g and encryption.

 

Nonetheless, on timing, I agree that I'm getting a l= ittle bored with fighting over this :)  I'm working on a review of -11= that tries to package up all the remaining comments such that they can get= resolved and we can move on with life.

 

--Richard

 

On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

Excellent question, Richard, because it= gets to the heart of why the JOSE specs are already highly successful and widely adopted.

 

  - We are building useful tools t= hat solve real problems for developers.

  - We are practically demonstrati= ng the value of rough consensus and running code.

  - We are making simple things si= mple.

  - We are making complex things p= ossible, when necessary (but not at the expense of keeping simple things simple).

  - We are developing specs with a= n explicit goal of enabling ubiquitous adoption.

  - We are developing specs guided= by practical engineering tradeoffs to enable commonly useful functionality in a straightforward manner.

 

The level of adoption, with dozens of d= eployed implementations, is compelling evidence that we’ve already achieved the goals above.  It’s time to “ship it&= #8221;, as making the JOSE specs actual standards will only increase their = adoption and value to the industry.

 

That’s what we’re doing her= e.

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   -- Mike

 

P.S.  I would be careful reasoning= from the premise of “The perfect protocol is one from which nothing can be removed”.  By that lo= gic, the perfect specification is the null specification, which leaves all = possibilities open, and solves no actual problems. ;-)

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: jose@ietf.org=
Subject: [jose] What are we doing here?

 

The conversation about "typ" has brought us back to a fa= miliar question for this working group -- what are we trying to do here?

 

The current document is ambiguous on this topic.  On the one = hand, it mostly covers the crypto bases, with things like "alg" a= nd "enc".  On the other hand, it mixes in application design concepts like "typ" and "crit".  The resul= t is a spec that's ambiguous in purpose and complex.  If I'm building = an application with this, how do I decide what goes in the "crit"= field, or what values to use for "typ"?    =

The charter for this working group is not ambiguous on this topic.=  This group is chartered to do signing and encryption.  The JOSE= formats should carry the parameters needed to perform those operations.  Anything else is extraneous, and in the sp= irit of "The perfect protocol is one from which nothing can be removed= ", should be removed.

 

Now, I'm not going to be a hard-liner on this.  I won't compl= ain about "zip" and "cty", since they are clearly defin= ed and have clear use cases.  But "crit" and "typ"= are so ambiguous and so little supported by use cases*, that they really should go.

 

</rant>

 

--Richard

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



 

--
-- Dick

--_000_4E1F6AAD24975D4BA5B16804296739436780A27FTK5EX14MBXC283r_-- From rlb@ipv.sx Fri Jun 7 07:54:16 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DE821F969F for ; Fri, 7 Jun 2013 07:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeWS0lQIJtxl for ; Fri, 7 Jun 2013 07:54:04 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 79FA921F96C2 for ; Fri, 7 Jun 2013 07:53:43 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id dn14so6716556obc.30 for ; Fri, 07 Jun 2013 07:53:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=fYVuXhsytTT3xvuMXLYBwU8mbjzeDV2mMLpJ6YMU4JU=; b=DaHhPdPy61nzUEf3B5s4NFP+Y+OS4EywzSmluxKRXUy/UBNnvovk5lPWvsL/PbPDtz TbEap43N2wgiViW2mgsGmaQJ9TtoaQfe4QFZbDKV8LHvfGob8u+oahNGiQ8W8Gd5xzp8 i7B/FWNvfmO5+HBWR5SMWCMrfzv6D5IWc7Ct2dz3tGzCeVjlwwqKyfBYBckx611u0IIE FCYkLZAyngU6Unyo+ZJ6ZmRUrHLH2eo7PG5fkrnuCKBvCXu52DSj8hvdLIp+UoHGvukZ DCs7Rt1avJ+C8KfpubgEXHqc3Hm28i/onN/FSCIrHqBRMYixbtd3vzGaN3Uu52F8F24m DO9w== MIME-Version: 1.0 X-Received: by 10.60.33.202 with SMTP id t10mr21754099oei.2.1370616823347; Fri, 07 Jun 2013 07:53:43 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Fri, 7 Jun 2013 07:53:43 -0700 (PDT) X-Originating-IP: [192.1.51.101] Date: Fri, 7 Jun 2013 10:53:43 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=089e013c66b4e10ce604de919800 X-Gm-Message-State: ALoCoQkNuHNbLQBdHRA6o3U1Y2ZZCo+UcL5MpWGSfTgbkYuWe6DauPt15z81sNw5L/smGQH0/TfE Cc: "jose@ietf.org" , Dick Hardt Subject: [jose] Use case for "typ" (Re: What are we doing here?) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:54:17 -0000 --089e013c66b4e10ce604de919800 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [Popping out to a separate thread, since we're into specifics here] Mike: I asked earlier for an example of an application that that needs "typ", noting that JWT doesn't count because it can provide that via two other channels ("cty" and OAuth). Could you provide one? Thanks, --Richard On Fri, Jun 7, 2013 at 10:48 AM, Mike Jones wr= ote: > I agree that we should provide some additional clarification on the > intended purpose for the =93typ=94 and =93cty=94 parameters. We just did= provide > substantial additional clarification for =93crit=94 in -11, based on the > working group decisions at the interim meeting. Are there other specific > things that you=92d suggest that we clarify, Dick?**** > > ** ** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Dick Hardt > *Sent:* Friday, June 07, 2013 7:33 AM > *To:* Richard Barnes > *Cc:* Mike Jones; jose@ietf.org > *Subject:* Re: [jose] What are we doing here?**** > > ** ** > > MIke: I don't find your response very useful for understanding the > question Richard proposed. I find the spec confusing as to what I am > supposed to do when as an implementer. It seems that it is clear to all t= he > people associated with OpenID Connect, but without that context, it is > confusing, and frankly, some of the parameters seem like hacks to me. > Perhaps some additional clarification on what the parameters are intended > for would assist?**** > > ** ** > > -- Dick**** > > ** ** > > On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes wrote:**** > > Of course, motherhood, apple pie, etc. :)**** > > ** ** > > The question is what we're trying to help developers do. The developers = I > talk to want a simple tool to do crypto stuff, full stop. They don't wan= t > semantic validation, critical fields, etc. **** > > ** ** > > The adoption you're pointing to is not really relevant to the process > here. The deployed implementations you're talking about are all in a > limited space, covering one use case. And the current solution comes wit= h > baggage for that use case that adds complexity for everyone else. If you > wanted to address that one use case, you should have chartered for that, > not general signing and encryption.**** > > ** ** > > Nonetheless, on timing, I agree that I'm getting a little bored with > fighting over this :) I'm working on a review of -11 that tries to packa= ge > up all the remaining comments such that they can get resolved and we can > move on with life.**** > > ** ** > > --Richard**** > > ** ** > > On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones > wrote:**** > > Excellent question, Richard, because it gets to the heart of why the JOSE > specs are already highly successful and widely adopted.**** > > **** > > - We are building useful tools that solve real problems for developers.= * > *** > > - We are practically demonstrating the value of rough consensus and > running code.**** > > - We are making simple things simple.**** > > - We are making complex things possible, when necessary (but not at the > expense of keeping simple things simple).**** > > - We are developing specs with an explicit goal of enabling ubiquitous > adoption.**** > > - We are developing specs guided by practical engineering tradeoffs to > enable commonly useful functionality in a straightforward manner.**** > > **** > > The level of adoption, with dozens of deployed implementations, is > compelling evidence that we=92ve already achieved the goals above. It=92= s time > to =93ship it=94, as making the JOSE specs actual standards will only inc= rease > their adoption and value to the industry.**** > > **** > > That=92s what we=92re doing here.**** > > **** > > -- Mike**** > > **** > > P.S. I would be careful reasoning from the premise of =93The perfect > protocol is one from which nothing can be removed=94. By that logic, the > perfect specification is the null specification, which leaves all > possibilities open, and solves no actual problems. ;-)**** > > **** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Thursday, June 06, 2013 2:44 PM > *To:* jose@ietf.org > *Subject:* [jose] What are we doing here?**** > > **** > > The conversation about "typ" has brought us back to a familiar question > for this working group -- what are we trying to do here?**** > > **** > > The current document is ambiguous on this topic. On the one hand, it > mostly covers the crypto bases, with things like "alg" and "enc". On the > other hand, it mixes in application design concepts like "typ" and "crit"= . > The result is a spec that's ambiguous in purpose and complex. If I'm > building an application with this, how do I decide what goes in the "crit= " > field, or what values to use for "typ"? **** > > The charter for this working group is not ambiguous on this topic. This > group is chartered to do signing and encryption. The JOSE formats should > carry the parameters needed to perform those operations. Anything else i= s > extraneous, and in the spirit of "The perfect protocol is one from which > nothing can be removed", should be removed.**** > > **** > > Now, I'm not going to be a hard-liner on this. I won't complain about > "zip" and "cty", since they are clearly defined and have clear use cases. > But "crit" and "typ" are so ambiguous and so little supported by use > cases*, that they really should go.**** > > **** > > **** > > **** > > --Richard**** > > ** ** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > > > **** > > ** ** > > -- > -- Dick **** > --089e013c66b4e10ce604de919800 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
[Popping out to a separate thread, since we're into sp= ecifics here]

Mike:

I asked earlier for an exampl= e of an application that that needs "typ", noting that JWT doesn&= #39;t count because it can provide that via two other channels ("cty&q= uot; and OAuth). =A0Could you provide one? =A0

Thanks,
--Richard


On Fri, Jun 7, 2013 at 10:48 AM, Mike= Jones <Michael.Jones@microsoft.com> wrote:

I agree that we should pr= ovide some additional clarification on the intended purpose for the =93typ= =94 and =93cty=94 parameters.=A0 We just did provide substantial additional clarification for =93crit=94 in -11, based on the working group decisions = at the interim meeting.=A0 Are there other specific things that you=92d sug= gest that we clarify, Dick?

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Friday, June 07, 2013 7:33 AM
To: Richard Barnes
Cc: Mike Jones; j= ose@ietf.org
Subject: Re: [jose] What are we doing here?

=

=A0

MIke: I don't find your response very useful for= understanding the question Richard proposed. I find the spec confusing as = to what I am supposed to do when as an implementer. It seems that it is cle= ar to all the people associated with OpenID Connect, but without that context, it is confusing, and frankly, some of t= he parameters seem like hacks to me. Perhaps some additional clarification = on what the parameters are intended for would assist?

=A0

-- Dick

=A0

On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx> wrote:=

Of course, motherhood, apple pie, etc. :)<= /u>

=A0

The question is what we're trying to help develo= pers do. =A0The developers I talk to want a simple tool to do crypto stuff,= full stop. =A0They don't want semantic validation, critical fields, et= c. =A0

=A0

The adoption you're pointing to is not really re= levant to the process here. =A0The deployed implementations you're talk= ing about are all in a limited space, covering one use case. =A0And the cur= rent solution comes with baggage for that use case that adds complexity for everyone else. =A0If you wanted to address t= hat one use case, you should have chartered for that, not general signing a= nd encryption.

=A0

Nonetheless, on timing, I agree that I'm getting= a little bored with fighting over this :) =A0I'm working on a review o= f -11 that tries to package up all the remaining comments such that they ca= n get resolved and we can move on with life.

=A0

--Richard

=A0

On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

Excellent question, Richa= rd, because it gets to the heart of why the JOSE specs are already highly successful and widely adopted.

=A0<= /p>

=A0 - We are building use= ful tools that solve real problems for developers.

=A0 - We are practically = demonstrating the value of rough consensus and running code.<= u>

=A0 - We are making simpl= e things simple.

=A0 - We are making compl= ex things possible, when necessary (but not at the expense of keeping simpl= e things simple).

=A0 - We are developing s= pecs with an explicit goal of enabling ubiquitous adoption.

=A0 - We are developing s= pecs guided by practical engineering tradeoffs to enable commonly useful fu= nctionality in a straightforward manner.

=A0<= /p>

The level of adoption, wi= th dozens of deployed implementations, is compelling evidence that we=92ve already achieved the goals above.=A0 It=92s time to =93ship it=94, as maki= ng the JOSE specs actual standards will only increase their adoption and va= lue to the industry.

=A0<= /p>

That=92s what we=92re doi= ng here.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

P.S.=A0 I would be carefu= l reasoning from the premise of =93The perfect protocol is one from = which nothing can be removed=94.=A0 By that logic, th= e perfect specification is the null specification, which leaves all possibi= lities open, and solves no actual problems. ;-)

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: jose@ietf.org=
Subject: [jose] What are we doing here?

=A0

The conversation about "typ" has brought u= s back to a familiar question for this working group -- what are we trying = to do here?

=A0

The current document is ambiguous on this topic. =A0= On the one hand, it mostly covers the crypto bases, with things like "= alg" and "enc". =A0On the other hand, it mixes in applicatio= n design concepts like "typ" and "crit". =A0The result i= s a spec that's ambiguous in purpose and complex. =A0If I'm buildin= g an application with this, how do I decide what goes in the "crit&quo= t; field, or what values to use for "typ"? =A0 =A0<= /p>

The charter for this working group is not ambiguous = on this topic. =A0This group is chartered to do signing and encryption. =A0= The JOSE formats should carry the parameters needed to perform those operations. =A0Anything else is extraneous, and in the spiri= t of "The perfect protocol is one from which nothing can be removed&qu= ot;, should be removed.

=A0

Now, I'm not going to be a hard-liner on this. = =A0I won't complain about "zip" and "cty", since th= ey are clearly defined and have clear use cases. =A0But "crit" an= d "typ" are so ambiguous and so little supported by use cases*, that they really should go.<= u>

=A0

</rant>

=A0

--Richard

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick


--089e013c66b4e10ce604de919800-- From Michael.Jones@microsoft.com Fri Jun 7 08:19:37 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EE521F91BC for ; Fri, 7 Jun 2013 08:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8caZ2PIkqGs for ; Fri, 7 Jun 2013 08:19:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 4612E21F9050 for ; Fri, 7 Jun 2013 08:19:31 -0700 (PDT) Received: from BY2FFO11FD015.protection.gbl (10.1.15.200) by BY2FFO11HUB030.protection.gbl (10.1.14.115) with Microsoft SMTP Server (TLS) id 15.0.707.0; Fri, 7 Jun 2013 15:09:39 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Fri, 7 Jun 2013 15:09:39 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.110]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0136.001; Fri, 7 Jun 2013 15:08:38 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] Use case for "typ" (Re: What are we doing here?) Thread-Index: AQHOY47x/x9/wIdlAEueYq4QJVTT9pkqWFcQ Date: Fri, 7 Jun 2013 15:08:37 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436780A35A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436780A35ATK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054003)(24454002)(377454002)(189002)(199002)(77096001)(79102001)(77982001)(6806003)(76786001)(56816003)(65816001)(20776003)(76796001)(80022001)(54316002)(56776001)(74876001)(66066001)(74662001)(74706001)(81542001)(512954002)(63696002)(33656001)(16406001)(31966008)(76482001)(71186001)(51856001)(46102001)(53806001)(44976003)(59766001)(16236675002)(47976001)(54356001)(49866001)(50986001)(55846006)(69226001)(81342001)(47736001)(74502001)(74366001)(47446002)(15202345002)(4396001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB030; H:TK5EX14MLTC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0870212862 Cc: "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Use case for "typ" (Re: What are we doing here?) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 15:19:37 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436780A35ATK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "typ" is there to dynamically answer the question "What is this data struct= ure?" for applications. It's needed in cases that that's potentially ambig= uous. If for instance, a token might be either a Facebook signed request o= r a JWT, the "typ" value could be used to distinguish between them. You're wrong that "cty" could be used for that, because "cty" answers the q= uestion "What is the data structure that is the payload of this JOSE messag= e?" - not "What is this data structure?". The distinction is particularly = important because as of -09 we decided to allow additional header parameter= s to be added by applications that must be ignored if not understood. So "= cty" doesn't provide a comprehensive answer to the question "What is this d= ata structure?". I know of no OAuth Mechanism for providing a general-case answer to the que= stion "What is this data structure?" (other than the use of "typ" :)). Wha= t specifically were you thinking of there? So JWT needs it, and is a valid application. John Bradley has also describ= ed a number of other potential uses. Again, I haven't heard anyone say tha= t Jim's original logic for why "typ" is the way it is today was wrong - onl= y that more clarification is needed, which we'll do. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Friday, June 07, 2013 7:54 AM To: Mike Jones Cc: jose@ietf.org; Dick Hardt Subject: [jose] Use case for "typ" (Re: What are we doing here?) [Popping out to a separate thread, since we're into specifics here] Mike: I asked earlier for an example of an application that that needs "typ", not= ing that JWT doesn't count because it can provide that via two other channe= ls ("cty" and OAuth). Could you provide one? Thanks, --Richard On Fri, Jun 7, 2013 at 10:48 AM, Mike Jones > wrote: I agree that we should provide some additional clarification on the intende= d purpose for the "typ" and "cty" parameters. We just did provide substant= ial additional clarification for "crit" in -11, based on the working group = decisions at the interim meeting. Are there other specific things that you= 'd suggest that we clarify, Dick? -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Dick Hardt Sent: Friday, June 07, 2013 7:33 AM To: Richard Barnes Cc: Mike Jones; jose@ietf.org Subject: Re: [jose] What are we doing here? MIke: I don't find your response very useful for understanding the question= Richard proposed. I find the spec confusing as to what I am supposed to do= when as an implementer. It seems that it is clear to all the people associ= ated with OpenID Connect, but without that context, it is confusing, and fr= ankly, some of the parameters seem like hacks to me. Perhaps some additiona= l clarification on what the parameters are intended for would assist? -- Dick On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes > wrote: Of course, motherhood, apple pie, etc. :) The question is what we're trying to help developers do. The developers I = talk to want a simple tool to do crypto stuff, full stop. They don't want = semantic validation, critical fields, etc. The adoption you're pointing to is not really relevant to the process here.= The deployed implementations you're talking about are all in a limited sp= ace, covering one use case. And the current solution comes with baggage fo= r that use case that adds complexity for everyone else. If you wanted to a= ddress that one use case, you should have chartered for that, not general s= igning and encryption. Nonetheless, on timing, I agree that I'm getting a little bored with fighti= ng over this :) I'm working on a review of -11 that tries to package up al= l the remaining comments such that they can get resolved and we can move on= with life. --Richard On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones > wrote: Excellent question, Richard, because it gets to the heart of why the JOSE s= pecs are already highly successful and widely adopted. - We are building useful tools that solve real problems for developers. - We are practically demonstrating the value of rough consensus and runni= ng code. - We are making simple things simple. - We are making complex things possible, when necessary (but not at the e= xpense of keeping simple things simple). - We are developing specs with an explicit goal of enabling ubiquitous ad= option. - We are developing specs guided by practical engineering tradeoffs to en= able commonly useful functionality in a straightforward manner. The level of adoption, with dozens of deployed implementations, is compelli= ng evidence that we've already achieved the goals above. It's time to "shi= p it", as making the JOSE specs actual standards will only increase their a= doption and value to the industry. That's what we're doing here. -- Mike P.S. I would be careful reasoning from the premise of "The perfect protoco= l is one from which nothing can be removed". By that logic, the perfect sp= ecification is the null specification, which leaves all possibilities open,= and solves no actual problems. ;-) From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Thursday, June 06, 2013 2:44 PM To: jose@ietf.org Subject: [jose] What are we doing here? The conversation about "typ" has brought us back to a familiar question for= this working group -- what are we trying to do here? The current document is ambiguous on this topic. On the one hand, it mostl= y covers the crypto bases, with things like "alg" and "enc". On the other = hand, it mixes in application design concepts like "typ" and "crit". The r= esult is a spec that's ambiguous in purpose and complex. If I'm building a= n application with this, how do I decide what goes in the "crit" field, or = what values to use for "typ"? The charter for this working group is not ambiguous on this topic. This gr= oup is chartered to do signing and encryption. The JOSE formats should car= ry the parameters needed to perform those operations. Anything else is ext= raneous, and in the spirit of "The perfect protocol is one from which nothi= ng can be removed", should be removed. Now, I'm not going to be a hard-liner on this. I won't complain about "zip= " and "cty", since they are clearly defined and have clear use cases. But = "crit" and "typ" are so ambiguous and so little supported by use cases*, th= at they really should go. --Richard _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- -- Dick --_000_4E1F6AAD24975D4BA5B16804296739436780A35ATK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“typ” is ther= e to dynamically answer the question “What is this data structure?= 221; for applications.  It’s needed in cases that that’s p= otentially ambiguous.  If for instance, a token might be either a Facebook signed request or a JW= T, the “typ” value could be used to distinguish between them.

 <= /p>

You’re wrong that &= #8220;cty” could be used for that, because “cty” answers = the question “What is the data structure that is the payload of this = JOSE message?” – not “What is this data structure?”.  The distinction is p= articularly important because as of -09 we decided to allow additional head= er parameters to be added by applications that must be ignored if not under= stood.  So “cty” doesn’t provide a comprehensive answer to the question “What is this data structure?”.

 <= /p>

I know of no OAuth Mechan= ism for providing a general-case answer to the question “What is this= data structure?” (other than the use of “typ” J).  What specifically were you thi= nking of there?

 <= /p>

So JWT needs it, and is a= valid application.  John Bradley has also described a number of other= potential uses.  Again, I haven’t heard anyone say that JimR= 17;s original logic for why “typ” is the way it is today was wrong = – only that more clarification is needed, which we’ll do.<= /o:p>

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, June 07, 2013 7:54 AM
To: Mike Jones
Cc: jose@ietf.org; Dick Hardt
Subject: [jose] Use case for "typ" (Re: What are we doing = here?)

 

[Popping out to a separate thread, since we're into = specifics here]

 

Mike:

I asked earlier for an example of an application that that needs "typ&= quot;, noting that JWT doesn't count because it can provide that via two ot= her channels ("cty" and OAuth).  Could you provide one? &nbs= p;

 

Thanks,

--Richard

 

On Fri, Jun 7, 2013 at 10:48 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

I agree that we should provide some add= itional clarification on the intended purpose for the “typ” and “cty” parameters.  We just did provide substantial ad= ditional clarification for “crit” in -11, based on the working = group decisions at the interim meeting.  Are there other specific thin= gs that you’d suggest that we clarify, Dick?

 

      &nb= sp;            =             &nb= sp;            =             &n= bsp;  -- Mike

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Friday, June 07, 2013 7:33 AM
To: Richard Barnes
Cc: Mike Jones; j= ose@ietf.org
Subject: Re: [jose] What are we doing here?

 

MIke: I don't find your response very useful for understanding the= question Richard proposed. I find the spec confusing as to what I am suppo= sed to do when as an implementer. It seems that it is clear to all the people associated with OpenID Connect, b= ut without that context, it is confusing, and frankly, some of the paramete= rs seem like hacks to me. Perhaps some additional clarification on what the= parameters are intended for would assist?

 

-- Dick

 

On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes <rlb@ipv.sx> wrote:

Of course, motherhood, apple pie, etc. :)

 

The question is what we're trying to help developers do.  The= developers I talk to want a simple tool to do crypto stuff, full stop. &nb= sp;They don't want semantic validation, critical fields, etc.  

 

The adoption you're pointing to is not really relevant to the proc= ess here.  The deployed implementations you're talking about are all i= n a limited space, covering one use case.  And the current solution comes with baggage for that use case that a= dds complexity for everyone else.  If you wanted to address that one u= se case, you should have chartered for that, not general signing and encryp= tion.

 

Nonetheless, on timing, I agree that I'm getting a little bored wi= th fighting over this :)  I'm working on a review of -11 that tries to= package up all the remaining comments such that they can get resolved and we can move on with life.

 

--Richard

 

On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Excellent question, Richard, because it= gets to the heart of why the JOSE specs are already highly successful and widely adopted.

 

  - We are building useful tools t= hat solve real problems for developers.

  - We are practically demonstrati= ng the value of rough consensus and running code.

  - We are making simple things si= mple.

  - We are making complex things p= ossible, when necessary (but not at the expense of keeping simple things simple).

  - We are developing specs with a= n explicit goal of enabling ubiquitous adoption.

  - We are developing specs guided= by practical engineering tradeoffs to enable commonly useful functionality in a straightforward manner.

 

The level of adoption, with dozens of d= eployed implementations, is compelling evidence that we’ve already achieved the goals above.  It’s time to “ship it&= #8221;, as making the JOSE specs actual standards will only increase their = adoption and value to the industry.

 

That’s what we’re doing her= e.

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   -- Mike

 

P.S.  I would be careful reasoning= from the premise of “The perfect protocol is one from which nothing can be removed”.  By that lo= gic, the perfect specification is the null specification, which leaves all = possibilities open, and solves no actual problems. ;-)

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: jose@ietf.org=
Subject: [jose] What are we doing here?

 

The conversation about "typ" has brought us back to a fa= miliar question for this working group -- what are we trying to do here?

 

The current document is ambiguous on this topic.  On the one = hand, it mostly covers the crypto bases, with things like "alg" a= nd "enc".  On the other hand, it mixes in application design concepts like "typ" and "crit".  The resul= t is a spec that's ambiguous in purpose and complex.  If I'm building = an application with this, how do I decide what goes in the "crit"= field, or what values to use for "typ"?    =

The charter for this working group is not ambiguous on this topic.=  This group is chartered to do signing and encryption.  The JOSE= formats should carry the parameters needed to perform those operations.  Anything else is extraneous, and in the sp= irit of "The perfect protocol is one from which nothing can be removed= ", should be removed.

 

Now, I'm not going to be a hard-liner on this.  I won't compl= ain about "zip" and "cty", since they are clearly defin= ed and have clear use cases.  But "crit" and "typ"= are so ambiguous and so little supported by use cases*, that they really should go.

 

</rant>

 

--Richard

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



 

--
-- Dick

 

--_000_4E1F6AAD24975D4BA5B16804296739436780A35ATK5EX14MBXC283r_-- From prateek.mishra@oracle.com Fri Jun 7 08:24:17 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C6A21F85DC for ; Fri, 7 Jun 2013 08:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqE0bS8eV8X7 for ; Fri, 7 Jun 2013 08:24:11 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9F33D21F85D1 for ; Fri, 7 Jun 2013 08:24:11 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r57FOAi7023721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Jun 2013 15:24:10 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r57FO9u0016798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Jun 2013 15:24:09 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r57FO9UW016887; Fri, 7 Jun 2013 15:24:09 GMT Received: from [192.168.2.2] (/24.91.51.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jun 2013 08:24:08 -0700 Message-ID: <51B1FB0F.40601@oracle.com> Date: Fri, 07 Jun 2013 11:23:59 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: jose@ietf.org References: <4E1F6AAD24975D4BA5B16804296739436780758E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070701070103030609000108" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: rlb@ipv.sx Subject: Re: [jose] What are we doing here? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 15:24:17 -0000 This is a multi-part message in MIME format. --------------070701070103030609000108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 to Richard's comments. I havent been able to review the latest drafts (we will provide comments from an internal review soon) but I am very concerned about the embedding of complex application semantics into headers defined by a signature/enryption specification. - prateek > Of course, motherhood, apple pie, etc. :) > > The question is what we're trying to help developers do. The > developers I talk to want a simple tool to do crypto stuff, full stop. > They don't want semantic validation, critical fields, etc. > > The adoption you're pointing to is not really relevant to the process > here. The deployed implementations you're talking about are all in a > limited space, covering one use case. And the current solution comes > with baggage for that use case that adds complexity for everyone else. > If you wanted to address that one use case, you should have chartered > for that, not general signing and encryption. > > Nonetheless, on timing, I agree that I'm getting a little bored with > fighting over this :) I'm working on a review of -11 that tries to > package up all the remaining comments such that they can get resolved > and we can move on with life. > > --Richard > > > On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones > > wrote: > > Excellent question, Richard, because it gets to the heart of why > the JOSE specs are already highly successful and widely adopted. > > - We are building useful tools that solve real problems for > developers. > > - We are practically demonstrating the value of rough consensus > and running code. > > - We are making simple things simple. > > - We are making complex things possible, when necessary (but not > at the expense of keeping simple things simple). > > - We are developing specs with an explicit goal of enabling > ubiquitous adoption. > > - We are developing specs guided by practical engineering > tradeoffs to enable commonly useful functionality in a > straightforward manner. > > The level of adoption, with dozens of deployed implementations, is > compelling evidence that we've already achieved the goals above. > It's time to "ship it", as making the JOSE specs actual standards > will only increase their adoption and value to the industry. > > That's what we're doing here. > > -- Mike > > P.S. I would be careful reasoning from the premise of "The perfect > protocol is one from which nothing can be removed". By that logic, > the perfect specification is the null specification, which leaves > all possibilities open, and solves no actual problems. ;-) > > *From:*jose-bounces@ietf.org > [mailto:jose-bounces@ietf.org ] *On > Behalf Of *Richard Barnes > *Sent:* Thursday, June 06, 2013 2:44 PM > *To:* jose@ietf.org > *Subject:* [jose] What are we doing here? > > The conversation about "typ" has brought us back to a familiar > question for this working group -- what are we trying to do here? > > The current document is ambiguous on this topic. On the one hand, > it mostly covers the crypto bases, with things like "alg" and > "enc". On the other hand, it mixes in application design concepts > like "typ" and "crit". The result is a spec that's ambiguous in > purpose and complex. If I'm building an application with this, > how do I decide what goes in the "crit" field, or what values to > use for "typ"? > > The charter for this working group is not ambiguous on this topic. > This group is chartered to do signing and encryption. The JOSE > formats should carry the parameters needed to perform those > operations. Anything else is extraneous, and in the spirit of > "The perfect protocol is one from which nothing can be removed", > should be removed. > > Now, I'm not going to be a hard-liner on this. I won't complain > about "zip" and "cty", since they are clearly defined and have > clear use cases. But "crit" and "typ" are so ambiguous and so > little supported by use cases*, that they really should go. > > > > --Richard > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------070701070103030609000108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 to Richard's comments.

I havent been able to review the latest drafts (we will provide comments from an internal review soon)
but I am very concerned about the embedding of complex application semantics into headers defined by a signature/enryption specification.

- prateek
Of course, motherhood, apple pie, etc. :)

The question is what we're trying to help developers do.  The developers I talk to want a simple tool to do crypto stuff, full stop.  They don't want semantic validation, critical fields, etc.  

The adoption you're pointing to is not really relevant to the process here.  The deployed implementations you're talking about are all in a limited space, covering one use case.  And the current solution comes with baggage for that use case that adds complexity for everyone else.  If you wanted to address that one use case, you should have chartered for that, not general signing and encryption.

Nonetheless, on timing, I agree that I'm getting a little bored with fighting over this :)  I'm working on a review of -11 that tries to package up all the remaining comments such that they can get resolved and we can move on with life.

--Richard


On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Excellent question, Richard, because it gets to the heart of why the JOSE specs are already highly successful and widely adopted.

 

  - We are building useful tools that solve real problems for developers.

  - We are practically demonstrating the value of rough consensus and running code.

  - We are making simple things simple.

  - We are making complex things possible, when necessary (but not at the expense of keeping simple things simple).

  - We are developing specs with an explicit goal of enabling ubiquitous adoption.

  - We are developing specs guided by practical engineering tradeoffs to enable commonly useful functionality in a straightforward manner.

 

The level of adoption, with dozens of deployed implementations, is compelling evidence that we’ve already achieved the goals above.  It’s time to “ship it”, as making the JOSE specs actual standards will only increase their adoption and value to the industry.

 

That’s what we’re doing here.

 

                                                            -- Mike

 

P.S.  I would be careful reasoning from the premise of “The perfect protocol is one from which nothing can be removed”.  By that logic, the perfect specification is the null specification, which leaves all possibilities open, and solves no actual problems. ;-)

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: jose@ietf.org
Subject: [jose] What are we doing here?

 

The conversation about "typ" has brought us back to a familiar question for this working group -- what are we trying to do here?

 

The current document is ambiguous on this topic.  On the one hand, it mostly covers the crypto bases, with things like "alg" and "enc".  On the other hand, it mixes in application design concepts like "typ" and "crit".  The result is a spec that's ambiguous in purpose and complex.  If I'm building an application with this, how do I decide what goes in the "crit" field, or what values to use for "typ"?    

The charter for this working group is not ambiguous on this topic.  This group is chartered to do signing and encryption.  The JOSE formats should carry the parameters needed to perform those operations.  Anything else is extraneous, and in the spirit of "The perfect protocol is one from which nothing can be removed", should be removed.

 

Now, I'm not going to be a hard-liner on this.  I won't complain about "zip" and "cty", since they are clearly defined and have clear use cases.  But "crit" and "typ" are so ambiguous and so little supported by use cases*, that they really should go.

 

</rant>

 

--Richard




_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

--------------070701070103030609000108-- From rlb@ipv.sx Fri Jun 7 08:41:13 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2D421F9732 for ; Fri, 7 Jun 2013 08:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxFz4eWughzY for ; Fri, 7 Jun 2013 08:41:09 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id C96D421F9711 for ; Fri, 7 Jun 2013 08:41:08 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so6836789obc.13 for ; Fri, 07 Jun 2013 08:41:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=JDZj6nfXuNgFM0Hh1kfrnlVQOZNyKTo+h8u7tfzKPZE=; b=aEgk5r87uvGZ24vv1/537uAajz9Y579omvupcqa5hW6jAUMRloFJcthXxM1KeBMG7A I56uM1WLyv1cztOEzWq/dmmwMuIwVMNppxNSvJhcChg5c3uRxqWBqC7oIdmuU1lotu1E zbPWCba8ZJ/mrUKDeDQp4BtjyQ17fbALiD/ectwq7kmseBX+iR6UQzfEJAy8Lqlony21 bdmaP7SHG6TtofbJCyhnCS/Jm3GHXUiWzOn3Pd3DrlWkeLIxVwvNgzf3Ke9QjYslAKlt s15XWcafGkF9+hFJ6i0REkUkwV40XX4uUrGNnO9+DZNt+ZzOSEt1iY9WJIo+lPpNAyog 34Uw== MIME-Version: 1.0 X-Received: by 10.182.237.77 with SMTP id va13mr22145815obc.65.1370619667925; Fri, 07 Jun 2013 08:41:07 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Fri, 7 Jun 2013 08:41:07 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436780A35A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436780A35A@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 7 Jun 2013 11:41:07 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8ff1cdcc6de20204de92424b X-Gm-Message-State: ALoCoQls6x126ySGG7Ex2wuqiXJYtoygLlPUGafFGhyiX+GA9Y59Cph/Cia89CYPffBVj3n2/gYU Cc: "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Use case for "typ" (Re: What are we doing here?) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 15:41:13 -0000 --e89a8ff1cdcc6de20204de92424b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jun 7, 2013 at 11:08 AM, Mike Jones wr= ote: > =93typ=94 is there to dynamically answer the question =93What is this da= ta > structure?=94 for applications. It=92s needed in cases that that=92s pot= entially > ambiguous. If for instance, a token might be either a Facebook signed > request or a JWT, the =93typ=94 value could be used to distinguish betwee= n them. > A more specific use case would be helpful. See also the below notes on "cty" distinction. > You=92re wrong that =93cty=94 could be used for that, because =93cty=94 a= nswers the > question =93What is the data structure that is the payload of this JOSE > message?=94 =96 not =93What is this data structure?=94. The distinction = is > particularly important because as of -09 we decided to allow additional > header parameters to be added by applications that must be ignored if not > understood. So =93cty=94 doesn=92t provide a comprehensive answer to the > question =93What is this data structure?=94. > "cty" tells you what the object is at the level of "It's this thing, wrapped in a JWE/JWS". In your Facebook vs. JWT example, in the one case, the content would be "application/facebook-request", in the other "application/jwt-claims" (using fictive MIME types). So "cty" is sufficient to distinguish between the two. The only way this is unclear is if two applications use the same "cty" and put different things in the header. But they shouldn't do that, because it's bad layering -- JOSE Is Just Crypto. I know of no OAuth Mechanism for providing a general-case answer to the > question =93What is this data structure?=94 (other than the use of =93typ= =94 J). > What specifically were you thinking of there? > Maybe I'm confused, but I was envisioning something like what's in RFC 6749= : Authorization: JWT Or this in draft-ietf-oauth-jwt-bearer: POST /token.oauth2 HTTP/1.1 Host: authz.example.net Content-Type: application/x-www-form-urlencoded grant_type=3Durn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer &assertion=3DeyJhbGciOiJFUzI1NiJ9. eyJpc3Mi[...omitted for brevity...]. J9l-ZhwP[...omitted for brevity...] Those are in addition to the "cty" disambiguation above. I'm not seeing a use case here. --Richard So JWT needs it, and is a valid application. John Bradley has also > described a number of other potential uses. Again, I haven=92t heard any= one > say that Jim=92s original logic for why =93typ=94 is the way it is today = was > wrong =96 only that more clarification is needed, which we=92ll do. > > ** ** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Friday, June 07, 2013 7:54 AM > *To:* Mike Jones > *Cc:* jose@ietf.org; Dick Hardt > *Subject:* [jose] Use case for "typ" (Re: What are we doing here?)**** > > ** ** > > [Popping out to a separate thread, since we're into specifics here]**** > > ** ** > > Mike: > > I asked earlier for an example of an application that that needs "typ", > noting that JWT doesn't count because it can provide that via two other > channels ("cty" and OAuth). Could you provide one? **** > > ** ** > > Thanks,**** > > --Richard**** > > ** ** > > On Fri, Jun 7, 2013 at 10:48 AM, Mike Jones > wrote:**** > > I agree that we should provide some additional clarification on the > intended purpose for the =93typ=94 and =93cty=94 parameters. We just did= provide > substantial additional clarification for =93crit=94 in -11, based on the > working group decisions at the interim meeting. Are there other specific > things that you=92d suggest that we clarify, Dick?**** > > **** > > -- Mike**** > > **** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Dick Hardt > *Sent:* Friday, June 07, 2013 7:33 AM > *To:* Richard Barnes > *Cc:* Mike Jones; jose@ietf.org > *Subject:* Re: [jose] What are we doing here?**** > > **** > > MIke: I don't find your response very useful for understanding the > question Richard proposed. I find the spec confusing as to what I am > supposed to do when as an implementer. It seems that it is clear to all t= he > people associated with OpenID Connect, but without that context, it is > confusing, and frankly, some of the parameters seem like hacks to me. > Perhaps some additional clarification on what the parameters are intended > for would assist?**** > > **** > > -- Dick**** > > **** > > On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes wrote:**** > > Of course, motherhood, apple pie, etc. :)**** > > **** > > The question is what we're trying to help developers do. The developers = I > talk to want a simple tool to do crypto stuff, full stop. They don't wan= t > semantic validation, critical fields, etc. **** > > **** > > The adoption you're pointing to is not really relevant to the process > here. The deployed implementations you're talking about are all in a > limited space, covering one use case. And the current solution comes wit= h > baggage for that use case that adds complexity for everyone else. If you > wanted to address that one use case, you should have chartered for that, > not general signing and encryption.**** > > **** > > Nonetheless, on timing, I agree that I'm getting a little bored with > fighting over this :) I'm working on a review of -11 that tries to packa= ge > up all the remaining comments such that they can get resolved and we can > move on with life.**** > > **** > > --Richard**** > > **** > > On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones > wrote:**** > > Excellent question, Richard, because it gets to the heart of why the JOSE > specs are already highly successful and widely adopted.**** > > **** > > - We are building useful tools that solve real problems for developers.= * > *** > > - We are practically demonstrating the value of rough consensus and > running code.**** > > - We are making simple things simple.**** > > - We are making complex things possible, when necessary (but not at the > expense of keeping simple things simple).**** > > - We are developing specs with an explicit goal of enabling ubiquitous > adoption.**** > > - We are developing specs guided by practical engineering tradeoffs to > enable commonly useful functionality in a straightforward manner.**** > > **** > > The level of adoption, with dozens of deployed implementations, is > compelling evidence that we=92ve already achieved the goals above. It=92= s time > to =93ship it=94, as making the JOSE specs actual standards will only inc= rease > their adoption and value to the industry.**** > > **** > > That=92s what we=92re doing here.**** > > **** > > -- Mike**** > > **** > > P.S. I would be careful reasoning from the premise of =93The perfect > protocol is one from which nothing can be removed=94. By that logic, the > perfect specification is the null specification, which leaves all > possibilities open, and solves no actual problems. ;-)**** > > **** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Thursday, June 06, 2013 2:44 PM > *To:* jose@ietf.org > *Subject:* [jose] What are we doing here?**** > > **** > > The conversation about "typ" has brought us back to a familiar question > for this working group -- what are we trying to do here?**** > > **** > > The current document is ambiguous on this topic. On the one hand, it > mostly covers the crypto bases, with things like "alg" and "enc". On the > other hand, it mixes in application design concepts like "typ" and "crit"= . > The result is a spec that's ambiguous in purpose and complex. If I'm > building an application with this, how do I decide what goes in the "crit= " > field, or what values to use for "typ"? **** > > The charter for this working group is not ambiguous on this topic. This > group is chartered to do signing and encryption. The JOSE formats should > carry the parameters needed to perform those operations. Anything else i= s > extraneous, and in the spirit of "The perfect protocol is one from which > nothing can be removed", should be removed.**** > > **** > > Now, I'm not going to be a hard-liner on this. I won't complain about > "zip" and "cty", since they are clearly defined and have clear use cases. > But "crit" and "typ" are so ambiguous and so little supported by use > cases*, that they really should go.**** > > **** > > **** > > **** > > --Richard**** > > **** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > > > **** > > **** > > -- > -- Dick **** > > ** ** > --e89a8ff1cdcc6de20204de92424b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 7, 2013 at 11:08 AM, Mike Jones <Mi= chael.Jones@microsoft.com> wrote:

=93typ=94 is there to dynamically answer the question= =93What is this data structure?=94 for applications.=A0 It=92s needed in c= ases that that=92s potentially ambiguous.=A0 If for instance, a token might be either a Facebook signed request or a JW= T, the =93typ=94 value could be used to distinguish between them.


A more specific use case woul= d be helpful. =A0See also the below notes on "cty" distinction.
=A0

You=92re wrong that =93cty=94 could be used for that,= because =93cty=94 answers the question =93What is the data structure that = is the payload of this JOSE message?=94 =96 not =93What is this data structure?=94.=A0 The distinction is particularly= important because as of -09 we decided to allow additional header paramete= rs to be added by applications that must be ignored if not understood.=A0 S= o =93cty=94 doesn=92t provide a comprehensive answer to the question =93What is this data structure?=94.


"cty" tells you what the = object is at the level of "It's this thing, wrapped in a JWE/JWS&q= uot;. =A0In your Facebook vs. JWT example, in the one case, the content wou= ld be "application/facebook-request", in the other "applicat= ion/jwt-claims" (using fictive MIME types). =A0So "cty" is s= ufficient to distinguish between the two.

The only way this is unclear is if two applications use= the same "cty" and put different things in the header. =A0But th= ey shouldn't do that, because it's bad layering -- JOSE Is Just Cry= pto.=A0
=A0

I know of no OAuth Mechanism for providing a general-= case answer to the question =93What is this data structure?=94 (other than = the use of =93typ=94 J).=A0 What specifically were you thinking of there?


Maybe I'm confused, but I = was envisioning something like what's in RFC 6749:
=A0 =A0 = =A0Authorization: JWT <jwt-object>
=A0
Or this in draft-ietf-oauth-jwt-bearer:
= =A0 =A0 =A0POST /token.oauth2 HTTP/1.1
=A0 =A0 =A0Host: authz.example.net
=A0 =A0 =A0Co= ntent-Type: application/x-www-form-urlencoded

=A0 =A0 =A0grant_type=3Durn%3Aietf%3Aparams%3Aoauth%3Ag= rant-type%3Ajwt-bearer
=A0 =A0 =A0&assertion=3DeyJhbGciOiJFUz= I1NiJ9.
=A0 =A0 =A0eyJpc3Mi[...omitted for brevity...].
=A0 =A0 =A0J9l-ZhwP[...omitted for brevity...]

Those are in addition to the = "cty" disambiguation above. =A0I'm not seeing a use case here= . =A0

--Richard


So JWT needs it, and is a valid application.=A0 John Bradley has also de= scribed a number of other potential uses.=A0 Again, I haven=92t heard anyon= e say that Jim=92s original logic for why =93typ=94 is the way it is today was wrong =96 only= that more clarification is needed, which we=92ll do.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0

From: jose-bounc= es@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, June 07, 2013 7:54 AM
To: Mike Jones
Cc: jose@ietf.org= ; Dick Hardt
Subject: [jose] Use case for "typ" (Re: What are we doing = here?)

=A0

[Popping out to a separate thread, since we're into speci= fics here]

=A0

Mike:

I asked earlier for an example of an application that that needs "typ&= quot;, noting that JWT doesn't count because it can provide that via tw= o other channels ("cty" and OAuth). =A0Could you provide one? =A0=

=A0

Thanks,

--Richard

=A0

On Fri, Jun 7, 2013 at 10:48 AM, Mike Jones <Michael.Jones@microsoft= .com> wrote:

I agree that we should provide some additional clarif= ication on the intended purpose for the =93typ=94 and =93cty=94 parameters.=A0 We just did provide substantial additional cl= arification for =93crit=94 in -11, based on the working group decisions at = the interim meeting.=A0 Are there other specific things that you=92d sugges= t that we clarify, Dick?

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike<= /u>

=A0

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Friday, June 07, 2013 7:33 AM
To: Richard Barnes
Cc: Mike Jones; j= ose@ietf.org
Subject: Re: [jose] What are we doing here?

=A0

MIke: I don't find your response very useful for understa= nding the question Richard proposed. I find the spec confusing as to what I= am supposed to do when as an implementer. It seems that it is clear to all the people associated with OpenID Connect, b= ut without that context, it is confusing, and frankly, some of the paramete= rs seem like hacks to me. Perhaps some additional clarification on what the= parameters are intended for would assist?

=A0

-- Dick

=A0

On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes <rlb@ipv.sx> wrote:

Of course, motherhood, apple pie, etc. :)

=A0

The question is what we're trying to help developers do. = =A0The developers I talk to want a simple tool to do crypto stuff, full sto= p. =A0They don't want semantic validation, critical fields, etc. =A0

=A0

The adoption you're pointing to is not really relevant to= the process here. =A0The deployed implementations you're talking about= are all in a limited space, covering one use case. =A0And the current solution comes with baggage for that use case that adds= complexity for everyone else. =A0If you wanted to address that one use cas= e, you should have chartered for that, not general signing and encryption.<= u>

=A0

Nonetheless, on timing, I agree that I'm getting a little= bored with fighting over this :) =A0I'm working on a review of -11 tha= t tries to package up all the remaining comments such that they can get resolved and we can move on with life.

=A0

--Richard

=A0

On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones <Michael.Jones@microsoft.= com> wrote:

Excellent question, Richard, because it gets to the h= eart of why the JOSE specs are already highly successful and widely adopted.

=A0

=A0 - We are building useful tools that solve real pr= oblems for developers.

=A0 - We are practically demonstrating the value of r= ough consensus and running code.

=A0 - We are making simple things simple.

=A0 - We are making complex things possible, when nec= essary (but not at the expense of keeping simple things simple).

=A0 - We are developing specs with an explicit goal o= f enabling ubiquitous adoption.

=A0 - We are developing specs guided by practical eng= ineering tradeoffs to enable commonly useful functionality in a straightforward manner.

=A0

The level of adoption, with dozens of deployed implem= entations, is compelling evidence that we=92ve already achieved the goals above.=A0 It=92s time to =93ship it=94, as maki= ng the JOSE specs actual standards will only increase their adoption and va= lue to the industry.

=A0

That=92s what we=92re doing here.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0

P.S.=A0 I would be careful reasoning from the premise= of =93The perfect protocol is one from which nothing can be removed=94.=A0 By that logic, the perfect specifica= tion is the null specification, which leaves all possibilities open, and so= lves no actual problems. ;-)

=A0

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: jose@ietf.org=
Subject: [jose] What are we doing here?

=A0

The conversation about "typ" has brought us back to= a familiar question for this working group -- what are we trying to do her= e?

=A0

The current document is ambiguous on this topic. =A0On the on= e hand, it mostly covers the crypto bases, with things like "alg"= and "enc". =A0On the other hand, it mixes in application design concepts like "typ" and "crit". =A0The result i= s a spec that's ambiguous in purpose and complex. =A0If I'm buildin= g an application with this, how do I decide what goes in the "crit&quo= t; field, or what values to use for "typ"? =A0 =A0<= /p>

The charter for this working group is not ambiguous on this t= opic. =A0This group is chartered to do signing and encryption. =A0The JOSE = formats should carry the parameters needed to perform those operations. =A0Anything else is extraneous, and in the spiri= t of "The perfect protocol is one from which nothing can be removed&qu= ot;, should be removed.

=A0

Now, I'm not going to be a hard-liner on this. =A0I won&#= 39;t complain about "zip" and "cty", since they are cle= arly defined and have clear use cases. =A0But "crit" and "ty= p" are so ambiguous and so little supported by use cases*, that they really should go.<= u>

=A0

</rant>

=A0

--Richard

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick

=A0


--e89a8ff1cdcc6de20204de92424b-- From dick.hardt@gmail.com Fri Jun 7 10:06:44 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D62E21F9600 for ; Fri, 7 Jun 2013 10:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[AWL=1.474, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIrY9Y4ww37p for ; Fri, 7 Jun 2013 10:06:43 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5F98321F93D2 for ; Fri, 7 Jun 2013 10:06:42 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji1so1595676bkc.24 for ; Fri, 07 Jun 2013 10:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qxXxW3mHxKMeHmco0JT+HOhU2Aw4c5+456A2sjC2lTs=; b=Y9thScrFuA/kCX4r8EiLApp42rqMEmnEp8L4PTLKdQI44TMpDeBG0TE6jqmTIU3e4Z rrougorrZ5vuYE8nFhme2J5/K07d+Fr4h3LRDEgTwV8b7ESzbBQWkMHs3XUCOSepEpTx +g4gm2NDzJKRPwo59tJ1/rnRAxcHvVaAC51TsAFGeF/BfMRX/0bwPfY2pu8kv25tPX8d PLf3aovKXeXbUO1t2diqXqWVWulNmvNSSHktKPMxWz4iC3Nd1ghDSHHhzH8A8u5eZChq 4yCODLco8aY3o47keyxqMQsjESD7xp7P/G2WMOJG8wkbd1D6WE5XTo9F0EYs+mvMhb8o 6bew== MIME-Version: 1.0 X-Received: by 10.204.70.203 with SMTP id e11mr12866307bkj.16.1370624801143; Fri, 07 Jun 2013 10:06:41 -0700 (PDT) Received: by 10.204.168.12 with HTTP; Fri, 7 Jun 2013 10:06:41 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436780A27F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436780758E@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436780A27F@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 7 Jun 2013 10:06:41 -0700 Message-ID: From: Dick Hardt To: Mike Jones Content-Type: multipart/alternative; boundary=047d7b87450e64c00904de93742b Cc: Richard Barnes , "jose@ietf.org" Subject: Re: [jose] What are we doing here? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 17:06:44 -0000 --047d7b87450e64c00904de93742b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mike, Currently I find "typ" and "cty" confusing. Once I understand them, I may be confused with other aspects. :) For example, in: https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11 What "typ" is supposed to be is confusing. In 3.1, it is defined as "typ":"JWT" In 4.1.8, it is "typ":"JWS" or "typ":"JWS+JSON" Which one is it? When would you use "cty"? -- Dick On Fri, Jun 7, 2013 at 7:48 AM, Mike Jones wro= te: > I agree that we should provide some additional clarification on the > intended purpose for the =93typ=94 and =93cty=94 parameters. We just did= provide > substantial additional clarification for =93crit=94 in -11, based on the > working group decisions at the interim meeting. Are there other specific > things that you=92d suggest that we clarify, Dick?**** > > ** ** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Dick Hardt > *Sent:* Friday, June 07, 2013 7:33 AM > *To:* Richard Barnes > *Cc:* Mike Jones; jose@ietf.org > *Subject:* Re: [jose] What are we doing here?**** > > ** ** > > MIke: I don't find your response very useful for understanding the > question Richard proposed. I find the spec confusing as to what I am > supposed to do when as an implementer. It seems that it is clear to all t= he > people associated with OpenID Connect, but without that context, it is > confusing, and frankly, some of the parameters seem like hacks to me. > Perhaps some additional clarification on what the parameters are intended > for would assist?**** > > ** ** > > -- Dick**** > > ** ** > > On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes wrote:**** > > Of course, motherhood, apple pie, etc. :)**** > > ** ** > > The question is what we're trying to help developers do. The developers = I > talk to want a simple tool to do crypto stuff, full stop. They don't wan= t > semantic validation, critical fields, etc. **** > > ** ** > > The adoption you're pointing to is not really relevant to the process > here. The deployed implementations you're talking about are all in a > limited space, covering one use case. And the current solution comes wit= h > baggage for that use case that adds complexity for everyone else. If you > wanted to address that one use case, you should have chartered for that, > not general signing and encryption.**** > > ** ** > > Nonetheless, on timing, I agree that I'm getting a little bored with > fighting over this :) I'm working on a review of -11 that tries to packa= ge > up all the remaining comments such that they can get resolved and we can > move on with life.**** > > ** ** > > --Richard**** > > ** ** > > On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones > wrote:**** > > Excellent question, Richard, because it gets to the heart of why the JOSE > specs are already highly successful and widely adopted.**** > > **** > > - We are building useful tools that solve real problems for developers.= * > *** > > - We are practically demonstrating the value of rough consensus and > running code.**** > > - We are making simple things simple.**** > > - We are making complex things possible, when necessary (but not at the > expense of keeping simple things simple).**** > > - We are developing specs with an explicit goal of enabling ubiquitous > adoption.**** > > - We are developing specs guided by practical engineering tradeoffs to > enable commonly useful functionality in a straightforward manner.**** > > **** > > The level of adoption, with dozens of deployed implementations, is > compelling evidence that we=92ve already achieved the goals above. It=92= s time > to =93ship it=94, as making the JOSE specs actual standards will only inc= rease > their adoption and value to the industry.**** > > **** > > That=92s what we=92re doing here.**** > > **** > > -- Mike**** > > **** > > P.S. I would be careful reasoning from the premise of =93The perfect > protocol is one from which nothing can be removed=94. By that logic, the > perfect specification is the null specification, which leaves all > possibilities open, and solves no actual problems. ;-)**** > > **** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Thursday, June 06, 2013 2:44 PM > *To:* jose@ietf.org > *Subject:* [jose] What are we doing here?**** > > **** > > The conversation about "typ" has brought us back to a familiar question > for this working group -- what are we trying to do here?**** > > **** > > The current document is ambiguous on this topic. On the one hand, it > mostly covers the crypto bases, with things like "alg" and "enc". On the > other hand, it mixes in application design concepts like "typ" and "crit"= . > The result is a spec that's ambiguous in purpose and complex. If I'm > building an application with this, how do I decide what goes in the "crit= " > field, or what values to use for "typ"? **** > > The charter for this working group is not ambiguous on this topic. This > group is chartered to do signing and encryption. The JOSE formats should > carry the parameters needed to perform those operations. Anything else i= s > extraneous, and in the spirit of "The perfect protocol is one from which > nothing can be removed", should be removed.**** > > **** > > Now, I'm not going to be a hard-liner on this. I won't complain about > "zip" and "cty", since they are clearly defined and have clear use cases. > But "crit" and "typ" are so ambiguous and so little supported by use > cases*, that they really should go.**** > > **** > > **** > > **** > > --Richard**** > > ** ** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > > > **** > > ** ** > > -- > -- Dick **** > --=20 -- Dick --047d7b87450e64c00904de93742b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Mike,=A0

Currently I find "typ" and "cty" confusing. Once I un= derstand them, I may be confused with other aspects. :)
For example, in:

https://tool= s.ietf.org/html/draft-ietf-jose-json-web-signature-11

What "typ" is supposed to be is confusing.
<= br>
In 3.1, it is defined as "typ":"JWT"= ;

In 4.1.8, it is "typ":&quo= t;JWS" or "typ":"JWS+JSON"

Which one is it?
When would= =A0you use "cty"?

-- Dick


On = Fri, Jun 7, 2013 at 7:48 AM, Mike Jones <Michael.Jones@microsoft= .com> wrote:

I agree that we should pr= ovide some additional clarification on the intended purpose for the =93typ= =94 and =93cty=94 parameters.=A0 We just did provide substantial additional clarification for =93crit=94 in -11, based on the working group decisions = at the interim meeting.=A0 Are there other specific things that you=92d sug= gest that we clarify, Dick?

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Dick Hardt
Sent: Friday, June 07, 2013 7:33 AM
To: Richard Barnes
Cc: Mike Jones; j= ose@ietf.org
Subject: Re: [jose] What are we doing here?

=

=A0

MIke: I don't find your response very useful for= understanding the question Richard proposed. I find the spec confusing as = to what I am supposed to do when as an implementer. It seems that it is cle= ar to all the people associated with OpenID Connect, but without that context, it is confusing, and frankly, some of t= he parameters seem like hacks to me. Perhaps some additional clarification = on what the parameters are intended for would assist?

=A0

-- Dick

=A0

On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx> wrote:=

Of course, motherhood, apple pie, etc. :)<= /u>

=A0

The question is what we're trying to help develo= pers do. =A0The developers I talk to want a simple tool to do crypto stuff,= full stop. =A0They don't want semantic validation, critical fields, et= c. =A0

=A0

The adoption you're pointing to is not really re= levant to the process here. =A0The deployed implementations you're talk= ing about are all in a limited space, covering one use case. =A0And the cur= rent solution comes with baggage for that use case that adds complexity for everyone else. =A0If you wanted to address t= hat one use case, you should have chartered for that, not general signing a= nd encryption.

=A0

Nonetheless, on timing, I agree that I'm getting= a little bored with fighting over this :) =A0I'm working on a review o= f -11 that tries to package up all the remaining comments such that they ca= n get resolved and we can move on with life.

=A0

--Richard

=A0

On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

Excellent question, Richa= rd, because it gets to the heart of why the JOSE specs are already highly successful and widely adopted.

=A0<= /p>

=A0 - We are building use= ful tools that solve real problems for developers.

=A0 - We are practically = demonstrating the value of rough consensus and running code.<= u>

=A0 - We are making simpl= e things simple.

=A0 - We are making compl= ex things possible, when necessary (but not at the expense of keeping simpl= e things simple).

=A0 - We are developing s= pecs with an explicit goal of enabling ubiquitous adoption.

=A0 - We are developing s= pecs guided by practical engineering tradeoffs to enable commonly useful fu= nctionality in a straightforward manner.

=A0<= /p>

The level of adoption, wi= th dozens of deployed implementations, is compelling evidence that we=92ve already achieved the goals above.=A0 It=92s time to =93ship it=94, as maki= ng the JOSE specs actual standards will only increase their adoption and va= lue to the industry.

=A0<= /p>

That=92s what we=92re doi= ng here.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

P.S.=A0 I would be carefu= l reasoning from the premise of =93The perfect protocol is one from = which nothing can be removed=94.=A0 By that logic, th= e perfect specification is the null specification, which leaves all possibi= lities open, and solves no actual problems. ;-)

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: jose@ietf.org=
Subject: [jose] What are we doing here?

=A0

The conversation about "typ" has brought u= s back to a familiar question for this working group -- what are we trying = to do here?

=A0

The current document is ambiguous on this topic. =A0= On the one hand, it mostly covers the crypto bases, with things like "= alg" and "enc". =A0On the other hand, it mixes in applicatio= n design concepts like "typ" and "crit". =A0The result i= s a spec that's ambiguous in purpose and complex. =A0If I'm buildin= g an application with this, how do I decide what goes in the "crit&quo= t; field, or what values to use for "typ"? =A0 =A0<= /p>

The charter for this working group is not ambiguous = on this topic. =A0This group is chartered to do signing and encryption. =A0= The JOSE formats should carry the parameters needed to perform those operations. =A0Anything else is extraneous, and in the spiri= t of "The perfect protocol is one from which nothing can be removed&qu= ot;, should be removed.

=A0

Now, I'm not going to be a hard-liner on this. = =A0I won't complain about "zip" and "cty", since th= ey are clearly defined and have clear use cases. =A0But "crit" an= d "typ" are so ambiguous and so little supported by use cases*, that they really should go.<= u>

=A0

</rant>

=A0

--Richard

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
-- Dick




--
-- Dick
--047d7b87450e64c00904de93742b-- From James.H.Manger@team.telstra.com Sat Jun 8 06:59:23 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CDC21F99E3 for ; Sat, 8 Jun 2013 06:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOL+zkjm53kp for ; Sat, 8 Jun 2013 06:59:18 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id DBCD221F963C for ; Sat, 8 Jun 2013 06:59:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,827,1363093200"; d="scan'208";a="140231516" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 08 Jun 2013 23:59:16 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7099"; a="189616256" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcavi.tcif.telstra.com.au with ESMTP; 08 Jun 2013 23:59:16 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Sat, 8 Jun 2013 23:59:15 +1000 From: "Manger, James H" To: Mike Jones , Richard Barnes Date: Sat, 8 Jun 2013 23:59:14 +1000 Thread-Topic: [jose] Use case for "typ" (Re: What are we doing here?) Thread-Index: AQHOY47x/x9/wIdlAEueYq4QJVTT9pkqWFcQgAF4dnA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B21FF65@WSMSG3153V.srv.dir.telstra.com> References: <4E1F6AAD24975D4BA5B16804296739436780A35A@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436780A35A@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Use case for "typ" (Re: What are we doing here?) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 13:59:23 -0000 TWlrZSBzYWlkOg0KPiBTbyBKV1QgbmVlZHMgaXQgWyJ0eXAiXQ0KDQpJdCBpcyBoYXJkIHRvIHVu ZGVyc3RhbmQgaG93IEpXVCBuZWVkcyAidHlwIiB3aGVuIHRoZSBKV1Qgc3BlYyBzYXlzICJ1c2Ug b2YgdGhpcyBoZWFkZXIgcGFyYW1ldGVyIGlzIE9QVElPTkFMIj8NCltodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA4I3NlY3Rpb24tNS4x XQ0KDQpFdmVuIGlmIGEgSldUIGNyZWF0b3IgZGVjaWRlcyB0byBpbmNsdWRlIHRoZSAidHlwIiBo ZWFkZXIgcGFyYW1ldGVyLCB0aGUgc3BlYyBtZXJlbHkgUkVDT01NRU5EUyB1c2luZyBvbmUgb2Yg dHdvIHZhbHVlczogIkpXVCIgb3IgInVybjppZXRmOnBhcmFtczpvYXV0aDp0b2tlbi10eXBlOmp3 dCIuIFNvIHRob3NlIG9yIGFueSBvdGhlciB2YWx1ZSBjYW4gYmUgaW5jbHVkZWQuDQoNCkkgY2Fu J3Qgc2VlIGFueSBoaW50IGFib3V0IGhvdyBhIEpXVCByZWNlaXZlciBpcyBzdXBwb3NlZCB0byBy ZWFjdCBkaWZmZXJlbnRseSBiYXNlZCBvbjogdGhlIGFic2VuY2Ugb2YgdGhlICJ0eXAiIGhlYWRl cjsgdGhlIHByZXNlbmNlIG9mIGVpdGhlciBvZiB0aGUgdHdvIHJlY29tbWVuZGVkIHZhbHVlczsg b3IgdGhlIHByZXNlbmNlIG9mIGFueSBvdGhlciAodW5yZWNvZ25pemVkPykgdmFsdWUuDQoNCi0t DQpKYW1lcyBNYW5nZXINCg== From ietf@augustcellars.com Sun Jun 9 22:40:57 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834BB21F8B90 for ; Sun, 9 Jun 2013 22:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o79iWqHpinA0 for ; Sun, 9 Jun 2013 22:40:51 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDD821F91B1 for ; Sun, 9 Jun 2013 22:40:51 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 0D1972C9BC for ; Sun, 9 Jun 2013 22:40:50 -0700 (PDT) From: "Jim Schaad" To: References: <02b701ce5cb8$46ae77e0$d40b67a0$@augustcellars.com> <02f501ce5cc5$ec9a2200$c5ce6600$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943677C58C4@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C5C0A@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C7399@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9B69@TK5EX14MBXC285.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943677C9E95@TK5EX14MBXC285.redmond.corp.microsoft.com> In-Reply-To: Date: Sun, 9 Jun 2013 22:39:59 -0700 Message-ID: <05fb01ce659c$f28a8170$d79f8450$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL+gOaQctokYsIF5NqCLBrsp9OxugIREdBOAZxwGYYA+xTLLwL/DSbtAkjfeb0CNOnLqQJml3CFAT+uwjIC8i/K0QKfBA3BAgAu76wCGMPjBQGo9J74AU9RWkABvcif6gJ7dcuLAdSQGswCQZpOCAKG8a7wAkKXKnkBUbCFRpV3M3rw Content-Language: en-us Subject: Re: [jose] Should we delete the "typ" header field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 05:40:57 -0000 I kept trying to send this message out during the last week, but I have been doing too much physical activity to be awake at night and produce a coherent message. The opinions here are my personal opinions, some of them might be things that I would also advocate as a chair, but don't assume just because it is here I would. I have been looking at the conversation on this topic with slight surprise, I did not really expect this type of firestorm to occur on a part of the spec that had been in for quite a while. Givens: 1. My general inclination is that things in the document generally stay in the document, however they do need to be shown to be clearly described and useful. 2. My general inclination is that things which can be shown to be useful for multiple applications can be done in the base document. That said, there is nothing that says such a thing could not be defined in one of the application specs which uses it rather than the base document. My understanding: My understanding of what Mike has said is that this field is meant to clearly present that this is a JSON thing for a specific application. This is contrary to the expectation that Richard, Dick and myself had where it was a description of the "security service" rather than the application. My problem with this understanding is I am not sure when it is a useful concept to have. In order for it to be needed you would need to have two statements being true: 1. There is no way to know the application from the current protocol being exercised and 2. There is no way to correctly infer the application from the value of the ctyp field (if present). Under the current circumstances as I understand the JWT specification, neither of these criteria would be met. Nat gave an interesting example of a case where it might be useful, that of a Time Stamp Provider. My problem with this is that I don't think of this as being an application protocol, but as being a different security service. Thus a timestamp JWS is a specialized version of a normal JWS. As such, yes it would make sense to me that the type field could be used to differentiate between a normal JWS and a timestamp-JWS. But a timestamp would be, by definition, completely agnostic about the inner content provided. The same could not be said of a JWT application. It needs to understand the specific inner content that was provided. SideBar: It is not immediately clear to me that a classic timestamp provider could be done using the JOSE data structures as it normally requires that one can produce a timestamp without sharing the content with the timestamp producer. There are also interesting discussions on if the fact that it is a timestamp or other special signature should be signaled in the signature object or as a key parameter. However none of this paragraph is relevant to the current discussion. I think that I would like to see the following things: 1. Two clear use cases provided, one for JWT and one for something else where the typ field as an application indicator would be useful/required. I think that such a thing needs to address the two points that I presented previously. 2. I don't believe that anyone has addressed the question I raised about the fact that both the ctyp and typ fields are using the same registry, thus JWT would mean different things depending on which field it is in. 3. I had a message dated 5/30/13 where I asked a couple of questions. This message was not responded to. Jim From ietf@augustcellars.com Sun Jun 9 22:47:19 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D628921F8B90 for ; Sun, 9 Jun 2013 22:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soFLKKKloUBc for ; Sun, 9 Jun 2013 22:47:14 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 01C5121F8F38 for ; Sun, 9 Jun 2013 22:47:14 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id D3E0238EF0 for ; Sun, 9 Jun 2013 22:47:13 -0700 (PDT) From: "Jim Schaad" To: Date: Sun, 9 Jun 2013 22:46:22 -0700 Message-ID: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05FD_01CE6563.2A4ADCC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5lnSf72X6a3Ku/SKOo5PcgVR4NIg== Content-Language: en-us Subject: [jose] Possible change to protected field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 05:47:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05FD_01CE6563.2A4ADCC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am trying to figure out if I am missing something. This is not yet a formal proposal to actual change the document. I was thinking about proposing that we make a change to the content of the protected field in the JWS JSON serialization format. If we encoded this as a UTF8 string rather than the base64url encoded UTF8 string, then the content would be smaller. The computation of the signature would be unchanged in that it would still be computed over the base64url encoded string. I believe that the conversion from the UTF8 string to the base64url encoded UTF8 string is a deterministic encoding and thus would not generate any problems from that point. At this point I and trying to figure out if I missed anything that would preclude this from working. I am not worried about how hard or easy it would be to do, just if it is even possible. Jim ------=_NextPart_000_05FD_01CE6563.2A4ADCC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<no = hat>

 

I am trying to figure out if I am missing = something.  This is not yet a formal proposal to actual change the = document.

 

I was thinking about proposing that we make a change = to the content of the protected field in the JWS JSON serialization = format.  If we encoded this as a UTF8 string rather than the = base64url encoded UTF8 string, then the content would be smaller. =  The computation of the signature would be unchanged in that it = would still be computed over the base64url encoded string.  I = believe that the conversion from the UTF8 string to the base64url = encoded UTF8 string is a deterministic encoding and thus would not = generate any problems from that point.

 

At this = point I and trying to figure out if I missed anything that would = preclude this from working.  I am not worried about how hard or = easy it would be to do, just if it is even possible.

 

Jim

 

------=_NextPart_000_05FD_01CE6563.2A4ADCC0-- From Michael.Jones@microsoft.com Mon Jun 10 09:07:57 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6963921F9675 for ; Mon, 10 Jun 2013 09:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo+BQyvTjeO9 for ; Mon, 10 Jun 2013 09:07:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id B876221F90EF for ; Mon, 10 Jun 2013 09:07:52 -0700 (PDT) Received: from BY2FFO11FD013.protection.gbl (10.1.15.202) by BY2FFO11HUB017.protection.gbl (10.1.14.91) with Microsoft SMTP Server (TLS) id 15.0.707.0; Mon, 10 Jun 2013 16:07:51 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Mon, 10 Jun 2013 16:07:51 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.110]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0136.001; Mon, 10 Jun 2013 16:07:35 +0000 From: Mike Jones To: "odonoghue@isoc.org" , "jose@ietf.org" Thread-Topic: [jose] jose wg teleconference announcement - 17 June 2013 Thread-Index: AQHOXax8pLabJNdcTESbphgL8YaBOZkvLeN2 Date: Mon, 10 Jun 2013 16:07:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436781B290@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <514C5FC3.20007@isoc.org>,<51A814A9.8060208@isoc.org> In-Reply-To: <51A814A9.8060208@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436781B290TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(479174002)(377454002)(189002)(30513003)(80022001)(16236675002)(46102001)(79102001)(47446002)(49866001)(69226001)(54316002)(65816001)(56816003)(74706001)(47736001)(63696002)(74366001)(51856001)(74876001)(74662001)(74502001)(77096001)(20776003)(31966008)(47976001)(50986001)(71186001)(56776001)(76796001)(55846006)(512954002)(54356001)(76786001)(59766001)(77982001)(81542001)(53806001)(33656001)(44976003)(4396001)(6806003)(15202345002)(76482001)(81342001)(16406001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB017; H:TK5EX14HUBC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 087396016C Subject: Re: [jose] jose wg teleconference announcement - 17 June 2013 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:07:57 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436781B290TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What is the call-in information? Sorry if I missed it. -- Mike ________________________________ From: Karen O'Donoghue Sent: 5/30/2013 8:11 PM To: jose@ietf.org Subject: [jose] jose wg teleconference announcement - 17 June 2013 The jose working group will have a teleconference on Monday 17 June 2013 at 5:00 pm UTC (10:00 am PDT / 1:00 pm EDT). The primary objective of the call will be to ensure the results of the interim meeting were adequately incorporated and to identify any final issues on the recently published drafts. The interim meeting minutes are available at: http://www.ietf.org/proceedings/interim/2013/04/29/jose/minutes/minutes-int= erim-2013-jose-1 The updated specifications are available at: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11 http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11 http://tools.ietf.org/html/draft-ietf-jose-json-web-key-11 http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-11 An agenda and webex details will be available next week. Regards, Karen _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436781B290TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
What is the c= all-in information?  Sorry if I missed it.

-- Mike


From: Karen = O'Donoghue
Sent: 5/30/2= 013 8:11 PM
To: jose@i= etf.org
Subject: [jose]= jose wg teleconference announcement - 17 June 2013

The jose working group will have a teleconference = on Monday 17 June 2013
at 5:00 pm UTC (10:00 am PDT / 1:00 pm EDT).

The primary objective of the call will be to ensure the results of the
interim meeting were adequately incorporated and to identify any final
issues on the recently published drafts.

The interim meeting minutes are available at:
http://www.ietf.org/proceedings/interim/2013/0= 4/29/jose/minutes/minutes-interim-2013-jose-1

The updated specifications are available at:
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11 http= ://tools.ietf.org/html/draft-ietf-jose-json-web-key-11
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-11
An agenda and webex details will be available next week.

Regards,
Karen

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org= /mailman/listinfo/jose
--_000_4E1F6AAD24975D4BA5B16804296739436781B290TK5EX14MBXC283r_-- From ve7jtb@ve7jtb.com Mon Jun 10 09:10:26 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DB721F9619 for ; Mon, 10 Jun 2013 09:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZYx5hVBQniA for ; Mon, 10 Jun 2013 09:10:25 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBA821F95D7 for ; Mon, 10 Jun 2013 09:10:25 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so3186657wgh.4 for ; Mon, 10 Jun 2013 09:10:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=5ar2rlJzXZZrcIwQD/SK+DFEVKubnyCwYsfrCNJKazs=; b=hBnLc/3cuswbkjtAEg8p36R0oBz6A3mCdc/flIwbXF16+nYj9Niv4RTESsdafKnM+o UZRpivUrOG+6P1+3ZelZAguirCz+oeFkovBfjb7Rjym6y35eXCo/KP+tjTajsNb9OYwX kNKgog+kLHUPMJ1e8CFVN5tSE044KUy/phqWclTkiovaYtg0yeXpWHpfIrbBWtfj2t9Y lgnlml/C3oW4rmsQkCSSRiSkvuGAceMwY7ruENUDk9Oz9C+VnHC0pu7y6lvaqZW77/J7 Gj33Ps5BNMEsNEiX0A4o0LGvVjrco0TcTiZvfZb1DnXi8hzNVB1W+LyFKsqMFC65Plv4 8T7A== X-Received: by 10.181.13.13 with SMTP id eu13mr5113779wid.26.1370880624406; Mon, 10 Jun 2013 09:10:24 -0700 (PDT) Received: from [10.147.129.63] ([188.207.110.177]) by mx.google.com with ESMTPSA id fu14sm12420717wic.8.2013.06.10.09.10.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 09:10:23 -0700 (PDT) References: <514C5FC3.20007@isoc.org> <51A814A9.8060208@isoc.org> <4E1F6AAD24975D4BA5B16804296739436781B290@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436781B290@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5718F173-3201-406B-8824-D46B7FF75C72; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: John Bradley Date: Mon, 10 Jun 2013 18:10:17 +0200 To: Mike Jones X-Gm-Message-State: ALoCoQkLZTladZEgkc4xXSfHhHloaq4EGtAv3d+9U2XsLoeu38ZrN7dSs/zpwBd0x+MccG3c4PhY Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] jose wg teleconference announcement - 17 June 2013 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:10:27 -0000 --Apple-Mail-5718F173-3201-406B-8824-D46B7FF75C72 Content-Type: multipart/alternative; boundary=Apple-Mail-D9D463B5-44DF-4310-B777-B2E67FAE7F4E Content-Transfer-Encoding: 7bit --Apple-Mail-D9D463B5-44DF-4310-B777-B2E67FAE7F4E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I am on a train. I will call once I arrive=20 Sent from my iPhone On 2013-06-10, at 6:07 PM, Mike Jones wrote: > What is the call-in information? Sorry if I missed it. >=20 > -- Mike >=20 > From: Karen O'Donoghue > Sent: 5/30/2013 8:11 PM > To: jose@ietf.org > Subject: [jose] jose wg teleconference announcement - 17 June 2013 >=20 > The jose working group will have a teleconference on Monday 17 June 2013=20= > at 5:00 pm UTC (10:00 am PDT / 1:00 pm EDT). >=20 > The primary objective of the call will be to ensure the results of the=20 > interim meeting were adequately incorporated and to identify any final=20 > issues on the recently published drafts. >=20 > The interim meeting minutes are available at: > http://www.ietf.org/proceedings/interim/2013/04/29/jose/minutes/minutes-in= terim-2013-jose-1 >=20 > The updated specifications are available at: > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11 > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11 > http://tools.ietf.org/html/draft-ietf-jose-json-web-key-11 > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-11 >=20 > An agenda and webex details will be available next week. >=20 > Regards, > Karen >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-D9D463B5-44DF-4310-B777-B2E67FAE7F4E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I am on a train. I will call once I arrive 

Sent from my iPhone

On 2013-06-10, at 6:07 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

What is the call-in information?  Sorry if I missed it.

-- Mike


From: Karen O'Donoghue
Sent: 5/30/2013 8:11 PM
To: jose@ietf.org
Subject: [jose] jose wg teleconference announcement - 17 June 2013

The jose working group will have a teleconference on Monday 17 June 2013
at 5:00 pm UTC (10:00 am PDT / 1:00 pm EDT).

The primary objective of the call will be to ensure the results of the
interim meeting were adequately incorporated and to identify any final
issues on the recently published drafts.

The interim meeting minutes are available at:
http://www.ietf.org/proceedings/interim/2013/04/29/jose/minutes/minutes-interim-2013-jose-1

The updated specifications are available at:
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11
http://tools.ietf.org/html/draft-ietf-jose-json-web-key-11
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-11

An agenda and webex details will be available next week.

Regards,
Karen

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
--Apple-Mail-D9D463B5-44DF-4310-B777-B2E67FAE7F4E-- --Apple-Mail-5718F173-3201-406B-8824-D46B7FF75C72 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYxMDE2MTAyMVowIwYJKoZIhvcNAQkEMRYEFK/A bw+O7T9dywPl6l+/YMYXa2wiMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBAGfRj1+5Hx4i7Ov/1fklFT/zf14c8E+e+oG7 25Qvhs4glOQEslpBFPY8Nh3rZRZ14IIQSEwrYcm4/xWQ4j8Zxa6XflZxXZ08dsCgfTxmYChMB97e di6PbCx8GoCQooOlarkJF/fA541VCqcBMGjnNkGLBpRkO5B7hOt+OLZwhHz67bH05ItYYDx1iV1n 3xNV85GdnhpFXglehfFhBJkEIJcIA5cY3F5Pak4liiRFYjTVCztpV9NdowJ8I6JrZem7WJU4Fl3t RDfBbynoxSK7j/P+Mlkk49RMpuf8cPFPZFvsz0ITMc/nJaqnUiz9td/I4G7mcrgo/xUOwNWBl/dX 2GsAAAAAAAA= --Apple-Mail-5718F173-3201-406B-8824-D46B7FF75C72-- From ve7jtb@ve7jtb.com Mon Jun 10 09:11:44 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37C421F95D7 for ; Mon, 10 Jun 2013 09:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OE-p9nM5PHJt for ; Mon, 10 Jun 2013 09:11:44 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCE121F9619 for ; Mon, 10 Jun 2013 09:11:39 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so1560511wiv.2 for ; Mon, 10 Jun 2013 09:11:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=Wnwcg7aThSvDJtH1NLkJIQbYM+l18nfYz8vIRyNTgw8=; b=W1uzKBZQpePIS8/sd3/Fs4qFxBRv+VeZ3lbO0lUX7rTXrYuyjmhDKG49Vex01EWXrp bBq1sYxyLho2HoaVbutCAfLOXhAijkzyXbOT2Znu+PDEAB/6KbhPRx8lA8APZq7GrkQN AK706LO7rNbrLN2XNhDfosbHPe3X+CraH01ETQfyGL38RnLvTvBOi72BEqYImARqF6ph ASx6xKmW/MfJykDhPilVoDPP204/lPlAlaCN2ApkiUP1B30W4lVSMmYyiNEyKmBRA9jc nB+lBzTk8XltgiZ08ovxV+XcRb7MOSLku3FUg/gpJEvdYXCmF3WAzqoz9uKlHGZ3ZiBc B82g== X-Received: by 10.180.36.205 with SMTP id s13mr5134000wij.31.1370880698789; Mon, 10 Jun 2013 09:11:38 -0700 (PDT) Received: from [10.147.129.63] ([188.207.110.177]) by mx.google.com with ESMTPSA id m3sm12441575wij.5.2013.06.10.09.11.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 09:11:37 -0700 (PDT) References: <514C5FC3.20007@isoc.org> <51A814A9.8060208@isoc.org> <4E1F6AAD24975D4BA5B16804296739436781B290@TK5EX14MBXC283.redmond.corp.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436781B290@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8AEFF63A-9826-4285-98D1-D8804D46098F; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B329) From: John Bradley Date: Mon, 10 Jun 2013 18:11:35 +0200 To: Mike Jones X-Gm-Message-State: ALoCoQlUfwLFCLl2Gr+FG9hYaCD/FSZ6vVkMARMynHG7KGg6CPMqMw5NAR6GrEBVBpvqGfFMmc1k Cc: "jose@ietf.org" , "odonoghue@isoc.org" Subject: Re: [jose] jose wg teleconference announcement - 17 June 2013 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:11:44 -0000 --Apple-Mail-8AEFF63A-9826-4285-98D1-D8804D46098F Content-Type: multipart/alternative; boundary=Apple-Mail-20ACA2DF-FC5D-4666-BC87-D07E250B3B5B Content-Transfer-Encoding: 7bit --Apple-Mail-20ACA2DF-FC5D-4666-BC87-D07E250B3B5B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Wait you tricked me, it is next Monday.=20 Sent from my iPhone On 2013-06-10, at 6:07 PM, Mike Jones wrote: > What is the call-in information? Sorry if I missed it. >=20 > -- Mike >=20 > From: Karen O'Donoghue > Sent: 5/30/2013 8:11 PM > To: jose@ietf.org > Subject: [jose] jose wg teleconference announcement - 17 June 2013 >=20 > The jose working group will have a teleconference on Monday 17 June 2013=20= > at 5:00 pm UTC (10:00 am PDT / 1:00 pm EDT). >=20 > The primary objective of the call will be to ensure the results of the=20 > interim meeting were adequately incorporated and to identify any final=20 > issues on the recently published drafts. >=20 > The interim meeting minutes are available at: > http://www.ietf.org/proceedings/interim/2013/04/29/jose/minutes/minutes-in= terim-2013-jose-1 >=20 > The updated specifications are available at: > http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11 > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11 > http://tools.ietf.org/html/draft-ietf-jose-json-web-key-11 > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-11 >=20 > An agenda and webex details will be available next week. >=20 > Regards, > Karen >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-20ACA2DF-FC5D-4666-BC87-D07E250B3B5B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Wait you tricked me,  it is next Monday. 

Sent from my iPhone

On 2013-06-10, at 6:07 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

What is the call-in information?  Sorry if I missed it.

-- Mike


From: Karen O'Donoghue
Sent: 5/30/2013 8:11 PM
To: jose@ietf.org
Subject: [jose] jose wg teleconference announcement - 17 June 2013

The jose working group will have a teleconference on Monday 17 June 2013
at 5:00 pm UTC (10:00 am PDT / 1:00 pm EDT).

The primary objective of the call will be to ensure the results of the
interim meeting were adequately incorporated and to identify any final
issues on the recently published drafts.

The interim meeting minutes are available at:
http://www.ietf.org/proceedings/interim/2013/04/29/jose/minutes/minutes-interim-2013-jose-1

The updated specifications are available at:
http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-11
http://tools.ietf.org/html/draft-ietf-jose-json-web-key-11
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-11

An agenda and webex details will be available next week.

Regards,
Karen

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose
--Apple-Mail-20ACA2DF-FC5D-4666-BC87-D07E250B3B5B-- --Apple-Mail-8AEFF63A-9826-4285-98D1-D8804D46098F Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDYxMDE2MTEzN1owIwYJKoZIhvcNAQkEMRYEFEgS 96R03CA2IOXoCNXC6neZ+WxmMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBAFv/aHM/JvmvLMpFYljIp62AU3SSfHvH+7uf jYTL4nQXHqqDzry86MSZZnyGWsfRDAdUc/II7WSl4PiXcsyEsxwFtVVs/KqocEx+whiVXOJS7G0y HVGHuBck08D4HcZTXyJ5KMN6lvHCUDsn7mYnOai930A7rLGoFYk4QVV4lxRMx3E+ObJPDCneRlia OzV370RqfhzZ9oMPHALtfzGNgPtEm7BpkcxzG4L+a5JdNZoxqthNxkIy9Yb/+y8ZOmu20c6GV0G1 1rxTuxpJ8+wn3Z8J/1n31B2yueKvrhN8CjmyOqVkOhnTpu09/gv69BkxEMqE06kL1OHYr0ZnQcEV UvEAAAAAAAA= --Apple-Mail-8AEFF63A-9826-4285-98D1-D8804D46098F-- From odonoghue@isoc.org Mon Jun 10 09:20:50 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CDC21F9732 for ; Mon, 10 Jun 2013 09:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.264 X-Spam-Level: X-Spam-Status: No, score=-103.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWDHPm9Zk+rM for ; Mon, 10 Jun 2013 09:20:46 -0700 (PDT) Received: from smtp146.dfw.emailsrvr.com (smtp146.dfw.emailsrvr.com [67.192.241.146]) by ietfa.amsl.com (Postfix) with ESMTP id 67F8521F993E for ; Mon, 10 Jun 2013 09:20:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 6775218077B for ; Mon, 10 Jun 2013 12:20:29 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id D14A3180787 for ; Mon, 10 Jun 2013 12:20:28 -0400 (EDT) Message-ID: <51B5FCCB.1000502@isoc.org> Date: Mon, 10 Jun 2013 12:20:27 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "jose@ietf.org" References: <425517518.61374.1370276346881.JavaMail.nobody@jva2tc003.webex.com> In-Reply-To: <425517518.61374.1370276346881.JavaMail.nobody@jva2tc003.webex.com> X-Forwarded-Message-Id: <425517518.61374.1370276346881.JavaMail.nobody@jva2tc003.webex.com> Content-Type: multipart/alternative; boundary="------------010104000103010807010700" Subject: [jose] webex information for JOSE teleconference: 17 June 2013 @ 1:00 pm EDT X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:20:50 -0000 This is a multi-part message in MIME format. --------------010104000103010807010700 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Folks, Here is the webex information for the call next Monday. Karen Cindy Morgan invites you to attend this online meeting. Topic: JOSE Date: Monday, June 17, 2013 Time: 11:00 am, Mountain Daylight Time (Denver, GMT-06:00) Meeting Number: 648 447 409 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=225472827&UID=1566381972&PW=NOWQ4YWY3NDc1&RT=MiM2 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=225472827&UID=1566381972&PW=NOWQ4YWY3NDc1&ORT=MiM2 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:648 447 409 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: cmorgan@amsl.com 1-510-492-4085 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=225472827&UID=1566381972&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAnBS0dxwb5o23cp6D4NhhtUFgQ0Ft4xS6lHRlHHZAwFT&RT=MiM2 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x648447409# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --------------010104000103010807010700 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Folks,

Here is the webex information for the call next Monday.

Karen


Cindy Morgan invites you to attend this online meeting.

Topic: JOSE
Date: Monday, June 17, 2013
Time: 11:00 am, Mountain Daylight Time (Denver, GMT-06:00)
Meeting Number: 648 447 409
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?ED=225472827&UID=1566381972&PW=NOWQ4YWY3NDc1&RT=MiM2
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?ED=225472827&UID=1566381972&PW=NOWQ4YWY3NDc1&ORT=MiM2

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
Call-in toll number (US/Canada): 1-650-479-3208

Access code:648 447 409

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You can contact me at:
cmorgan@amsl.com
1-510-492-4085

To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://ietf.webex.com/ietf/j.php?ED=225472827&UID=1566381972&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAnBS0dxwb5o23cp6D4NhhtUFgQ0Ft4xS6lHRlHHZAwFT&RT=MiM2

The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com

CCP:+16504793208x648447409#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.


--------------010104000103010807010700-- From rlb@ipv.sx Mon Jun 10 09:28:35 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB33A21F85C0 for ; Mon, 10 Jun 2013 09:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGTbLbPv0Lfi for ; Mon, 10 Jun 2013 09:28:31 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A071021F859A for ; Mon, 10 Jun 2013 09:28:31 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id ef5so10423847obb.15 for ; Mon, 10 Jun 2013 09:28:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=FSHLbw2XtWDOHnr219Ppk3c8z9JfAKN98iOFYcSxkyM=; b=RTA8UfWeHjJiu9dehn9mVqfVXFv46DrcwDgstTIjmHfuQAz37FHEUYFOvix0PlAMxY 6sZPwly8DFOVqVdaYniX2ZZACVFVSaLF6FfNsLUKsGuOZBEhsB3AleZIM5iuTgyfScYX cF6dYgmDzk3aisMLyRqFT7uTedIVwBqxWyAohNwZ+zzhagZM/38/ynp4jNngs3g40bGo nVKnAHaNE4ig+t9QixFly2DWXP8pJs4E+eFCBWLGfHfjxqMg/PIgOWw+Q+hzWqj45amJ TEDlj9Yh76WvZwvCc5wKB2tpgOjEUjlcfItyT34ZZE/oMYTTha31Cx+t3jr+AYoLC1lN K5tg== MIME-Version: 1.0 X-Received: by 10.60.52.15 with SMTP id p15mr8585693oeo.87.1370881711117; Mon, 10 Jun 2013 09:28:31 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Mon, 10 Jun 2013 09:28:31 -0700 (PDT) X-Originating-IP: [192.1.255.206] In-Reply-To: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> References: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> Date: Mon, 10 Jun 2013 12:28:31 -0400 Message-ID: From: Richard Barnes To: Jim Schaad Content-Type: multipart/alternative; boundary=001a113309ce6bf3fc04decf458f X-Gm-Message-State: ALoCoQlkhUUnrobD01byzRKymLAdOgLwi42SxcvaBav4aWxBETYJ41lIjrFyo+YwGQxYpKI7PZab Cc: "jose@ietf.org" Subject: Re: [jose] Possible change to protected field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:28:35 -0000 --001a113309ce6bf3fc04decf458f Content-Type: text/plain; charset=ISO-8859-1 This sounds like a fine idea to me. It saves space and makes the JSON format more human-readable. It actually makes kind of a nice analogy to ASN.1, namely use of OCTET STRING to encapsulate more DER content. The compact serialization can continue to base64url-encode that field, so it would not be a breaking change for that serialization. --Richard On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad wrote: > **** > > ** ** > > I am trying to figure out if I am missing something. This is not yet a > formal proposal to actual change the document.**** > > ** ** > > I was thinking about proposing that we make a change to the content of the > protected field in the JWS JSON serialization format. If we encoded this > as a UTF8 string rather than the base64url encoded UTF8 string, then the > content would be smaller. The computation of the signature would be > unchanged in that it would still be computed over the base64url encoded > string. I believe that the conversion from the UTF8 string to the > base64url encoded UTF8 string is a deterministic encoding and thus would > not generate any problems from that point.**** > > ** ** > > At this point I and trying to figure out if I missed anything that would > preclude this from working. I am not worried about how hard or easy it > would be to do, just if it is even possible.**** > > ** ** > > Jim**** > > ** ** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --001a113309ce6bf3fc04decf458f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This sounds like a fine idea to me. =A0It saves space and = makes the JSON format more human-readable. =A0It actually makes kind of a n= ice analogy to ASN.1, namely use of OCTET STRING to encapsulate more DER co= ntent.

The compact serialization can continue to base64url-encode t= hat field, so it would not be a breaking change for that serialization.

--Richard


On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad = <ietf@augustcellars.com> wrote:

<no hat>

=A0

I am trying to figure out if I am missing somet= hing.=A0 This is not yet a formal proposal to actual change the document.

=A0

I was th= inking about proposing that we make a change to the content of the protecte= d field in the JWS JSON serialization format.=A0 If we encoded this as a UT= F8 string rather than the base64url encoded UTF8 string, then the content w= ould be smaller. =A0The computation of the signature would be unchanged in = that it would still be computed over the base64url encoded string.=A0 I bel= ieve that the conversion from the UTF8 string to the base64url encoded UTF8= string is a deterministic encoding and thus would not generate any problem= s from that point.

=A0

At this = point I and trying to figure out if I missed anything that would preclude t= his from working. =A0I am not worried about how hard or easy it would be to= do, just if it is even possible.

=A0

Jim

=A0


________________= _______________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--001a113309ce6bf3fc04decf458f-- From rlb@ipv.sx Mon Jun 10 09:32:04 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE0521F9675 for ; Mon, 10 Jun 2013 09:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQXo+xkpArqF for ; Mon, 10 Jun 2013 09:32:00 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1D23621F8900 for ; Mon, 10 Jun 2013 09:31:43 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id 16so10319377obc.26 for ; Mon, 10 Jun 2013 09:31:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=8NvWVCyFFTBEBYl6yq7fXg9YnK2IEtX5L3Z3VnRdeFE=; b=hvVO6QJaqZZqse5Rhfe5AaNJ8O7K0j44XirwGzEbyeJ/1LkHwYBUmrlfi/Wl2/mH1f 9rtOE7cfDWbfu3L4A9R1DmxJy4/ebJjsl/ojFSTgBash+l+IEEpR4Po+q3FGGQAVm3s9 idsDjortlPASJB0hav+dEn7h6UUg3NaYw5UolYPcs4mIee1ksx2jFlNPi+zMc7F8HKDI hOdQthfMdGYWRUT4URkFRDWDRkCDnclqPFkDcHDthd4sFC+wdJdFdAQlVTZeGLKy22Qf xnw0GXEhk+al2Qof/RkfJqid+6qahLTXw3D8+/PXSue0VJuYc6ZYYcFd4zStqb/3s8dz SW9Q== MIME-Version: 1.0 X-Received: by 10.182.74.131 with SMTP id t3mr8733861obv.87.1370881902528; Mon, 10 Jun 2013 09:31:42 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Mon, 10 Jun 2013 09:31:42 -0700 (PDT) X-Originating-IP: [192.1.255.206] In-Reply-To: References: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> Date: Mon, 10 Jun 2013 12:31:42 -0400 Message-ID: From: Richard Barnes To: Jim Schaad Content-Type: multipart/alternative; boundary=001a11c1be06d4becd04decf5095 X-Gm-Message-State: ALoCoQmQLsUuq9Y1DhFY/49TqsWlFmxn1d3I65ykarul0kIgwd/7bQeaB6Hl2/5tBuJ67cFOc5A+ Cc: "jose@ietf.org" Subject: Re: [jose] Possible change to protected field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:32:04 -0000 --001a11c1be06d4becd04decf5095 Content-Type: text/plain; charset=ISO-8859-1 On second thought: It seems like the signature should actually be over the UTF-8 octets, rather than the base64 octets. To reason by analogy: For every other field in a JWE, you decode the field before using it in a cryptographic computation. So it should be the same with the protected header. --Richard On Mon, Jun 10, 2013 at 12:28 PM, Richard Barnes wrote: > This sounds like a fine idea to me. It saves space and makes the JSON > format more human-readable. It actually makes kind of a nice analogy to > ASN.1, namely use of OCTET STRING to encapsulate more DER content. > > The compact serialization can continue to base64url-encode that field, so > it would not be a breaking change for that serialization. > > --Richard > > > On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad wrote: > >> **** >> >> ** ** >> >> I am trying to figure out if I am missing something. This is not yet a >> formal proposal to actual change the document.**** >> >> ** ** >> >> I was thinking about proposing that we make a change to the content of >> the protected field in the JWS JSON serialization format. If we encoded >> this as a UTF8 string rather than the base64url encoded UTF8 string, then >> the content would be smaller. The computation of the signature would be >> unchanged in that it would still be computed over the base64url encoded >> string. I believe that the conversion from the UTF8 string to the >> base64url encoded UTF8 string is a deterministic encoding and thus would >> not generate any problems from that point.**** >> >> ** ** >> >> At this point I and trying to figure out if I missed anything that would >> preclude this from working. I am not worried about how hard or easy it >> would be to do, just if it is even possible.**** >> >> ** ** >> >> Jim**** >> >> ** ** >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > --001a11c1be06d4becd04decf5095 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On second thought: It seems like the signature should actu= ally be over the UTF-8 octets, rather than the base64 octets. =A0To reason = by analogy: For every other field in a JWE, you decode the field before usi= ng it in a cryptographic computation. =A0So it should be the same with the = protected header.

--Richard


On Mon, Jun 10, 2013 at 12:28 PM, Richard Barnes <rlb@ipv.= sx> wrote:
This sounds like a fine ide= a to me. =A0It saves space and makes the JSON format more human-readable. = =A0It actually makes kind of a nice analogy to ASN.1, namely use of OCTET S= TRING to encapsulate more DER content.

The compact serialization can continue to base64url-encode t= hat field, so it would not be a breaking change for that serialization.

--Richard


On Mon, Jun 10, 2013 = at 1:46 AM, Jim Schaad <ietf@augustcellars.com> wrote:<= br>

<no hat>

=A0

I am trying to figure out if I am missing somet= hing.=A0 This is not yet a formal proposal to actual change the document.

=A0

I was th= inking about proposing that we make a change to the content of the protecte= d field in the JWS JSON serialization format.=A0 If we encoded this as a UT= F8 string rather than the base64url encoded UTF8 string, then the content w= ould be smaller. =A0The computation of the signature would be unchanged in = that it would still be computed over the base64url encoded string.=A0 I bel= ieve that the conversion from the UTF8 string to the base64url encoded UTF8= string is a deterministic encoding and thus would not generate any problem= s from that point.

=A0

At this = point I and trying to figure out if I missed anything that would preclude t= his from working. =A0I am not worried about how hard or easy it would be to= do, just if it is even possible.

=A0

<= p class=3D"MsoNormal">Jim

= =A0


___________________= ____________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--001a11c1be06d4becd04decf5095-- From Michael.Jones@microsoft.com Mon Jun 10 09:39:01 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E15821F84B4 for ; Mon, 10 Jun 2013 09:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sjc8dfyqnMjE for ; Mon, 10 Jun 2013 09:38:56 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id D0E8121F84B1 for ; Mon, 10 Jun 2013 09:38:55 -0700 (PDT) Received: from BY2FFO11FD014.protection.gbl (10.1.15.201) by BY2FFO11HUB012.protection.gbl (10.1.14.83) with Microsoft SMTP Server (TLS) id 15.0.707.0; Mon, 10 Jun 2013 16:38:53 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Mon, 10 Jun 2013 16:38:52 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.110]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0136.001; Mon, 10 Jun 2013 16:38:43 +0000 From: Mike Jones To: Richard Barnes , Jim Schaad Thread-Topic: [jose] Possible change to protected field Thread-Index: Ac5lnSf72X6a3Ku/SKOo5PcgVR4NIgAWmNmAAAAbQTA= Date: Mon, 10 Jun 2013 16:38:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436781C117@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436781C117TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(24454002)(377454002)(512954002)(50986001)(63696002)(54356001)(53806001)(80022001)(20776003)(74366001)(561944002)(76786001)(69226001)(56776001)(77096001)(47446002)(74706001)(16406001)(33656001)(59766001)(79102001)(56816003)(65816001)(81342001)(77982001)(76482001)(76796001)(47976001)(81542001)(15202345002)(74502001)(66066001)(46102001)(44976003)(31966008)(16236675002)(71186001)(4396001)(6806003)(54316002)(74662001)(51856001)(47736001)(74876001)(55846006)(49866001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB012; H:TK5EX14HUBC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 087396016C Cc: "jose@ietf.org" Subject: Re: [jose] Possible change to protected field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:39:01 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436781C117TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The problem with this suggested change is that it requires unencoded JSON o= bjects to be transmitted with no transformations whatsoever, whereas the pr= oblems with this assumption are well known. For starters, on UNIX-based sy= stems, newlines are typically represented by a bare LF character, whereas o= n DOS-based systems, newlines are typically represented by a CRLF pair. In= transmission, many systems, including mail agents tend to convert newlines= to the system's normal format. This would break these JOSE objects. Some agents wrap lines after a certain length. Particularly when being tra= nsmitted in HTML or XML, many systems replace two or more consecutive space= s with a single space. Others replace two or more spaces with a single spa= ce and N-1 non-breaking space characters. I could go on... I appreciate the attempt to make things appear to be more uniform and reada= ble, but the CRLF/LF problems alone are enough to make this a non-starter. Best wishes= , -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Monday, June 10, 2013 9:29 AM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Possible change to protected field This sounds like a fine idea to me. It saves space and makes the JSON form= at more human-readable. It actually makes kind of a nice analogy to ASN.1,= namely use of OCTET STRING to encapsulate more DER content. The compact serialization can continue to base64url-encode that field, so i= t would not be a breaking change for that serialization. --Richard On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad > wrote: I am trying to figure out if I am missing something. This is not yet a for= mal proposal to actual change the document. I was thinking about proposing that we make a change to the content of the = protected field in the JWS JSON serialization format. If we encoded this a= s a UTF8 string rather than the base64url encoded UTF8 string, then the con= tent would be smaller. The computation of the signature would be unchanged= in that it would still be computed over the base64url encoded string. I b= elieve that the conversion from the UTF8 string to the base64url encoded UT= F8 string is a deterministic encoding and thus would not generate any probl= ems from that point. At this point I and trying to figure out if I missed anything that would pr= eclude this from working. I am not worried about how hard or easy it would= be to do, just if it is even possible. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436781C117TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The problem with this sug= gested change is that it requires unencoded JSON objects to be transmitted = with no transformations whatsoever, whereas the problems with this assumption are well known.  For starters, on UNIX-based sys= tems, newlines are typically represented by a bare LF character, whereas on= DOS-based systems, newlines are typically represented by a CRLF pair. = ; In transmission, many systems, including mail agents tend to convert newlines to the system’s normal format.&= nbsp; This would break these JOSE objects.

 <= /p>

Some agents wrap lines af= ter a certain length.  Particularly when being transmitted in HTML or = XML, many systems replace two or more consecutive spaces with a single space.  Others replace two or more spaces with a single spac= e and N-1 non-breaking space characters.  I could go on…

 <= /p>

I appreciate the attempt = to make things appear to be more uniform and readable, but the CRLF/LF prob= lems alone are enough to make this a non-starter.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         Best wishes,

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, June 10, 2013 9:29 AM
To: Jim Schaad
Cc: jose@ietf.org
Subject: Re: [jose] Possible change to protected field

 

This sounds like a fine idea to me.  It saves s= pace and makes the JSON format more human-readable.  It actually makes= kind of a nice analogy to ASN.1, namely use of OCTET STRING to encapsulate= more DER content.

 

The compact serialization can continue to base64url-= encode that field, so it would not be a breaking change for that serializat= ion.

 

--Richard

 

On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad <ietf@augustcellars.= com> wrote:

<no hat>

 

I am trying to figure out if I am missing something.  This is= not yet a formal proposal to actual change the document.

 

I was thinking about proposing that we make a change to the conten= t of the protected field in the JWS JSON serialization format.  If we = encoded this as a UTF8 string rather than the base64url encoded UTF8 string, then the content would be smaller. &nbs= p;The computation of the signature would be unchanged in that it would stil= l be computed over the base64url encoded string.  I believe that the c= onversion from the UTF8 string to the base64url encoded UTF8 string is a deterministic encoding and thus would not generat= e any problems from that point.

 

At this point I and trying to figure out if I missed anything that= would preclude this from working.  I am not worried about how hard or= easy it would be to do, just if it is even possible.

 

Jim

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B16804296739436781C117TK5EX14MBXC283r_-- From rlb@ipv.sx Mon Jun 10 10:01:03 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82D221F995F for ; Mon, 10 Jun 2013 10:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfSc2Yl46Lqw for ; Mon, 10 Jun 2013 10:00:54 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 370E021F9965 for ; Mon, 10 Jun 2013 10:00:54 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id l20so6327479oag.9 for ; Mon, 10 Jun 2013 10:00:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=AWKu7RQh2uQcZFOwVAxLHjWigX3lcyAZMvwYpLQuBMo=; b=Kr9lnULv9yFK/GBV0AKWVdZ9LErymR/PrXUN4gCAaFSnaFauqiz80H67WyCRXMyMoh y/AS19Kt4T5/y8XL9KYEJHgVg/Jn3yXo67IP2lSxfHdX8DG19GBcv0f52aEAtXWFeBdW JLulH4IRxr3altxa01jKz4P0eO9azF90d9//nJY8E9zbkXQoDNiCl9cBnh9BMdm0EVZg K3isQyAqPlhs8sif3llzCoVo+n7/2MIvDNlXbESkYjQAK1Fs3HJSK7zeSNPwHv8eOQRq PnLGWtBAwz4i7j/+mMe2UVlAkpakivdsVvOxnEvNAqfRsAsmfCe/dU9WihMuTvC5ZPIB J0wQ== MIME-Version: 1.0 X-Received: by 10.60.134.236 with SMTP id pn12mr9138746oeb.4.1370883653684; Mon, 10 Jun 2013 10:00:53 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Mon, 10 Jun 2013 10:00:53 -0700 (PDT) X-Originating-IP: [192.1.255.206] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436781C117@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436781C117@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 10 Jun 2013 13:00:53 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=047d7b471f6a353c2104decfb91d X-Gm-Message-State: ALoCoQk0YdBjUnyDcRfVGialuHOZIxkZ48WQeTFXfP+HIQrYE8fYvaE3q+V3xSHVq4HE2CjwhZ71 Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Possible change to protected field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 17:01:04 -0000 --047d7b471f6a353c2104decfb91d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think you've misunderstood the proposal. It's not that the field will be unencoded, it's that it will be encoded as a UTF-8 string instead of a base64 string. OLD: (json) --> UTF-8 --> base64 NEW: (json) --> UTF-8 OLD: { protected: "eyJhbGciOiJSUzI1NiJ9Cg=3D=3D" } NEW: { protected: "{\"alg\":\"RS256\"}" } Now, there might still be a problem with that, because JSON strings aren't canonical. In the example above, the quote characters could also have been presented as "\u0022". So if some JSON re-processor were to change the encoding ot the string, it would break the signature. However, that's also a problem for the base64-encoded version ("a" vs. "\u0061"). On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones w= rote: > The problem with this suggested change is that it requires unencoded > JSON objects to be transmitted with no transformations whatsoever, wherea= s > the problems with this assumption are well known. For starters, on > UNIX-based systems, newlines are typically represented by a bare LF > character, whereas on DOS-based systems, newlines are typically represent= ed > by a CRLF pair. In transmission, many systems, including mail agents ten= d > to convert newlines to the system=92s normal format. This would break th= ese > JOSE objects.**** > > ** ** > > Some agents wrap lines after a certain length. Particularly when being > transmitted in HTML or XML, many systems replace two or more consecutive > spaces with a single space. Others replace two or more spaces with a > single space and N-1 non-breaking space characters. I could go on=85**** > > ** ** > > I appreciate the attempt to make things appear to be more uniform and > readable, but the CRLF/LF problems alone are enough to make this a > non-starter.**** > > ** ** > > Best > wishes,**** > > -- Mike**= * > * > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Monday, June 10, 2013 9:29 AM > *To:* Jim Schaad > *Cc:* jose@ietf.org > *Subject:* Re: [jose] Possible change to protected field**** > > ** ** > > This sounds like a fine idea to me. It saves space and makes the JSON > format more human-readable. It actually makes kind of a nice analogy to > ASN.1, namely use of OCTET STRING to encapsulate more DER content.**** > > ** ** > > The compact serialization can continue to base64url-encode that field, so > it would not be a breaking change for that serialization.**** > > ** ** > > --Richard**** > > ** ** > > On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad > wrote:**** > > **** > > **** > > I am trying to figure out if I am missing something. This is not yet a > formal proposal to actual change the document.**** > > **** > > I was thinking about proposing that we make a change to the content of th= e > protected field in the JWS JSON serialization format. If we encoded this > as a UTF8 string rather than the base64url encoded UTF8 string, then the > content would be smaller. The computation of the signature would be > unchanged in that it would still be computed over the base64url encoded > string. I believe that the conversion from the UTF8 string to the > base64url encoded UTF8 string is a deterministic encoding and thus would > not generate any problems from that point.**** > > **** > > At this point I and trying to figure out if I missed anything that would > preclude this from working. I am not worried about how hard or easy it > would be to do, just if it is even possible.**** > > **** > > Jim**** > > **** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > --047d7b471f6a353c2104decfb91d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I think you've misunderstood the proposal. =A0It's= not that the field will be unencoded, it's that it will be encoded as = a UTF-8 string instead of a base64 string.

OLD: (json) -= -> UTF-8 --> base64
NEW: (json) --> UTF-8

OLD: =A0{ protected:= "eyJhbGciOiJSUzI1NiJ9Cg=3D=3D" }
NEW: { protected: &qu= ot;{\"alg\":\"RS256\"}" }

Now, there might still be a problem with that, because JSON strings aren&#= 39;t canonical. =A0In the example above, the quote characters could also ha= ve been presented as "\u0022". =A0So if some JSON re-processor we= re to change the encoding ot the string, it would break the signature. =A0H= owever, that's also a problem for the base64-encoded version ("a&q= uot; vs. "\u0061").





<= div class=3D"gmail_quote">On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

The problem with this suggested change is that it req= uires unencoded JSON objects to be transmitted with no transformations what= soever, whereas the problems with this assumption are well known.=A0 For starters, on UNIX-based system= s, newlines are typically represented by a bare LF character, whereas on DO= S-based systems, newlines are typically represented by a CRLF pair.=A0 In t= ransmission, many systems, including mail agents tend to convert newlines to the system=92s normal format.=A0 T= his would break these JOSE objects.

=A0

Some agents wrap lines after a certain length.=A0 Par= ticularly when being transmitted in HTML or XML, many systems replace two o= r more consecutive spaces with a single space.=A0 Others replace two or more spaces with a single space a= nd N-1 non-breaking space characters.=A0 I could go on=85

=A0

I appreciate the attempt to make things appear to be = more uniform and readable, but the CRLF/LF problems alone are enough to mak= e this a non-starter.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Best wishes= ,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike<= /u>

=A0

From: jose-bounc= es@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, June 10, 2013 9:29 AM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Possible change to protected field=

=A0

This sounds like a fine idea to me. =A0It saves space and mak= es the JSON format more human-readable. =A0It actually makes kind of a nice= analogy to ASN.1, namely use of OCTET STRING to encapsulate more DER conte= nt.

=A0

The compact serialization can continue to base64url-encode th= at field, so it would not be a breaking change for that serialization.

=A0

--Richard

=A0

On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad <ietf@augustcellars.com&g= t; wrote:

<no hat>

=A0

I am trying to figure out if I am missing something.=A0 This = is not yet a formal proposal to actual change the document.

=A0

I was thinking about proposing that we make a change to the c= ontent of the protected field in the JWS JSON serialization format.=A0 If w= e encoded this as a UTF8 string rather than the base64url encoded UTF8 string, then the content would be smaller. =A0T= he computation of the signature would be unchanged in that it would still b= e computed over the base64url encoded string.=A0 I believe that the convers= ion from the UTF8 string to the base64url encoded UTF8 string is a deterministic encoding and thus would not generat= e any problems from that point.

=A0

At this point I and trying to figure out if I missed anything= that would preclude this from working. =A0I am not worried about how hard = or easy it would be to do, just if it is even possible.

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0


--047d7b471f6a353c2104decfb91d-- From Michael.Jones@microsoft.com Mon Jun 10 10:08:54 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8019721F85E6 for ; Mon, 10 Jun 2013 10:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zd9fismCBfv for ; Mon, 10 Jun 2013 10:08:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0D96121F88AC for ; Mon, 10 Jun 2013 10:08:48 -0700 (PDT) Received: from BL2FFO11FD012.protection.gbl (10.173.161.203) by BL2FFO11HUB032.protection.gbl (10.173.161.56) with Microsoft SMTP Server (TLS) id 15.0.707.0; Mon, 10 Jun 2013 17:08:46 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD012.mail.protection.outlook.com (10.173.161.18) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Mon, 10 Jun 2013 17:08:46 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.110]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0136.001; Mon, 10 Jun 2013 17:08:35 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] Possible change to protected field Thread-Index: Ac5lnSf72X6a3Ku/SKOo5PcgVR4NIgAWmNmAAAAbQTAAAQYggAAAFDPg Date: Mon, 10 Jun 2013 17:08:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436781D714@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436781C117@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436781D714TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(24454002)(377454002)(199002)(81542001)(6806003)(51856001)(47976001)(76786001)(63696002)(33656001)(80022001)(66066001)(16236675002)(74876001)(79102001)(49866001)(31966008)(50986001)(44976003)(74706001)(20776003)(56816003)(16406001)(65816001)(76796001)(54316002)(47736001)(56776001)(53806001)(512954002)(4396001)(55846006)(77096001)(76482001)(47446002)(71186001)(74366001)(46102001)(15202345002)(81342001)(74502001)(561944002)(74662001)(77982001)(59766001)(54356001)(69226001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB032; H:TK5EX14HUBC104.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 087396016C Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Possible change to protected field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 17:08:54 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436781D714TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This would take us down the road to canonicalization. How would you repres= ent a CRLF in the value? How would you represent a bare LF? How would you= represent a tab? Canonical representations for all of these, and more, wo= uld have to be specified. Using a special encoding for this field that is different than the encoding= used for all other fields (base64url encoding) is developer-hostile. It f= orces them to have (and test) special code to produce a different for this = field alone. This would undoubtedly result in interop problems, because th= e corner cases almost never get tested (and often never get coded correctly= either). We already have a simple means of ensuring the correct transmission of fiel= ds. Occam's Razor would suggest just using it. -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Monday, June 10, 2013 10:01 AM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] Possible change to protected field I think you've misunderstood the proposal. It's not that the field will be= unencoded, it's that it will be encoded as a UTF-8 string instead of a bas= e64 string. OLD: (json) --> UTF-8 --> base64 NEW: (json) --> UTF-8 OLD: { protected: "eyJhbGciOiJSUzI1NiJ9Cg=3D=3D" } NEW: { protected: "{\"alg\":\"RS256\"}" } Now, there might still be a problem with that, because JSON strings aren't = canonical. In the example above, the quote characters could also have been= presented as "\u0022". So if some JSON re-processor were to change the en= coding ot the string, it would break the signature. However, that's also a= problem for the base64-encoded version ("a" vs. "\u0061"). On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones > wrote: The problem with this suggested change is that it requires unencoded JSON o= bjects to be transmitted with no transformations whatsoever, whereas the pr= oblems with this assumption are well known. For starters, on UNIX-based sy= stems, newlines are typically represented by a bare LF character, whereas o= n DOS-based systems, newlines are typically represented by a CRLF pair. In= transmission, many systems, including mail agents tend to convert newlines= to the system's normal format. This would break these JOSE objects. Some agents wrap lines after a certain length. Particularly when being tra= nsmitted in HTML or XML, many systems replace two or more consecutive space= s with a single space. Others replace two or more spaces with a single spa= ce and N-1 non-breaking space characters. I could go on... I appreciate the attempt to make things appear to be more uniform and reada= ble, but the CRLF/LF problems alone are enough to make this a non-starter. Best wishes= , -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, June 10, 2013 9:29 AM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Possible change to protected field This sounds like a fine idea to me. It saves space and makes the JSON form= at more human-readable. It actually makes kind of a nice analogy to ASN.1,= namely use of OCTET STRING to encapsulate more DER content. The compact serialization can continue to base64url-encode that field, so i= t would not be a breaking change for that serialization. --Richard On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad > wrote: I am trying to figure out if I am missing something. This is not yet a for= mal proposal to actual change the document. I was thinking about proposing that we make a change to the content of the = protected field in the JWS JSON serialization format. If we encoded this a= s a UTF8 string rather than the base64url encoded UTF8 string, then the con= tent would be smaller. The computation of the signature would be unchanged= in that it would still be computed over the base64url encoded string. I b= elieve that the conversion from the UTF8 string to the base64url encoded UT= F8 string is a deterministic encoding and thus would not generate any probl= ems from that point. At this point I and trying to figure out if I missed anything that would pr= eclude this from working. I am not worried about how hard or easy it would= be to do, just if it is even possible. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436781D714TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This would take us down t= he road to canonicalization.  How would you represent a CRLF in the va= lue?  How would you represent a bare LF?  How would you represent a tab?  Canonical representations for all of these, and more, would h= ave to be specified.

 <= /p>

Using a special encoding = for this field that is different than the encoding used for all other field= s (base64url encoding) is developer-hostile.  It forces them to have (and test) special code to produce a different for this field= alone.  This would undoubtedly result in interop problems, because th= e corner cases almost never get tested (and often never get coded correctly= either).

 <= /p>

We already have a simple = means of ensuring the correct transmission of fields.  Occam’s R= azor would suggest just using it.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Monday, June 10, 2013 10:01 AM
To: Mike Jones
Cc: Jim Schaad; jose@ietf.org
Subject: Re: [jose] Possible change to protected field

 

I think you've misunderstood the proposal.  It'= s not that the field will be unencoded, it's that it will be encoded as a U= TF-8 string instead of a base64 string.

 

OLD: (json) --> UTF-8 --> base64

NEW: (json) --> UTF-8

 

OLD:  { protected: "eyJhbGciOiJSUzI1NiJ9Cg= =3D=3D" }

NEW: { protected: "{\"alg\":\"RS= 256\"}" }

 

Now, there might still be a problem with that, becau= se JSON strings aren't canonical.  In the example above, the quote cha= racters could also have been presented as "\u0022".  So if s= ome JSON re-processor were to change the encoding ot the string, it would break the signature.  However, that's also a problem= for the base64-encoded version ("a" vs. "\u0061").

 

 

 

 

On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

The problem with this suggested change = is that it requires unencoded JSON objects to be transmitted with no transformations whatsoever, whereas the problems with this assumpt= ion are well known.  For starters, on UNIX-based systems, newlines are= typically represented by a bare LF character, whereas on DOS-based systems= , newlines are typically represented by a CRLF pair.  In transmission, many systems, including mail agents= tend to convert newlines to the system’s normal format.  This w= ould break these JOSE objects.

 

Some agents wrap lines after a certain = length.  Particularly when being transmitted in HTML or XML, many systems replace two or more consecutive spaces with a single space.&n= bsp; Others replace two or more spaces with a single space and N-1 non-brea= king space characters.  I could go on…

 

I appreciate the attempt to make things= appear to be more uniform and readable, but the CRLF/LF problems alone are enough to make this a non-starter.

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;       Best wishes,

      &nb= sp;            =             &nb= sp;            =             &nb= sp;       -- Mike

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, June 10, 2013 9:29 AM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Possible change to protected field

 

This sounds like a fine idea to me.  It saves space and makes= the JSON format more human-readable.  It actually makes kind of a nic= e analogy to ASN.1, namely use of OCTET STRING to encapsulate more DER content.

 

The compact serialization can continue to base64url-encode that fi= eld, so it would not be a breaking change for that serialization.

 

--Richard

 

On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad <ietf@augustcellars.com> wr= ote:

<no hat>

 

I am trying to figure out if I am missing something.  This is= not yet a formal proposal to actual change the document.

 

I was thinking about proposing that we make a change to the conten= t of the protected field in the JWS JSON serialization format.  If we = encoded this as a UTF8 string rather than the base64url encoded UTF8 string, then the content would be smaller. &nbs= p;The computation of the signature would be unchanged in that it would stil= l be computed over the base64url encoded string.  I believe that the c= onversion from the UTF8 string to the base64url encoded UTF8 string is a deterministic encoding and thus would not generat= e any problems from that point.

 

At this point I and trying to figure out if I missed anything that= would preclude this from working.  I am not worried about how hard or= easy it would be to do, just if it is even possible.

 

Jim

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436781D714TK5EX14MBXC283r_-- From ietf@augustcellars.com Mon Jun 10 10:25:48 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798A021F94DC for ; Mon, 10 Jun 2013 10:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xf9Vsd-Afm7q for ; Mon, 10 Jun 2013 10:25:43 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABA9421F9690 for ; Mon, 10 Jun 2013 10:25:43 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D3DEB2CA29; Mon, 10 Jun 2013 10:25:42 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Richard Barnes'" References: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436781C117@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436781C117@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 10 Jun 2013 10:24:50 -0700 Message-ID: <067701ce65ff$6a1d8b30$3e58a190$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0678_01CE65C4.BDC039D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG0QxNjNQen5xE7UI53mmuxyr9BfQI0cZ/ZAVlbblKZRwW1AA== Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Possible change to protected field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 17:25:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0678_01CE65C4.BDC039D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mike, I can dispose of the CRLF question quite simply. I have not removed the UTF8 string from the protected field so all CRLF characters (along with a number of others) will be escaped so they will not be transformed. It would still be {"protected":"---UTF8 encoded string ---"} Rather than {"protected":"--- Base64 URL encoded ( -- UTF8 encoded string -- ) ---" } There are a number of other questions that do come into play that you did raise however. The first would be space folding - It has been my experience that this is normally the XML parser that does it rather than things in transit. There will always be a problem with things in the middle that could possibly change things with this approach. It is something that I need to be looked at and think about. If we have a line wrapping issue, this is going to be a problem with JSON parsers today. It is not legal to have any of the CRLF characters inside of a string in JSON according to the current ABNF in the document. I think this may already cause parsers to go boom in some cases. If this is going to be a real issue then we probably need to start dealing with it sooner rather than later. Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, June 10, 2013 9:39 AM To: Richard Barnes; Jim Schaad Cc: jose@ietf.org Subject: RE: [jose] Possible change to protected field The problem with this suggested change is that it requires unencoded JSON objects to be transmitted with no transformations whatsoever, whereas the problems with this assumption are well known. For starters, on UNIX-based systems, newlines are typically represented by a bare LF character, whereas on DOS-based systems, newlines are typically represented by a CRLF pair. In transmission, many systems, including mail agents tend to convert newlines to the system's normal format. This would break these JOSE objects. Some agents wrap lines after a certain length. Particularly when being transmitted in HTML or XML, many systems replace two or more consecutive spaces with a single space. Others replace two or more spaces with a single space and N-1 non-breaking space characters. I could go on. I appreciate the attempt to make things appear to be more uniform and readable, but the CRLF/LF problems alone are enough to make this a non-starter. Best wishes, -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, June 10, 2013 9:29 AM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Possible change to protected field This sounds like a fine idea to me. It saves space and makes the JSON format more human-readable. It actually makes kind of a nice analogy to ASN.1, namely use of OCTET STRING to encapsulate more DER content. The compact serialization can continue to base64url-encode that field, so it would not be a breaking change for that serialization. --Richard On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad wrote: I am trying to figure out if I am missing something. This is not yet a formal proposal to actual change the document. I was thinking about proposing that we make a change to the content of the protected field in the JWS JSON serialization format. If we encoded this as a UTF8 string rather than the base64url encoded UTF8 string, then the content would be smaller. The computation of the signature would be unchanged in that it would still be computed over the base64url encoded string. I believe that the conversion from the UTF8 string to the base64url encoded UTF8 string is a deterministic encoding and thus would not generate any problems from that point. At this point I and trying to figure out if I missed anything that would preclude this from working. I am not worried about how hard or easy it would be to do, just if it is even possible. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ------=_NextPart_000_0678_01CE65C4.BDC039D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mike,

 

I can dispose of the CRLF question quite simply.  I have not = removed the UTF8 string from the protected field so all CRLF characters = (along with a number of others) will be escaped so they will not be = transformed.

 

It would still be

 

{“protected”:”---UTF8 encoded string = ---“}

 

Rather than

 

{“protected”:”--- Base64 URL encoded ( -- UTF8 = encoded string  -- ) ---“ }

 

There are a number of other questions that do come into play that you = did raise however.

 

The first would be space folding -  It has been my experience = that this is normally the XML parser that does it rather than things in = transit.  There will always be a problem with things in the middle = that could possibly change things with this approach.  It is = something that I need to be looked at and think = about.

 

If we have a line wrapping issue, this is going to be a problem with = JSON parsers today.  It is not legal to have any of the CRLF = characters inside of a string in JSON according to the current ABNF in = the document.  I think this may already cause parsers to go boom in = some cases.  If this is going to be a real issue then we probably = need to start dealing with it sooner rather than = later.

 

Jim

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Monday, = June 10, 2013 9:39 AM
To: Richard Barnes; Jim = Schaad
Cc: jose@ietf.org
Subject: RE: [jose] = Possible change to protected field

 

The problem with this suggested change is that it requires unencoded = JSON objects to be transmitted with no transformations whatsoever, = whereas the problems with this assumption are well known.  For = starters, on UNIX-based systems, newlines are typically represented by a = bare LF character, whereas on DOS-based systems, newlines are typically = represented by a CRLF pair.  In transmission, many systems, = including mail agents tend to convert newlines to the system’s = normal format.  This would break these JOSE = objects.

 

Some agents wrap lines after a certain length.  Particularly = when being transmitted in HTML or XML, many systems replace two or more = consecutive spaces with a single space.  Others replace two or more = spaces with a single space and N-1 non-breaking space characters.  = I could go on…

 

I appreciate the attempt to make things appear to be more uniform and = readable, but the CRLF/LF problems alone are enough to make this a = non-starter.

 

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   Best wishes,

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   -- Mike

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Richard Barnes
Sent: Monday, June 10, 2013 = 9:29 AM
To: Jim Schaad
Cc: jose@ietf.org
Subject: Re: = [jose] Possible change to protected field

 

This = sounds like a fine idea to me.  It saves space and makes the JSON = format more human-readable.  It actually makes kind of a nice = analogy to ASN.1, namely use of OCTET STRING to encapsulate more DER = content.

 

The compact serialization can continue to = base64url-encode that field, so it would not be a breaking change for = that serialization.

 

--Richard

 

On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad <ietf@augustcellars.com> = wrote:

<no = hat>

 <= /o:p>

I am trying = to figure out if I am missing something.  This is not yet a formal = proposal to actual change the document.

 <= /o:p>

I was = thinking about proposing that we make a change to the content of the = protected field in the JWS JSON serialization format.  If we = encoded this as a UTF8 string rather than the base64url encoded UTF8 = string, then the content would be smaller.  The computation of the = signature would be unchanged in that it would still be computed over the = base64url encoded string.  I believe that the conversion from the = UTF8 string to the base64url encoded UTF8 string is a deterministic = encoding and thus would not generate any problems from that = point.

 <= /o:p>

At this = point I and trying to figure out if I missed anything that would = preclude this from working.  I am not worried about how hard or = easy it would be to do, just if it is even possible.

 

Jim

 


______________________________________= _________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 

------=_NextPart_000_0678_01CE65C4.BDC039D0-- From rlb@ipv.sx Mon Jun 10 10:42:50 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD8721F8ECB for ; Mon, 10 Jun 2013 10:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.125 X-Spam-Level: X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktq4s0LXnkqF for ; Mon, 10 Jun 2013 10:42:46 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id DD95121F8F85 for ; Mon, 10 Jun 2013 10:42:45 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ta17so10610765obb.36 for ; Mon, 10 Jun 2013 10:42:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=xrkkgNbtPrfaCGe6B8h6PX1su2hhLJUd6+tJtl0X0/Y=; b=Z51rHV9O28ZMQVolfoeVU/83PnsUcwhLmKI3XAXdywUPaVXBV3pKmCqStaBh/rxyuC +OMAdLgjo8P5ivhK9JT8OnbotX3QEKaQDngAOEkd3Uwm5XRVkcZdHzQOMecSmmbV53T/ n7g7RLU1fEqS4k7XwADtVRdfHdp8/Bndr73obqSetcRwtf6ccdHKn1z1frpal80b83WI McP5o2IeVUGvohx4Lfo13Ksx4ytiVBMSf2z5Et1/B4H0kh3hJtSeWTAmNC2d2/8wFFSV AiIRpOjZMuBJ1Fq+DbFAxCW/tE+RzwYPqIQ44p56yK8zWqOYZjW9onoY0fYvIHFH+39A P/ZQ== MIME-Version: 1.0 X-Received: by 10.182.39.133 with SMTP id p5mr5566841obk.69.1370886165046; Mon, 10 Jun 2013 10:42:45 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Mon, 10 Jun 2013 10:42:44 -0700 (PDT) X-Originating-IP: [192.1.255.206] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436781D714@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436781C117@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436781D714@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 10 Jun 2013 13:42:44 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c2e804e58c5604ded04e8c X-Gm-Message-State: ALoCoQnQV6x9ehaC67rgFE55J+NkSLRRNzQ/i6gCOm7OZE7riHpgd6jX5kcxw9Mxgyr5uKKawHEI Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Possible change to protected field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 17:42:50 -0000 --001a11c2e804e58c5604ded04e8c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It's not canonicalization, it's just UTF-8 serialization. As to your questions about CR / LF / tab, let us recall RFC 4627: char =3D unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX Empirically, it appears that this serialization is stable with regard to re-encoding, at least for browser JSON engines: The only thing that would lead me to prefer this serialization against the Occam's Razor argument is that it's more readable for someone that receives a JOSE object. Instead of staring at base64-encoded junk, you can actually sort of see what's in there. But I don't feel very strongly about this. --Richard On Mon, Jun 10, 2013 at 1:08 PM, Mike Jones wr= ote: > This would take us down the road to canonicalization. How would you > represent a CRLF in the value? How would you represent a bare LF? How > would you represent a tab? Canonical representations for all of these, a= nd > more, would have to be specified.**** > > ** ** > > Using a special encoding for this field that is different than the > encoding used for all other fields (base64url encoding) is > developer-hostile. It forces them to have (and test) special code to > produce a different for this field alone. This would undoubtedly result = in > interop problems, because the corner cases almost never get tested (and > often never get coded correctly either).**** > > ** ** > > We already have a simple means of ensuring the correct transmission of > fields. Occam=92s Razor would suggest just using it.**** > > ** ** > > -- Mike**= * > * > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Monday, June 10, 2013 10:01 AM > *To:* Mike Jones > *Cc:* Jim Schaad; jose@ietf.org > > *Subject:* Re: [jose] Possible change to protected field**** > > ** ** > > I think you've misunderstood the proposal. It's not that the field will > be unencoded, it's that it will be encoded as a UTF-8 string instead of a > base64 string.**** > > ** ** > > OLD: (json) --> UTF-8 --> base64**** > > NEW: (json) --> UTF-8**** > > ** ** > > OLD: { protected: "eyJhbGciOiJSUzI1NiJ9Cg=3D=3D" }**** > > NEW: { protected: "{\"alg\":\"RS256\"}" }**** > > ** ** > > Now, there might still be a problem with that, because JSON strings aren'= t > canonical. In the example above, the quote characters could also have be= en > presented as "\u0022". So if some JSON re-processor were to change the > encoding ot the string, it would break the signature. However, that's al= so > a problem for the base64-encoded version ("a" vs. "\u0061").**** > > ** ** > > ** ** > > ** ** > > ** ** > > On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones > wrote:**** > > The problem with this suggested change is that it requires unencoded JSON > objects to be transmitted with no transformations whatsoever, whereas the > problems with this assumption are well known. For starters, on UNIX-base= d > systems, newlines are typically represented by a bare LF character, where= as > on DOS-based systems, newlines are typically represented by a CRLF pair. > In transmission, many systems, including mail agents tend to convert > newlines to the system=92s normal format. This would break these JOSE > objects.**** > > **** > > Some agents wrap lines after a certain length. Particularly when being > transmitted in HTML or XML, many systems replace two or more consecutive > spaces with a single space. Others replace two or more spaces with a > single space and N-1 non-breaking space characters. I could go on=85**** > > **** > > I appreciate the attempt to make things appear to be more uniform and > readable, but the CRLF/LF problems alone are enough to make this a > non-starter.**** > > **** > > Best > wishes,**** > > -- Mike**= * > * > > **** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Monday, June 10, 2013 9:29 AM > *To:* Jim Schaad > *Cc:* jose@ietf.org > *Subject:* Re: [jose] Possible change to protected field**** > > **** > > This sounds like a fine idea to me. It saves space and makes the JSON > format more human-readable. It actually makes kind of a nice analogy to > ASN.1, namely use of OCTET STRING to encapsulate more DER content.**** > > **** > > The compact serialization can continue to base64url-encode that field, so > it would not be a breaking change for that serialization.**** > > **** > > --Richard**** > > **** > > On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad > wrote:**** > > **** > > **** > > I am trying to figure out if I am missing something. This is not yet a > formal proposal to actual change the document.**** > > **** > > I was thinking about proposing that we make a change to the content of th= e > protected field in the JWS JSON serialization format. If we encoded this > as a UTF8 string rather than the base64url encoded UTF8 string, then the > content would be smaller. The computation of the signature would be > unchanged in that it would still be computed over the base64url encoded > string. I believe that the conversion from the UTF8 string to the > base64url encoded UTF8 string is a deterministic encoding and thus would > not generate any problems from that point.**** > > **** > > At this point I and trying to figure out if I missed anything that would > preclude this from working. I am not worried about how hard or easy it > would be to do, just if it is even possible.**** > > **** > > Jim**** > > **** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > **** > > ** ** > --001a11c2e804e58c5604ded04e8c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
It's not canonicalization, it's just UTF-8 se= rialization. =A0As to your questions about CR / LF / tab, let us recall RFC= 4627:

         char =3D unescaped /
                escape (
                    %x22 /          ; "    quotation mark  U+0022
                    %x5C /          ; \    reverse solidus U+005C
                    %x2F /          ; /    solidus         U+002F
                    %x62 /          ; b    backspace       U+0008
                    %x66 /          ; f    form feed       U+000C
                    %x6E /          ; n    line feed       U+000A
                    %x72 /          ; r    carriage return U+000D
                    %x74 /          ; t    tab             U+0009
                    %x75 4HEXDIG )  ; uXXXX                U+XXXX

Empirically, it appears that this serialization is st= able with regard to re-encoding, at least for browser JSON engines:

The only thing that = would lead me to prefer this serialization against the Occam's Razor ar= gument is that it's more readable for someone that receives a JOSE obje= ct. =A0Instead of staring at base64-encoded junk, you can actually sort of = see what's in there. =A0But I don't feel very strongly about this.<= /div>

--Richard




On Mon, Jun 10, 2= 013 at 1:08 PM, Mike Jones <Michael.Jones@microsoft.com><= /span> wrote:

This would take us down t= he road to canonicalization.=A0 How would you represent a CRLF in the value= ?=A0 How would you represent a bare LF?=A0 How would you represent a tab?=A0 Canonical representations for all of these, and more, would have= to be specified.

=A0<= /p>

Using a special encoding = for this field that is different than the encoding used for all other field= s (base64url encoding) is developer-hostile.=A0 It forces them to have (and test) special code to produce a different for this field= alone.=A0 This would undoubtedly result in interop problems, because the c= orner cases almost never get tested (and often never get coded correctly ei= ther).

=A0<= /p>

We already have a simple = means of ensuring the correct transmission of fields.=A0 Occam=92s Razor wo= uld suggest just using it.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Monday, June 10, 2013 10:01 AM
To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org


Subject: Re: [jose] Possible change to protected field=

=A0

I think you've misunderstood the proposal. =A0It= 's not that the field will be unencoded, it's that it will be encod= ed as a UTF-8 string instead of a base64 string.

=A0

OLD: (json) --> UTF-8 --> base64=

NEW: (json) --> UTF-8

=A0

OLD: =A0{ protected: "eyJhbGciOiJSUzI1NiJ9Cg=3D= =3D" }

NEW: { protected: "{\"alg\":\"RS= 256\"}" }

=A0

Now, there might still be a problem with that, becau= se JSON strings aren't canonical. =A0In the example above, the quote ch= aracters could also have been presented as "\u0022". =A0So if som= e JSON re-processor were to change the encoding ot the string, it would break the signature. =A0However, that's also a proble= m for the base64-encoded version ("a" vs. "\u0061").=

=A0

=A0

=A0

=A0

On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

The problem with this sug= gested change is that it requires unencoded JSON objects to be transmitted with no transformations whatsoever, whereas the problems with this assumpt= ion are well known.=A0 For starters, on UNIX-based systems, newlines are ty= pically represented by a bare LF character, whereas on DOS-based systems, n= ewlines are typically represented by a CRLF pair.=A0 In transmission, many systems, including mail agents te= nd to convert newlines to the system=92s normal format.=A0 This would break= these JOSE objects.

=A0<= /p>

Some agents wrap lines af= ter a certain length.=A0 Particularly when being transmitted in HTML or XML= , many systems replace two or more consecutive spaces with a single space.= =A0 Others replace two or more spaces with a single space and N-1 non-break= ing space characters.=A0 I could go on=85

=A0<= /p>

I appreciate the attempt = to make things appear to be more uniform and readable, but the CRLF/LF prob= lems alone are enough to make this a non-starter.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Best wishes,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, June 10, 2013 9:29 AM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Possible change to protected field
=

=A0

This sounds like a fine idea to me. =A0It saves spac= e and makes the JSON format more human-readable. =A0It actually makes kind = of a nice analogy to ASN.1, namely use of OCTET STRING to encapsulate more DER content.

=A0

The compact serialization can continue to base64url-= encode that field, so it would not be a breaking change for that serializat= ion.

=A0

--Richard

=A0

On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad <ietf@augustcellars.= com> wrote:

<no hat>

=A0

I am trying to figure out if I am missing something.= =A0 This is not yet a formal proposal to actual change the document.=

=A0

I was thinking about proposing that we make a change= to the content of the protected field in the JWS JSON serialization format= .=A0 If we encoded this as a UTF8 string rather than the base64url encoded UTF8 string, then the content would be smaller. =A0T= he computation of the signature would be unchanged in that it would still b= e computed over the base64url encoded string.=A0 I believe that the convers= ion from the UTF8 string to the base64url encoded UTF8 string is a deterministic encoding and thus would not generat= e any problems from that point.

=A0

At this point I and trying to figure out if I missed= anything that would preclude this from working. =A0I am not worried about = how hard or easy it would be to do, just if it is even possible.

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0

=A0


--001a11c2e804e58c5604ded04e8c-- From ietf@augustcellars.com Mon Jun 10 10:53:14 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AB721F9954 for ; Mon, 10 Jun 2013 10:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veIPjvDHDnbX for ; Mon, 10 Jun 2013 10:53:09 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id ACE5521F9950 for ; Mon, 10 Jun 2013 10:53:02 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id EF67F38EFA; Mon, 10 Jun 2013 10:53:01 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Richard Barnes'" References: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436781C117@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436781D714@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436781D714@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 10 Jun 2013 10:52:09 -0700 Message-ID: <068101ce6603$3b27c440$b1774cc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0682_01CE65C8.8ECDF550" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG0QxNjNQen5xE7UI53mmuxyr9BfQI0cZ/ZAVlbblICaXzKXgJtpxE3mSBVoqA= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Possible change to protected field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 17:53:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0682_01CE65C8.8ECDF550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't understand why you think it takes us down the road to canonicalization. If there are canonization problems in this proposal I would say that they may already exist. I don't know if you are reading the JSON list or not, however you seem to be confusing the encoded and the unencoded versions of the string. The string does need to be encoded into a format that is legal to place into a JSON string field. In that case there is a number of ways that it can be done using quoting. However when the JSON parser gives that string to the application - it will be the original UTF8 encoded string. This means that a bare LF character would be the "code point" 10. That is the UTF8 encoding for a line feed character. It does not get canonicalized in any way. A UTF8 string does have possible code points that are not legal in a JSON string, but that is JSONs problem not ours. The JSON string encoding format is responsible for the string to text and text to string transformations and making sure that those transformations are loss-less. I agree that it may be harder to do, I have not formally presented this as a change to the document and will not do so until I have done a full analysis on how hard it is. I am currently just trying to figure out if it is even technically feasible. Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, June 10, 2013 10:09 AM To: Richard Barnes Cc: Jim Schaad; jose@ietf.org Subject: RE: [jose] Possible change to protected field This would take us down the road to canonicalization. How would you represent a CRLF in the value? How would you represent a bare LF? How would you represent a tab? Canonical representations for all of these, and more, would have to be specified. Using a special encoding for this field that is different than the encoding used for all other fields (base64url encoding) is developer-hostile. It forces them to have (and test) special code to produce a different for this field alone. This would undoubtedly result in interop problems, because the corner cases almost never get tested (and often never get coded correctly either). We already have a simple means of ensuring the correct transmission of fields. Occam's Razor would suggest just using it. -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Monday, June 10, 2013 10:01 AM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] Possible change to protected field I think you've misunderstood the proposal. It's not that the field will be unencoded, it's that it will be encoded as a UTF-8 string instead of a base64 string. OLD: (json) --> UTF-8 --> base64 NEW: (json) --> UTF-8 OLD: { protected: "eyJhbGciOiJSUzI1NiJ9Cg==" } NEW: { protected: "{\"alg\":\"RS256\"}" } Now, there might still be a problem with that, because JSON strings aren't canonical. In the example above, the quote characters could also have been presented as "\u0022". So if some JSON re-processor were to change the encoding ot the string, it would break the signature. However, that's also a problem for the base64-encoded version ("a" vs. "\u0061"). On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones wrote: The problem with this suggested change is that it requires unencoded JSON objects to be transmitted with no transformations whatsoever, whereas the problems with this assumption are well known. For starters, on UNIX-based systems, newlines are typically represented by a bare LF character, whereas on DOS-based systems, newlines are typically represented by a CRLF pair. In transmission, many systems, including mail agents tend to convert newlines to the system's normal format. This would break these JOSE objects. Some agents wrap lines after a certain length. Particularly when being transmitted in HTML or XML, many systems replace two or more consecutive spaces with a single space. Others replace two or more spaces with a single space and N-1 non-breaking space characters. I could go on. I appreciate the attempt to make things appear to be more uniform and readable, but the CRLF/LF problems alone are enough to make this a non-starter. Best wishes, -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, June 10, 2013 9:29 AM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Possible change to protected field This sounds like a fine idea to me. It saves space and makes the JSON format more human-readable. It actually makes kind of a nice analogy to ASN.1, namely use of OCTET STRING to encapsulate more DER content. The compact serialization can continue to base64url-encode that field, so it would not be a breaking change for that serialization. --Richard On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad wrote: I am trying to figure out if I am missing something. This is not yet a formal proposal to actual change the document. I was thinking about proposing that we make a change to the content of the protected field in the JWS JSON serialization format. If we encoded this as a UTF8 string rather than the base64url encoded UTF8 string, then the content would be smaller. The computation of the signature would be unchanged in that it would still be computed over the base64url encoded string. I believe that the conversion from the UTF8 string to the base64url encoded UTF8 string is a deterministic encoding and thus would not generate any problems from that point. At this point I and trying to figure out if I missed anything that would preclude this from working. I am not worried about how hard or easy it would be to do, just if it is even possible. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ------=_NextPart_000_0682_01CE65C8.8ECDF550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t understand why you think it takes us down the road to = canonicalization.  If there are canonization problems in this = proposal I would say that they may already = exist.

 

I don’t know if you are reading the JSON list or not, however = you seem to be confusing the encoded and the unencoded versions of the = string.  The string does need to be encoded into a format that is = legal to place into a JSON string field.  In that case there is a = number of ways that it can be done using quoting.  However when the = JSON parser gives that string to the application – it will be the = original UTF8 encoded string.  This means that a bare LF character = would be the “code point” 10.  That is the UTF8 = encoding for a line feed character.  It does not get canonicalized = in any way.  A UTF8 string does have possible code points that are = not legal in a JSON string, but that is JSONs problem not ours.  = The JSON string encoding format is responsible for the string to text = and text to string transformations and making sure that those = transformations are loss-less.

 

I agree that it may be harder to do, I have not formally presented = this as a change to the document and will not do so until I have done a = full analysis on how hard it is.  I am currently just trying to = figure out if it is even technically feasible.

 

Jim

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Monday, = June 10, 2013 10:09 AM
To: Richard Barnes
Cc: Jim = Schaad; jose@ietf.org
Subject: RE: [jose] Possible change to = protected field

 

This would take us down the road to canonicalization.  How would = you represent a CRLF in the value?  How would you represent a bare = LF?  How would you represent a tab?  Canonical representations = for all of these, and more, would have to be = specified.

 

Using a special encoding for this field that is different than the = encoding used for all other fields (base64url encoding) is = developer-hostile.  It forces them to have (and test) special code = to produce a different for this field alone.  This would = undoubtedly result in interop problems, because the corner cases almost = never get tested (and often never get coded correctly = either).

 

We already have a simple means of ensuring the correct transmission = of fields.  Occam’s Razor would suggest just using = it.

 

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   -- Mike

 

From:= = Richard Barnes [mailto:rlb@ipv.sx] =
Sent: Monday, June 10, 2013 10:01 AM
To: Mike = Jones
Cc: Jim Schaad; jose@ietf.org
Subject: Re: = [jose] Possible change to protected field

 

I think = you've misunderstood the proposal.  It's not that the field will be = unencoded, it's that it will be encoded as a UTF-8 string instead of a = base64 string.

 

OLD: (json) --> UTF-8 --> = base64

NEW: (json) --> = UTF-8

 

OLD:  { protected: = "eyJhbGciOiJSUzI1NiJ9Cg=3D=3D" }

NEW: { protected: = "{\"alg\":\"RS256\"}" = }

 

Now, there might still be a problem with that, because = JSON strings aren't canonical.  In the example above, the quote = characters could also have been presented as "\u0022". =  So if some JSON re-processor were to change the encoding ot the = string, it would break the signature.  However, that's also a = problem for the base64-encoded version ("a" vs. = "\u0061").

 

 

 

 

On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

The problem with this suggested change is that it requires unencoded = JSON objects to be transmitted with no transformations whatsoever, = whereas the problems with this assumption are well known.  For = starters, on UNIX-based systems, newlines are typically represented by a = bare LF character, whereas on DOS-based systems, newlines are typically = represented by a CRLF pair.  In transmission, many systems, = including mail agents tend to convert newlines to the system’s = normal format.  This would break these JOSE = objects.

 

Some agents wrap lines after a certain length.  Particularly = when being transmitted in HTML or XML, many systems replace two or more = consecutive spaces with a single space.  Others replace two or more = spaces with a single space and N-1 non-breaking space characters.  = I could go on…

 

I appreciate the attempt to make things appear to be more uniform and = readable, but the CRLF/LF problems alone are enough to make this a = non-starter.

 

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   Best wishes,

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;   -- Mike

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Monday, June 10, 2013 9:29 AM
To: Jim = Schaad
Cc: jose@ietf.org
Subject: Re: [jose] = Possible change to protected field

 <= /o:p>

This sounds = like a fine idea to me.  It saves space and makes the JSON format = more human-readable.  It actually makes kind of a nice analogy to = ASN.1, namely use of OCTET STRING to encapsulate more DER = content.

 <= /o:p>

The compact = serialization can continue to base64url-encode that field, so it would = not be a breaking change for that = serialization.

 <= /o:p>

--Richard

 <= /p>

On Mon, Jun = 10, 2013 at 1:46 AM, Jim Schaad <ietf@augustcellars.com> = wrote:

<no = hat>

 <= /o:p>

I am trying = to figure out if I am missing something.  This is not yet a formal = proposal to actual change the document.

 <= /o:p>

I was = thinking about proposing that we make a change to the content of the = protected field in the JWS JSON serialization format.  If we = encoded this as a UTF8 string rather than the base64url encoded UTF8 = string, then the content would be smaller.  The computation of the = signature would be unchanged in that it would still be computed over the = base64url encoded string.  I believe that the conversion from the = UTF8 string to the base64url encoded UTF8 string is a deterministic = encoding and thus would not generate any problems from that = point.

 <= /o:p>

At this = point I and trying to figure out if I missed anything that would = preclude this from working.  I am not worried about how hard or = easy it would be to do, just if it is even possible.

 

Jim

 


______________= _________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 <= /o:p>

 

------=_NextPart_000_0682_01CE65C8.8ECDF550-- From Michael.Jones@microsoft.com Mon Jun 10 13:25:15 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70EE21F99E9 for ; Mon, 10 Jun 2013 13:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egQud9S9Df9a for ; Mon, 10 Jun 2013 13:25:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6C74621F8633 for ; Mon, 10 Jun 2013 13:25:09 -0700 (PDT) Received: from BY2FFO11FD027.protection.gbl (10.1.15.200) by BY2FFO11HUB033.protection.gbl (10.1.14.117) with Microsoft SMTP Server (TLS) id 15.0.707.0; Mon, 10 Jun 2013 20:25:08 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD027.mail.protection.outlook.com (10.1.15.216) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Mon, 10 Jun 2013 20:25:07 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.110]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Mon, 10 Jun 2013 20:25:07 +0000 From: Mike Jones To: Jim Schaad , 'Richard Barnes' Thread-Topic: [jose] Possible change to protected field Thread-Index: Ac5lnSf72X6a3Ku/SKOo5PcgVR4NIgAWmNmAAAAbQTAAAQYggAAAFDPgAAG2KYAABP2qQA== Date: Mon, 10 Jun 2013 20:25:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436781E496@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436781C117@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436781D714@TK5EX14MBXC283.redmond.corp.microsoft.com> <068101ce6603$3b27c440$b1774cc0$@augustcellars.com> In-Reply-To: <068101ce6603$3b27c440$b1774cc0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436781E496TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(377454002)(24454002)(51856001)(47446002)(47736001)(561944002)(44976003)(16406001)(54316002)(76796001)(63696002)(66066001)(31966008)(76786001)(50986001)(53806001)(80022001)(20776003)(74502001)(69226001)(59766001)(65816001)(79102001)(33656001)(76482001)(54356001)(49866001)(4396001)(74662001)(47976001)(15202345002)(71186001)(6806003)(81342001)(77096001)(81542001)(46102001)(74366001)(55846006)(16236675002)(74876001)(512954002)(74706001)(56816003)(56776001)(77982001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB033; H:TK5EX14HUBC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 087396016C Cc: "jose@ietf.org" Subject: Re: [jose] Possible change to protected field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:25:15 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436781E496TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's a form of canonicalization when you take one representation of a strin= g and apply a set of rules to transform it to a more stable/transmissible s= tring. In this case, we'd be proposing that developers have to translate C= RLF to \u000DU\u00A, and other similar canonicalization transformations. T= hat's a kind of canonicalization. Worse, it's one that I don't believe the= re's standard library support for, so developers would have to write it for= every implementation and platform. They'd hate us, and with good reason. And this isn't academic. It's commonplace to use newlines in formatted JSO= N, such as: {"alg": "RSA-OAEP", "enc": "A256GCM", "kid": "7" } Occam's Razor suggests always using the same encoding when a stable, transm= issible string representation is needed - in this case base64url encoding. The somewhat improved readability of the canonicalization being discussed i= sn't worth the interop problems or developer pain it would cost. Therefore= , I sincerely hope that no one actually proposes this. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, June 10, 2013 10:52 AM To: Mike Jones; 'Richard Barnes' Cc: jose@ietf.org Subject: RE: [jose] Possible change to protected field I don't understand why you think it takes us down the road to canonicalizat= ion. If there are canonization problems in this proposal I would say that = they may already exist. I don't know if you are reading the JSON list or not, however you seem to b= e confusing the encoded and the unencoded versions of the string. The stri= ng does need to be encoded into a format that is legal to place into a JSON= string field. In that case there is a number of ways that it can be done = using quoting. However when the JSON parser gives that string to the appli= cation - it will be the original UTF8 encoded string. This means that a ba= re LF character would be the "code point" 10. That is the UTF8 encoding fo= r a line feed character. It does not get canonicalized in any way. A UTF8= string does have possible code points that are not legal in a JSON string,= but that is JSONs problem not ours. The JSON string encoding format is re= sponsible for the string to text and text to string transformations and mak= ing sure that those transformations are loss-less. I agree that it may be harder to do, I have not formally presented this as = a change to the document and will not do so until I have done a full analys= is on how hard it is. I am currently just trying to figure out if it is ev= en technically feasible. Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, June 10, 2013 10:09 AM To: Richard Barnes Cc: Jim Schaad; jose@ietf.org Subject: RE: [jose] Possible change to protected field This would take us down the road to canonicalization. How would you repres= ent a CRLF in the value? How would you represent a bare LF? How would you= represent a tab? Canonical representations for all of these, and more, wo= uld have to be specified. Using a special encoding for this field that is different than the encoding= used for all other fields (base64url encoding) is developer-hostile. It f= orces them to have (and test) special code to produce a different for this = field alone. This would undoubtedly result in interop problems, because th= e corner cases almost never get tested (and often never get coded correctly= either). We already have a simple means of ensuring the correct transmission of fiel= ds. Occam's Razor would suggest just using it. -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Monday, June 10, 2013 10:01 AM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] Possible change to protected field I think you've misunderstood the proposal. It's not that the field will be= unencoded, it's that it will be encoded as a UTF-8 string instead of a bas= e64 string. OLD: (json) --> UTF-8 --> base64 NEW: (json) --> UTF-8 OLD: { protected: "eyJhbGciOiJSUzI1NiJ9Cg=3D=3D" } NEW: { protected: "{\"alg\":\"RS256\"}" } Now, there might still be a problem with that, because JSON strings aren't = canonical. In the example above, the quote characters could also have been= presented as "\u0022". So if some JSON re-processor were to change the en= coding ot the string, it would break the signature. However, that's also a= problem for the base64-encoded version ("a" vs. "\u0061"). On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones > wrote: The problem with this suggested change is that it requires unencoded JSON o= bjects to be transmitted with no transformations whatsoever, whereas the pr= oblems with this assumption are well known. For starters, on UNIX-based sy= stems, newlines are typically represented by a bare LF character, whereas o= n DOS-based systems, newlines are typically represented by a CRLF pair. In= transmission, many systems, including mail agents tend to convert newlines= to the system's normal format. This would break these JOSE objects. Some agents wrap lines after a certain length. Particularly when being tra= nsmitted in HTML or XML, many systems replace two or more consecutive space= s with a single space. Others replace two or more spaces with a single spa= ce and N-1 non-breaking space characters. I could go on... I appreciate the attempt to make things appear to be more uniform and reada= ble, but the CRLF/LF problems alone are enough to make this a non-starter. Best wishes= , -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, June 10, 2013 9:29 AM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Possible change to protected field This sounds like a fine idea to me. It saves space and makes the JSON form= at more human-readable. It actually makes kind of a nice analogy to ASN.1,= namely use of OCTET STRING to encapsulate more DER content. The compact serialization can continue to base64url-encode that field, so i= t would not be a breaking change for that serialization. --Richard On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad > wrote: I am trying to figure out if I am missing something. This is not yet a for= mal proposal to actual change the document. I was thinking about proposing that we make a change to the content of the = protected field in the JWS JSON serialization format. If we encoded this a= s a UTF8 string rather than the base64url encoded UTF8 string, then the con= tent would be smaller. The computation of the signature would be unchanged= in that it would still be computed over the base64url encoded string. I b= elieve that the conversion from the UTF8 string to the base64url encoded UT= F8 string is a deterministic encoding and thus would not generate any probl= ems from that point. At this point I and trying to figure out if I missed anything that would pr= eclude this from working. I am not worried about how hard or easy it would= be to do, just if it is even possible. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436781E496TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’s a form of cano= nicalization when you take one representation of a string and apply a set o= f rules to transform it to a more stable/transmissible string.  In this case, we’d be proposing that developers have to translate CR= LF to \u000DU\u00A, and other similar canonicalization transformations.&nbs= p; That’s a kind of canonicalization.  Worse, it’s one tha= t I don’t believe there’s standard library support for, so deve= lopers would have to write it for every implementation and platform.  They&#= 8217;d hate us, and with good reason.

 <= /p>

And this isn’t acad= emic.  It’s commonplace to use newlines in formatted JSON, such = as:

 <= /p>

{"alg": "R= SA-OAEP",

"enc": "A2= 56GCM",

"kid": "7&= quot;

}

 <= /p>

Occam’s Razor sugge= sts always using the same encoding when a stable, transmissible string repr= esentation is needed – in this case base64url encoding.

 <= /p>

The somewhat improved rea= dability of the canonicalization being discussed isn’t worth the inte= rop problems or developer pain it would cost.  Therefore, I sincerely hope that no one actually proposes this.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: Jim Scha= ad [mailto:ietf@augustcellars.com]
Sent: Monday, June 10, 2013 10:52 AM
To: Mike Jones; 'Richard Barnes'
Cc: jose@ietf.org
Subject: RE: [jose] Possible change to protected field

 

I don’t understand = why you think it takes us down the road to canonicalization.  If there= are canonization problems in this proposal I would say that they may already exist.

 <= /p>

I don’t know if you= are reading the JSON list or not, however you seem to be confusing the enc= oded and the unencoded versions of the string.  The string does need to be encoded into a format that is legal to place into a JSON string= field.  In that case there is a number of ways that it can be done us= ing quoting.  However when the JSON parser gives that string to the ap= plication – it will be the original UTF8 encoded string.  This means that a bare LF character would be the “code= point” 10.  That is the UTF8 encoding for a line feed character= .  It does not get canonicalized in any way.  A UTF8 string does = have possible code points that are not legal in a JSON string, but that is JSONs problem not ours.  The JSON string encoding format is r= esponsible for the string to text and text to string transformations and ma= king sure that those transformations are loss-less.

 <= /p>

I agree that it may be ha= rder to do, I have not formally presented this as a change to the document = and will not do so until I have done a full analysis on how hard it is.  I am currently just trying to figure out if it is ev= en technically feasible.

 <= /p>

Jim

 <= /p>

 <= /p>

From: Mike Jon= es [mailto:Michael.Jones@mic= rosoft.com]
Sent: Monday, June 10, 2013 10:09 AM
To: Richard Barnes
Cc: Jim Schaad; jose@ietf.org Subject: RE: [jose] Possible change to protected field

 

This would take us down t= he road to canonicalization.  How would you represent a CRLF in the va= lue?  How would you represent a bare LF?  How would you represent a tab?  Canonical representations for all of these, and more, would h= ave to be specified.

 <= /p>

Using a special encoding = for this field that is different than the encoding used for all other field= s (base64url encoding) is developer-hostile.  It forces them to have (and test) special code to produce a different for this field= alone.  This would undoubtedly result in interop problems, because th= e corner cases almost never get tested (and often never get coded correctly= either).

 <= /p>

We already have a simple = means of ensuring the correct transmission of fields.  Occam’s R= azor would suggest just using it.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Monday, June 10, 2013 10:01 AM
To: Mike Jones
Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] Possible change to protected field

 

I think you've misunderstood the proposal.  It'= s not that the field will be unencoded, it's that it will be encoded as a U= TF-8 string instead of a base64 string.

 

OLD: (json) --> UTF-8 --> base64

NEW: (json) --> UTF-8

 

OLD:  { protected: "eyJhbGciOiJSUzI1NiJ9Cg= =3D=3D" }

NEW: { protected: "{\"alg\":\"RS= 256\"}" }

 

Now, there might still be a problem with that, becau= se JSON strings aren't canonical.  In the example above, the quote cha= racters could also have been presented as "\u0022".  So if s= ome JSON re-processor were to change the encoding ot the string, it would break the signature.  However, that's also a problem= for the base64-encoded version ("a" vs. "\u0061").

 

 

 

 

On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

The problem with this suggested change = is that it requires unencoded JSON objects to be transmitted with no transformations whatsoever, whereas the problems with this assumpt= ion are well known.  For starters, on UNIX-based systems, newlines are= typically represented by a bare LF character, whereas on DOS-based systems= , newlines are typically represented by a CRLF pair.  In transmission, many systems, including mail agents= tend to convert newlines to the system’s normal format.  This w= ould break these JOSE objects.

 

Some agents wrap lines after a certain = length.  Particularly when being transmitted in HTML or XML, many systems replace two or more consecutive spaces with a single space.&n= bsp; Others replace two or more spaces with a single space and N-1 non-brea= king space characters.  I could go on…

 

I appreciate the attempt to make things= appear to be more uniform and readable, but the CRLF/LF problems alone are enough to make this a non-starter.

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;       Best wishes,

      &nb= sp;            =             &nb= sp;            =             &nb= sp;       -- Mike

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, June 10, 2013 9:29 AM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Possible change to protected field

 

This sounds like a fine idea to me.  It saves space and makes= the JSON format more human-readable.  It actually makes kind of a nic= e analogy to ASN.1, namely use of OCTET STRING to encapsulate more DER content.

 

The compact serialization can continue to base64url-encode that fi= eld, so it would not be a breaking change for that serialization.

 

--Richard

 

On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad <ietf@augustcellars.com> wr= ote:

<no hat>

 

I am trying to figure out if I am missing something.  This is= not yet a formal proposal to actual change the document.

 

I was thinking about proposing that we make a change to the conten= t of the protected field in the JWS JSON serialization format.  If we = encoded this as a UTF8 string rather than the base64url encoded UTF8 string, then the content would be smaller. &nbs= p;The computation of the signature would be unchanged in that it would stil= l be computed over the base64url encoded string.  I believe that the c= onversion from the UTF8 string to the base64url encoded UTF8 string is a deterministic encoding and thus would not generat= e any problems from that point.

 

At this point I and trying to figure out if I missed anything that= would preclude this from working.  I am not worried about how hard or= easy it would be to do, just if it is even possible.

 

Jim

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

 

--_000_4E1F6AAD24975D4BA5B16804296739436781E496TK5EX14MBXC283r_-- From rlb@ipv.sx Mon Jun 10 14:29:36 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A7021F9A17 for ; Mon, 10 Jun 2013 14:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.357 X-Spam-Level: * X-Spam-Status: No, score=1.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzBJjWK0RUjy for ; Mon, 10 Jun 2013 14:29:32 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9F27721F9A11 for ; Mon, 10 Jun 2013 14:29:32 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wc20so10625689obb.4 for ; Mon, 10 Jun 2013 14:29:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=+JeKVcNpa7/aK6iMB/L4fCMb8yuqB+a/7kgHCqmnU6o=; b=ToLnsZFkLctU3rBsowxrO/TF0+CrgOPQG3Cnvj9ze/xF8A1q9hNCJb9w2gMUN7AYwG ohZ7LgswLd79ZgqNNaigB5TUFSkAdET+CnmtioHuW2ipNl8f2pqvPJao/IKuWEM9qGxK FR3LfbU1U3GXR1ZIBy8x/tCpmenRaeMlyJM5NuiC1TZJVsQp6x2UQRoqgCUtjzMhRz3t R4dYcFAP/KwEOwx77bwEh5y559O/y2SuB3NxR7voLiFk0lTuJ10464UUngDNQtox/Le5 WgCjI3wMFNBKuO4pOth8eg0T4l/Jmt4zRClqqoHGeUybxym50RQ9tRPGrn+nnHkZ3amk nULA== MIME-Version: 1.0 X-Received: by 10.60.35.100 with SMTP id g4mr9703630oej.53.1370899771992; Mon, 10 Jun 2013 14:29:31 -0700 (PDT) Received: by 10.60.84.8 with HTTP; Mon, 10 Jun 2013 14:29:31 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436781E496@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436781C117@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436781D714@TK5EX14MBXC283.redmond.corp.microsoft.com> <068101ce6603$3b27c440$b1774cc0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436781E496@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 10 Jun 2013 17:29:31 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=089e013c68a0ef0ef804ded379a6 X-Gm-Message-State: ALoCoQm+vhALELzxvllU+IwH/qC92MFyUAXhyGCRCS181JYGo0enI17blCTBOyj1Wyieu0Ch1MPT Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Possible change to protected field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 21:29:37 -0000 --089e013c68a0ef0ef804ded379a6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mike: They already have to do that stuff before they base64-encode it. All Jim is talking about is *not* doing the base64. On Mon, Jun 10, 2013 at 4:25 PM, Mike Jones wr= ote: > It=92s a form of canonicalization when you take one representation of a > string and apply a set of rules to transform it to a more > stable/transmissible string. In this case, we=92d be proposing that > developers have to translate CRLF to \u000DU\u00A, and other similar > canonicalization transformations. That=92s a kind of canonicalization. > Worse, it=92s one that I don=92t believe there=92s standard library suppo= rt for, > so developers would have to write it for every implementation and > platform. They=92d hate us, and with good reason.**** > > ** ** > > And this isn=92t academic. It=92s commonplace to use newlines in formatt= ed > JSON, such as:**** > > ** ** > > {"alg": "RSA-OAEP",**** > > "enc": "A256GCM",**** > > "kid": "7"**** > > }**** > > ** ** > > Occam=92s Razor suggests always using the same encoding when a stable, > transmissible string representation is needed =96 in this case base64url > encoding.**** > > ** ** > > The somewhat improved readability of the canonicalization being discussed > isn=92t worth the interop problems or developer pain it would cost. > Therefore, I sincerely hope that no one actually proposes this.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* Jim Schaad [mailto:ietf@augustcellars.com] > *Sent:* Monday, June 10, 2013 10:52 AM > *To:* Mike Jones; 'Richard Barnes' > *Cc:* jose@ietf.org > > *Subject:* RE: [jose] Possible change to protected field**** > > ** ** > > I don=92t understand why you think it takes us down the road to > canonicalization. If there are canonization problems in this proposal I > would say that they may already exist.**** > > ** ** > > I don=92t know if you are reading the JSON list or not, however you seem = to > be confusing the encoded and the unencoded versions of the string. The > string does need to be encoded into a format that is legal to place into = a > JSON string field. In that case there is a number of ways that it can be > done using quoting. However when the JSON parser gives that string to th= e > application =96 it will be the original UTF8 encoded string. This means = that > a bare LF character would be the =93code point=94 10. That is the UTF8 > encoding for a line feed character. It does not get canonicalized in any > way. A UTF8 string does have possible code points that are not legal in = a > JSON string, but that is JSONs problem not ours. The JSON string encodin= g > format is responsible for the string to text and text to string > transformations and making sure that those transformations are loss-less.= * > *** > > ** ** > > I agree that it may be harder to do, I have not formally presented this a= s > a change to the document and will not do so until I have done a full > analysis on how hard it is. I am currently just trying to figure out if = it > is even technically feasible.**** > > ** ** > > Jim**** > > ** ** > > ** ** > > *From:* Mike Jones [mailto:Michael.Jones@microsoft.com] > > *Sent:* Monday, June 10, 2013 10:09 AM > *To:* Richard Barnes > *Cc:* Jim Schaad; jose@ietf.org > *Subject:* RE: [jose] Possible change to protected field**** > > ** ** > > This would take us down the road to canonicalization. How would you > represent a CRLF in the value? How would you represent a bare LF? How > would you represent a tab? Canonical representations for all of these, a= nd > more, would have to be specified.**** > > ** ** > > Using a special encoding for this field that is different than the > encoding used for all other fields (base64url encoding) is > developer-hostile. It forces them to have (and test) special code to > produce a different for this field alone. This would undoubtedly result = in > interop problems, because the corner cases almost never get tested (and > often never get coded correctly either).**** > > ** ** > > We already have a simple means of ensuring the correct transmission of > fields. Occam=92s Razor would suggest just using it.**** > > ** ** > > -- Mike**= * > * > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx ] > *Sent:* Monday, June 10, 2013 10:01 AM > *To:* Mike Jones > *Cc:* Jim Schaad; jose@ietf.org > *Subject:* Re: [jose] Possible change to protected field**** > > ** ** > > I think you've misunderstood the proposal. It's not that the field will > be unencoded, it's that it will be encoded as a UTF-8 string instead of a > base64 string.**** > > ** ** > > OLD: (json) --> UTF-8 --> base64**** > > NEW: (json) --> UTF-8**** > > ** ** > > OLD: { protected: "eyJhbGciOiJSUzI1NiJ9Cg=3D=3D" }**** > > NEW: { protected: "{\"alg\":\"RS256\"}" }**** > > ** ** > > Now, there might still be a problem with that, because JSON strings aren'= t > canonical. In the example above, the quote characters could also have be= en > presented as "\u0022". So if some JSON re-processor were to change the > encoding ot the string, it would break the signature. However, that's al= so > a problem for the base64-encoded version ("a" vs. "\u0061").**** > > ** ** > > ** ** > > ** ** > > ** ** > > On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones > wrote:**** > > The problem with this suggested change is that it requires unencoded JSON > objects to be transmitted with no transformations whatsoever, whereas the > problems with this assumption are well known. For starters, on UNIX-base= d > systems, newlines are typically represented by a bare LF character, where= as > on DOS-based systems, newlines are typically represented by a CRLF pair. > In transmission, many systems, including mail agents tend to convert > newlines to the system=92s normal format. This would break these JOSE > objects.**** > > **** > > Some agents wrap lines after a certain length. Particularly when being > transmitted in HTML or XML, many systems replace two or more consecutive > spaces with a single space. Others replace two or more spaces with a > single space and N-1 non-breaking space characters. I could go on=85**** > > **** > > I appreciate the attempt to make things appear to be more uniform and > readable, but the CRLF/LF problems alone are enough to make this a > non-starter.**** > > **** > > Best > wishes,**** > > -- Mike**= * > * > > **** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Monday, June 10, 2013 9:29 AM > *To:* Jim Schaad > *Cc:* jose@ietf.org > *Subject:* Re: [jose] Possible change to protected field**** > > **** > > This sounds like a fine idea to me. It saves space and makes the JSON > format more human-readable. It actually makes kind of a nice analogy to > ASN.1, namely use of OCTET STRING to encapsulate more DER content.**** > > **** > > The compact serialization can continue to base64url-encode that field, so > it would not be a breaking change for that serialization.**** > > **** > > --Richard**** > > **** > > On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad > wrote:**** > > **** > > **** > > I am trying to figure out if I am missing something. This is not yet a > formal proposal to actual change the document.**** > > **** > > I was thinking about proposing that we make a change to the content of th= e > protected field in the JWS JSON serialization format. If we encoded this > as a UTF8 string rather than the base64url encoded UTF8 string, then the > content would be smaller. The computation of the signature would be > unchanged in that it would still be computed over the base64url encoded > string. I believe that the conversion from the UTF8 string to the > base64url encoded UTF8 string is a deterministic encoding and thus would > not generate any problems from that point.**** > > **** > > At this point I and trying to figure out if I missed anything that would > preclude this from working. I am not worried about how hard or easy it > would be to do, just if it is even possible.**** > > **** > > Jim**** > > **** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > **** > > ** ** > --089e013c68a0ef0ef804ded379a6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Mike: They already have to do that stuff before they base6= 4-encode it. =A0All Jim is talking about is *not* doing the base64.


On Mon, Jun 10,= 2013 at 4:25 PM, Mike Jones <Michael.Jones@microsoft.com>= ; wrote:

It=92s a form of canonica= lization when you take one representation of a string and apply a set of ru= les to transform it to a more stable/transmissible string.=A0 In this case, we=92d be proposing that developers have to translate CRLF t= o \u000DU\u00A, and other similar canonicalization transformations.=A0 That= =92s a kind of canonicalization.=A0 Worse, it=92s one that I don=92t believ= e there=92s standard library support for, so developers would have to write it for every implementation and platform.=A0 They=92d = hate us, and with good reason.

=A0<= /p>

And this isn=92t academic= .=A0 It=92s commonplace to use newlines in formatted JSON, such as:<= u>

=A0<= /p>

{"alg": "R= SA-OAEP",

"enc": "A2= 56GCM",

"kid": "7&= quot;

}

=A0<= /p>

Occam=92s Razor suggests = always using the same encoding when a stable, transmissible string represen= tation is needed =96 in this case base64url encoding.<= /p>

=A0<= /p>

The somewhat improved rea= dability of the canonicalization being discussed isn=92t worth the interop = problems or developer pain it would cost.=A0 Therefore, I sincerely hope that no one actually proposes this.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: Jim Scha= ad [mailto:ietf= @augustcellars.com]
Sent: Monday, June 10, 2013 10:52 AM
To: Mike Jones; 'Richard Barnes'
Cc: jose@ietf.org=


Subject: RE: [jose] Possible change to protected field=

=A0

I don=92t understand why = you think it takes us down the road to canonicalization. =A0If there are ca= nonization problems in this proposal I would say that they may already exist.

=A0<= /p>

I don=92t know if you are= reading the JSON list or not, however you seem to be confusing the encoded= and the unencoded versions of the string.=A0 The string does need to be encoded into a format that is legal to place into a JSON string= field.=A0 In that case there is a number of ways that it can be done using= quoting.=A0 However when the JSON parser gives that string to the applicat= ion =96 it will be the original UTF8 encoded string.=A0 This means that a bare LF character would be the =93code point= =94 10.=A0 That is the UTF8 encoding for a line feed character.=A0 It does = not get canonicalized in any way.=A0 A UTF8 string does have possible code = points that are not legal in a JSON string, but that is JSONs problem not ours.=A0 The JSON string encoding format is resp= onsible for the string to text and text to string transformations and makin= g sure that those transformations are loss-less.

=A0<= /p>

I agree that it may be ha= rder to do, I have not formally presented this as a change to the document = and will not do so until I have done a full analysis on how hard it is.=A0 I am currently just trying to figure out if it is even = technically feasible.

=A0<= /p>

Jim<= /p>

=A0<= /p>

=A0<= /p>

From: Mike Jon= es [mailto= :Michael.Jones@microsoft.com]
Sent: Monday, June 10, 2013 10:09 AM
To: Richard Barnes
Cc: Jim Schaad; j= ose@ietf.org
Subject: RE: [jose] Possible change to protected field=

=A0

This would take us down t= he road to canonicalization.=A0 How would you represent a CRLF in the value= ?=A0 How would you represent a bare LF?=A0 How would you represent a tab?=A0 Canonical representations for all of these, and more, would have= to be specified.

=A0<= /p>

Using a special encoding = for this field that is different than the encoding used for all other field= s (base64url encoding) is developer-hostile.=A0 It forces them to have (and test) special code to produce a different for this field= alone.=A0 This would undoubtedly result in interop problems, because the c= orner cases almost never get tested (and often never get coded correctly ei= ther).

=A0<= /p>

We already have a simple = means of ensuring the correct transmission of fields.=A0 Occam=92s Razor wo= uld suggest just using it.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Monday, June 10, 2013 10:01 AM
To: Mike Jones
Cc: Jim Schaad;
j= ose@ietf.org
Subject: Re: [jose] Possible change to protected field=

=A0

I think you've misunderstood the proposal. =A0It= 's not that the field will be unencoded, it's that it will be encod= ed as a UTF-8 string instead of a base64 string.

=A0

OLD: (json) --> UTF-8 --> base64=

NEW: (json) --> UTF-8

=A0

OLD: =A0{ protected: "eyJhbGciOiJSUzI1NiJ9Cg=3D= =3D" }

NEW: { protected: "{\"alg\":\"RS= 256\"}" }

=A0

Now, there might still be a problem with that, becau= se JSON strings aren't canonical. =A0In the example above, the quote ch= aracters could also have been presented as "\u0022". =A0So if som= e JSON re-processor were to change the encoding ot the string, it would break the signature. =A0However, that's also a proble= m for the base64-encoded version ("a" vs. "\u0061").=

=A0

=A0

=A0

=A0

On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

The problem with this sug= gested change is that it requires unencoded JSON objects to be transmitted with no transformations whatsoever, whereas the problems with this assumpt= ion are well known.=A0 For starters, on UNIX-based systems, newlines are ty= pically represented by a bare LF character, whereas on DOS-based systems, n= ewlines are typically represented by a CRLF pair.=A0 In transmission, many systems, including mail agents te= nd to convert newlines to the system=92s normal format.=A0 This would break= these JOSE objects.

=A0<= /p>

Some agents wrap lines af= ter a certain length.=A0 Particularly when being transmitted in HTML or XML= , many systems replace two or more consecutive spaces with a single space.= =A0 Others replace two or more spaces with a single space and N-1 non-break= ing space characters.=A0 I could go on=85

=A0<= /p>

I appreciate the attempt = to make things appear to be more uniform and readable, but the CRLF/LF prob= lems alone are enough to make this a non-starter.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Best wishes,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, June 10, 2013 9:29 AM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Possible change to protected field
=

=A0

This sounds like a fine idea to me. =A0It saves spac= e and makes the JSON format more human-readable. =A0It actually makes kind = of a nice analogy to ASN.1, namely use of OCTET STRING to encapsulate more DER content.

=A0

The compact serialization can continue to base64url-= encode that field, so it would not be a breaking change for that serializat= ion.

=A0

--Richard

=A0

On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad <ietf@augustcellars.= com> wrote:

<no hat>

=A0

I am trying to figure out if I am missing something.= =A0 This is not yet a formal proposal to actual change the document.=

=A0

I was thinking about proposing that we make a change= to the content of the protected field in the JWS JSON serialization format= .=A0 If we encoded this as a UTF8 string rather than the base64url encoded UTF8 string, then the content would be smaller. =A0T= he computation of the signature would be unchanged in that it would still b= e computed over the base64url encoded string.=A0 I believe that the convers= ion from the UTF8 string to the base64url encoded UTF8 string is a deterministic encoding and thus would not generat= e any problems from that point.

=A0

At this point I and trying to figure out if I missed= anything that would preclude this from working. =A0I am not worried about = how hard or easy it would be to do, just if it is even possible.

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0

=A0


--089e013c68a0ef0ef804ded379a6-- From Michael.Jones@microsoft.com Mon Jun 10 14:36:25 2013 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD7A21F9A13 for ; Mon, 10 Jun 2013 14:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7EO48XDJB5O for ; Mon, 10 Jun 2013 14:36:20 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 662CA21F9A29 for ; Mon, 10 Jun 2013 14:36:19 -0700 (PDT) Received: from BL2FFO11FD006.protection.gbl (10.173.161.203) by BL2FFO11HUB032.protection.gbl (10.173.161.56) with Microsoft SMTP Server (TLS) id 15.0.707.0; Mon, 10 Jun 2013 21:36:16 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Mon, 10 Jun 2013 21:36:16 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.110]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0136.001; Mon, 10 Jun 2013 21:36:03 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] Possible change to protected field Thread-Index: Ac5lnSf72X6a3Ku/SKOo5PcgVR4NIgAWmNmAAAAbQTAAAQYggAAAFDPgAAG2KYAABP2qQAACmb+AAAAGo1A= Date: Mon, 10 Jun 2013 21:36:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436781EE0B@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <05fc01ce659d$d6a93f90$83fbbeb0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436781C117@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436781D714@TK5EX14MBXC283.redmond.corp.microsoft.com> <068101ce6603$3b27c440$b1774cc0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436781E496@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436781EE0BTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(377454002)(189002)(24454002)(55846006)(4396001)(512954002)(77096001)(76482001)(53806001)(65816001)(56776001)(47736001)(76796001)(54316002)(69226001)(77982001)(46102001)(54356001)(561944002)(47446002)(15202345002)(74366001)(74502001)(74662001)(81342001)(59766001)(33656001)(63696002)(76786001)(66066001)(74876001)(80022001)(16236675002)(71186001)(81542001)(6806003)(47976001)(50986001)(44976003)(56816003)(20776003)(16406001)(74706001)(49866001)(51856001)(79102001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB032; H:TK5EX14HUBC106.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 087396016C Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Possible change to protected field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 21:36:25 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436781EE0BTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My point is that if you just base64url encode the string - line the one bel= ow - CRLFs and all, you don't have to do any of the canonicalization steps = to make the representation JSON-string-safe in the first place. And you're= using the same tool you're already using for encoding every other piece of= binary content that needs to be encoded in some way for JOSE. Otherwise, we also still have to worry about "innocuous" transformations th= at might during transport like space to non-breaking-space, tab to spaces, = spaces being added at the end of lines (which HTML mail transports are noto= rious for), etc. If we apply the KISS principle and use the same encoding in this case that = we do in all other cases, we don't have to even consider whether those and = other content integrity threats that we may not have even thought of are go= ing to hurt anyone in practice, because they can never arise. -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Monday, June 10, 2013 2:30 PM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] Possible change to protected field Mike: They already have to do that stuff before they base64-encode it. All= Jim is talking about is *not* doing the base64. On Mon, Jun 10, 2013 at 4:25 PM, Mike Jones > wrote: It's a form of canonicalization when you take one representation of a strin= g and apply a set of rules to transform it to a more stable/transmissible s= tring. In this case, we'd be proposing that developers have to translate C= RLF to \u000DU\u00A, and other similar canonicalization transformations. T= hat's a kind of canonicalization. Worse, it's one that I don't believe the= re's standard library support for, so developers would have to write it for= every implementation and platform. They'd hate us, and with good reason. And this isn't academic. It's commonplace to use newlines in formatted JSO= N, such as: {"alg": "RSA-OAEP", "enc": "A256GCM", "kid": "7" } Occam's Razor suggests always using the same encoding when a stable, transm= issible string representation is needed - in this case base64url encoding. The somewhat improved readability of the canonicalization being discussed i= sn't worth the interop problems or developer pain it would cost. Therefore= , I sincerely hope that no one actually proposes this. -- Mike From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Monday, June 10, 2013 10:52 AM To: Mike Jones; 'Richard Barnes' Cc: jose@ietf.org Subject: RE: [jose] Possible change to protected field I don't understand why you think it takes us down the road to canonicalizat= ion. If there are canonization problems in this proposal I would say that = they may already exist. I don't know if you are reading the JSON list or not, however you seem to b= e confusing the encoded and the unencoded versions of the string. The stri= ng does need to be encoded into a format that is legal to place into a JSON= string field. In that case there is a number of ways that it can be done = using quoting. However when the JSON parser gives that string to the appli= cation - it will be the original UTF8 encoded string. This means that a ba= re LF character would be the "code point" 10. That is the UTF8 encoding fo= r a line feed character. It does not get canonicalized in any way. A UTF8= string does have possible code points that are not legal in a JSON string,= but that is JSONs problem not ours. The JSON string encoding format is re= sponsible for the string to text and text to string transformations and mak= ing sure that those transformations are loss-less. I agree that it may be harder to do, I have not formally presented this as = a change to the document and will not do so until I have done a full analys= is on how hard it is. I am currently just trying to figure out if it is ev= en technically feasible. Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Monday, June 10, 2013 10:09 AM To: Richard Barnes Cc: Jim Schaad; jose@ietf.org Subject: RE: [jose] Possible change to protected field This would take us down the road to canonicalization. How would you repres= ent a CRLF in the value? How would you represent a bare LF? How would you= represent a tab? Canonical representations for all of these, and more, wo= uld have to be specified. Using a special encoding for this field that is different than the encoding= used for all other fields (base64url encoding) is developer-hostile. It f= orces them to have (and test) special code to produce a different for this = field alone. This would undoubtedly result in interop problems, because th= e corner cases almost never get tested (and often never get coded correctly= either). We already have a simple means of ensuring the correct transmission of fiel= ds. Occam's Razor would suggest just using it. -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Monday, June 10, 2013 10:01 AM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] Possible change to protected field I think you've misunderstood the proposal. It's not that the field will be= unencoded, it's that it will be encoded as a UTF-8 string instead of a bas= e64 string. OLD: (json) --> UTF-8 --> base64 NEW: (json) --> UTF-8 OLD: { protected: "eyJhbGciOiJSUzI1NiJ9Cg=3D=3D" } NEW: { protected: "{\"alg\":\"RS256\"}" } Now, there might still be a problem with that, because JSON strings aren't = canonical. In the example above, the quote characters could also have been= presented as "\u0022". So if some JSON re-processor were to change the en= coding ot the string, it would break the signature. However, that's also a= problem for the base64-encoded version ("a" vs. "\u0061"). On Mon, Jun 10, 2013 at 12:38 PM, Mike Jones > wrote: The problem with this suggested change is that it requires unencoded JSON o= bjects to be transmitted with no transformations whatsoever, whereas the pr= oblems with this assumption are well known. For starters, on UNIX-based sy= stems, newlines are typically represented by a bare LF character, whereas o= n DOS-based systems, newlines are typically represented by a CRLF pair. In= transmission, many systems, including mail agents tend to convert newlines= to the system's normal format. This would break these JOSE objects. Some agents wrap lines after a certain length. Particularly when being tra= nsmitted in HTML or XML, many systems replace two or more consecutive space= s with a single space. Others replace two or more spaces with a single spa= ce and N-1 non-breaking space characters. I could go on... I appreciate the attempt to make things appear to be more uniform and reada= ble, but the CRLF/LF problems alone are enough to make this a non-starter. Best wishes= , -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, June 10, 2013 9:29 AM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Possible change to protected field This sounds like a fine idea to me. It saves space and makes the JSON form= at more human-readable. It actually makes kind of a nice analogy to ASN.1,= namely use of OCTET STRING to encapsulate more DER content. The compact serialization can continue to base64url-encode that field, so i= t would not be a breaking change for that serialization. --Richard On Mon, Jun 10, 2013 at 1:46 AM, Jim Schaad > wrote: I am trying to figure out if I am missing something. This is not yet a for= mal proposal to actual change the document. I was thinking about proposing that we make a change to the content of the = protected field in the JWS JSON serialization format. If we encoded this a= s a UTF8 string rather than the base64url encoded UTF8 string, then the con= tent would be smaller. The computation of the signature would be unchanged= in that it would still be computed over the base64url encoded string. I b= elieve that the conversion from the UTF8 string to the base64url encoded UT= F8 string is a deterministic encoding and thus would not generate any probl= ems from that point. At this point I and trying to figure out if I missed anything that would pr= eclude this from working. I am not worried about how hard or easy it would= be to do, just if it is even possible. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436781EE0BTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My point is that if you j= ust base64url encode the string – line the one below – CRLFs an= d all, you don’t have to do any of the canonicalization steps to make the representation JSON-string-safe in the first place.  And you̵= 7;re using the same tool you’re already using for encoding every othe= r piece of binary content that needs to be encoded in some way for JOSE.

 <= /p>

Otherwise, we also still = have to worry about “innocuous” transformations that might duri= ng transport like space to non-breaking-space, tab to spaces, spaces being added at the end of lines (which HTML mail transports are notorious = for), etc.

 <= /p>

If we apply the KISS prin= ciple and use the same encoding in this case that we do in all other cases,= we don’t have to even consider whether those and other content integrity threats that we may not have even thought of are going t= o hurt anyone in practice, because they can never arise.<= /p>

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Monday, June 10, 2013 2:30 PM
To: Mike Jones
Cc: Jim Schaad; jose@ietf.org
Subject: Re: [jose] Possible change to protected field

 

Mike: They already have to do that stuff before they= base64-encode it.  All Jim is talking about is *not* doing the base64= .

 

On Mon, Jun 10, 2013 at 4:25 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

It’s a form of canonicalization w= hen you take one representation of a string and apply a set of rules to transform it to a more stable/transmissible string.  In this case,= we’d be proposing that developers have to translate CRLF to \u000DU\= u00A, and other similar canonicalization transformations.  That’= s a kind of canonicalization.  Worse, it’s one that I don’t believe there’s standard library support for, so develop= ers would have to write it for every implementation and platform.  The= y’d hate us, and with good reason.

 

And this isn’t academic.  It= ’s commonplace to use newlines in formatted JSON, such as:

 

{"alg": "RSA-OAEP",=

"enc": "A256GCM",

"kid": "7"

}

 

Occam’s Razor suggests always usi= ng the same encoding when a stable, transmissible string representation is needed – in this case base64url encoding.

 

The somewhat improved readability of th= e canonicalization being discussed isn’t worth the interop problems or developer pain it would cost.  Therefore, I sincerely hop= e that no one actually proposes this.

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   -- Mike

 

From: Jim Schaad [mailto:ietf@augustcellars= .com]
Sent: Monday, June 10, 2013 10:52 AM
To: Mike Jones; 'Richard Barnes'
Cc: jose@ietf.org=


Subject: RE: [jose] Possible change to protected field