From nobody Sat Jul 1 01:01:02 2017 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 B33E21315E7 for ; Sat, 1 Jul 2017 01:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFko503GrZPZ for ; Sat, 1 Jul 2017 01:00:59 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FA31315E6 for ; Sat, 1 Jul 2017 01:00:59 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 59A6F81235 for ; Sat, 1 Jul 2017 08:00:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 59A6F81235 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=simo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 59A6F81235 Received: from rhino.ipa.ssimo.org (ovpn-116-100.phx2.redhat.com [10.3.116.100]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3E31570C00; Sat, 1 Jul 2017 08:00:53 +0000 (UTC) Message-ID: <1498896051.11334.78.camel@redhat.com> From: Simo Sorce To: Nathaniel McCallum , jose@ietf.org Cc: Nikos Mavrogiannopoulos , Daiki Ueno Date: Sat, 01 Jul 2017 04:00:51 -0400 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Sat, 01 Jul 2017 08:00:58 +0000 (UTC) Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 08:01:01 -0000 On Fri, 2017-06-30 at 17:33 -0400, Nathaniel McCallum wrote: > I have prepared an initial stab at a draft for offloading JWK private > key data to PKCS #11. > > You can find the document here: >    https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt > > Thanks for your consideration! It's a nice start. A few immediate comments: JWKs that wish to offload their private key material using PKCS #11    will provide a JSON property named "p11" instead of the private key    material. JWKs are inanimate objects, hard to have them have any wish :-) I would say: "Users that wish to offload their JWKs private key material to an HSM ..." Later on you talk about performance penalty and say: Implementations SHOULD perform public    key operations, such as asymmetric signature verification or    asymmetric encryption, without using PKCS #11 I think this should be at most a MAY. If I wanted to be more pedantic I would say you should take in consideration there may be PKCS#11 modules that are already smart enough to implement such functions in software so that they do not incur in performance penalties, so the whole this would have to be wrapped in something like: "If the PKCS#11 implementation perform public key operation in hardare that may result in poor performance then implementations MAY perfrom public ..." Curious to see example JWKs in the appendix. HTH, Simo. From nobody Sat Jul 1 05:42:28 2017 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 0134512ECB7 for ; Sat, 1 Jul 2017 05:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwgJLgp11oQF for ; Sat, 1 Jul 2017 05:42:25 -0700 (PDT) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com [209.85.214.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B62A12ECB6 for ; Sat, 1 Jul 2017 05:42:25 -0700 (PDT) Received: by mail-it0-f49.google.com with SMTP id m84so37135313ita.0 for ; Sat, 01 Jul 2017 05:42:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wJayq9tlrer1HLG1MqHWCAUqvigNOXTs+Pra/tLFWfg=; b=PH42o/8avHVKAp8poqtI2XBeZQDbADkz4+fbUcizX0DtcKNGAESKBh3sIVfnYTA4b5 KOP/fuv6rUEy9lyK1/JTRtt4wCRkTbRM1P4Zx+GBQqWXvE8JM3kekL9fZWRhmtEHb+pW tiBjnKIgNrCMobsx8x95Yiz35ytdVIZqAw/Fy9a0atoe6I0Ul/SIhIZ2ROdH1gkodci6 n4FsV6RorUmzU43sEaWcMvAv8WyRVT3CtHFpFIde+MYDzTgE93Vj7kcg4o8CqouWd0EX O8LIeIkUpaBVxrU2w8iLcAIfCluzulACouIqSCTYoYH35erTOjAkpU3moaZPndWsBCVB jx6A== X-Gm-Message-State: AIVw1122jPxJcdxtwkvjkL9bD01TFWFEJS8odN0slEvsr8kZ/AM/Thx0 Vl8mqFDGES8k7hXNpUP0L8iIQAe6XrGA X-Received: by 10.36.248.131 with SMTP id a125mr722302ith.50.1498912943382; Sat, 01 Jul 2017 05:42:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.132.88 with HTTP; Sat, 1 Jul 2017 05:42:22 -0700 (PDT) In-Reply-To: <1498896051.11334.78.camel@redhat.com> References: <1498896051.11334.78.camel@redhat.com> From: Nathaniel McCallum Date: Sat, 1 Jul 2017 08:42:22 -0400 Message-ID: To: Simo Sorce Cc: jose@ietf.org, Nikos Mavrogiannopoulos , Daiki Ueno Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 12:42:27 -0000 On Sat, Jul 1, 2017 at 4:00 AM, Simo Sorce wrote: > On Fri, 2017-06-30 at 17:33 -0400, Nathaniel McCallum wrote: >> I have prepared an initial stab at a draft for offloading JWK private >> key data to PKCS #11. >> >> You can find the document here: >> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt >> >> Thanks for your consideration! > > It's a nice start. > A few immediate comments: > > JWKs that wish to offload their private key material using PKCS #11 > will provide a JSON property named "p11" instead of the private key > material. > > JWKs are inanimate objects, hard to have them have any wish :-) You've never heard of personification? ;) You're right. I'll change it. > I would say: > "Users that wish to offload their JWKs private key material to an HSM > ..." > > Later on you talk about performance penalty and say: > > Implementations SHOULD perform public > key operations, such as asymmetric signature verification or > asymmetric encryption, without using PKCS #11 > > I think this should be at most a MAY. If I wanted to be more pedantic I > would say you should take in consideration there may be PKCS#11 modules > that are already smart enough to implement such functions in software > so that they do not incur in performance penalties, so the whole this > would have to be wrapped in something like: > "If the PKCS#11 implementation perform public key operation in hardare > that may result in poor performance then implementations MAY perfrom > public ..." If we downgrade this recommendation, then we probably need to discuss how implementations would correlate public key and private key object URIs. That is, "p11" refers only to the private key. For public key crypto operations, we need a URI that refers to the public key. Thus, we would need a way to either: 1. Store the public key URI. 2. Transmute the private key URI into a public key URI implicitly. I'm not sure we can do #2. Sometimes keys are differentiated by id=. Sometimes they are differentiated by object=. Thus we can't do a single s/private/public/ on type= and expect things to work. Therefore, I expect #1 is our only option. Thoughts? > Curious to see example JWKs in the appendix. Will do! From nobody Sat Jul 1 12:03:09 2017 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 6BD6F129503 for ; Sat, 1 Jul 2017 12:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wi1o2ICeBQP2 for ; Sat, 1 Jul 2017 12:03:06 -0700 (PDT) Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725D81201F8 for ; Sat, 1 Jul 2017 12:03:06 -0700 (PDT) Received: from [192.168.43.252] ([212.5.158.102]) by :SMTPAUTH: with SMTP id RNf2d38ip0GfFRNf5dHRe6; Sat, 01 Jul 2017 12:02:35 -0700 To: Nathaniel McCallum Cc: jose@ietf.org References: <010301d2f03b$8f1a7c20$ad4f7460$@augustcellars.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <35c86d7d-eaec-adc0-e41a-9e186a8ba826@connect2id.com> Date: Sat, 1 Jul 2017 21:02:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000705080603080802000408" X-CMAE-Envelope: MS4wfAe+FuavzQxFISiFRGQnahx9xnE5EGYj2eKMUaqY2yjDZz8K3vDtibkocvdIf4gT2xURFeY2/JNK5RIx0HKszgS/ArWXKW82F284mjUKMAMmbrjGPRxV 525wdH3AR7gzon/90HYfvP9OVT9pT6rDyWJvkHhC6BikPCJMjg+NcE8KRJxZ+lgGsg2XbfymNmpT1gMTHyBcioxN+L36iOy7smw= Archived-At: Subject: Re: [jose] PKCS#11 Support for JWKs X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 19:03:08 -0000 This is a cryptographically signed message in MIME format. --------------ms000705080603080802000408 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 30/06/17 22:17, Nathaniel McCallum wrote: > On Fri, Jun 30, 2017 at 2:30 PM, Vladimir Dzhuvinov > wrote: >> I was unaware of this spec until you mentioned it here. I had a look a= t it >> last night. Am I correct that the pkcs11 URIs are simply a representat= ion of >> the config parameters used for loading Cryptoki libs and modules? >> >> I'm unsure how much of a utility a p11 parameter can have. The p11 URI= s seem >> to contain a lot of details that are not about the key, but about driv= ers, >> hardware, the OS. Also, parameters that can change, e.g. the HSM slots= =2E We >> have a machine with two HSMs, and after a reboot the HSMs can get a >> different slot assigned, which can be nuisance. > This doesn't really describe PKCS#11 URIs; or at least how they are > used in practice. The URI standard itself is basically just a 1-to-1 > mapping of all possible metadata you can extract from PKCS #11. In > that sense the standard is deficient in that it lets you generate URIs > that can only work in certain contexts. > > However, in practice, implementations only use a reliable subset of > properties*. So, for example, if you use p11tool -O, you do not > receive slot identifiers (which, as you said, might change) in the > generated URIs. The resulting URIs will work on all OSes and HW > configurations (so long as the same crypto hardware is used). Features > like driver specification are relegated to the query string within the > standard itself and are typically omitted in real world practice. Thanks for the clarifications. I'm won over now :) > It would be entirely possible (and, in fact, the default behavior of > GNU TLS) for you to provide a URI that would match your HSM keys every > time, reproducibly. This could be easily summed up in a new JWK > standard which would recommend to avoid attributes that would make it > difficult to match. (Again, this is not hard and is widely done > already.) > > Yes, we could write a new standard URI that wouldn't have these > caveats. But it would be much better to simply handles these cases > within a "recommendations" section of a new JWK standard for the "p11" > attribute. +1 to keep that as a recommendations section. Doing a new standard for the p11 URIs would be too much work. > >> When we used JWK sets backed by Cryptoki before we took the following >> approach (in Java): >> >> Load PKCS#11 KeyStore. >> Export the found PKCS#11 keys into a JWK set, where the key alias beco= mes >> the JWK "kid", the certificate is included as an option; each JWK keep= s a >> reference to the private key in the store. >> If the private key is needed, that same reference is used to get at it= =2E > This is precisely what we don't want to do: build custom code every > time we want to access crypto hardware. Instead, we want the Jos=C3=A9[= 0] > project to have exactly the same interface whether crypto hardware is > used or the private key is in the JWK directly. For example: > > $ jose jwe dec -i my.jwe -O plain.txt -k mykey.jwk > $ jose jwe dec -i my.jwe -O plain.txt -k myhwkey.jwk > > In the above case, it doesn't matter whether the private key material > is in the JWK directly or only referenced to by the JWK. We would > provide exactly the same interface from the C API as well. > > This is going to be made all the more crucial for us given our (Red > Hat's) broader adoption of PKCS #11 as a system level interface. That > is, PKCS #11 is going to be much more common, not less. GNOME already > exports PKCS #11 interfaces for its keyring. GNU TLS and OpenSC's PKCS > #11 Engine for OpenSSL do too. This will be extended to the system > level as well (we have active internal projects ongoing). We are even > exploring a TPM interface via PKCS #11. All of these are using the > URIs. Having PKCS#11 support across the board is good for all who want to take an extra step to secure their keys. I hope that the PKCS standard will eventually catch up with the recent CFRG work. > We want JOSE to be a first class citizen in this world. And that > should not involve writing special-case hardware code. It should be a > matter of generating a properly formatted, standardized JWK. > > [0]: https://github.com/latchset/jose > > * - For example, GNU TLS outputs the following parameters as the full > path to an object: model, manufacturer, serial, token, id, object and > type. These uniquely identify a PKCS #11 key object in any context. --------------ms000705080603080802000408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA3MDExOTAyMjdaMC8GCSqGSIb3DQEJBDEiBCAiBYe4EWeTT09lsv2cilxAIdta93a9 Ab4qwTB+pSSpQjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQBYqFRjH9k3 BDRA0g7nnFw1kKxL+3y8n9XLYJ2jr+Uva+6Z9uOxcywDwO0KqOg6PkBvD1T7xlI7PM4dkflM fd/LKzy4h9P3ostzcpX0Is7zbjlYHLA0oBj3aipPKr60vsYH33shzGKYFi30GJjF40ldQi6W 86lDmlBf7wbYRjeNrssLxlH85rtYuk7kP5wq1/WZ3OOa/DJmX6XFZeaSZjUGMbCrbALgRpOC XCRc9Q1boGOa223qXhipk1au8/slxMnKBx9mPeEaGfwBEDAc+S6n2GrYnNQdD+ovaKlVygL5 WmKhn7hX9wcsow+9KiNxorv3vGAE2wU4cBlw1wpeOyo0AAAAAAAA --------------ms000705080603080802000408-- From nobody Sat Jul 1 12:09:08 2017 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 C55D1127B60 for ; Sat, 1 Jul 2017 12:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VF7XEArMaeiU for ; Sat, 1 Jul 2017 12:09:05 -0700 (PDT) Received: from p3plsmtpa07-01.prod.phx3.secureserver.net (p3plsmtpa07-01.prod.phx3.secureserver.net [173.201.192.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFD41201F8 for ; Sat, 1 Jul 2017 12:09:05 -0700 (PDT) Received: from [192.168.43.252] ([212.5.158.102]) by :SMTPAUTH: with SMTP id RNkqdjmGbpV9MRNksdseSU; Sat, 01 Jul 2017 12:08:34 -0700 To: Nathaniel McCallum , jose@ietf.org Cc: Nikos Mavrogiannopoulos , Daiki Ueno , "Sorce, Simo" References: From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <23b3748b-afa5-ad04-57ec-145e69565774@connect2id.com> Date: Sat, 1 Jul 2017 21:08:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050208080606050300030402" X-CMAE-Envelope: MS4wfEcXpteL0tFf5zdmwiTHwoseJr3Fl6ZBc3Q+o/13eeYlK2VoB4721IZgRBswoHY6M1++GeFTYoM426n3KAeq6deBnCr/PUTbIojUt50AVedXM1/XqKEW VFNA/FIwPuUvp+ueEBY5vHjW3Jv4rCTiz5WvQKYECLxDEnNOD7E1DZuDNHHPwkw6saJj3wF3xCq6DQIIew+bBDYrnWxO4/nhcjzyBuNz0C5YfsM3sIGpW2xI 0m05YddspvgGZoBFwtHL7D7F7mZ6QpP6+RbFm2h6nJowCvS95mZKQ6g55It9NT5x Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 19:09:07 -0000 This is a cryptographically signed message in MIME format. --------------ms050208080606050300030402 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Looks good! +1 to have examples included. Question: When I parse a JWK with a "p11" parameter, should the p11 URI syntax be validated? What constitutes a syntactically valid p11 URI? On 30/06/17 23:33, Nathaniel McCallum wrote: > I have prepared an initial stab at a draft for offloading JWK private > key data to PKCS #11. > > You can find the document here: > https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt > > Thanks for your consideration! --------------ms050208080606050300030402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA3MDExOTA4MjhaMC8GCSqGSIb3DQEJBDEiBCAcx5qbs522NoZj9gVkozJAiPQt1Vuu jT013SBSrDzE3DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQAOyjE59fXr w8tbQyZLnnW1MT3wUDmoR5vOad+Vi3HemvM/CFhxsL2ZBoPuineghz7vHXVR9SQvHSHARIZA YuUGJ8UDjpAkfn4K+K9YTBpSOZbj4gxpaNS0zetsUN9MgPV1eqozVOc5N8S3jhl/R+y8tlKJ nSOt+dvgceDfprKP861dYhCtCWhod+ZVQsxLw15gZwLjmy78QDSSP8PqxkEksWVdFhdzmgfr GV/nWpkQ0OM5//er7/mi+dGXIlympJGKZ+SyQcvyQ/G5FfmPmrUOWA8FHhFum2MPaL2DNKYP etBzYwEriJUCAaSe4B//ic7mFgDzAlx3Erf9TUW6KEQgAAAAAAAA --------------ms050208080606050300030402-- From nobody Sat Jul 1 12:16:29 2017 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 5BD41127B60 for ; Sat, 1 Jul 2017 12:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6dpR3naUQOG for ; Sat, 1 Jul 2017 12:16:26 -0700 (PDT) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CAD1200B9 for ; Sat, 1 Jul 2017 12:16:26 -0700 (PDT) Received: by mail-it0-f45.google.com with SMTP id v202so73897018itb.0 for ; Sat, 01 Jul 2017 12:16:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jdMiqkZtqpSXg2ZC88mxncD4pFvvxUQK7gp00WVXd0Y=; b=Mg4vUQj+ffRtUxBrFUCGgbEWo9FZfQioMC9N9HRgGcglJs8lMTprW/y3aUV7v5OOhc c6D5MUGP3lyHpQzBiTZodIRZFv/8tqfcgamHy1yP4EreMk7NyQQ8virIWI5pWNqRpxm8 8CmkQlQs3kU6EAmp/pipRG88teZUTfdhRSoZ1SnyI0JT3Z6xoQF1PYkvdKnBL+u6FAc2 axbGOsaeMmCD7ynkE1YHlliSKd7kp1IgvL8j6qbptOHZjjF8NrS9FBilcocnJXA/11kE nAOhYgSsaOBmPdXQC9rsmZbo1Edu3yk5SCz9dFCFdQvZGTS2MzWiNUbeVD5LfQfWwBQ2 RD8Q== X-Gm-Message-State: AKS2vOzlzS14XXXuRQ2NTCUN9Ac1eV/gwj/fw6yerqgjqMQNv92aGSJm QRuTD7m0sRczopNmVrXnSLYPxzQhbAha X-Received: by 10.36.60.206 with SMTP id m197mr24676801ita.3.1498936585474; Sat, 01 Jul 2017 12:16:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.132.88 with HTTP; Sat, 1 Jul 2017 12:16:24 -0700 (PDT) In-Reply-To: <23b3748b-afa5-ad04-57ec-145e69565774@connect2id.com> References: <23b3748b-afa5-ad04-57ec-145e69565774@connect2id.com> From: Nathaniel McCallum Date: Sat, 1 Jul 2017 15:16:24 -0400 Message-ID: To: Vladimir Dzhuvinov Cc: jose@ietf.org, Nikos Mavrogiannopoulos , Daiki Ueno , "Sorce, Simo" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 19:16:28 -0000 Section 3 states: 'The "p11" property MUST contain a valid PKCS #11 URI [RFC7517] that points to a private key object (that is, type=private).' As I understand this sentence, the "p11" URI should be validated according to RFC 7517 with the additional constraint that it must have type=private. On Sat, Jul 1, 2017 at 3:08 PM, Vladimir Dzhuvinov wrote: > Looks good! > > +1 to have examples included. > > Question: When I parse a JWK with a "p11" parameter, should the p11 URI > syntax be validated? What constitutes a syntactically valid p11 URI? > > > > On 30/06/17 23:33, Nathaniel McCallum wrote: >> I have prepared an initial stab at a draft for offloading JWK private >> key data to PKCS #11. >> >> You can find the document here: >> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt >> >> Thanks for your consideration! > > From nobody Sat Jul 1 12:17:46 2017 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 321B71201F8 for ; Sat, 1 Jul 2017 12:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWjGHENqw5Ll for ; Sat, 1 Jul 2017 12:17:43 -0700 (PDT) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9EA1200B9 for ; Sat, 1 Jul 2017 12:17:43 -0700 (PDT) Received: by mail-io0-f171.google.com with SMTP id r36so38656501ioi.1 for ; Sat, 01 Jul 2017 12:17:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JqPQgh4MA/zTYo0hWmo7axy28Zi/EvAwdhaSU0QK0u4=; b=fnqsaN3laj8EZhcntn39JY2Oq2Fb9y9qNkIho4ukA3zzHKp0YEldD3QCxhQ4Ae2Y52 PB9UddtAooULS3u0/1utZLFMISbmPajEKERDBmgxB6C3WaOJ/73bqV6PQhzXhdXyCePD 3y4hmWAlOVlEApC44zFF5p1hzO3bPLVcLM7+c6KzE/hNvTTDFLpSvTfcZ71WDd+mZh0H eiFYp2xpMaG7G9n+f9L64l284vgydIiJCiIeO+59Y0QXVbBzBJGJyDH2zBaCRmeJn35J Q74Vgz1tcyW8kLJfD1E6L4RnaXld6axBD3XTzNYrDUvnjWGHDWhl1Qr5f3NbKizLVePP 0KeA== X-Gm-Message-State: AKS2vOynEdUDT3X6qMFS8bi3kjp+V+s1OdDLAJu6byPlmoRmYnePykiI EFr2gk6pe7drv1GAOFgAttq2pjCBVUeR X-Received: by 10.107.173.66 with SMTP id w63mr30540792ioe.24.1498936662604; Sat, 01 Jul 2017 12:17:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.132.88 with HTTP; Sat, 1 Jul 2017 12:17:42 -0700 (PDT) In-Reply-To: References: <23b3748b-afa5-ad04-57ec-145e69565774@connect2id.com> From: Nathaniel McCallum Date: Sat, 1 Jul 2017 15:17:42 -0400 Message-ID: To: Vladimir Dzhuvinov Cc: jose@ietf.org, Nikos Mavrogiannopoulos , Daiki Ueno , "Sorce, Simo" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 19:17:45 -0000 (That does appear to be a typo. The RFC should be 7512.) On Sat, Jul 1, 2017 at 3:16 PM, Nathaniel McCallum wrote: > Section 3 states: > > 'The "p11" property MUST contain a valid PKCS #11 URI [RFC7517] that > points to a private key object (that is, type=private).' > > As I understand this sentence, the "p11" URI should be validated > according to RFC 7517 with the additional constraint that it must have > type=private. > > On Sat, Jul 1, 2017 at 3:08 PM, Vladimir Dzhuvinov > wrote: >> Looks good! >> >> +1 to have examples included. >> >> Question: When I parse a JWK with a "p11" parameter, should the p11 URI >> syntax be validated? What constitutes a syntactically valid p11 URI? >> >> >> >> On 30/06/17 23:33, Nathaniel McCallum wrote: >>> I have prepared an initial stab at a draft for offloading JWK private >>> key data to PKCS #11. >>> >>> You can find the document here: >>> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt >>> >>> Thanks for your consideration! >> >> From nobody Sat Jul 1 13:23:57 2017 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 A19E8129AB7 for ; Sat, 1 Jul 2017 13:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDLcQQLv3nHw for ; Sat, 1 Jul 2017 13:23:55 -0700 (PDT) Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48089126B7E for ; Sat, 1 Jul 2017 13:23:55 -0700 (PDT) Received: from [192.168.43.252] ([212.39.89.6]) by :SMTPAUTH: with SMTP id ROvGdW0xrTDDTROvJdDxnk; Sat, 01 Jul 2017 13:23:24 -0700 To: Nathaniel McCallum Cc: Nikos Mavrogiannopoulos , Daiki Ueno , "Sorce, Simo" , jose@ietf.org References: <23b3748b-afa5-ad04-57ec-145e69565774@connect2id.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <0b30e2c3-2dfc-6176-d401-7f533782d3c3@connect2id.com> Date: Sat, 1 Jul 2017 22:23:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090804030605050301000304" X-CMAE-Envelope: MS4wfPzyg3oteiR9GDxpRCH2BEZteAV6KyNz+xrXHuTHpv43izAFL9eEqGs6hyV1CMhOEQs6Lgv1/0cRkh01KG6lMTyNxPUup7FCdDpsLlJQX+wVC0843+sH /zVU4P/Zjd/rO6AGhmVHMnbeODIXC5IGb0TO08TjpE5WyG/nI1Le2+2lm88E83kY+28CbtjZnWpVF5qIGF9W7PzTw3DUAqxJ9+y+bfWEPhP9x41SSDPkv2NB zCfsdToU+e3dZ5Uz62JMzC/8mNJHNC7svrAuVJqySQc= Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 20:23:56 -0000 This is a cryptographically signed message in MIME format. --------------ms090804030605050301000304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Thanks, this answered my question. Now, if the p11 URI must point to a private key object, shouldn't "type" in section 4 be declared REQUIRED? BTW, did you also consider using the p11 URIs for JWKs of type "oct"? On 01/07/17 21:17, Nathaniel McCallum wrote: > (That does appear to be a typo. The RFC should be 7512.) > > On Sat, Jul 1, 2017 at 3:16 PM, Nathaniel McCallum > wrote: >> Section 3 states: >> >> 'The "p11" property MUST contain a valid PKCS #11 URI [RFC7517] that >> points to a private key object (that is, type=3Dprivate).' >> >> As I understand this sentence, the "p11" URI should be validated >> according to RFC 7517 with the additional constraint that it must have= >> type=3Dprivate. >> >> On Sat, Jul 1, 2017 at 3:08 PM, Vladimir Dzhuvinov >> wrote: >>> Looks good! >>> >>> +1 to have examples included. >>> >>> Question: When I parse a JWK with a "p11" parameter, should the p11 U= RI >>> syntax be validated? What constitutes a syntactically valid p11 URI? >>> >>> >>> >>> On 30/06/17 23:33, Nathaniel McCallum wrote: >>>> I have prepared an initial stab at a draft for offloading JWK privat= e >>>> key data to PKCS #11. >>>> >>>> You can find the document here: >>>> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt >>>> >>>> Thanks for your consideration! >>> > --------------ms090804030605050301000304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA3MDEyMDIzMThaMC8GCSqGSIb3DQEJBDEiBCD7/XzX3rw5cbAS2fouvN92d4FOaa92 y4d0/A6meAnczTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQADOEsDMoty VBUCQv51AJ06X71QVxOgNZf90ckkPWpbzlP8q8ph5wVj21iBsyxPQSHrcRxaCfO4YKPNMl4Y szxReIIm9kRYJnnMhyui1BJFo+RqwiFMUOGsXfGNVNWJuJYtpc8OJyEnIBXQy3qD3BB4qDsL ogKIUEjESF3aMWg6VayAZezhTly2Z/MZcHftgj8PhlM4Spil6fdIl99Cjrct7aR3bCCrFjvq qO1Sgc5RthrBjmpA1bOuzlPp+RoMh7gKErSV7ET8LJ9ymCzJGNe8JJapSKz5hlCur2CZOpm2 Tv8s837PLQZJOK+2WSDpS9fGdVminQBUc0gqs3nh0BIxAAAAAAAA --------------ms090804030605050301000304-- From nobody Sat Jul 1 13:43:52 2017 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 9510E126BFD for ; Sat, 1 Jul 2017 13:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_gfaAIpzH0S for ; Sat, 1 Jul 2017 13:43:49 -0700 (PDT) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA08124D6C for ; Sat, 1 Jul 2017 13:43:49 -0700 (PDT) Received: by mail-it0-f53.google.com with SMTP id k192so40099155ith.1 for ; Sat, 01 Jul 2017 13:43:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UDv/BI/pywyr0xuULM1mQxf2NRW2iYxeylxFWM46X24=; b=SJuJmosXgQVUVHExuU/ozrTpZcfwfvSPWUS2AgD1YefDsR4bery5HP0h+DhW6uXcpm mpocBZj9LUYHqzaQL6FwbkKFlZCGhwRRevbUjfuPt1N91ihc+ewOZBY3IUcZlWrl2a4O D5bhBgxxtK/0hGSwI5TaIXY5hdwooA5GOzCPipjtt3ua/aZtEege5lM2LKjs5i4tiVeO pwE8yd+kd0P2atGssXaiKIs2JwSTqD38WtlOgCAKeMBNOjPRDk+0kHLp9r/vD99vIvh7 4HT94C5uwPsC9wQSf+dbAiv0vCmOEQv1+SOEhMHe6nV0bBn4DyrXErP88FfOdXGp/vNJ R8SA== X-Gm-Message-State: AIVw110xNkRUhbPtWXS2X5ItBFXgkPJs47u/Xt3Pj3qlvnOeS8PzQ5hr OfVfX6DHNPn8u3Uuz9eQJDlCw7as81qM X-Received: by 10.36.248.131 with SMTP id a125mr2286765ith.50.1498941828890; Sat, 01 Jul 2017 13:43:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.132.88 with HTTP; Sat, 1 Jul 2017 13:43:48 -0700 (PDT) In-Reply-To: <0b30e2c3-2dfc-6176-d401-7f533782d3c3@connect2id.com> References: <23b3748b-afa5-ad04-57ec-145e69565774@connect2id.com> <0b30e2c3-2dfc-6176-d401-7f533782d3c3@connect2id.com> From: Nathaniel McCallum Date: Sat, 1 Jul 2017 16:43:48 -0400 Message-ID: To: Vladimir Dzhuvinov Cc: Nikos Mavrogiannopoulos , Daiki Ueno , "Sorce, Simo" , jose@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 20:43:51 -0000 On Sat, Jul 1, 2017 at 4:23 PM, Vladimir Dzhuvinov wrote: > Thanks, this answered my question. > > Now, if the p11 URI must point to a private key object, shouldn't "type" > in section 4 be declared REQUIRED? Probably so. I think we need to answer the question about public key URI (see other emails in this thread) first. But, yes, I agree. > BTW, did you also consider using the p11 URIs for JWKs of type "oct"? Yes, the document does this implicitly. Section 3 states: "Private key material is defined by the Parameter Information Class of Section 8.1.1 of RFC 7517 [RFC7517]." This section defines "k" as private key material for JWKs of type "oct". It should probably be spelled out in the actual draft that symmetric keys do not have public key material. The draft should probably also make explicit that this is usable for "oct" JWKs. This would help with clarity. >From an implementation perspective, symmetric keys are probably most useful for the key wrap algorithms since we probably don't want to offload full data encryption (for performance reasons). From nobody Sun Jul 2 06:49:46 2017 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 378B912EC00 for ; Sun, 2 Jul 2017 06:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcAFETKWT2XN for ; Sun, 2 Jul 2017 06:49:42 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id B0B6A129468 for ; Sun, 2 Jul 2017 06:49:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id BEF113B2C5; Sun, 2 Jul 2017 16:49:40 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id HLAehtgpB3dG; Sun, 2 Jul 2017 16:49:40 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id EDE70C4; Sun, 2 Jul 2017 16:49:34 +0300 (EEST) Date: Sun, 2 Jul 2017 16:49:34 +0300 From: Ilari Liusvaara To: Nathaniel McCallum Cc: Simo Sorce , Nikos Mavrogiannopoulos , Daiki Ueno , jose@ietf.org Message-ID: <20170702134934.pb77govnpifo54dm@LK-Perkele-VII> References: <1498896051.11334.78.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 13:49:45 -0000 On Sat, Jul 01, 2017 at 08:42:22AM -0400, Nathaniel McCallum wrote: > On Sat, Jul 1, 2017 at 4:00 AM, Simo Sorce wrote: > > On Fri, 2017-06-30 at 17:33 -0400, Nathaniel McCallum wrote: > >> I have prepared an initial stab at a draft for offloading JWK private > >> key data to PKCS #11. > >> > >> You can find the document here: > >> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt > > > > Later on you talk about performance penalty and say: > > > > Implementations SHOULD perform public > > key operations, such as asymmetric signature verification or > > asymmetric encryption, without using PKCS #11 > > > > I think this should be at most a MAY. If I wanted to be more pedantic I > > would say you should take in consideration there may be PKCS#11 modules > > that are already smart enough to implement such functions in software > > so that they do not incur in performance penalties, so the whole this > > would have to be wrapped in something like: > > "If the PKCS#11 implementation perform public key operation in hardare > > that may result in poor performance then implementations MAY perfrom > > public ..." > > If we downgrade this recommendation, then we probably need to discuss > how implementations would correlate public key and private key object > URIs. That is, "p11" refers only to the private key. For public key > crypto operations, we need a URI that refers to the public key. Thus, > we would need a way to either: One another thing to note is that some pieces of codebases can easily work with external private keys but not external public keys. That is, those pieces of code expect to work with private keys using signer interface (which can easily encapsulate PKCS#11 operation), but deal with public keys directly (so PKCS#11 there would be a major change). Some codebases even expect to be able to directly load the public key parts. -Ilari From nobody Mon Jul 3 06:21:15 2017 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 3F47613161A for ; Mon, 3 Jul 2017 06:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0ObpF08CAGU for ; Mon, 3 Jul 2017 06:21:11 -0700 (PDT) Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5892E12785F for ; Mon, 3 Jul 2017 06:21:11 -0700 (PDT) Received: from [10.67.123.188] ([212.5.158.166]) by :SMTPAUTH: with SMTP id S1HGdHyl3SRqVS1HIdtZSH; Mon, 03 Jul 2017 06:20:40 -0700 Date: Mon, 03 Jul 2017 15:20:02 +0200 From: Vladimir Dzhuvinov To: Ilari Liusvaara Cc: Nathaniel McCallum , Simo Sorce , Daiki Ueno , jose@ietf.org, Nikos Mavrogiannopoulos MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-CMAE-Envelope: MS4wfKFbPMkJkPsXh5QwunmMP7Z9jvHYJJpwXFQis1/N2XNN/3naQIY/aaQOG4BGt8m89DeKg8q7uIwXijXogLw0dpZN3sl988k39pO8b8R408gRycxEPsi9 QSqwCpx6oA6OHU8NicVKsZRuxThq3Y8E0MZjDZGJyM7Y2qP/276sa0KJ5z63813Bvg6/A5yL1mhY11Fu5OB5pVuPE6Z+4PwW9H1viBgYVibgMRnfeWoQUL4E KwDlHaQCPOw6HKFr87rNzIfmdatc0o3vmBOIorcbFZahBDhipEXOtW24uDRNmEHQ+F4FKbcjZPvvaZWAnAd1fw== Message-Id: <20170703132111.5892E12785F@ietfa.amsl.com> Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 13:21:13 -0000 Ck9uIDIgSnVsIDIwMTcgMTU6NDksIElsYXJpIExpdXN2YWFyYSA8aWxhcmlsaXVzdmFhcmFAd2Vs aG8uY29tPiB3cm90ZToKPgo+IE9uIFNhdCwgSnVsIDAxLCAyMDE3IGF0IDA4OjQyOjIyQU0gLTA0 MDAsIE5hdGhhbmllbCBNY0NhbGx1bSB3cm90ZTogCj4gPiBPbiBTYXQsIEp1bCAxLCAyMDE3IGF0 IDQ6MDAgQU0sIFNpbW8gU29yY2UgPHNpbW9AcmVkaGF0LmNvbT4gd3JvdGU6IAo+ID4gPiBPbiBG cmksIDIwMTctMDYtMzAgYXQgMTc6MzMgLTA0MDAsIE5hdGhhbmllbCBNY0NhbGx1bSB3cm90ZTog Cj4gPiA+PiBJIGhhdmUgcHJlcGFyZWQgYW4gaW5pdGlhbCBzdGFiIGF0IGEgZHJhZnQgZm9yIG9m ZmxvYWRpbmcgSldLIHByaXZhdGUgCj4gPiA+PiBrZXkgZGF0YSB0byBQS0NTICMxMS4gCj4gPiA+ PiAKPiA+ID4+IFlvdSBjYW4gZmluZCB0aGUgZG9jdW1lbnQgaGVyZTogCj4gPiA+PsKgwqDCoCBo dHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1tY2NhbGx1bS1qb3NlLXBrY3MxMS1qd2stMDAu dHh0IAo+ID4gPiAKPiA+ID4gTGF0ZXIgb24geW91IHRhbGsgYWJvdXQgcGVyZm9ybWFuY2UgcGVu YWx0eSBhbmQgc2F5OiAKPiA+ID4gCj4gPiA+wqDCoMKgIEltcGxlbWVudGF0aW9ucyBTSE9VTEQg cGVyZm9ybSBwdWJsaWMgCj4gPiA+wqDCoMKgIGtleSBvcGVyYXRpb25zLCBzdWNoIGFzIGFzeW1t ZXRyaWMgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBvciAKPiA+ID7CoMKgwqAgYXN5bW1ldHJpYyBl bmNyeXB0aW9uLCB3aXRob3V0IHVzaW5nIFBLQ1MgIzExIAo+ID4gPiAKPiA+ID4gSSB0aGluayB0 aGlzIHNob3VsZCBiZSBhdCBtb3N0IGEgTUFZLiBJZiBJIHdhbnRlZCB0byBiZSBtb3JlIHBlZGFu dGljIEkgCj4gPiA+IHdvdWxkIHNheSB5b3Ugc2hvdWxkIHRha2UgaW4gY29uc2lkZXJhdGlvbiB0 aGVyZSBtYXkgYmUgUEtDUyMxMSBtb2R1bGVzIAo+ID4gPiB0aGF0IGFyZSBhbHJlYWR5IHNtYXJ0 IGVub3VnaCB0byBpbXBsZW1lbnQgc3VjaCBmdW5jdGlvbnMgaW4gc29mdHdhcmUgCj4gPiA+IHNv IHRoYXQgdGhleSBkbyBub3QgaW5jdXIgaW4gcGVyZm9ybWFuY2UgcGVuYWx0aWVzLCBzbyB0aGUg d2hvbGUgdGhpcyAKPiA+ID4gd291bGQgaGF2ZSB0byBiZSB3cmFwcGVkIGluIHNvbWV0aGluZyBs aWtlOiAKPiA+ID7CoCAiSWYgdGhlIFBLQ1MjMTEgaW1wbGVtZW50YXRpb24gcGVyZm9ybSBwdWJs aWMga2V5IG9wZXJhdGlvbiBpbiBoYXJkYXJlIAo+ID4gPiB0aGF0IG1heSByZXN1bHQgaW4gcG9v ciBwZXJmb3JtYW5jZSB0aGVuIGltcGxlbWVudGF0aW9ucyBNQVkgcGVyZnJvbSAKPiA+ID4gcHVi bGljIC4uLiIgCj4gPiAKPiA+IElmIHdlIGRvd25ncmFkZSB0aGlzIHJlY29tbWVuZGF0aW9uLCB0 aGVuIHdlIHByb2JhYmx5IG5lZWQgdG8gZGlzY3VzcyAKPiA+IGhvdyBpbXBsZW1lbnRhdGlvbnMg d291bGQgY29ycmVsYXRlIHB1YmxpYyBrZXkgYW5kIHByaXZhdGUga2V5IG9iamVjdCAKPiA+IFVS SXMuIFRoYXQgaXMsICJwMTEiIHJlZmVycyBvbmx5IHRvIHRoZSBwcml2YXRlIGtleS4gRm9yIHB1 YmxpYyBrZXkgCj4gPiBjcnlwdG8gb3BlcmF0aW9ucywgd2UgbmVlZCBhIFVSSSB0aGF0IHJlZmVy cyB0byB0aGUgcHVibGljIGtleS4gVGh1cywgCj4gPiB3ZSB3b3VsZCBuZWVkIGEgd2F5IHRvIGVp dGhlcjogCj4KPiBPbmUgYW5vdGhlciB0aGluZyB0byBub3RlIGlzIHRoYXQgc29tZSBwaWVjZXMg b2YgY29kZWJhc2VzIGNhbiBlYXNpbHkgCj4gd29yayB3aXRoIGV4dGVybmFsIHByaXZhdGUga2V5 cyBidXQgbm90IGV4dGVybmFsIHB1YmxpYyBrZXlzLiAKPgo+IFRoYXQgaXMsIHRob3NlIHBpZWNl cyBvZiBjb2RlIGV4cGVjdCB0byB3b3JrIHdpdGggcHJpdmF0ZSBrZXlzIHVzaW5nIAo+IHNpZ25l ciBpbnRlcmZhY2UgKHdoaWNoIGNhbiBlYXNpbHkgZW5jYXBzdWxhdGUgUEtDUyMxMSBvcGVyYXRp b24pLCBidXQgCj4gZGVhbCB3aXRoIHB1YmxpYyBrZXlzIGRpcmVjdGx5IChzbyBQS0NTIzExIHRo ZXJlIHdvdWxkIGJlIGEgbWFqb3IgCj4gY2hhbmdlKS4gU29tZSBjb2RlYmFzZXMgZXZlbiBleHBl Y3QgdG8gYmUgYWJsZSB0byBkaXJlY3RseSBsb2FkIHRoZSAKPiBwdWJsaWMga2V5IHBhcnRzLgoK SSBzZWUgbW9zdCB2YWx1ZSBpbiB1c2luZyB0aGUgcDExIHBhcmFtZXRlciBmb3IgdGhlIHByaXZh dGUga2V5IG9ubHkuIFRoaXMgaXMgYWZ0ZXIgYWxsIHRoZSBtYWluIHJlYXNvbiBmb3IgcGVvcGxl IHRvIGNvbnNpZGVyIGEgUEtDUyMxMSBzdG9yZS4KClRoZSBleGlzdGluZyBKV0sgcGFyYW1ldGVy cyBmb3IgdGhlIHB1YmxpYyBiaXRzIGlzIHRoZSBtb3N0IHBvcnRhYmxlIGFwcHJvYWNoLiBJdCBp cyBzaW1wbGUgYW5kIHNob3VsZCBhbHdheXMgd29yay4KCklmIHRoZXJlIGlzIHZhbHVlIGluIHVz aW5nIGEgUEtDUyMxMSBVUkkgZm9yIHRoZSBwdWJsaWMga2V5LCBvciBldmVuIGFzIGEgY2VydGlm aWNhdGUgcmVmZXJlbmNlLCB3aHkgbm90IGRlZmluZSBzZXBhcmF0ZSBwMTEgcGFyYW1zIGZvciB0 aGF0PyBXaXRoIHNlcGFyYXRlLCBkZWRpY2F0ZWQgcGFyYW1ldGVycyB3ZSdsbCBhbHNvIGRvIGF3 YXkgd2l0aCB0aGUgbmVlZCB0byBwZXJmb3JtIGNvcnJlbGF0aW9uIGJlaGluZCB0aGUgc2NlbmVz LgoKVmxhZGltaXI= From nobody Mon Jul 3 12:03:51 2017 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 852A712441E for ; Mon, 3 Jul 2017 00:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRTe_0S3gZBi for ; Mon, 3 Jul 2017 00:43:02 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579B61243FE for ; Mon, 3 Jul 2017 00:43:02 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id f67so45133386wmh.1 for ; Mon, 03 Jul 2017 00:43:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:subject:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=qlpqFYoNI3iBYF3eob4FyNz8H8nJ1xdSCDwgxUgkJ68=; b=QRMP8rn/aCssTeEqqb1606WWtj9Mm/fAl6d3H5lzjvMnKcl1P3z1Suv4ps0lP1Ya/s 0+2sXCNow4ZhSKXzPFFZMPn3ZNw69frHkJcugzKWK5/ylp5rAj8B3IACy50T7EdhTn7L jdgmeKEJF59iHJkMbeuZ7jWJ6H4OUeEbYNVqB9p4j9olYyWjr5uQ1R1tThBrb0hysiiG DWrKtPPwbkP3HnCHhm5tLot54hKGzCOC/+fkPalX0scrGJih6Q6Z0H9IlpCIVHgnOpAE Qrk65X0zQLufnY5gvyWXhyeHA9RRhDq1KKYPdTeYlQDJDE2afdR8sR0pjF+yhB9duZOS CEGQ== X-Gm-Message-State: AIVw1133rPCzNBAmiuQSqs8juziBbxKkZ3qCIj3LRtouPHUp/uvlJqeX uP9tHFgKK0Cg+uYwyJ0Sew== X-Received: by 10.28.165.140 with SMTP id o134mr11454792wme.114.1499067780784; Mon, 03 Jul 2017 00:43:00 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id n31sm18013127wrn.59.2017.07.03.00.42.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 03 Jul 2017 00:42:59 -0700 (PDT) From: Nikos Mavrogiannopoulos X-Google-Original-From: Nikos Mavrogiannopoulos Message-ID: <1499067779.2834.9.camel@redhat.com> To: Nathaniel McCallum , Simo Sorce Cc: jose@ietf.org, Daiki Ueno Date: Mon, 03 Jul 2017 09:42:59 +0200 In-Reply-To: References: <1498896051.11334.78.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 03 Jul 2017 12:03:50 -0700 Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 07:43:05 -0000 On Sat, 2017-07-01 at 08:42 -0400, Nathaniel McCallum wrote: > > > I think this should be at most a MAY. If I wanted to be more > > pedantic I > > would say you should take in consideration there may be PKCS#11 > > modules > > that are already smart enough to implement such functions in > > software > > so that they do not incur in performance penalties, so the whole > > this > > would have to be wrapped in something like: > >  "If the PKCS#11 implementation perform public key operation in > > hardare > > that may result in poor performance then implementations MAY > > perfrom > > public ..." > > If we downgrade this recommendation, then we probably need to discuss > how implementations would correlate public key and private key object > URIs. That is, "p11" refers only to the private key. For public key > crypto operations, we need a URI that refers to the public key. Thus, > we would need a way to either: > > 1. Store the public key URI. > 2. Transmute the private key URI into a public key URI implicitly. PKCS#11 mentions the following: "The CKA_ID attribute is intended as a means of distinguishing multiple public-key/private-key pairs held by the same subject (whether stored in the same token or not)." That field is also expected to match a certificate's subject key identifier field: "Note that with the version 3 extensions to X.509 certificates, the key identifier may be carried in the certificate. It is intended that the CKA_ID value be identical to the key identifier in such a certificate extension, although this will not be enforced by Cryptoki." Thus you can certainly rely on that, and if you have control on how the public/private key pair is generated, you can require this field to adhere to the above properties. regards, Nikos From nobody Wed Jul 5 06:05:15 2017 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 09B06131CED for ; Wed, 5 Jul 2017 06:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEUbdoQjcWtC for ; Wed, 5 Jul 2017 06:05:13 -0700 (PDT) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F0D1329FE for ; Wed, 5 Jul 2017 06:04:58 -0700 (PDT) Received: by mail-io0-f173.google.com with SMTP id z62so85243548ioi.3 for ; Wed, 05 Jul 2017 06:04:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/Dsyx/L4cNdDFbjIqx2CGNJiAFlmmTqMFm2gdgn0vWQ=; b=lFdVptRd4Bxodcm8CidFbAfGbB1PozKDs3jVfeEo8yb8bPQEPW+gZndAByMC99+cfj HcdRdWV33g9nU3L07dHV/57mSdsX5i1z5JiDElPf+6Y2OfKQMFlrvBrjMBnCCZ9vP3FC MLXroW1vTuaq/cuenpGug7E0IM5Hp/tAVnCm3aIlDpzU9yPf4cokiSIM8RPAhaNwLzHE wqJweGyk5Dm6wmdyjwZjg4059EIxYyBVDmA3xihuQXjMa1XOR4bhpG5gbQxQx/md0yQs fnMei2KR7oEtrSKyofMRFRPqQV6l442Vh/waTq6XVZD7RaBZWoMXO19/AXVxvE0tqpIa 6kcw== X-Gm-Message-State: AIVw111CbRII8BLotcuzrRy6DiBCGhubZP89kvRmgiCs7XGSIKKBv2vn LvqhUrsK5cvR9tlJPtZkLfTNcKwSt4g7 X-Received: by 10.107.160.202 with SMTP id j193mr13134507ioe.49.1499259897703; Wed, 05 Jul 2017 06:04:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.132.88 with HTTP; Wed, 5 Jul 2017 06:04:57 -0700 (PDT) In-Reply-To: <1498896051.11334.78.camel@redhat.com> References: <1498896051.11334.78.camel@redhat.com> From: Nathaniel McCallum Date: Wed, 5 Jul 2017 09:04:57 -0400 Message-ID: To: Simo Sorce Cc: jose@ietf.org, Nikos Mavrogiannopoulos , Daiki Ueno Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 13:05:15 -0000 On Sat, Jul 1, 2017 at 4:00 AM, Simo Sorce wrote: > Later on you talk about performance penalty and say: > > Implementations SHOULD perform public > key operations, such as asymmetric signature verification or > asymmetric encryption, without using PKCS #11 > > I think this should be at most a MAY. If I wanted to be more pedantic I > would say you should take in consideration there may be PKCS#11 modules > that are already smart enough to implement such functions in software > so that they do not incur in performance penalties, so the whole this > would have to be wrapped in something like: > "If the PKCS#11 implementation perform public key operation in hardare > that may result in poor performance then implementations MAY perfrom > public ..." I did some reflection on this over the long weekend. If we wanted to support offloading public key operations to PKCS #11, we'd need to have a "p11pub" JWK property which defines the URI to the public key to perform the operation on. This duplicates the existing public key information in the JWK. We could allow three modes: 1. pubkey-only; no PKCS #11 2. URI-only; PKCS #11 3. both; optional PKCS #11 In mode #3, there is a possibility for public key mismatch. However, no attacks exist which don't also exist for mode #1. My worry is that this is a lot of complexity for minimal gain. JOSE implementations already have to support #1. At best, mode #2 is going to be as fast as #1. I just don't see any compelling reason to support public key URIs. Do you? As an aside, I do see value in exporting X.509 material from certificate URIs and placing them in the already established JWK parameters. However, I do not think standardization is required to support this; implementations can do this in a compatible way without any new RFCs once they have "p11". From nobody Wed Jul 5 06:07:22 2017 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 083FF1329F8 for ; Wed, 5 Jul 2017 06:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSU40Lspmo_i for ; Wed, 5 Jul 2017 06:07:19 -0700 (PDT) Received: from mail-it0-f48.google.com (mail-it0-f48.google.com [209.85.214.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B87132A0A for ; Wed, 5 Jul 2017 06:06:31 -0700 (PDT) Received: by mail-it0-f48.google.com with SMTP id m68so113641866ith.1 for ; Wed, 05 Jul 2017 06:06:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T7P7rStNbEHV1592VB9U5HURcpBEqyH5C7Pd4fmfTac=; b=GdShDGPRk4sZAxa8Vmn2CB4jZc1LZ/NbR1FWOvhbgf9wbpuFUDphhgryNcPJBL9CZW wJlhJtKeGPLaGrCR+VCd87kQgcEYVv7S/9+Es29Hp3oduyNwRtOYyfPnNCi+0x3QU0lJ /H8xJaJOoZKNum6+kQ5xXSZgbORh6FndIAZGbFYWh/ukpqpDstjzZez4jBC/DjscSiLd XWxJTEnebwWcyhW1VlXtJ3OMrZ1d/oAeEiqbQeooi+bTXwJteGOU3aNFN0Pz1U1ryjbO AgbxaLPH007SFE9fs/q9mZ/DEKGQi9Gg1QNxOmtCkj5MUFz/hEm10YDN76UF4TNUuOp3 EXYQ== X-Gm-Message-State: AIVw111azDQV/S6TlvSZ2GTLb0FL3ZiAE1QdEGm/i8HTA9RaAx4R9Txk irTpFxaPH7zG2iNjpyzv7KwO+ZLwsbn2 X-Received: by 10.36.215.135 with SMTP id y129mr17709277itg.3.1499259990638; Wed, 05 Jul 2017 06:06:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.132.88 with HTTP; Wed, 5 Jul 2017 06:06:30 -0700 (PDT) In-Reply-To: <20170703132111.5892E12785F@ietfa.amsl.com> References: <20170703132111.5892E12785F@ietfa.amsl.com> From: Nathaniel McCallum Date: Wed, 5 Jul 2017 09:06:30 -0400 Message-ID: To: Vladimir Dzhuvinov Cc: Ilari Liusvaara , Nikos Mavrogiannopoulos , Daiki Ueno , jose@ietf.org, Simo Sorce Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 13:07:21 -0000 I agree. Please see my other reply to Simo for more details. On Mon, Jul 3, 2017 at 9:20 AM, Vladimir Dzhuvinov wrote: > > On 2 Jul 2017 15:49, Ilari Liusvaara wrote: >> >> On Sat, Jul 01, 2017 at 08:42:22AM -0400, Nathaniel McCallum wrote: >> > On Sat, Jul 1, 2017 at 4:00 AM, Simo Sorce wrote: >> > > On Fri, 2017-06-30 at 17:33 -0400, Nathaniel McCallum wrote: >> > >> I have prepared an initial stab at a draft for offloading JWK private >> > >> key data to PKCS #11. >> > >> >> > >> You can find the document here: >> > >> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt >> > > >> > > Later on you talk about performance penalty and say: >> > > >> > > Implementations SHOULD perform public >> > > key operations, such as asymmetric signature verification or >> > > asymmetric encryption, without using PKCS #11 >> > > >> > > I think this should be at most a MAY. If I wanted to be more pedantic I >> > > would say you should take in consideration there may be PKCS#11 modules >> > > that are already smart enough to implement such functions in software >> > > so that they do not incur in performance penalties, so the whole this >> > > would have to be wrapped in something like: >> > > "If the PKCS#11 implementation perform public key operation in hardare >> > > that may result in poor performance then implementations MAY perfrom >> > > public ..." >> > >> > If we downgrade this recommendation, then we probably need to discuss >> > how implementations would correlate public key and private key object >> > URIs. That is, "p11" refers only to the private key. For public key >> > crypto operations, we need a URI that refers to the public key. Thus, >> > we would need a way to either: >> >> One another thing to note is that some pieces of codebases can easily >> work with external private keys but not external public keys. >> >> That is, those pieces of code expect to work with private keys using >> signer interface (which can easily encapsulate PKCS#11 operation), but >> deal with public keys directly (so PKCS#11 there would be a major >> change). Some codebases even expect to be able to directly load the >> public key parts. > > I see most value in using the p11 parameter for the private key only. This is after all the main reason for people to consider a PKCS#11 store. > > The existing JWK parameters for the public bits is the most portable approach. It is simple and should always work. > > If there is value in using a PKCS#11 URI for the public key, or even as a certificate reference, why not define separate p11 params for that? With separate, dedicated parameters we'll also do away with the need to perform correlation behind the scenes. > > Vladimir > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From nobody Wed Jul 5 07:26:38 2017 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 8019B132049 for ; Wed, 5 Jul 2017 07:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpyDvqO9CfuL for ; Wed, 5 Jul 2017 07:26:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C96E131840 for ; Wed, 5 Jul 2017 07:26:35 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 60C0B4E4E6 for ; Wed, 5 Jul 2017 14:26:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 60C0B4E4E6 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=simo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 60C0B4E4E6 Received: from rhino.ipa.ssimo.org (ovpn-116-100.phx2.redhat.com [10.3.116.100]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 45C005C897; Wed, 5 Jul 2017 14:26:29 +0000 (UTC) Message-ID: <1499264787.11334.81.camel@redhat.com> From: Simo Sorce To: Nathaniel McCallum Cc: jose@ietf.org, Nikos Mavrogiannopoulos , Daiki Ueno Date: Wed, 05 Jul 2017 10:26:27 -0400 In-Reply-To: References: <1498896051.11334.78.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 05 Jul 2017 14:26:35 +0000 (UTC) Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 14:26:37 -0000 On Wed, 2017-07-05 at 09:04 -0400, Nathaniel McCallum wrote: > On Sat, Jul 1, 2017 at 4:00 AM, Simo Sorce wrote: > > Later on you talk about performance penalty and say: > > > >    Implementations SHOULD perform public > >    key operations, such as asymmetric signature verification or > >    asymmetric encryption, without using PKCS #11 > > > > I think this should be at most a MAY. If I wanted to be more > > pedantic I > > would say you should take in consideration there may be PKCS#11 > > modules > > that are already smart enough to implement such functions in > > software > > so that they do not incur in performance penalties, so the whole > > this > > would have to be wrapped in something like: > >  "If the PKCS#11 implementation perform public key operation in > > hardare > > that may result in poor performance then implementations MAY > > perfrom > > public ..." > > I did some reflection on this over the long weekend. If we wanted to > support offloading public key operations to PKCS #11, we'd need to > have a "p11pub" JWK property which defines the URI to the public key > to perform the operation on. This duplicates the existing public key > information in the JWK. > > We could allow three modes: > 1. pubkey-only; no PKCS #11 > 2. URI-only; PKCS #11 > 3. both; optional PKCS #11 > > In mode #3, there is a possibility for public key mismatch. However, > no attacks exist which don't also exist for mode #1. > > My worry is that this is a lot of complexity for minimal gain. JOSE > implementations already have to support #1. At best, mode #2 is going > to be as fast as #1. I just don't see any compelling reason to > support > public key URIs. Do you? > > As an aside, I do see value in exporting X.509 material from > certificate URIs and placing them in the already established JWK > parameters. However, I do not think standardization is required to > support this; implementations can do this in a compatible way without > any new RFCs once they have "p11". I do not think we need to explicitly add a p11public parameter. As Nikos noted (unless I misunderstood) implementations can infer the public key from the private one. So implementations may chose to use the corresponding public key via pkcs11 if they so desire. Otherwise they can use the current stuff which is just fine. Simo. From nobody Wed Jul 5 07:45:58 2017 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 A60E4131D45 for ; Wed, 5 Jul 2017 07:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrdPZ4CaNovC for ; Wed, 5 Jul 2017 07:45:56 -0700 (PDT) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DE0131D3F for ; Wed, 5 Jul 2017 07:45:55 -0700 (PDT) Received: by mail-io0-f175.google.com with SMTP id z62so86981020ioi.3 for ; Wed, 05 Jul 2017 07:45:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VVwu+4GcW28GONn979hcHcbcVsxZL4QUbaNK6yp8YT0=; b=NocdHv5cy7usKPIwd57IzZZkZh778YMuV7MpluCjFDgPa/f5VOqqApzV7ewxuzC12T bM3zb35c608JtBtIsVAb4HPv3Iilonbx/8PnH7R6JdkCL/jXTCz9Cjlc2bllEWX4mFaL H2AD4nlXFGqgHla92w5/EGI0dN6y0XIenmcqxgQJJBurWsdLXhXcwOlcSZYgxRYC6NH1 i8hQvld7qgjBasIWdAkN/X5arr4Wt7crKP3jBuT1PxNpOBALzJsIZRSmdy8GRRxJQtHH yHFau13QXaPtw9lPupDis6y9mCmXiZxuJZmzbFM7ZBivHR0/xFDr49ll52OGSNcxN9Xt 8fyw== X-Gm-Message-State: AKS2vOxfOEsYkSXF5aXWaWeKbEwU/FrhYLoS6TrhRCXZXzqSLDGmiKSf p2mXqOdGGY/l1gB7jI18E3Yl97jjsKXt X-Received: by 10.107.173.66 with SMTP id w63mr48561612ioe.24.1499265955037; Wed, 05 Jul 2017 07:45:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.132.88 with HTTP; Wed, 5 Jul 2017 07:45:54 -0700 (PDT) In-Reply-To: <1499264787.11334.81.camel@redhat.com> References: <1498896051.11334.78.camel@redhat.com> <1499264787.11334.81.camel@redhat.com> From: Nathaniel McCallum Date: Wed, 5 Jul 2017 10:45:54 -0400 Message-ID: To: Simo Sorce Cc: jose@ietf.org, Nikos Mavrogiannopoulos , Daiki Ueno Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 14:45:58 -0000 I believe that this will work in most, but not all, situations. The correlation of keys using the id= parameter is only a recommendation. On Wed, Jul 5, 2017 at 10:26 AM, Simo Sorce wrote: > On Wed, 2017-07-05 at 09:04 -0400, Nathaniel McCallum wrote: >> On Sat, Jul 1, 2017 at 4:00 AM, Simo Sorce wrote: >> > Later on you talk about performance penalty and say: >> > >> > Implementations SHOULD perform public >> > key operations, such as asymmetric signature verification or >> > asymmetric encryption, without using PKCS #11 >> > >> > I think this should be at most a MAY. If I wanted to be more >> > pedantic I >> > would say you should take in consideration there may be PKCS#11 >> > modules >> > that are already smart enough to implement such functions in >> > software >> > so that they do not incur in performance penalties, so the whole >> > this >> > would have to be wrapped in something like: >> > "If the PKCS#11 implementation perform public key operation in >> > hardare >> > that may result in poor performance then implementations MAY >> > perfrom >> > public ..." >> >> I did some reflection on this over the long weekend. If we wanted to >> support offloading public key operations to PKCS #11, we'd need to >> have a "p11pub" JWK property which defines the URI to the public key >> to perform the operation on. This duplicates the existing public key >> information in the JWK. >> >> We could allow three modes: >> 1. pubkey-only; no PKCS #11 >> 2. URI-only; PKCS #11 >> 3. both; optional PKCS #11 >> >> In mode #3, there is a possibility for public key mismatch. However, >> no attacks exist which don't also exist for mode #1. >> >> My worry is that this is a lot of complexity for minimal gain. JOSE >> implementations already have to support #1. At best, mode #2 is going >> to be as fast as #1. I just don't see any compelling reason to >> support >> public key URIs. Do you? >> >> As an aside, I do see value in exporting X.509 material from >> certificate URIs and placing them in the already established JWK >> parameters. However, I do not think standardization is required to >> support this; implementations can do this in a compatible way without >> any new RFCs once they have "p11". > > I do not think we need to explicitly add a p11public parameter. > As Nikos noted (unless I misunderstood) implementations can infer the > public key from the private one. So implementations may chose to use > the corresponding public key via pkcs11 if they so desire. Otherwise > they can use the current stuff which is just fine. > > Simo. From nobody Wed Jul 5 12:01:22 2017 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 3C4C5131DC8 for ; Wed, 5 Jul 2017 12:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBBOjr4mYX1B for ; Wed, 5 Jul 2017 12:01:19 -0700 (PDT) Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428D8131DC4 for ; Wed, 5 Jul 2017 12:01:06 -0700 (PDT) Received: by mail-it0-f46.google.com with SMTP id m68so121001061ith.1 for ; Wed, 05 Jul 2017 12:01:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oj/i3n7Fj9edN8a0MSduK4zKLozHqe4sqwLkxhuhHiE=; b=siaBziUFRHGNCJIvOVyPcm4BKgGoFpWYLYVqeC86U4IQNVxi+zwsAy5iSODDbbFc0B p0gOC2wykQvhRAhg6J8EUIYMfOYJtDkSbi/winuJi2SccqGEanFxms63ZT/S+MXVeMa9 3GwaStQBZtjiUfCsu1sPTDZ1N4TRdXtn0K8d1IeTAt6xLNh19I0iru6VPRASHIbzYJwA ZonQtw4VEuBRXliVmA0ho8tcG3Nwx15IHck16r5Gv12O/PaOwU5jElGZL6AhpGXDq9my TPFJMR2o6JyOosGRkV6kqMyJkj2XXrU1dJwdhx/HJCfoMYQQKxiILjMb9tb0D96qAXQS icEw== X-Gm-Message-State: AKS2vOxDoEc7ZTSMQPHz8GmBNoBnkrF9JKsRT5iCCqpujwl1QPBkQPd9 NzYfoBfwEyC6pQMB5hE+/5+WmQgb+tOujU4= X-Received: by 10.107.9.96 with SMTP id j93mr43332848ioi.161.1499281264765; Wed, 05 Jul 2017 12:01:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.132.88 with HTTP; Wed, 5 Jul 2017 12:01:03 -0700 (PDT) In-Reply-To: References: From: Nathaniel McCallum Date: Wed, 5 Jul 2017 15:01:03 -0400 Message-ID: To: jose@ietf.org Cc: "Sorce, Simo" , Nikos Mavrogiannopoulos , Daiki Ueno Content-Type: multipart/mixed; boundary="001a113fc30234ff870553969f73" Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 19:01:21 -0000 --001a113fc30234ff870553969f73 Content-Type: text/plain; charset="UTF-8" I have updated the draft from the comments everyone has provided. However, document uploads are currently locked due to the IETF meeting, so I have attached the document here. Your feedback is greatly appreciated. On Fri, Jun 30, 2017 at 5:33 PM, Nathaniel McCallum wrote: > I have prepared an initial stab at a draft for offloading JWK private > key data to PKCS #11. > > You can find the document here: > https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt > > Thanks for your consideration! --001a113fc30234ff870553969f73 Content-Type: text/plain; charset="US-ASCII"; name="draft-mccallum-jose-pkcs11-jwk-01.txt" Content-Disposition: attachment; filename="draft-mccallum-jose-pkcs11-jwk-01.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j4rd3fv90 CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBOLiBNY0NhbGx1bQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFJlZCBIYXQsIEluYy4KVXBkYXRlczogNzUxNyAoaWYgYXBw cm92ZWQpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVseSA1LCAyMDE3CkludGVu ZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrCkV4cGlyZXM6IEphbnVhcnkgNiwgMjAxOAoKCiAg ICAgICAgICAgICAgICAgICAgICAgUEtDUyAjMTEgZm9yIEpTT04gV2ViIEtleXMKICAgICAgICAg ICAgICAgICAgIGRyYWZ0LW1jY2FsbHVtLWpvc2UtcGtjczExLWp3ay0wMQoKQWJzdHJhY3QKCiAg IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMgNzUxNyBpbiBvcmRlciB0byBzcGVjaWZ5IGFuIGV4 dGVuc2lvbiB0bwogICB0aGUgSlNPTiBXZWIgS2V5IChKV0spIGZvcm1hdCBzbyB0aGF0IHByaXZh dGUga2V5IG1hdGVyaWFsIG1heSBiZQogICBzdG9yZWQgaW4gY3J5cHRvZ3JhcGhpYyBoYXJkd2Fy ZSB1c2luZyBQS0NTICMxMS4gIEl0IGRlZmluZXMgYSBuZXcKICAgcHJvcGVydHkgZm9yIEpXS3Mg d2hpY2ggY29udGFpbnMgdGhlIFBLQ1MgIzExIFVSSSBpZGVudGlmeWluZyB0aGUKICAgbG9jYXRp b24gb2YgdGhlIHByaXZhdGUga2V5IG1hdGVyaWFsLiAgSW1wbGVtZW50YXRpb25zIGNhbiB1c2Ug dGhpcwogICBVUkkgdG8gb2ZmbG9hZCB0aGUgY3J5cHRvZ3JhcGhpYyBvcGVyYXRpb25zIHRvIHRo ZSBpZGVudGlmaWVkCiAgIGhhcmR3YXJlLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJ bnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQog ICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBG b3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUK ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3Vy cmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50 cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVk LCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGlt ZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVu Y2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJv Z3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKYW51YXJ5IDYs IDIwMTguCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKGMpIDIwMTcgSUVURiBUcnVz dCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4g IEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQ IDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8g SUVURiBEb2N1bWVudHMKICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykg aW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQu ICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVz Y3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhp cyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50 IG11c3QKCgoKTWNDYWxsdW0gICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDE4 ICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIFBL Q1MgIzExIGZvciBKV0sgICAgICAgICAgICAgICAgICAgSnVseSAyMDE3CgoKICAgaW5jbHVkZSBT aW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9m CiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3 YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpU YWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDIuICBEb2N1bWVudCBDb252ZW50 aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMgogICAzLiAg SldLIFBLQ1MgIzExIFVSSSBQcm9wZXJ0eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDIKICAgNC4gIFVSSSBBdHRyaWJ1dGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgIDUuICBJbXBsZW1lbnRhdGlvbiBDb25zaWRlcmF0 aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICA2LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQK ICAgNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA1CiAgIDguICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICBBcHBlbmRpeCBBLiAgRXhhbXBsZXMg b2YgUEtDUyAjMTEgSldLcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgICBBLjEu ICBTeW1tZXRyaWMgUEtDUyAjMTEgSldLICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA2CiAgICAgQS4yLiAgRWxsaXB0aWMgQ3VydmUgUEtDUyAjMTEgSldLIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICAgIEEuMy4gIFJTQSBQS0NTICMxMSBKV0sgKHRydW5j YXRlZCkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgQXV0aG9yJ3MgQWRkcmVz cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2Cgox LiAgSW50cm9kdWN0aW9uCgogICBKU09OIFdlYiBLZXkgKEpXSykgW1JGQzc1MTddIGRlZmluZXMg YSBmb3JtYXQgZm9yIGtleXMgd2hpY2ggY2FuIGJlCiAgIHVzZWQgdG8gcGVyZm9ybSBjcnlwdG9n cmFwaGljIG9wZXJhdGlvbnMuICBXaGVuIHRoZXNlIEpXS3MgY29udGFpbgogICBwcml2YXRlIGtl eSBtYXRlcmlhbCwgaWxsZWdpdGltYXRlIGFjY2VzcyB0byB0aGlzIG1hdGVyaWFsIGNyZWF0ZXMK ICAgdGhlIHBvc3NpYmlsaXR5IGZvciB3aWRlLXNjYWxlIHNlY3VyaXR5IGNvbXByb21pc2UuCgog ICBBcyBhIGRlZmVuc2l2ZSBzdHJhdGVneSwgb3RoZXIga2V5IHR5cGVzIHdpbGwgb2ZmbG9hZCB0 aGVpciBwcml2YXRlCiAgIGtleSBtYXRlcmlhbCB0byBjcnlwdG9ncmFwaGljIGhhcmR3YXJlIG9y IG90aGVyIHNlY3VyZSBzdG9yYWdlIHVzaW5nCiAgIFBLQ1MgIzExLiAgVGhlIGxvY2F0aW9ucyBv ZiB0aGVzZSBrZXlzIGFyZSBjb21tdW5pY2F0ZWQgdXNpbmcgUEtDUwogICAjMTEgVVJJcyBbUkZD NzUxMl0uICBUaGVyZWZvcmUsIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG1ldGhvZCB0bwogICBy ZXBsYWNlIHRoZSBwcml2YXRlIGtleSBtYXRlcmlhbCBvZiBhIEpXSyB3aXRoIGEgUEtDUyAjMTEg VVJJLgoKMi4gIERvY3VtZW50IENvbnZlbnRpb25zCgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0 aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZD IDIxMTkgW1JGQzIxMTldLgoKMy4gIEpXSyBQS0NTICMxMSBVUkkgUHJvcGVydHkKCiAgIFVzZXJz IHRoYXQgd2lzaCB0byBvZmZsb2FkIHRoZWlyIHByaXZhdGUga2V5IG1hdGVyaWFsIHRvCiAgIGNy eXB0b2dyYXBoaWMgaGFyZHdhcmUgdXNpbmcgUEtDUyAjMTEgd2lsbCBwcm92aWRlIGEgSlNPTiBw cm9wZXJ0eQogICBuYW1lZCAicDExIiBpbnN0ZWFkIG9mIHRoZSBwcml2YXRlIGtleSBtYXRlcmlh bC4gIFRoZSAicDExIiBwcm9wZXJ0eQogICBNVVNUIGNvbnRhaW4gYSB2YWxpZCBQS0NTICMxMSBV UkkgW1JGQzc1MTddIHRoYXQgcG9pbnRzIHRvIGEgcHJpdmF0ZQogICBrZXkgb2JqZWN0ICh0aGF0 IGlzLCB0eXBlPXByaXZhdGUpLgoKCgoKCk1jQ2FsbHVtICAgICAgICAgICAgICAgICBFeHBpcmVz IEphbnVhcnkgNiwgMjAxOCAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBQS0NTICMxMSBmb3IgSldLICAgICAgICAgICAgICAgICAgIEp1bHkgMjAx NwoKCiAgIFByaXZhdGUga2V5IG1hdGVyaWFsIGZvciBib3RoIHN5bW1ldHJpYyBhbmQgYXN5bW1l dHJpYyBrZXlzIGlzCiAgIGRlZmluZWQgYnkgdGhlIFBhcmFtZXRlciBJbmZvcm1hdGlvbiBDbGFz cyBvZiBTZWN0aW9uIDguMS4xIG9mIFJGQwogICA3NTE3IFtSRkM3NTE3XS4gIEpXS3MgTVVTVCBO T1QgcHJvdmlkZSBib3RoIHRoZSAicDExIiBwcm9wZXJ0eSBhbmQKICAgb3RoZXIgcHJpdmF0ZSBr ZXkgbWF0ZXJpYWwuICBIb3dldmVyLCBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIHByb3ZpZGUKICAg ZnVsbCBwdWJsaWMga2V5IG1hdGVyaWFsIGFwcHJvcHJpYXRlIHRvIHRoZSBrZXkgdHlwZS4gIFRo aXMgZW5hYmxlcwogICBpbXBsZW1lbnRhdGlvbnMgdG8gcGVyZm9ybSBwdWJsaWMga2V5IGNyeXB0 b2dyYXBoaWMgb3BlcmF0aW9ucwogICB3aXRob3V0IGNvbnN1bHRpbmcgUEtDUyAjMTEuCgo0LiAg VVJJIEF0dHJpYnV0ZXMKCiAgIFRoZSBQS0NTICMxMSBVUkkgc3RhbmRhcmQgcHJvdmlkZXMgbWFw cGluZ3MgdG8gVVJJIGZvcm1hdCBmb3IgbW9zdAogICBtZXRhZGF0YSBhdHRyaWJ1dGVzIGF2YWls YWJsZSBvdmVyIFBLQ1MgIzExLiAgU29tZSBvZiB0aGVzZQogICBhdHRyaWJ1dGVzIG1heSBkaWZm ZXIgYmFzZWQgb24gb3BlcmF0aW5nIHN5c3RlbSwgZHJpdmVyIG9yCiAgIGltcGxlbWVudGF0aW9u IHZlcnNpb24uICBJbiBvcmRlciB0byBhdm9pZCBVUkkgZnJhZ2lsaXR5LCB0aGUKICAgZ2VuZXJh dGlvbiBvZiBVUklzIFNIT1VMRCBhdm9pZCBwYXJhbWV0ZXJzIHRoYXQgbWF5IGNoYW5nZQogICB1 bm5lY2Vzc2FyaWx5LgoKICAgVGhlIGZvbGxvd2luZyBwYXRoIGF0dHJpYnV0ZXMgYXJlIFJFUVVJ UkVEIGZvciB1c2UgaW4gInAxMSI6CgogICBvIGlkCiAgIG8gdHlwZT1wcml2YXRlCgogICBUaGUg Zm9sbG93aW5nIHBhdGggYXR0cmlidXRlcyBhcmUgUkVDT01NRU5ERUQgZm9yIHVzZSBpbiAicDEx IjoKCiAgIG8gbW9kZWwKICAgbyBtYW51ZmFjdHVyZXIKICAgbyBzZXJpYWwKICAgbyB0b2tlbgog ICBvIG9iamVjdAoKICAgVGhlIGZvbGxvd2luZyBxdWVyeSBhdHRyaWJ1dGVzIGFyZSBSRUNPTU1F TkRFRCBmb3IgdXNlIGluICJwMTEiOgoKICAgbyBwaW4tdmFsdWUKICAgbyBwaW4tc291cmNlCiAg IG8gbW9kdWxlLW5hbWUKCiAgIFRvb2xzIHdoaWNoIGdlbmVyYXRlIFBLQ1MgIzExIFVSSXMgZm9y IHVzZSBpbiBKV0tzIFNIT1VMRCBOT1QKICAgZ2VuZXJhdGUgcGF0aCBvciBxdWVyeSBhdHRyaWJ1 dGVzIHRoYXQgYXJlIG5vdCByZWNvbW1lbmRlZCBvcgogICByZXF1aXJlZCBhYm92ZSBhbmQgTUFZ IGVtaXQgVVJJcyB3aGljaCBvbWl0IHRoZSByZWNvbW1lbmRlZAogICBhdHRyaWJ1dGVzLiAgT24g dGhlIG90aGVyIGhhbmQsIHRvb2xzIHdoaWNoIHByb2Nlc3MgSldLcyBjb250YWluaW5nCiAgIHRo ZSAicDExIiBwcm9wZXJ0eSBNQVkgcHJvY2VzcyBwYXRoIG9yIHF1ZXJ5IGF0dHJpYnV0ZXMgdGhh dCBhcmUgbm90CiAgIHJlY29tbWVuZGVkIG9yIHJlcXVpcmVkIGFib3ZlLgoKNS4gIEltcGxlbWVu dGF0aW9uIENvbnNpZGVyYXRpb25zCgogICBVc2luZyBQS0NTICMxMSBmb3IgY3J5cHRvZ3JhcGhp YyBvcGVyYXRpb25zIGlzIG9mdGVuIGFzc29jaWF0ZWQgd2l0aAogICBhIHBlcmZvcm1hbmNlIHBl bmFsdHkuICBJbXBsZW1lbnRhdGlvbnMgTUFZIHBlcmZvcm0gcHVibGljIGtleQoKCgoKTWNDYWxs dW0gICAgICAgICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDE4ICAgICAgICAgICAgICAg IFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIFBLQ1MgIzExIGZvciBKV0sg ICAgICAgICAgICAgICAgICAgSnVseSAyMDE3CgoKICAgb3BlcmF0aW9ucywgc3VjaCBhcyBhc3lt bWV0cmljIHNpZ25hdHVyZSB2ZXJpZmljYXRpb24gb3IgYXN5bW1ldHJpYwogICBlbmNyeXB0aW9u LCB3aXRob3V0IHVzaW5nIFBLQ1MgIzExIGluIG9yZGVyIHRvIGluY3JlYXNlIHNwZWVkLgoKICAg SW1wbGVtZW50YXRpb25zIHRoYXQgd2lzaCB0byB1c2UgUEtDUyAjMTEgZXZlbiBmb3IgcHVibGlj IGtleQogICBvcGVyYXRpb25zIHdpbGwgbmVlZCB0byB0cmFuc2Zvcm0gdGhlIFBLQ1MgIzExIHBy aXZhdGUga2V5IFVSSSBpbnRvIGEKICAgcHVibGljIGtleSBVUkkuICBUaGlzIGNhbiBiZSBwZXJm b3JtZWQgYnkgcmV0YWluaW5nIHRoZSAiaWQiIFVSSSBwYXRoCiAgIGF0dHJpYnV0ZSwgd2hpY2gg Y29ycmVsYXRlcyBiZXR3ZWVuIHJlbGF0ZWQga2V5IHR5cGVzLCBhbmQgY2hhbmdpbmcKICAgInR5 cGU9cHJpdmF0ZSIgdG8gInR5cGU9cHVibGljIi4gIEltcGxlbWVudGF0aW9ucyB3aGljaCBjcmVh dGUga2V5CiAgIHBhaXJzIHZpYSBQS0NTICMxMSBmb3IgdXNlIGluIEpXS3MgU0hPVUxEIHRha2Ug Y2FyZSB0byBlbnN1cmUgdGhhdAogICByZWxhdGVkIGtleSB0eXBlcyBhcmUgZGlmZmVyZW50aWF0 ZWQgb25seSBieSB0aGUgInR5cGUiIFVSSSBwYXRoCiAgIGF0dHJpYnV0ZS4KCiAgIFN5bW1ldHJp YyBKV0tzLCBzdWNoIGFzIGt0eT0ib2N0IiwgY29udGFpbiBubyBwdWJsaWMga2V5IG1hdGVyaWFs IGFuZAogICBoYXZlIG5vIHB1YmxpYyBrZXkgb3BlcmF0aW9ucy4gIFRodXMsIGFsbCBvcGVyYXRp b25zIHdpbGwgbmVlZCB0byBiZQogICBwZXJmb3JtZWQgdXNpbmcgUEtDUyAjMTEuCgo2LiAgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIEFjY2Vzc2luZyBhIEpXSyBjb250YWluaW5nIHRoZSAi cDExIiBwcm9wZXJ0eSBpbiBwbGFjZSBvZiB0aGUgcHJpdmF0ZQogICBrZXkgbWF0ZXJpYWwgbWF5 IHN0aWxsIGFsbG93IGFuIGF0dGFja2VyIHRvIHBlcmZvcm0gb3BlcmF0aW9ucyB1c2luZwogICB0 aGUgcHJpdmF0ZSBrZXkgd2hpbGUgbm90IG9idGFpbmluZyB0aGUgcHJpdmF0ZSBrZXkgaXRzZWxm LiAgVGhpcyBpcwogICBwYXJ0aWN1bGFybHkgdHJ1ZSB3aGVuIHRoZSAicGluLXZhbHVlIiBvciAi cGluLXNvdXJjZSIgcXVlcnkKICAgYXR0cmlidXRlcyBhcmUgdXNlZC4KCiAgIE5ldmVydGhlbGVz cywgYmVjYXVzZSB0aGUgYXR0YWNrZXIgZG9lcyBub3QgbGVhcm4gdGhlIHByaXZhdGUga2V5CiAg IGl0c2VsZiwgdGhlIGF0dGFja2VyJ3MgYWNjZXNzIHRvIHVzZSBvZiB0aGUga2V5IGNhbiBiZSBs aW1pdGVkIHRvIGEKICAgcGFydGljdWxhciBjb250ZXh0OyBmb3IgZXhhbXBsZSwgb25seSB0aGUg aG9zdCB3aXRoIGRpcmVjdCBhY2Nlc3MgdG8KICAgdGhlIGhhcmR3YXJlLiAgQmVjYXVzZSBvZiB0 aGlzLCB0aGUgYWJpbGl0eSB0byByZW1vdmUgdGhlIGF0dGFja2VyJ3MKICAgYWNjZXNzIHRvIHRo aXMgY29udGV4dCBwcm92aWRlcyB0aGUgb3B0aW9uIGZvciBzaWduaWZpY2FudCBkYW1hZ2UKICAg bWl0aWdhdGlvbiBzdHJhdGVnaWVzLiAgVGhlcmVmb3JlLCBvZmZsb2FkaW5nIHRoZSBwcml2YXRl IGtleQogICBtYXRlcmlhbCBzaG91bGQgbm90IGJlIG1pc3VuZGVyc3Rvb2QgdG8gYmUgYSBwYW5h Y2VhIGFnYWluc3QKICAgY29tcHJvbWlzZXMgYnV0IHJhdGhlciBhIHdheSB0byByZWR1Y2UgdGhl IGNvc3Qgb2YgYSBjb21wcm9taXNlLgoKICAgRXhwb3NpbmcgdGhlICJwMTEiIHByb3BlcnR5IGNh biBsZWFrIGluc3RpdHV0aW9uYWwgb3IgY29uZmlndXJhdGlvbgogICBpbmZvcm1hdGlvbiB0byBh biBhdHRhY2tlciB0aGF0IGNvdWxkIGJlIHVzZWQgYXMgcGFydCBvZiBhCiAgIG11bHRpZmFjZXRl ZCBhdHRhY2suICBUaGlzIGlzIHBhcnRpY3VsYXJseSB0cnVlIHdoZW4gdGhlIFBLQ1MgIzExIFVS SQogICBjb250YWlucyB0aGUgInBpbi12YWx1ZSIgb3IgInBpbi1zb3VyY2UiIHF1ZXJ5IGF0dHJp YnV0ZXMgc2luY2UgdGhpcwogICBQSU4gaXMgdXNlZCB0byBwcm90ZWN0IGFjY2VzcyB0byB0aGUg cHJpdmF0ZSBrZXkgbWF0ZXJpYWwuICBGb3IgdGhpcwogICByZWFzb24sIHRoZSAicDExIiBwcm9w ZXJ0eSBNVVNUIGJlIHRyZWF0ZWQgYXMgYSBwcml2YXRlIGtleSBtYXRlcmlhbAogICBpbiBpdHMg b3duIHJpZ2h0IGFuZCBjYXJlIHNob3VsZCBiZSB0YWtlbiBub3QgdG8gZXhwb3NlIGl0LgoKICAg SXQgbWF5IGJlIGRlc2lyYWJsZSB0byBhdm9pZCB0aGUgdXNlIG9mIHRoZSAicGluLXZhbHVlIiBh bmQvb3IgInBpbi0KICAgc291cmNlIiBxdWVyeSBhdHRyaWJ1dGVzIGFsdG9nZXRoZXIgYnkgcGFz c2luZyBpbiB0aGlzIHZhbHVlIG91dCBvZgogICBiYW5kLiAgVGhpcyBzdHJhdGVneSBpbXBsaWVz IHRoYXQgdGhlIGF0dGFja2VyIHdpbGwgbmVlZCB0byB0YXJnZXQKICAgdGhlIG91dCBvZiBiYW5k IGRlbGl2ZXJ5IG1lY2hhbmlzbSBpbiBhZGRpdGlvbiB0byB0aGUgSldLIGluIG9yZGVyIHRvCiAg IHVzZSB0aGUgcHJpdmF0ZSBrZXkgbWF0ZXJpYWwuCgoKCgoKTWNDYWxsdW0gICAgICAgICAgICAg ICAgIEV4cGlyZXMgSmFudWFyeSA2LCAyMDE4ICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIFBLQ1MgIzExIGZvciBKV0sgICAgICAgICAgICAgICAg ICAgSnVseSAyMDE3CgoKICAgSldLcyBwcm92aWRlIHZhcmlvdXMgbWV0aG9kcyBmb3IgcmVzdHJp Y3RpbmcgdXNhZ2UgKHN1Y2ggYXMgdGhlICJ1c2UiCiAgIGFuZCAia2V5X29wcyIgcHJvcGVydGll cykuICBMaWtld2lzZSwgUEtDUyAjMTEgY29udGFpbnMgc2ltaWxhciB1c2FnZQogICByZXN0cmlj dGlvbnMgKHN1Y2ggYXMgQ0tBX1NJR04sIENLQV9WRVJJRlksIGV0YykuICBTaW1pbGFybHksIGJv dGgKICAgcHJvdmlkZSBtZXRhZGF0YSB0byBjb21tdW5pY2F0ZSBzdXBwb3J0ZWQgYWxnb3JpdGht cyAoSldLOiAiYWxnIgogICBwcm9wZXJ0eSwgUEtDUyAjMTE6IHZpYSB0aGUgQ19HZXRNZWNoYW5p c21MaXN0KCkgZnVuY3Rpb24pLgogICBVdGlsaXRpZXMgd2hpY2ggZ2VuZXJhdGUgSldLcyBmcm9t IFBLQ1MgIzExIGRhdGEgU0hPVUxEIHBvcHVsYXRlIHRoZQogICByZXNwZWN0aXZlIEpXSyBwcm9w ZXJ0aWVzIGZyb20gdGhlIFBLQ1MgIzExIGRhdGEgaW4gb3JkZXIgdG8gYXZvaWQKICAgY29uZnVz aW9uLiAgSW1wbGVtZW50YXRpb25zIHdoaWNoIHVzZSB0aGVzZSBrZXlzIE1VU1QgcmVzcGVjdCB0 aGUKICAgY29uc3RyYWludHMgcHJlc2VudCBpbiBlaXRoZXIgdGhlIEpXSyBvciBpdHMgY29ycmVz cG9uZGluZyBQS0NTICMxMQogICBvYmplY3QuICBUaGlzIHByZXZlbnRzIGNvbmZ1c2lvbiBhbmQg cG9zc2libGUgY29tcHJvbWlzZSB3aGVuIHRoZSBKV0sKICAgY29udGFpbnMgZGlmZmVyZW50IHJl c3RyaWN0aW9ucyB0aGFuIGl0cyBQS0NTICMxMSBwcml2YXRlIGtleSBvYmplY3QuCgo3LiAgSUFO QSBDb25zaWRlcmF0aW9ucwoKICAgVGhlIGZvbGxvd2luZyBoYXMgYmVlbiBhZGRlZCB0byB0aGUg IkpTT04gV2ViIEtleSBQYXJhbWV0ZXJzIgogICByZWdpc3RyeToKCiAgIG8gUGFyYW1ldGVyIE5h bWU6ICJwMTEiCiAgIG8gUGFyYW1ldGVyIERlc2NyaXB0aW9uOiBUaGUgUEtDUyAjMTEgVVJJCiAg IG8gUGFyYW1ldGVyIEluZm9ybWF0aW9uIENsYXNzOiBQcml2YXRlCiAgIG8gVXNlZCB3aXRoICJr dHkiIFZhbHVlKHMpOiAqCiAgIG8gQ2hhbmdlIENvbnRyb2xsZXI6IElFU0cKICAgbyBTcGVjaWZp Y2F0aW9uIERvY3VtZW50KHMpOiBTZWN0aW9uIDMgb2YgVEhJUyBET0NVTUVOVAoKOC4gIE5vcm1h dGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZv ciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVs cyIsIEJDUCAxNCwgUkZDIDIxMTksCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMTks IE1hcmNoIDE5OTcsCiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmMyMTE5Pi4KCiAgIFtSRkM3NTEyXSAgUGVjaGFuZWMsIEouIGFuZCBELiBNb2ZmYXQsICJU aGUgUEtDUyAjMTEgVVJJIFNjaGVtZSIsCiAgICAgICAgICAgICAgUkZDIDc1MTIsIERPSSAxMC4x NzQ4Ny9SRkM3NTEyLCBBcHJpbCAyMDE1LAogICAgICAgICAgICAgIDxodHRwOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2luZm8vcmZjNzUxMj4uCgogICBbUkZDNzUxN10gIEpvbmVzLCBNLiwgIkpTT04g V2ViIEtleSAoSldLKSIsIFJGQyA3NTE3LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3 NTE3LCBNYXkgMjAxNSwKICAgICAgICAgICAgICA8aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9p bmZvL3JmYzc1MTc+LgoKCgoKCgoKCgoKCgoKTWNDYWxsdW0gICAgICAgICAgICAgICAgIEV4cGly ZXMgSmFudWFyeSA2LCAyMDE4ICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIFBLQ1MgIzExIGZvciBKV0sgICAgICAgICAgICAgICAgICAgSnVseSAy MDE3CgoKQXBwZW5kaXggQS4gIEV4YW1wbGVzIG9mIFBLQ1MgIzExIEpXS3MKCkEuMS4gIFN5bW1l dHJpYyBQS0NTICMxMSBKV0sKCiAgIHsKICAgICAia3R5IjogIm9jdCIsCiAgICAgInVzZSI6ICJl bmMiLAogICAgICJwMTEiOiAicGtjczExOmlkPSVlOCVhMyUwYyUwYiVlMyU5YTt0eXBlPXByaXZh dGU/cGluLXZhbHVlPTEyMzQ1NiIKICAgfQoKQS4yLiAgRWxsaXB0aWMgQ3VydmUgUEtDUyAjMTEg SldLCgogICB7CiAgICAgImt0eSI6ICJFQyIsCiAgICAgImNydiI6ICJQLTI1NiIsCiAgICAgInVz ZSI6ICJzaWciLAogICAgICAgIngiOiAiUVFTeDFaTUtrYms1Q2dJZnMzVlF0ZFZpMFE2YzRvNVJD NmVzU1ctY3ViVnQiLAogICAgICAgInkiOiAiYlpkQUcxbXlDZDYyRThJeWRQVHBxRXlsejBSUjRB MFpsUVVMUXJneGtVSnkiLAogICAgICJwMTEiOiAicGtjczExOmlkPSViOSUxMCU2ZCVmNyVhOSUx Nzt0eXBlPXByaXZhdGU/cGluLXZhbHVlPTEyMzQ1NiIKICAgfQoKQS4zLiAgUlNBIFBLQ1MgIzEx IEpXSyAodHJ1bmNhdGVkKQoKICAgewogICAgICJrdHkiOiAiUlNBIiwKICAgICAiYWxnIjogIlJT MjU2IiwKICAgICAgICJlIjogIkFRQUIiLAogICAgICAgIm4iOiAiM0Q1Q1RUNEQzeF9zN0x5OG5T ak1UakpudHBWVTQzMXNMUjhYcGRuNUJUTS4uLiIsCiAgICAgInAxMSI6ICJwa2NzMTE6aWQ9JWYx JTliJTU2JTk2JTg3JWFmO3R5cGU9cHJpdmF0ZT9waW4tdmFsdWU9MTIzNDU2IgogICB9CgpBdXRo b3IncyBBZGRyZXNzCgogICBOYXRoYW5pZWwgTWNDYWxsdW0KICAgUmVkIEhhdCwgSW5jLgogICAx MDAgRWFzdCBEYXZpZSBTdHJlZXQKICAgUmFsZWlnaCwgTkMgIDI3NjAxCiAgIFVTQQoKICAgRU1h aWw6IG5wbWNjYWxsdW1AcmVkaGF0LmNvbQoKCgoKCgoKCgoKCk1jQ2FsbHVtICAgICAgICAgICAg ICAgICBFeHBpcmVzIEphbnVhcnkgNiwgMjAxOCAgICAgICAgICAgICAgICBbUGFnZSA2XQo= --001a113fc30234ff870553969f73-- From nobody Thu Jul 6 00:57:58 2017 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 5B3C0126CC4 for ; Thu, 6 Jul 2017 00:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dj83UnZ7Ex6p for ; Thu, 6 Jul 2017 00:57:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCADA126C7A for ; Thu, 6 Jul 2017 00:57:55 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 20E017F40D for ; Thu, 6 Jul 2017 07:57:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 20E017F40D Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=simo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 20E017F40D Received: from rhino.ipa.ssimo.org (ovpn-116-100.phx2.redhat.com [10.3.116.100]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3B6CE5F909; Thu, 6 Jul 2017 07:57:50 +0000 (UTC) Message-ID: <1499327868.11334.83.camel@redhat.com> From: Simo Sorce To: Nathaniel McCallum Cc: jose@ietf.org, Nikos Mavrogiannopoulos , Daiki Ueno Date: Thu, 06 Jul 2017 03:57:48 -0400 In-Reply-To: References: <1498896051.11334.78.camel@redhat.com> <1499264787.11334.81.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 06 Jul 2017 07:57:55 +0000 (UTC) Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 07:57:57 -0000 On Wed, 2017-07-05 at 10:45 -0400, Nathaniel McCallum wrote: > I believe that this will work in most, but not all, situations. The > correlation of keys using the id= parameter is only a recommendation. I think it is ok to rely on the recommendation and fail otherwise, all JWK libraries must be prepared to handle public keys on their own anyway, so they can always just do that. Simo. > On Wed, Jul 5, 2017 at 10:26 AM, Simo Sorce wrote: > > On Wed, 2017-07-05 at 09:04 -0400, Nathaniel McCallum wrote: > > > On Sat, Jul 1, 2017 at 4:00 AM, Simo Sorce > > > wrote: > > > > Later on you talk about performance penalty and say: > > > > > > > >    Implementations SHOULD perform public > > > >    key operations, such as asymmetric signature verification or > > > >    asymmetric encryption, without using PKCS #11 > > > > > > > > I think this should be at most a MAY. If I wanted to be more > > > > pedantic I > > > > would say you should take in consideration there may be PKCS#11 > > > > modules > > > > that are already smart enough to implement such functions in > > > > software > > > > so that they do not incur in performance penalties, so the > > > > whole > > > > this > > > > would have to be wrapped in something like: > > > >  "If the PKCS#11 implementation perform public key operation in > > > > hardare > > > > that may result in poor performance then implementations MAY > > > > perfrom > > > > public ..." > > > > > > I did some reflection on this over the long weekend. If we wanted > > > to > > > support offloading public key operations to PKCS #11, we'd need > > > to > > > have a "p11pub" JWK property which defines the URI to the public > > > key > > > to perform the operation on. This duplicates the existing public > > > key > > > information in the JWK. > > > > > > We could allow three modes: > > > 1. pubkey-only; no PKCS #11 > > > 2. URI-only; PKCS #11 > > > 3. both; optional PKCS #11 > > > > > > In mode #3, there is a possibility for public key mismatch. > > > However, > > > no attacks exist which don't also exist for mode #1. > > > > > > My worry is that this is a lot of complexity for minimal gain. > > > JOSE > > > implementations already have to support #1. At best, mode #2 is > > > going > > > to be as fast as #1. I just don't see any compelling reason to > > > support > > > public key URIs. Do you? > > > > > > As an aside, I do see value in exporting X.509 material from > > > certificate URIs and placing them in the already established JWK > > > parameters. However, I do not think standardization is required > > > to > > > support this; implementations can do this in a compatible way > > > without > > > any new RFCs once they have "p11". > > > > I do not think we need to explicitly add a p11public parameter. > > As Nikos noted (unless I misunderstood) implementations can infer > > the > > public key from the private one. So implementations may chose to > > use > > the corresponding public key via pkcs11 if they so desire. > > Otherwise > > they can use the current stuff which is just fine. > > > > Simo. From nobody Thu Jul 6 14:07:52 2017 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 DDB26131553 for ; Thu, 6 Jul 2017 14:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLpC7FyFSCac for ; Thu, 6 Jul 2017 14:07:49 -0700 (PDT) Received: from p3plsmtpa11-02.prod.phx3.secureserver.net (p3plsmtpa11-02.prod.phx3.secureserver.net [68.178.252.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC1A12EA58 for ; Thu, 6 Jul 2017 14:07:49 -0700 (PDT) Received: from [192.168.43.252] ([212.39.89.173]) by :SMTPAUTH: with SMTP id TDzVdV3Bg9yfiTDzXd6xnU; Thu, 06 Jul 2017 14:07:18 -0700 To: Nathaniel McCallum , jose@ietf.org Cc: Nikos Mavrogiannopoulos , Daiki Ueno , "Sorce, Simo" References: From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <4a84c70f-885e-3125-f736-71c404b28d95@connect2id.com> Date: Thu, 6 Jul 2017 23:07:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-CMAE-Envelope: MS4wfLcK5vnjiuOwH/dgpcaNhy22hvs0/WLSQv8NOd1zBY8ekoGPzqq05qhNgIDlDAAIC3nCAwAiJTHIImynjRRN7B0+GVFcA7RaMdmSS47pWZsrhYAVnq7o YsxtFF3B8imRb+VDBzqSfcbMkbmBilYCVj+Yj88zpghyFjlL0uGrvyL/e0wNuHu6MpnGQ3ggL80Dqcd64biil5aWMOScvR8DWNYwVlTTKu+rZNheMvIQrcQ7 ZNnZo0gSBPZbIGcniRNg4eYTpfrO8HIkkMYyKP3rJmsJ9pp73hk0TiaXHXi69lG4 Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 21:07:51 -0000 Great! The "k" parameter appears to be mandatory for "oct" JWKs. How can we reconcile that with the p11 spec? Ideas? https://tools.ietf.org/html/rfc7518#section-6.4.1 On 05/07/17 21:01, Nathaniel McCallum wrote: > I have updated the draft from the comments everyone has provided. > However, document uploads are currently locked due to the IETF > meeting, so I have attached the document here. Your feedback is > greatly appreciated. > > On Fri, Jun 30, 2017 at 5:33 PM, Nathaniel McCallum > wrote: >> I have prepared an initial stab at a draft for offloading JWK private >> key data to PKCS #11. >> >> You can find the document here: >> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt >> From nobody Thu Jul 6 14:50:14 2017 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 77CC5131844 for ; Thu, 6 Jul 2017 14:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQj97CPPJwkl for ; Thu, 6 Jul 2017 14:50:08 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFA7126B7F for ; Thu, 6 Jul 2017 14:50:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1499377797; h=from:subject:to:date:message-id; bh=MWoPvGa1FsWoltwQEES2wEGkrTi+UlIF+5oSUnseeKE=; b=fpvBsHUyzTb9t7CMvDpGzG8cM85cD0sQTbG/9W46wZPTRI21rzBKbB0e+PKA2Ah23tVlEIQmSEH DVhqMzxpue0ntZUr+71Yon0nw5d+iIObxCn3mInFA5osQZKNNaJZmy2OIhtApWiC77xAHyK9fqGxN tykOEBVafY9Hu3Q/ukNZ+Ig/0I56cwDGItrhrk4nhFhmdyl7sYHf6UlgB+Ex6vv1pFXCxa94HDdZw 4cwnTqyxZWpe7iWJOondhZkyywVrDP4WU3or6fmjhGwCD28kBp0rAyXMW2pMjKVw/N47MahCD/F2p S6EiuYmhs5I46E2EQRKs3juiAtHJ3escZPIA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 6 Jul 2017 14:49:56 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 6 Jul 2017 14:49:52 -0700 From: Jim Schaad To: 'Vladimir Dzhuvinov' , 'Nathaniel McCallum' , References: <4a84c70f-885e-3125-f736-71c404b28d95@connect2id.com> In-Reply-To: <4a84c70f-885e-3125-f736-71c404b28d95@connect2id.com> Date: Thu, 6 Jul 2017 14:49:58 -0700 Message-ID: <01cb01d2f6a1$d1d795e0$7586c1a0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQE+CZkqRZsSU48EP4Y+XkYClZmhtgID4I7rAaEcpzCjVAgg4A== X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 21:50:12 -0000 This would require that this document update RFC 7518 to make one or the other be present. You probably want to have a general update of some type that says you either have the 'p11' element or the private fields but not both for all key types. Jim -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Vladimir Dzhuvinov Sent: Thursday, July 6, 2017 2:07 PM To: Nathaniel McCallum ; jose@ietf.org Cc: Nikos Mavrogiannopoulos ; Daiki Ueno ; Sorce, Simo Subject: Re: [jose] PKCS #11 for JWK Great! The "k" parameter appears to be mandatory for "oct" JWKs. How can we reconcile that with the p11 spec? Ideas? https://tools.ietf.org/html/rfc7518#section-6.4.1 On 05/07/17 21:01, Nathaniel McCallum wrote: > I have updated the draft from the comments everyone has provided. > However, document uploads are currently locked due to the IETF > meeting, so I have attached the document here. Your feedback is > greatly appreciated. > > On Fri, Jun 30, 2017 at 5:33 PM, Nathaniel McCallum > wrote: >> I have prepared an initial stab at a draft for offloading JWK private >> key data to PKCS #11. >> >> You can find the document here: >> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt >> _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From nobody Fri Jul 7 00:05:49 2017 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 EB6B5129B31 for ; Fri, 7 Jul 2017 00:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia1EMxzPQW2a for ; Fri, 7 Jul 2017 00:05:46 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC3B126579 for ; Fri, 7 Jul 2017 00:05:45 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id x23so5587153wrb.0 for ; Fri, 07 Jul 2017 00:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BQ2XhWDIk9KRmA61PkNUMqw/HMARU377s1nr9KDfYUk=; b=vgob4DWp5ZksHtWbBUw4x7xRJruOA/lWdidd17L4qKFo8a0MHmhiu8rAxxYK7B9jYB i76Gsz6FIhwpCZe2dHU3NcCUnJE++CANJXJ3UpZbwLw8WBk4QxWflKgSleOEyXFtSt0x fuE1/UAJuXFZEmhQUJ/58zBy1WSSLmlLPF8joOz86C+YwFJZrPUcVGhDtHl45bdZs0/9 RH5pkLKDdWbkYnNTs941WXLb2I9im2480G59eQzLxjxazSxDF+e4hRqD+z2AqqDn3rlR JLpxCK+cYsTPLlKbprCzpn5COYJpRd19hobjLLLv0nb5Lf+xEtp12zdJQXMQuSwzyBNS S8+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BQ2XhWDIk9KRmA61PkNUMqw/HMARU377s1nr9KDfYUk=; b=ezgHbsSgk4UfxyRDEC1Uh6hGOrX2WbGBwcbGGEzFCTUi0jqME888PbKWQ6duWp4zRc vw8kcJkgGMCqsH8TgEa3ujbwZEDXAoNudjjWmbMbi4WIyZEenXZHdfoTVZswG5wFNSqo h3q/KmTvgZIPPyynQEW51y7A6pbnVEL9upaMViib+e18AWDfXepicRzT9jXLcqQYHXFp biCJKlhxXO5fnXoVe9HDDdKPjLKJfmMUOkX/nAIypCD4aDZSVImuC/2ImRFOrQmPeaup PozZDf6TvPEw0NLLESM6pHub5vwLVeFmxkh+I/QI3GBCaFVJRb5slxdUqEMeZsy6xESt 2pKg== X-Gm-Message-State: AIVw112tigB0dHP67MRpgoOqVDAGg5L93cCb/O6of50nocDMUeVAzm6A 8NhSfKwPcrfiyA== X-Received: by 10.28.109.218 with SMTP id b87mr1105632wmi.125.1499411144472; Fri, 07 Jul 2017 00:05:44 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id b94sm1809784wrd.40.2017.07.07.00.05.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 00:05:43 -0700 (PDT) To: Vladimir Dzhuvinov , Nathaniel McCallum , jose@ietf.org Cc: Nikos Mavrogiannopoulos , Daiki Ueno , "Sorce, Simo" References: <4a84c70f-885e-3125-f736-71c404b28d95@connect2id.com> From: Anders Rundgren Message-ID: <78d0105d-cccc-49ed-2e9e-ff1c6caf8e6c@gmail.com> Date: Fri, 7 Jul 2017 09:05:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4a84c70f-885e-3125-f736-71c404b28d95@connect2id.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 07:05:48 -0000 On 2017-07-06 23:07, Vladimir Dzhuvinov wrote: > Great! > > The "k" parameter appears to be mandatory for "oct" JWKs. How can we > reconcile that with the p11 spec? Ideas? > > https://tools.ietf.org/html/rfc7518#section-6.4.1 It gets even more fun with OKP JWKs: https://github.com/cyberphone/java-cfrg-spec Anders > > > On 05/07/17 21:01, Nathaniel McCallum wrote: >> I have updated the draft from the comments everyone has provided. >> However, document uploads are currently locked due to the IETF >> meeting, so I have attached the document here. Your feedback is >> greatly appreciated. >> >> On Fri, Jun 30, 2017 at 5:33 PM, Nathaniel McCallum >> wrote: >>> I have prepared an initial stab at a draft for offloading JWK private >>> key data to PKCS #11. >>> >>> You can find the document here: >>> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt >>> > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From nobody Fri Jul 7 02:56:57 2017 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 948FA12EC3F for ; Fri, 7 Jul 2017 02:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C7ay8bq6Mdi for ; Fri, 7 Jul 2017 02:56:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B9F12EC3B for ; Fri, 7 Jul 2017 02:56:54 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 81064C0587C4; Fri, 7 Jul 2017 09:56:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 81064C0587C4 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=simo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 81064C0587C4 Received: from rhino.ipa.ssimo.org (ovpn-116-56.phx2.redhat.com [10.3.116.56]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 95B986CDA0; Fri, 7 Jul 2017 09:56:48 +0000 (UTC) Message-ID: <1499421406.4686.5.camel@redhat.com> From: Simo Sorce To: Vladimir Dzhuvinov , Nathaniel McCallum , jose@ietf.org Cc: Nikos Mavrogiannopoulos , Daiki Ueno Date: Fri, 07 Jul 2017 05:56:46 -0400 In-Reply-To: <4a84c70f-885e-3125-f736-71c404b28d95@connect2id.com> References: <4a84c70f-885e-3125-f736-71c404b28d95@connect2id.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 07 Jul 2017 09:56:53 +0000 (UTC) Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 09:56:55 -0000 On Thu, 2017-07-06 at 23:07 +0200, Vladimir Dzhuvinov wrote: > Great! > > The "k" parameter appears to be mandatory for "oct" JWKs. How can we > reconcile that with the p11 spec? Ideas? > > https://tools.ietf.org/html/rfc7518#section-6.4.1 I wonder if an empty value would be properly handled by implementations or would cause them to leak information instead of encrypting it, or worse fall over themselves. Worst case we could define a new type "hwoct" ? Sounds a bit silly tho. Simo. From nobody Fri Jul 7 03:32:00 2017 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 A91F313167D for ; Fri, 7 Jul 2017 03:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XJWVoWw9fZe for ; Fri, 7 Jul 2017 03:31:57 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0D798129AD3 for ; Fri, 7 Jul 2017 03:31:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 26B8A65374 for ; Fri, 7 Jul 2017 13:31:55 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 5vMgYApcAj8X for ; Fri, 7 Jul 2017 13:31:54 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id B413E21C for ; Fri, 7 Jul 2017 13:31:53 +0300 (EEST) Date: Fri, 7 Jul 2017 13:31:53 +0300 From: Ilari Liusvaara To: jose@ietf.org Message-ID: <20170707103153.foufsm2wuibmomip@LK-Perkele-VII> References: <4a84c70f-885e-3125-f736-71c404b28d95@connect2id.com> <78d0105d-cccc-49ed-2e9e-ff1c6caf8e6c@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <78d0105d-cccc-49ed-2e9e-ff1c6caf8e6c@gmail.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 10:32:00 -0000 On Fri, Jul 07, 2017 at 09:05:38AM +0200, Anders Rundgren wrote: > On 2017-07-06 23:07, Vladimir Dzhuvinov wrote: > > Great! > > > > The "k" parameter appears to be mandatory for "oct" JWKs. How can we > > reconcile that with the p11 spec? Ideas? > > > > https://tools.ietf.org/html/rfc7518#section-6.4.1 > > It gets even more fun with OKP JWKs: Actually from what I can gather, RSA and OKP require the private key material for private keys. EC and OCT do not (at least I can't find explicit language saying they have to). So sounds like updating to RFC 7518 and RFC 8037 is in order. (Of course, I don't think presently OKP keys can be used with PKCS#11, but that is due to lack of specification, so it could change...) -Ilari From nobody Fri Jul 7 07:24:04 2017 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 75B5E12EC23 for ; Fri, 7 Jul 2017 07:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irnW4EGzpuUR for ; Fri, 7 Jul 2017 07:24:02 -0700 (PDT) Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D02129ABE for ; Fri, 7 Jul 2017 07:24:02 -0700 (PDT) Received: from [192.168.43.252] ([212.5.158.160]) by :SMTPAUTH: with SMTP id TUAIdiOHyznf6TUAJd5Wov; Fri, 07 Jul 2017 07:23:31 -0700 To: Nathaniel McCallum , jose@ietf.org Cc: Nikos Mavrogiannopoulos , Daiki Ueno , "Sorce, Simo" References: From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Fri, 7 Jul 2017 16:23:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050300030507070809030405" X-CMAE-Envelope: MS4wfNKIVOnNV0utvvQcqbjG7mAMIKQJqmxVMBPMRsxOsly9F8CeYGfjwITHV8HuC4Tnc7qJZK6DfirnnC9y+iSzxIortv1W6+HXjBcEyw3osVlBR8lp374K k/tGYukmaJUmzAOcSN1KSprEV1OxmGrJgRL5U5gDLY+QEwEDj5Y3wZs0y0EY3Cq04glBR903FDUYZoNSX+ix9r8bOCg1xn0ma0pwpzsTMqtyFPm8DtghlEia UYTG6Vya+/u4CtHgrCVV8e9w41vDQf+4w7qax87N3rBYWmNnhk5YnWaNf9tax3be Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 14:24:03 -0000 This is a cryptographically signed message in MIME format. --------------ms050300030507070809030405 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Regarding section 4 of the proposed -01 spec: When dealing with "oct" JWKs, shouldn't the PKCS#11 URI type parameter become "secret-key"? Vladimir On 05/07/17 21:01, Nathaniel McCallum wrote: > I have updated the draft from the comments everyone has provided. > However, document uploads are currently locked due to the IETF > meeting, so I have attached the document here. Your feedback is > greatly appreciated. > > On Fri, Jun 30, 2017 at 5:33 PM, Nathaniel McCallum > wrote: >> I have prepared an initial stab at a draft for offloading JWK private >> key data to PKCS #11. >> >> You can find the document here: >> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt >> >> Thanks for your consideration! --------------ms050300030507070809030405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2 CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5 7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN 880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5 RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5 60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzA3MDcxNDIzMjRaMC8GCSqGSIb3DQEJBDEiBCBl2cM9tmXAxy7e+zHvhyppEnYnT+Q8 Vc72AKtCuLgkujBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQCB7aIVgYry vj6VryuKQnFBx8Xufp5+waqwQfRfbZIbeQvGyEKApL0PDJ5hq3kty3uzjBZp59LELxZcqymP GtewHv0lRfJh4+I2+Ka+Wjvph0zZBOAgcl/P7azz+pqZnv0ceSbiJPt4QHPp6jXIS3XV3jre xdANcl5SXerF0XxLLdxagDFypgcMwIJrpNyR9OmgBqcQSNbnSv+3S+yLXDK5L6hf9hsgZFkq yvzhdV7iGjd7C/6xfUkDHoDMgueQs/RroPseteFwhSbbeGDjS0nGfA2AEjuTrsLNgjHJ+KYC MQA25XqMBaCYZ5/e7xs46aL9+uwaOJsN9pY/54Wgp463AAAAAAAA --------------ms050300030507070809030405-- From nobody Fri Jul 7 07:25:06 2017 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 A47AA131533 for ; Fri, 7 Jul 2017 07:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX7_dUePGOBe for ; Fri, 7 Jul 2017 07:25:03 -0700 (PDT) Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C195B12EC23 for ; Fri, 7 Jul 2017 07:25:03 -0700 (PDT) Received: by mail-it0-f47.google.com with SMTP id m84so37414913ita.0 for ; Fri, 07 Jul 2017 07:25:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HSofTAq9nOGpvbP97hITeEI1/b+PdOHHrkYneRAqGWQ=; b=gICpToeHfdzgLfSJkFm/ohjDlC1m/EsddE8sTppwybqo3vuId3cKtxFTiHBPp60h9v Is9DpmmU/BNrR5HMDTaHXIw3sW9f2RFiNn0uEVTh2oS3rlLS/Wlc6uECnopCiX/uoszT 4D/9CRObKH1HFmWANxx+l5QZwqHFdv6zungVR39kav8MLz2F+FGT8RfYJmDbNwE5SREK 42uPTPd4r8Tb73yfaJq0PLFhL+aiNcdX0mueUPyYOcE5Ff9WjbCwnoy5uEZVOkUdiKr/ /2dqyaXcy7tdbgvK10OzRt39uIh+aMKlJeq2TLrTYjhd0uK1jCmpl8akxcS7asvqwPrH lA6w== X-Gm-Message-State: AIVw111u2siiWvdAp2oyZR97JJ7iCvctkW//jxdlSFIRahlpLvhSLtFu fqLOeEK8BAdU/+u2nblC9xhn4/fVn7t9zeg= X-Received: by 10.36.254.199 with SMTP id w190mr3482449ith.108.1499437502933; Fri, 07 Jul 2017 07:25:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.132.88 with HTTP; Fri, 7 Jul 2017 07:25:02 -0700 (PDT) In-Reply-To: References: From: Nathaniel McCallum Date: Fri, 7 Jul 2017 10:25:02 -0400 Message-ID: To: Vladimir Dzhuvinov Cc: jose@ietf.org, Nikos Mavrogiannopoulos , Daiki Ueno , "Sorce, Simo" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 14:25:06 -0000 Yes. Thank you for correcting my oversight! On Fri, Jul 7, 2017 at 10:23 AM, Vladimir Dzhuvinov wrote: > Regarding section 4 of the proposed -01 spec: > > When dealing with "oct" JWKs, shouldn't the PKCS#11 URI type parameter > become "secret-key"? > > Vladimir > > > On 05/07/17 21:01, Nathaniel McCallum wrote: >> I have updated the draft from the comments everyone has provided. >> However, document uploads are currently locked due to the IETF >> meeting, so I have attached the document here. Your feedback is >> greatly appreciated. >> >> On Fri, Jun 30, 2017 at 5:33 PM, Nathaniel McCallum >> wrote: >>> I have prepared an initial stab at a draft for offloading JWK private >>> key data to PKCS #11. >>> >>> You can find the document here: >>> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt >>> >>> Thanks for your consideration! > > From nobody Sat Jul 8 21:48:31 2017 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 3A0E9126B71 for ; Sat, 8 Jul 2017 21:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3lyTSr-aqXI for ; Sat, 8 Jul 2017 21:48:28 -0700 (PDT) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087BA124D37 for ; Sat, 8 Jul 2017 21:48:27 -0700 (PDT) Received: by mail-wr0-x242.google.com with SMTP id k67so16891305wrc.1 for ; Sat, 08 Jul 2017 21:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=S2qz6CimD6X/ARw/DJ8SZIenUw0diwpqolTUQNbcTBo=; b=DfTZKrQ9WWu//9rx7YcwDPYpgZlCQWnYqpxUFh5EKRyyYIUbHaD4GU/i+5Xg6TJbNH NumGHGpLZFR+GQuy6m9qQCExC4iGj2IVSFWqCwfR1n5NxiV+wZkunORGoBsbDnEuTeaQ sngVnBKpQjVHpzZavNWmjn97+QiweVgh/vojYjZofrUQDr/nn+jfIrx/ocfzfVXT+KOM lvbF5xMfMdP2QH2M9aMrcDk5S10/xDO3N4WBgb7O/PNNi28M8yN0JTqS+PkfrzjooqFo FZvqyzXvxgsnJuMZPWvQ32tDuAPWS1fM+sfHnp9QfITvi+bwj6p3jpjk5XwRHJD9jgZT COkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=S2qz6CimD6X/ARw/DJ8SZIenUw0diwpqolTUQNbcTBo=; b=jo7H6m/fn4cmB4gZWCXVL5r2kDWwjt0iSoFatFZLANPqAznAikoKekY7D8Pq7QiYLi k4SwCxbUICRY7mVLikNKif+dtPbq2ZNBROfndTrURh4mcK/XBawNEzPrbUMB0rqZn+lM qQN5ijMyOCE14TGOUFIuhcYNakYNJh29p+o1Zp2CzMULUodkucWOS7i0S1aQIu5o69Sk p7m+DQjV07ZqEomRneGD+mkQ/jye0c4K+ljoIa8P4+lWAhbK+Gt0HyMbZUtyTmHzJ/IG O8wc4fznz3WtbPXjs+edcTAFqglHUXz5ADoywN1A+MaSHk3bcqoWza9t7qJ6PfrSV5bY n4/A== X-Gm-Message-State: AIVw110viHqFMXTt5eZTpa5qVKeO0BDCMEKxYQVbiOYm6xJRkOkSozYz jRBpjTWxHRETkZfc X-Received: by 10.28.133.76 with SMTP id h73mr3563622wmd.92.1499575705911; Sat, 08 Jul 2017 21:48:25 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id b94sm6046809wrd.40.2017.07.08.21.48.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jul 2017 21:48:25 -0700 (PDT) References: To: "jose@ietf.org" From: Anders Rundgren X-Forwarded-Message-Id: Message-ID: <24f14cb1-3117-0eaa-4447-6f26581595d6@gmail.com> Date: Sun, 9 Jul 2017 06:48:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [jose] JSON Signatures in OpenBanking (UK) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jul 2017 04:48:30 -0000 Since the market for clear text JSON signatures is sort of heating up, the following may be of some interest... Here is a (probably biased), extremely condensed comparison of the three JSON signature schemes, all having one thing in common which was NOT the priority of the IETF JOSE WG, namely preserving the JSON text "as is" (=human readable). The OpenBanking signature scheme is quite straightforward but also have huge limitations since messages are tied to HTTP making the concept incompatible with JavaScript/Browsers, WebSockets, Message Embedding as well as with Serialization in databases. LDS (Linked Data Signatures) and JCS both claim adherence to JOSE standards but achieves that through entirely different methods: - LDS use (a subset of) the JWS detached signature format but put all information regarding the signature key outside of the base64-encoded JWS container. - JCS do not use the JWS container since one of the goals was providing all information in clear, including algorithms, public keys, etc. JCS rather reuse (a subset of) the JWK container and the JWA signature algorithms. Since in-line signatures need some form of normalization in order to be interoperable, LDS utilizes a specific canonicalization algorithm while JCS only relies on JSON.stringify() as defined by ECMA. This difference has major implications for applications as well as tools. LDS primarily targets Linked Data, while JCS only targets plain-vanilla JSON/JavaScript. Anders On 2017-07-08 22:04, Kim Hamilton wrote: > > We're about to release a paper on this topic originating out of last Rebooting Web of Trust. Manu developed an approach reconciling LD signatures with JWS. The approach uses the unencoded payload option (also detached), enabled by RFC7797 (https://tools.ietf.org/html/rfc7797). > > The LD signature suite is called RSA Signature Suite 2017 (https://w3c-dvcg.github.io/lds-rsa2017/). > > The paper describing the approach and implementation is in draft form below, but will soon be released in final form > https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2017/blob/master/event-documents/group-abstracts/SignatureAlignmentAbstract.md > > -- Kim > > On Sat, Jul 8, 2017 at 4:25 AM Anders Rundgren > wrote: > > Maybe of interest to the Security Task Force: > https://www.openbanking.org.uk/read-write-apis/payment-initiation-api/v1-0-0/#basics-headers > > Apparently they use a signature based on a detached JWS supplied as a header parameter and where the data to be signed is simply the HTTP body "as is". > > So at this stage we have not less than three entirely different ways of dealing with signed JSON: > > - OpenBanking(UK) as described above > > - The Linked Data Signature scheme (initially) created by Digitalbazaar and adopted by the Verified Credentials CG: https://github.com/w3c-dvcg/ld-signatures > > - My JSON Cleartext Signature scheme: https://cyberphone.github.io/doc/security/jcs.html > > Anders > From nobody Sun Jul 9 23:03:05 2017 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 5D0C6120454 for ; Sun, 9 Jul 2017 23:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCjCDYS8oaCX for ; Sun, 9 Jul 2017 23:03:01 -0700 (PDT) Received: from mail-wr0-f177.google.com (mail-wr0-f177.google.com [209.85.128.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807E11200B9 for ; Sun, 9 Jul 2017 23:03:01 -0700 (PDT) Received: by mail-wr0-f177.google.com with SMTP id k67so122959901wrc.2 for ; Sun, 09 Jul 2017 23:03:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=/1/hR2wuD2kd5A/vl72DeLM1c9odQ1dmWmL5wgdxutA=; b=HLWXSku+EBpQkfjubx8DM1UI3fB5oJjYwX94z4gric7B97C0x0oYRxiIxpJxXPp5Y2 RagOb1aJaGiYjcsXbNC6Y8ZDXMEwn08OkkVJzdqXv62m/oHpwFpELy9zBNfPnbAZqjg1 yZuCYlvlQ71zO8WvVQSoGXYBnFPqNOw2TScPqDwxoydsl5IBt1U7rOX02OZUF6igntR0 A0Cd12fMRRWEDy5/HIVh8wisIXWTyN4gMBCE+E17WM875OUwO02xyFbdq1mOmREjH6aq oh+Vp76227jM5RuxGSPaK1FgKOMwsgoOMBOWPEK3rRDowTYAeF5DuF3JzkjKSQbCecQs Pvdg== X-Gm-Message-State: AIVw112G1By0999h2NJAY8Ue3ndpV4lvUVYZQuLANEqcLhWcNaM4BUty 3B2edzR0kvSrTrApf2gBpw== X-Received: by 10.223.142.202 with SMTP id q68mr5860878wrb.13.1499666579504; Sun, 09 Jul 2017 23:02:59 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id v2sm15026494wrb.68.2017.07.09.23.02.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 09 Jul 2017 23:02:58 -0700 (PDT) Message-ID: <1499666578.2933.3.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Nathaniel McCallum , Simo Sorce Cc: jose@ietf.org, Daiki Ueno Date: Mon, 10 Jul 2017 08:02:58 +0200 In-Reply-To: References: <1498896051.11334.78.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [jose] PKCS #11 for JWK X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 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 Jul 2017 06:03:03 -0000 On Wed, 2017-07-05 at 09:04 -0400, Nathaniel McCallum wrote: > On Sat, Jul 1, 2017 at 4:00 AM, Simo Sorce wrote: > > Later on you talk about performance penalty and say: > > > >    Implementations SHOULD perform public > >    key operations, such as asymmetric signature verification or > >    asymmetric encryption, without using PKCS #11 > > > > I think this should be at most a MAY. If I wanted to be more > > pedantic I > > would say you should take in consideration there may be PKCS#11 > > modules > > that are already smart enough to implement such functions in > > software > > so that they do not incur in performance penalties, so the whole > > this > > would have to be wrapped in something like: > >  "If the PKCS#11 implementation perform public key operation in > > hardare > > that may result in poor performance then implementations MAY > > perfrom > > public ..." > > I did some reflection on this over the long weekend. If we wanted to > support offloading public key operations to PKCS #11, we'd need to > have a "p11pub" JWK property which defines the URI to the public key > to perform the operation on. This duplicates the existing public key > information in the JWK. > > We could allow three modes: > 1. pubkey-only; no PKCS #11 > 2. URI-only; PKCS #11 > 3. both; optional PKCS #11 > > In mode #3, there is a possibility for public key mismatch. However, > no attacks exist which don't also exist for mode #1. > > My worry is that this is a lot of complexity for minimal gain. JOSE > implementations already have to support #1. At best, mode #2 is going > to be as fast as #1. I just don't see any compelling reason to > support public key URIs. Do you? As long as you have the tooling to extract that public key/cert from the HSM, I can think of no reason using the HSM for public key operations. regards, Nikos From nobody Thu Jul 27 11:50:32 2017 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 733F41320D8 for ; Thu, 27 Jul 2017 11:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDoB7GU8BCSt for ; Thu, 27 Jul 2017 11:50:28 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3A51320CD for ; Thu, 27 Jul 2017 11:50:28 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id z129so47293316pfb.3 for ; Thu, 27 Jul 2017 11:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=AGV8lNuZMlSJvBhNn1opB4HDTBLBuGCi0M1VXnxMv48=; b=Pizl4/Q8s57Q0QQSjWypPCivU2zAoYXlyCeSDJuNOa6iJOptGBJIzQLo5n0FS/uJBR BxRZ7eRU3xmZa92W4Kc1OceD48h/Ugg7f2pWrazrj+y6F6VFku5o/yt2VIaXuCN+ZF0C cRcu4xZbwMTyjbSTbzR42OE6hlpgHF9F2tGmY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AGV8lNuZMlSJvBhNn1opB4HDTBLBuGCi0M1VXnxMv48=; b=Sz0FKeLDFWhpnXKFtbGAuWhFq5O+wBhSHyJNTtypUl+qdF8TKr9HsiUY9GyE2WIE5X MMG6TqwYEjzKIu3FHssGy65jSLI6OMb46iGTe4pn3nLjXlXh/VzJ6+9OxK16qHsYLxvd Vi72XHhubjdpQoc62G7MPuBNDMblk3RokOVmG3wAztO1W5m2xQJDiAWlI8ufZub46rHx DnnGgShn6nqjNZ7t+TVoX7FMymPEgs7iKdaE00UU7LcsPzzMdVTg6642Wh10c7jxLkQx ek5cUC3h8JmPj9qqYxwb+L8pl1v8bZhgj/JgwTT0MInGueyi9C828V2dKcAlRGoikfm7 Sfqw== X-Gm-Message-State: AIVw111xhBbeHL2fezmkRp+2wIX+jvtm7T9pE2cl5QanPy+09ILyLdUu qYaFnaFJ1aofQXjTKsMzCv/nS/hGWW/V6q+EyE5YCf5zs/HOD8hNKCeiwv8Qlb4jesxgu24DlPE KAFRPvA== X-Received: by 10.84.232.143 with SMTP id i15mr5409741plk.248.1501181427707; Thu, 27 Jul 2017 11:50:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Thu, 27 Jul 2017 11:49:57 -0700 (PDT) From: Brian Campbell Date: Thu, 27 Jul 2017 12:49:57 -0600 Message-ID: To: oauth , "jose@ietf.org" Content-Type: multipart/alternative; boundary="f40304361ef4be0b9d05555109bf" Archived-At: Subject: [jose] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 18:50:30 -0000 --f40304361ef4be0b9d05555109bf Content-Type: text/plain; charset="UTF-8" During the first WG meeting last week I asked if use of the JOSE "crit" (Critical) Header Parameter had been considered as a recommendation for preventing confusion of one kind of JWT for another. Time was running short in the meeting so there wasn't much discussion and it was requested that I take the question to the list. And so here on the list is that. Section 3.9 of the JWT BCP draft now recommends explicit typing using the "typ" JWS/JWE header parameter but does concede that 'the use of explicit typing may not achieve disambiguation from existing kinds of JWTs, as the validation rules for existing kinds JWTs often do not use the "typ" header parameter value.' And the recommendations for how to use the Type Header Parameter in JWT strongly suggest that it's not currently being used for any validation. Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to signal the type/intent/profile/application of a JWT could achieve disambiguation even in validation of existing kinds of JWTs. The critical header lists other headers which must be understood and processed by the receiver and that the JWS/JWE is invalid if those listed aren't understood. So a new type/profile of JWT that uses the "crit" header would produce JWTs that would be rejected even by existing applications of JWT validation (that actually implement "crit" properly anyway). The JWT BCP could suggest the use of "crit" in conjunction with a profile/application/type specific header. Or it could provide a bit more of a framework like defining a registering a new JOSE header "p" (strawman of p as a very short name for profile) and create a registry for its values. A JWT header using that approach might look like the following where the value 1 is registered as some cool new JWT profile/application. The consumer of such a JWT would have to understand and process the "p" header, which would mean checking that it had the value expected. { "alg":"ES256", "crit":["p"], "p":1 } A JOSE compliant JWT validator would reject such a JWT even for an OAuth access token or OIDC id_token because the "p" header isn't known or understood but is marked as critical. To me, that seems like an approach to preventing confusion that has more teeth than the "typ" header. Which is why I asked about it last week and am now bringing it to the list. -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --f40304361ef4be0b9d05555109bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
During the first WG meeting last week I a= sked if use of the JOSE "crit" (Critical) Header Parameter had be= en considered as a recommendation for preventing confusion of one kind of J= WT for another. Time was running short in the meeting so there wasn't m= uch discussion and it was requested that I take the question to the list. A= nd so here on the list is that.

Section 3.9 of th= e JWT BCP draft now recommends explicit typing using the "typ" JW= S/JWE header parameter but does concede that 'the use of explicit typin= g may not achieve disambiguation from existing kinds of JWTs, as the valida= tion rules for existing kinds JWTs often do not use the "typ" hea= der parameter value.'=C2=A0 And the recommendations for how to use the = Type Header Par= ameter in JWT strongly suggest that it's not currently being used f= or any validation.

Alternatively using the JWS/JWE "crit" (Crit= ical) Header Parameter to signal the type/intent/profile/application of= a JWT could achieve disambiguation even in validation of existing kinds of= JWTs. The critical header lists other headers which must be understood and= processed by the receiver and that the JWS/JWE is invalid if those listed = aren't understood. So a new type/profile of JWT that uses the "cri= t" header would produce JWTs that would be rejected even by existing a= pplications of JWT validation (that actually implement "crit" pro= perly anyway).

The JWT BCP could suggest the use of "crit= " in conjunction with a profile/application/type specific header. Or i= t could provide a bit more of a framework like defining a registering a new= JOSE header "p" (strawman of p as a very short name for profile)= and create a registry for its values. A JWT header using that approach mig= ht look like the following where the value 1 is registered as some cool new= JWT profile/application. The consumer of such a JWT would have to understa= nd and process the "p" header, which would mean checking that it = had the value expected.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "alg":"ES256",
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "crit":["p"],
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 "p":1
=C2=A0=C2=A0=C2=A0=C2=A0 }

A J= OSE compliant JWT validator would reject such a JWT even for an OAuth acces= s token or OIDC id_token because the "p" header isn't known o= r understood but is marked as critical.

To me, that seems lik= e an approach to preventing confusion that has more teeth than the "ty= p" header. Which is why I asked about it last week and am now bringing= it to the list.









<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f40304361ef4be0b9d05555109bf-- From nobody Thu Jul 27 12:31:06 2017 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 05AC8132184 for ; Thu, 27 Jul 2017 12:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWH-TPx7xEWk for ; Thu, 27 Jul 2017 12:30:58 -0700 (PDT) Received: from mail-it0-f51.google.com (mail-it0-f51.google.com [209.85.214.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15BD129562 for ; Thu, 27 Jul 2017 12:30:57 -0700 (PDT) Received: by mail-it0-f51.google.com with SMTP id h199so87600327ith.0 for ; Thu, 27 Jul 2017 12:30:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cxqnsmY86lDsmVHlQ4LcmGoFHKwPin2R2bfMlQxKjVE=; b=q7/BSUxd611dR/pdHmRBt25gfnpE+VObB99RKhkUXP2IWTlgssNCvBWVc8h40N95yY +9dqABqaTOiRdrHBUFyOLXyNLRESvaw6SDT9FiGVgSOagb3DWj2ow9BoNvYmQpQj7luC mzhgUUL3HfU8lrcHf1+Xgvzy7hLhfC1lFeBrAJtTmIvBhpEDmYNqlas0VETwh1aRbtnK VsEhAC1Z1ez7ERcpQcRkkQcp8Xm3Lu3cgza6GAO+o0kFVxXZx7g7CLcbCUBOcdf0j83W RygGau4Q8kwi1gGaQ/C+LvfQ1zgUAAKfvmfENBi8FCtPr34yEZ9GmoF1HA5vOapihKhf rRRA== X-Gm-Message-State: AIVw111tHH+afK8r3y9WEH5jEOqkuY6c0EJ8k1yupusHhmEgFiSwKHvN dSQVMBa2Vk9678yZH3a4niSz+5rKka+a X-Received: by 10.36.185.14 with SMTP id w14mr6557593ite.76.1501183857107; Thu, 27 Jul 2017 12:30:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.6 with HTTP; Thu, 27 Jul 2017 12:30:56 -0700 (PDT) In-Reply-To: References: From: Nathaniel McCallum Date: Thu, 27 Jul 2017 15:30:56 -0400 Message-ID: To: Brian Campbell Cc: oauth , "jose@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [jose] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 19:31:00 -0000 What class of attacks is this trying to prevent? I frankly don't see a problem with confusing different types of JWT. But I may just be ignorant. On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell wrote: > During the first WG meeting last week I asked if use of the JOSE "crit" > (Critical) Header Parameter had been considered as a recommendation for > preventing confusion of one kind of JWT for another. Time was running short > in the meeting so there wasn't much discussion and it was requested that I > take the question to the list. And so here on the list is that. > > Section 3.9 of the JWT BCP draft now recommends explicit typing using the > "typ" JWS/JWE header parameter but does concede that 'the use of explicit > typing may not achieve disambiguation from existing kinds of JWTs, as the > validation rules for existing kinds JWTs often do not use the "typ" header > parameter value.' And the recommendations for how to use the Type Header > Parameter in JWT strongly suggest that it's not currently being used for any > validation. > > Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to signal > the type/intent/profile/application of a JWT could achieve disambiguation > even in validation of existing kinds of JWTs. The critical header lists > other headers which must be understood and processed by the receiver and > that the JWS/JWE is invalid if those listed aren't understood. So a new > type/profile of JWT that uses the "crit" header would produce JWTs that > would be rejected even by existing applications of JWT validation (that > actually implement "crit" properly anyway). > > The JWT BCP could suggest the use of "crit" in conjunction with a > profile/application/type specific header. Or it could provide a bit more of > a framework like defining a registering a new JOSE header "p" (strawman of p > as a very short name for profile) and create a registry for its values. A > JWT header using that approach might look like the following where the value > 1 is registered as some cool new JWT profile/application. The consumer of > such a JWT would have to understand and process the "p" header, which would > mean checking that it had the value expected. > > { > "alg":"ES256", > "crit":["p"], > "p":1 > } > > A JOSE compliant JWT validator would reject such a JWT even for an OAuth > access token or OIDC id_token because the "p" header isn't known or > understood but is marked as critical. > > To me, that seems like an approach to preventing confusion that has more > teeth than the "typ" header. Which is why I asked about it last week and am > now bringing it to the list. > > > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From nobody Thu Jul 27 12:34:57 2017 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 5C370129B55 for ; Thu, 27 Jul 2017 12:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWceP1htQRMD for ; Thu, 27 Jul 2017 12:34:47 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164F81287A5 for ; Thu, 27 Jul 2017 12:34:47 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id y129so101734178pgy.4 for ; Thu, 27 Jul 2017 12:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lnhRzdoimbqhOwwyNhZHA9pWM1yyLBI7aSS1N48vdoY=; b=SelcqJ/rTLxB02yXyhD8ixVLZeuY+kwHNwzU0wSAadpRotn1sPizESw4vv8SexVW1P Lced2VBHl6C26O2UjO7UpI8WfPSPOy/KYRmUCGOkprq5mViwJJ4BAtodOKIBfVCqVZFY THRQm9L65GUIWQbhrENEZJk5jeWyWABD/iwJo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lnhRzdoimbqhOwwyNhZHA9pWM1yyLBI7aSS1N48vdoY=; b=d5sDEvdAL++KxJByNiZ2DBhEBghPUxLkjhK61hpofQDDSyUeJhNICInNZeU/J4jW7x mdQIRG6Mpo6hV/keQehpcFXPGpzONYF3OLsSG5Ks3mknS72n/5KjGtEb7Udlwra+QFRm dVXHI0A+p+fmW1DKX93AEZhkmHK2N8sz1oYqHZCVOFSZo3H0VERJd7LNFhiaSO5lUn4f cEPgnJBK1oGpZHgfJg3Vj2LUpG8rD19zkQPhi05sNClO88hXpa8nMJTsYFIWxgCf9HSu o9/dbcUWDCp67OX8Tu6gVttPZk7G7EwZkqk8fyDQd5uazNRrkxgn06QJTwAJ+zccn+MC CNxA== X-Gm-Message-State: AIVw110ujYrtYlNjFY+pm8v4e3qiFJBzEHnMFuWBrCNKTL8NEngX8Ud8 yV0HTIWiPvQPL6nkT4WtTXlRzFt2vDU6HlRJDvkhbJH7k7LgsD14vOlrOryayxqjWTFaFLpu3w+ LM3I= X-Received: by 10.84.212.1 with SMTP id d1mr5579071pli.17.1501184086633; Thu, 27 Jul 2017 12:34:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Thu, 27 Jul 2017 12:34:16 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 27 Jul 2017 13:34:16 -0600 Message-ID: To: Nathaniel McCallum Cc: oauth , "jose@ietf.org" Content-Type: multipart/alternative; boundary="f403045d1f5e3a0e49055551a86e" Archived-At: Subject: Re: [jose] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 19:34:50 -0000 --f403045d1f5e3a0e49055551a86e Content-Type: text/plain; charset="UTF-8" The draft describes it in https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#section-2.7 On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum wrote: > What class of attacks is this trying to prevent? I frankly don't see a > problem with confusing different types of JWT. But I may just be > ignorant. > > On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell > wrote: > > During the first WG meeting last week I asked if use of the JOSE "crit" > > (Critical) Header Parameter had been considered as a recommendation for > > preventing confusion of one kind of JWT for another. Time was running > short > > in the meeting so there wasn't much discussion and it was requested that > I > > take the question to the list. And so here on the list is that. > > > > Section 3.9 of the JWT BCP draft now recommends explicit typing using the > > "typ" JWS/JWE header parameter but does concede that 'the use of explicit > > typing may not achieve disambiguation from existing kinds of JWTs, as the > > validation rules for existing kinds JWTs often do not use the "typ" > header > > parameter value.' And the recommendations for how to use the Type Header > > Parameter in JWT strongly suggest that it's not currently being used for > any > > validation. > > > > Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to > signal > > the type/intent/profile/application of a JWT could achieve > disambiguation > > even in validation of existing kinds of JWTs. The critical header lists > > other headers which must be understood and processed by the receiver and > > that the JWS/JWE is invalid if those listed aren't understood. So a new > > type/profile of JWT that uses the "crit" header would produce JWTs that > > would be rejected even by existing applications of JWT validation (that > > actually implement "crit" properly anyway). > > > > The JWT BCP could suggest the use of "crit" in conjunction with a > > profile/application/type specific header. Or it could provide a bit more > of > > a framework like defining a registering a new JOSE header "p" (strawman > of p > > as a very short name for profile) and create a registry for its values. A > > JWT header using that approach might look like the following where the > value > > 1 is registered as some cool new JWT profile/application. The consumer of > > such a JWT would have to understand and process the "p" header, which > would > > mean checking that it had the value expected. > > > > { > > "alg":"ES256", > > "crit":["p"], > > "p":1 > > } > > > > A JOSE compliant JWT validator would reject such a JWT even for an OAuth > > access token or OIDC id_token because the "p" header isn't known or > > understood but is marked as critical. > > > > To me, that seems like an approach to preventing confusion that has more > > teeth than the "typ" header. Which is why I asked about it last week and > am > > now bringing it to the list. > > > > > > > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > > material for the sole use of the intended recipient(s). Any review, use, > > distribution or disclosure by others is strictly prohibited. If you have > > received this communication in error, please notify the sender > immediately > > by e-mail and delete the message and any file attachments from your > > computer. Thank you. > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --f403045d1f5e3a0e49055551a86e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Jul 27, 2017 at 1:30 PM= , Nathaniel McCallum <npmccallum@redhat.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">What class of attacks is this trying to preve= nt? I frankly don't see a
problem with confusing different types of JWT. But I may just be
ignorant.

On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
<bcampbell@pingidentity.co= m> wrote:
> During the first WG meeting last week I asked if use of the JOSE "= ;crit"
> (Critical) Header Parameter had been considered as a recommendation fo= r
> preventing confusion of one kind of JWT for another. Time was running = short
> in the meeting so there wasn't much discussion and it was requeste= d that I
> take the question to the list. And so here on the list is that.
>
> Section 3.9 of the JWT BCP draft now recommends explicit typing using = the
> "typ" JWS/JWE header parameter but does concede that 'th= e use of explicit
> typing may not achieve disambiguation from existing kinds of JWTs, as = the
> validation rules for existing kinds JWTs often do not use the "ty= p" header
> parameter value.'=C2=A0 And the recommendations for how to use the= Type Header
> Parameter in JWT strongly suggest that it's not currently being us= ed for any
> validation.
>
> Alternatively using the JWS/JWE "crit" (Critical) Header Par= ameter to signal
> the type/intent/profile/application of a JWT could achieve disamb= iguation
> even in validation of existing kinds of JWTs. The critical header list= s
> other headers which must be understood and processed by the receiver a= nd
> that the JWS/JWE is invalid if those listed aren't understood. So = a new
> type/profile of JWT that uses the "crit" header would produc= e JWTs that
> would be rejected even by existing applications of JWT validation (tha= t
> actually implement "crit" properly anyway).
>
> The JWT BCP could suggest the use of "crit" in conjunction w= ith a
> profile/application/type specific header. Or it could provide a bit mo= re of
> a framework like defining a registering a new JOSE header "p"= ; (strawman of p
> as a very short name for profile) and create a registry for its values= . A
> JWT header using that approach might look like the following where the= value
> 1 is registered as some cool new JWT profile/application. The consumer= of
> such a JWT would have to understand and process the "p" head= er, which would
> mean checking that it had the value expected.
>
>=C2=A0 =C2=A0 =C2=A0 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"alg":"ES256",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"crit":["p"],
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"p":1
>=C2=A0 =C2=A0 =C2=A0 }
>
> A JOSE compliant JWT validator would reject such a JWT even for an OAu= th
> access token or OIDC id_token because the "p" header isn'= ;t known or
> understood but is marked as critical.
>
> To me, that seems like an approach to preventing confusion that has mo= re
> teeth than the "typ" header. Which is why I asked about it l= ast week and am
> now bringing it to the list.
>
>
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidentia= l and privileged
> material for the sole use of the intended recipient(s). Any review, us= e,
> distribution or disclosure by others is strictly prohibited.=C2=A0 If = you have
> received this communication in error, please notify the sender immedia= tely
> by e-mail and delete the message and any file attachments from your > computer. Thank you.
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose >


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f403045d1f5e3a0e49055551a86e-- From nobody Thu Jul 27 14:00:15 2017 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 6E9891321B1 for ; Thu, 27 Jul 2017 14:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONJkeyEvcVHJ for ; Thu, 27 Jul 2017 14:00:07 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF220129B10 for ; Thu, 27 Jul 2017 14:00:06 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id v127so3368181itd.0 for ; Thu, 27 Jul 2017 14:00:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XxgZ/BpiJRPSmPuIyBMEikiwlmKnTswyKvdgDeqRxmg=; b=U8N9+tkSkybuRc6QX2dQY7wmPbHnNyxXPC3gWXT5mo++2xR85FFeUbekovHpt1AV4/ 8uKvB32leCNqJ/KuaYtpzODLlQkZLfFOHuDJVyAhyKudox9bjayR7CVCuy5bCcxbSehY J6nGogaknGCYj9HLZNDLAe2JZRmVqhKVMPynolfS3flRQjZg9wznFfQTaIZXb9jnpbLz 4XiAtmgU9zAnwKar67+puyC+GQJObUtoQp8bqrCPtFJK4Sl1SpKH1/InODWiJMuf7ALJ ZB6pJUCG6835hpTb/TgW0cZXQmjv7ZpaD5TEcjf0gIdEJx/Bx5RFydnCnNc+r1ivIeoM QxzA== X-Gm-Message-State: AIVw113EQzwZ3wQfj/dCmq4g85/ukifNa7153q/N9WGOM+AboOjI8rSd 32oeF5ovmB082+4fFlMJi+eiwK3kbhQ4 X-Received: by 10.36.185.14 with SMTP id w14mr6837480ite.76.1501189206161; Thu, 27 Jul 2017 14:00:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.6 with HTTP; Thu, 27 Jul 2017 14:00:05 -0700 (PDT) In-Reply-To: References: From: Nathaniel McCallum Date: Thu, 27 Jul 2017 17:00:05 -0400 Message-ID: To: Brian Campbell Cc: oauth , "jose@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [jose] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 21:00:09 -0000 Even after reading the whole section, I still don't understand the problem. Yes, a class of attack could exist where an attacker substitutes a valid JWT from one security context into another context. But isn't this resolved by audience validation? On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell wrote: > The draft describes it in > https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#section-2.7 > > On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum > wrote: >> >> What class of attacks is this trying to prevent? I frankly don't see a >> problem with confusing different types of JWT. But I may just be >> ignorant. >> >> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell >> wrote: >> > During the first WG meeting last week I asked if use of the JOSE "crit" >> > (Critical) Header Parameter had been considered as a recommendation for >> > preventing confusion of one kind of JWT for another. Time was running >> > short >> > in the meeting so there wasn't much discussion and it was requested that >> > I >> > take the question to the list. And so here on the list is that. >> > >> > Section 3.9 of the JWT BCP draft now recommends explicit typing using >> > the >> > "typ" JWS/JWE header parameter but does concede that 'the use of >> > explicit >> > typing may not achieve disambiguation from existing kinds of JWTs, as >> > the >> > validation rules for existing kinds JWTs often do not use the "typ" >> > header >> > parameter value.' And the recommendations for how to use the Type >> > Header >> > Parameter in JWT strongly suggest that it's not currently being used for >> > any >> > validation. >> > >> > Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to >> > signal >> > the type/intent/profile/application of a JWT could achieve >> > disambiguation >> > even in validation of existing kinds of JWTs. The critical header lists >> > other headers which must be understood and processed by the receiver and >> > that the JWS/JWE is invalid if those listed aren't understood. So a new >> > type/profile of JWT that uses the "crit" header would produce JWTs that >> > would be rejected even by existing applications of JWT validation (that >> > actually implement "crit" properly anyway). >> > >> > The JWT BCP could suggest the use of "crit" in conjunction with a >> > profile/application/type specific header. Or it could provide a bit more >> > of >> > a framework like defining a registering a new JOSE header "p" (strawman >> > of p >> > as a very short name for profile) and create a registry for its values. >> > A >> > JWT header using that approach might look like the following where the >> > value >> > 1 is registered as some cool new JWT profile/application. The consumer >> > of >> > such a JWT would have to understand and process the "p" header, which >> > would >> > mean checking that it had the value expected. >> > >> > { >> > "alg":"ES256", >> > "crit":["p"], >> > "p":1 >> > } >> > >> > A JOSE compliant JWT validator would reject such a JWT even for an OAuth >> > access token or OIDC id_token because the "p" header isn't known or >> > understood but is marked as critical. >> > >> > To me, that seems like an approach to preventing confusion that has more >> > teeth than the "typ" header. Which is why I asked about it last week and >> > am >> > now bringing it to the list. >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and >> > privileged >> > material for the sole use of the intended recipient(s). Any review, use, >> > distribution or disclosure by others is strictly prohibited. If you >> > have >> > received this communication in error, please notify the sender >> > immediately >> > by e-mail and delete the message and any file attachments from your >> > computer. Thank you. >> > _______________________________________________ >> > jose mailing list >> > jose@ietf.org >> > https://www.ietf.org/mailman/listinfo/jose >> > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. From nobody Thu Jul 27 14:18:00 2017 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 AE402131761; Thu, 27 Jul 2017 14:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H8r98A1ZnkI; Thu, 27 Jul 2017 14:17:49 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE3C131563; Thu, 27 Jul 2017 14:17:48 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id d136so113996717qkg.3; Thu, 27 Jul 2017 14:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tIaTRg+C0wRkbJieUt6+8XLmpSZ0zuWe1rm8LIj9dOg=; b=YUh0/Sbs/PO/kjA1eaoQm7tUnJLTN3No2dRiAIZv2RwbS3NfJNtzGPFOhqmPBBRNJH ujjHfZH6iBV87QVHM+HzPUKR0UVDomY+J1d3C7vPsRFLU/LYjgPB6Q/67RJANk5funrQ s2Mbd0VUAlix4RKefe5JcVSrqdARqLCzhcda9IDxD8jYLNDq3UL01o4VrXqVyZ+5tKKf DM4qsFOVm1mQ3ppwK9jzefT8/dwy8hUqJlVXL89cZCyzFaqTcPCzsbYHuuz5rCdYx51u rI6tLwekk6uI55r4Vc2EowOrv/qeeaBpRoh9j96T38wLqymzb9pJB6Ff4zcRS/0mWW0D T8wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tIaTRg+C0wRkbJieUt6+8XLmpSZ0zuWe1rm8LIj9dOg=; b=Tc2RNUuXgpZ+ImtGqqMmyk+CFM+99pLOa4BXKr3NXmXQlAbL8hGIuthbn3k5+iibYH i3R5m6juv9eC+hSnofKGfLBJ5IFOygX7GPFwktwVSM/K9nKQSPkS05nBOWb+NogzGucu 96/wqTHyXZWsqHZCdT6BD3HE1dJQ1BqWnqbn6ram6QD52/Z14qAH47E008PNmdQM4L2L +mLYgaYTmiYhKGCS5hXsDjqsPb9p6UNCZ2CWhanV7IijvTL4i70bvqgshUcXM9/rsc/5 qPwYrYd3Jr9TMRqDzkfX/ul+YKpheS5+gWWNQ3r50oYqYg8kTaLQY0tibS4eEsJhW57t dwxQ== X-Gm-Message-State: AIVw112AY77cZWoJboJFCrcmbFuFF4rOP4EAU73tM5Fe0RRj2SavCYoU uuOgx2sjUisUEZV3blXyOp4m1oRpCQ== X-Received: by 10.55.124.67 with SMTP id x64mr7710969qkc.98.1501190267828; Thu, 27 Jul 2017 14:17:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.131 with HTTP; Thu, 27 Jul 2017 14:17:27 -0700 (PDT) In-Reply-To: References: From: Dick Hardt Date: Thu, 27 Jul 2017 22:17:27 +0100 Message-ID: To: Nathaniel McCallum Cc: Brian Campbell , oauth , "jose@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c062748a7852e0555531832" Archived-At: Subject: Re: [jose] [OAUTH-WG] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 21:17:51 -0000 --94eb2c062748a7852e0555531832 Content-Type: text/plain; charset="UTF-8" Only if the audience is different. On Thu, Jul 27, 2017 at 10:00 PM, Nathaniel McCallum wrote: > Even after reading the whole section, I still don't understand the > problem. Yes, a class of attack could exist where an attacker > substitutes a valid JWT from one security context into another > context. But isn't this resolved by audience validation? > > On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell > wrote: > > The draft describes it in > > https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#section-2.7 > > > > On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum < > npmccallum@redhat.com> > > wrote: > >> > >> What class of attacks is this trying to prevent? I frankly don't see a > >> problem with confusing different types of JWT. But I may just be > >> ignorant. > >> > >> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell > >> wrote: > >> > During the first WG meeting last week I asked if use of the JOSE > "crit" > >> > (Critical) Header Parameter had been considered as a recommendation > for > >> > preventing confusion of one kind of JWT for another. Time was running > >> > short > >> > in the meeting so there wasn't much discussion and it was requested > that > >> > I > >> > take the question to the list. And so here on the list is that. > >> > > >> > Section 3.9 of the JWT BCP draft now recommends explicit typing using > >> > the > >> > "typ" JWS/JWE header parameter but does concede that 'the use of > >> > explicit > >> > typing may not achieve disambiguation from existing kinds of JWTs, as > >> > the > >> > validation rules for existing kinds JWTs often do not use the "typ" > >> > header > >> > parameter value.' And the recommendations for how to use the Type > >> > Header > >> > Parameter in JWT strongly suggest that it's not currently being used > for > >> > any > >> > validation. > >> > > >> > Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to > >> > signal > >> > the type/intent/profile/application of a JWT could achieve > >> > disambiguation > >> > even in validation of existing kinds of JWTs. The critical header > lists > >> > other headers which must be understood and processed by the receiver > and > >> > that the JWS/JWE is invalid if those listed aren't understood. So a > new > >> > type/profile of JWT that uses the "crit" header would produce JWTs > that > >> > would be rejected even by existing applications of JWT validation > (that > >> > actually implement "crit" properly anyway). > >> > > >> > The JWT BCP could suggest the use of "crit" in conjunction with a > >> > profile/application/type specific header. Or it could provide a bit > more > >> > of > >> > a framework like defining a registering a new JOSE header "p" > (strawman > >> > of p > >> > as a very short name for profile) and create a registry for its > values. > >> > A > >> > JWT header using that approach might look like the following where the > >> > value > >> > 1 is registered as some cool new JWT profile/application. The consumer > >> > of > >> > such a JWT would have to understand and process the "p" header, which > >> > would > >> > mean checking that it had the value expected. > >> > > >> > { > >> > "alg":"ES256", > >> > "crit":["p"], > >> > "p":1 > >> > } > >> > > >> > A JOSE compliant JWT validator would reject such a JWT even for an > OAuth > >> > access token or OIDC id_token because the "p" header isn't known or > >> > understood but is marked as critical. > >> > > >> > To me, that seems like an approach to preventing confusion that has > more > >> > teeth than the "typ" header. Which is why I asked about it last week > and > >> > am > >> > now bringing it to the list. > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > CONFIDENTIALITY NOTICE: This email may contain confidential and > >> > privileged > >> > material for the sole use of the intended recipient(s). Any review, > use, > >> > distribution or disclosure by others is strictly prohibited. If you > >> > have > >> > received this communication in error, please notify the sender > >> > immediately > >> > by e-mail and delete the message and any file attachments from your > >> > computer. Thank you. > >> > _______________________________________________ > >> > jose mailing list > >> > jose@ietf.org > >> > https://www.ietf.org/mailman/listinfo/jose > >> > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > > material for the sole use of the intended recipient(s). Any review, use, > > distribution or disclosure by others is strictly prohibited. If you have > > received this communication in error, please notify the sender > immediately > > by e-mail and delete the message and any file attachments from your > > computer. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Subscribe to the HARDTWARE mail list to learn about projects I am working on! --94eb2c062748a7852e0555531832 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Only if the audience is different.=C2=A0

On Thu, Jul 27, 2017 at 10:= 00 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:=
Even after reading the whole section, I = still don't understand the
problem. Yes, a class of attack could exist where an attacker
substitutes a valid JWT from one security context into another
context. But isn't this resolved by audience validation?

On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
> The draft describes it in
> https://tools.ietf.org/ht= ml/draft-sheffer-oauth-jwt-bcp-01#section-2.7
>
> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <npmccallum@redhat.com>
> wrote:
>>
>> What class of attacks is this trying to prevent? I frankly don'= ;t see a
>> problem with confusing different types of JWT. But I may just be >> ignorant.
>>
>> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
>> <bcampbell@pingid= entity.com> wrote:
>> > During the first WG meeting last week I asked if use of the J= OSE "crit"
>> > (Critical) Header Parameter had been considered as a recommen= dation for
>> > preventing confusion of one kind of JWT for another. Time was= running
>> > short
>> > in the meeting so there wasn't much discussion and it was= requested that
>> > I
>> > take the question to the list. And so here on the list is tha= t.
>> >
>> > Section 3.9 of the JWT BCP draft now recommends explicit typi= ng using
>> > the
>> > "typ" JWS/JWE header parameter but does concede tha= t 'the use of
>> > explicit
>> > typing may not achieve disambiguation from existing kinds of = JWTs, as
>> > the
>> > validation rules for existing kinds JWTs often do not use the= "typ"
>> > header
>> > parameter value.'=C2=A0 And the recommendations for how t= o use the Type
>> > Header
>> > Parameter in JWT strongly suggest that it's not currently= being used for
>> > any
>> > validation.
>> >
>> > Alternatively using the JWS/JWE "crit" (Critical) H= eader Parameter to
>> > signal
>> > the type/intent/profile/application of a JWT could achie= ve
>> > disambiguation
>> > even in validation of existing kinds of JWTs. The critical he= ader lists
>> > other headers which must be understood and processed by the r= eceiver and
>> > that the JWS/JWE is invalid if those listed aren't unders= tood. So a new
>> > type/profile of JWT that uses the "crit" header wou= ld produce JWTs that
>> > would be rejected even by existing applications of JWT valida= tion (that
>> > actually implement "crit" properly anyway).
>> >
>> > The JWT BCP could suggest the use of "crit" in conj= unction with a
>> > profile/application/type specific header. Or it could provide= a bit more
>> > of
>> > a framework like defining a registering a new JOSE header &qu= ot;p" (strawman
>> > of p
>> > as a very short name for profile) and create a registry for i= ts values.
>> > A
>> > JWT header using that approach might look like the following = where the
>> > value
>> > 1 is registered as some cool new JWT profile/application. The= consumer
>> > of
>> > such a JWT would have to understand and process the "p&q= uot; header, which
>> > would
>> > mean checking that it had the value expected.
>> >
>> >=C2=A0 =C2=A0 =C2=A0 {
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"alg":"ES256",<= br> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"crit":["p"], >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"p":1
>> >=C2=A0 =C2=A0 =C2=A0 }
>> >
>> > A JOSE compliant JWT validator would reject such a JWT even f= or an OAuth
>> > access token or OIDC id_token because the "p" heade= r isn't known or
>> > understood but is marked as critical.
>> >
>> > To me, that seems like an approach to preventing confusion th= at has more
>> > teeth than the "typ" header. Which is why I asked a= bout it last week and
>> > am
>> > now bringing it to the list.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > CONFIDENTIALITY NOTICE: This email may contain confidential a= nd
>> > privileged
>> > material for the sole use of the intended recipient(s). Any r= eview, use,
>> > distribution or disclosure by others is strictly prohibited.= =C2=A0 If you
>> > have
>> > received this communication in error, please notify the sende= r
>> > immediately
>> > by e-mail and delete the message and any file attachments fro= m your
>> > computer. Thank you.
>> > _______________________________________________
>> > jose mailing list
>> > jose@ietf.org
>> > https://www.ietf.org/mailman/listinfo/j= ose
>> >
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged
> material for the sole use of the intended recipient(s). Any review, us= e,
> distribution or disclosure by others is strictly prohibited.=C2=A0 If = you have
> received this communication in error, please notify the sender immedia= tely
> by e-mail and delete the message and any file attachments from your > computer. Thank you.

_______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
=
Subscribe to the HARDTWARE mail list to l= earn about projects I am working on!
--94eb2c062748a7852e0555531832-- From nobody Thu Jul 27 14:20:05 2017 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 67B7C131771; Thu, 27 Jul 2017 14:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtR8bQjO1m31; Thu, 27 Jul 2017 14:19:53 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92431131563; Thu, 27 Jul 2017 14:19:53 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6RLJpca029999 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Jul 2017 21:19:51 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6RLJpC1006758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Jul 2017 21:19:51 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6RLJokN002416; Thu, 27 Jul 2017 21:19:50 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Jul 2017 14:19:50 -0700 From: Phil Hunt Message-Id: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0396C5EF-FEE2-483C-BA89-2556CEBF7219" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 27 Jul 2017 14:19:48 -0700 In-Reply-To: Cc: Brian Campbell , oauth , "jose@ietf.org" To: Nathaniel McCallum References: X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [jose] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 21:19:56 -0000 --Apple-Mail=_0396C5EF-FEE2-483C-BA89-2556CEBF7219 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We have the use case in SECEVENTS where a logout event (e.g. OIDF = backchannel logout) is extremely close to an ID_TOKEN.=20 Older relying parties who are do not yet support logout could be tricked = into accepting a logout assertion as an ID_TOKEN since they are too = similar, and because a valid ID_TOKEN parser is in theory allowed to = ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) - = leading to a possible erroneous acceptance of the logout event AS and = ID_TOKEN. Because of this the issue of distinguishing classes or types of JWTs = emerged. We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, = =E2=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc that would help. But that = really lead to the idea there there should be some best practices in the = JWT BCP covering the issue(s). Phil Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum = wrote: >=20 > Even after reading the whole section, I still don't understand the > problem. Yes, a class of attack could exist where an attacker > substitutes a valid JWT from one security context into another > context. But isn't this resolved by audience validation? >=20 > On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell > wrote: >> The draft describes it in >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html= _draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=3DDwICAg&c=3DR= oP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEiv= zjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPC= ouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D=20 >>=20 >> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum = >> wrote: >>>=20 >>> What class of attacks is this trying to prevent? I frankly don't see = a >>> problem with confusing different types of JWT. But I may just be >>> ignorant. >>>=20 >>> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell >>> wrote: >>>> During the first WG meeting last week I asked if use of the JOSE = "crit" >>>> (Critical) Header Parameter had been considered as a recommendation = for >>>> preventing confusion of one kind of JWT for another. Time was = running >>>> short >>>> in the meeting so there wasn't much discussion and it was requested = that >>>> I >>>> take the question to the list. And so here on the list is that. >>>>=20 >>>> Section 3.9 of the JWT BCP draft now recommends explicit typing = using >>>> the >>>> "typ" JWS/JWE header parameter but does concede that 'the use of >>>> explicit >>>> typing may not achieve disambiguation from existing kinds of JWTs, = as >>>> the >>>> validation rules for existing kinds JWTs often do not use the "typ" >>>> header >>>> parameter value.' And the recommendations for how to use the Type >>>> Header >>>> Parameter in JWT strongly suggest that it's not currently being = used for >>>> any >>>> validation. >>>>=20 >>>> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter = to >>>> signal >>>> the type/intent/profile/application of a JWT could achieve >>>> disambiguation >>>> even in validation of existing kinds of JWTs. The critical header = lists >>>> other headers which must be understood and processed by the = receiver and >>>> that the JWS/JWE is invalid if those listed aren't understood. So a = new >>>> type/profile of JWT that uses the "crit" header would produce JWTs = that >>>> would be rejected even by existing applications of JWT validation = (that >>>> actually implement "crit" properly anyway). >>>>=20 >>>> The JWT BCP could suggest the use of "crit" in conjunction with a >>>> profile/application/type specific header. Or it could provide a bit = more >>>> of >>>> a framework like defining a registering a new JOSE header "p" = (strawman >>>> of p >>>> as a very short name for profile) and create a registry for its = values. >>>> A >>>> JWT header using that approach might look like the following where = the >>>> value >>>> 1 is registered as some cool new JWT profile/application. The = consumer >>>> of >>>> such a JWT would have to understand and process the "p" header, = which >>>> would >>>> mean checking that it had the value expected. >>>>=20 >>>> { >>>> "alg":"ES256", >>>> "crit":["p"], >>>> "p":1 >>>> } >>>>=20 >>>> A JOSE compliant JWT validator would reject such a JWT even for an = OAuth >>>> access token or OIDC id_token because the "p" header isn't known or >>>> understood but is marked as critical. >>>>=20 >>>> To me, that seems like an approach to preventing confusion that has = more >>>> teeth than the "typ" header. Which is why I asked about it last = week and >>>> am >>>> now bringing it to the list. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged >>>> material for the sole use of the intended recipient(s). Any review, = use, >>>> distribution or disclosure by others is strictly prohibited. If = you >>>> have >>>> received this communication in error, please notify the sender >>>> immediately >>>> by e-mail and delete the message and any file attachments from your >>>> computer. Thank you. >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10= &r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSn= cXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D= =20 >>>>=20 >>=20 >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged >> material for the sole use of the intended recipient(s). Any review, = use, >> distribution or disclosure by others is strictly prohibited. If you = have >> received this communication in error, please notify the sender = immediately >> by e-mail and delete the message and any file attachments from your >> computer. Thank you. >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10= &r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSn= cXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D= =20 --Apple-Mail=_0396C5EF-FEE2-483C-BA89-2556CEBF7219 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We have the use case in SECEVENTS where a logout event (e.g. = OIDF backchannel logout) is extremely close to an ID_TOKEN. 

Older relying parties = who are do not yet support logout could be tricked into accepting a = logout assertion as an ID_TOKEN since they are too similar, and =  because a valid ID_TOKEN parser is in theory allowed to ignore = claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) - leading = to a possible erroneous acceptance of the logout event AS and = ID_TOKEN.

Because of this the issue of distinguishing classes or types = of JWTs emerged.

We discussed a number of differentiators like =E2=80=9Caud=E2=80= =9D, =E2=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc that would help. =  But that really lead to the idea there there should be some best = practices in the JWT BCP covering the issue(s).

Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:

Even = after reading the whole section, I still don't understand the
problem. Yes, a class of attack could exist where an = attacker
substitutes a valid JWT from one security context = into another
context. But isn't this resolved by audience = validation?

On Thu, Jul 27, 2017 at 3:34 = PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
The draft describes it = in
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ie= tf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d= =3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5= biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b= 9sbh5pTrtBfQsC52A&s=3D9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&= e=3D

On Thu, Jul 27, 2017 at 1:30 PM, = Nathaniel McCallum <npmccallum@redhat.com>
wrote:

What = class of attacks is this trying to prevent? I frankly don't see a
problem with confusing different types of JWT. But I may just = be
ignorant.

On Thu, Jul 27, = 2017 at 2:49 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
During the first WG = meeting last week I asked if use of the JOSE "crit"
(Critical) Header Parameter had been considered as a = recommendation for
preventing confusion of one kind of JWT = for another. Time was running
short
in the = meeting so there wasn't much discussion and it was requested that
I
take the question to the list. And so here on = the list is that.

Section 3.9 of the JWT = BCP draft now recommends explicit typing using
the
"typ" JWS/JWE header parameter but does concede that 'the use = of
explicit
typing may not achieve = disambiguation from existing kinds of JWTs, as
the
validation rules for existing kinds JWTs often do not use the = "typ"
header
parameter value.'  And the = recommendations for how to use the Type
Header
Parameter in JWT strongly suggest that it's not currently = being used for
any
validation.

Alternatively using the JWS/JWE "crit" = (Critical) Header Parameter to
signal
the = type/intent/profile/application of a JWT could achieve
disambiguation
even in validation of existing = kinds of JWTs. The critical header lists
other headers = which must be understood and processed by the receiver and
that the JWS/JWE is invalid if those listed aren't = understood. So a new
type/profile of JWT that uses the = "crit" header would produce JWTs that
would be rejected = even by existing applications of JWT validation (that
actually implement "crit" properly anyway).

The JWT BCP could suggest the use of "crit" in conjunction = with a
profile/application/type specific header. Or it = could provide a bit more
of
a framework like = defining a registering a new JOSE header "p" (strawman
of = p
as a very short name for profile) and create a registry = for its values.
A
JWT header using that = approach might look like the following where the
value
1 is registered as some cool new JWT profile/application. The = consumer
of
such a JWT would have to = understand and process the "p" header, which
would
mean checking that it had the value expected.
    {
=      "alg":"ES256",
=      "crit":["p"],
=      "p":1
=     }

A JOSE compliant = JWT validator would reject such a JWT even for an OAuth
access token or OIDC id_token because the "p" header isn't = known or
understood but is marked as critical.

To me, that seems like an approach to = preventing confusion that has more
teeth than the "typ" = header. Which is why I asked about it last week and
am
now bringing it to the list.









CONFIDENTIALITY = NOTICE: This email may contain confidential and
privileged
material for the sole use of the = intended recipient(s). Any review, use,
distribution or = disclosure by others is strictly prohibited.  If you
have
received this communication in error, = please notify the sender
immediately
by = e-mail and delete the message and any file attachments from your
computer. Thank you.
_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcx= BKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&am= p;m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_= E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D




CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged
material for the sole use of the intended = recipient(s). Any review, use,
distribution or disclosure = by others is strictly prohibited.  If you have
received= this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments = from your
computer. Thank you.

_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcx= BKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&am= p;m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_= E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D

= --Apple-Mail=_0396C5EF-FEE2-483C-BA89-2556CEBF7219-- From nobody Thu Jul 27 14:29:38 2017 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 5F1431321BB; Thu, 27 Jul 2017 14:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-xh4Gj3Qq9n; Thu, 27 Jul 2017 14:29:34 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0158D1321BD; Thu, 27 Jul 2017 14:29:33 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id p3so68181167qtg.2; Thu, 27 Jul 2017 14:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XSTLI0ZY66yudmGmJZcDkLZ735Q2jjVHp5LbBwYYvWo=; b=UpO8xZzuHo4vtbTfiN2K+TSoXSCin+2JqXkt++jbzaXsaXdWIE7R95wCj+/myOK4Uc nd0/8VH4+lFuWFBQlSvp7/ltcsHxVqJbDGffESRh5P4gVMk+U6mCwAqR5dbNvl27Irmw fHv4xh5VNifsi4TbRyvmh58NgeVqD2QWqE5Og7yjwQxQyXnX1BnZV03Rej/kHD7DKzWY YN6wWriizYFk+1vtObex5LLELxRUEr+WZH/uDcJIulQc+0Y+Vukbb9HmgJWXgheFrLK4 dApngr1FDMXOCh675WWeIn8cBfwhTeQGV1eXLnvmr8J+nBb6Zy23KFgTvqAdKLFy1MJE yOYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XSTLI0ZY66yudmGmJZcDkLZ735Q2jjVHp5LbBwYYvWo=; b=Y+oz7a7J3F8EYIJycLS8R5Kz9udUoULHJ4dMHPXP292E6PDzOscK3SBR+c6F3IQvxl MhLCbdxUG2FjGLa8mVE82dat69KMDEtExq4KzrphANn9O4v5HzpMlVHV6tvB1bwmu0SX Cdt2dpU5vCXT3YpAMONyGj82gVlMhc56tO4xWgm6EjDOwcw//14JYjPHJRuK8rYBzw0D xX61wSKDxNBH8CGAMmIm8KKgrHS/Zbcqd12B7R0U8MONTBLEZ09KWWZ7ZUMCvgQa2B7h zAh/yubROlGPOS+cs1pZAWzwTea05xBIhT4KdAnpe3WNScx7QRyYfhF3TVKiZirOkZkk ntYQ== X-Gm-Message-State: AIVw112qzOLPcvgAfBNe4ubX3Pvzk1d4UU4Gq7jVWWClk14jOu4Kg1mq 3K/9d1gLUH73IxAbDPrSCPW+D1sGLQ== X-Received: by 10.237.63.92 with SMTP id q28mr8355802qtf.49.1501190973101; Thu, 27 Jul 2017 14:29:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.131 with HTTP; Thu, 27 Jul 2017 14:29:09 -0700 (PDT) In-Reply-To: References: From: Dick Hardt Date: Thu, 27 Jul 2017 22:29:09 +0100 Message-ID: To: Brian Campbell Cc: oauth , "jose@ietf.org" Content-Type: multipart/alternative; boundary="001a1146e496b11e36055553428c" Archived-At: Subject: Re: [jose] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 21:29:37 -0000 --001a1146e496b11e36055553428c Content-Type: text/plain; charset="UTF-8" Brian: I did not think that 'crit' processing is required in JWT https://tools.ietf.org/html/rfc7519 We have two goals: Preventing new JWT profiles from being confused with older JWTs, which 'typ' solves (as does your proposal of 'crit' and 'p', but requires more bytes) Preventing existing JWT implementations from being confused with new JWT profiles. 'crit' can solve that for JOSE JWTs, but not other JWTs. On Thu, Jul 27, 2017 at 7:49 PM, Brian Campbell wrote: > During the first WG meeting last week > I asked if use of > the JOSE "crit" (Critical) Header Parameter had been considered as a > recommendation for preventing confusion of one kind of JWT for another. > Time was running short in the meeting so there wasn't much discussion and > it was requested that I take the question to the list. And so here on the > list is that. > > Section 3.9 > > of the JWT BCP draft now recommends explicit typing using the "typ" JWS/JWE > header parameter but does concede that 'the use of explicit typing may not > achieve disambiguation from existing kinds of JWTs, as the validation rules > for existing kinds JWTs often do not use the "typ" header parameter > value.' And the recommendations for how to use the Type Header Parameter > in JWT strongly suggest > that it's not currently being used for any validation. > > Alternatively using the JWS/JWE "crit" (Critical) Header Parameter > to signal the > type/intent/profile/application of a JWT could achieve disambiguation > even in validation of existing kinds of JWTs. The critical header lists > other headers which must be understood and processed by the receiver and > that the JWS/JWE is invalid if those listed aren't understood. So a new > type/profile of JWT that uses the "crit" header would produce JWTs that > would be rejected even by existing applications of JWT validation (that > actually implement "crit" properly anyway). > > The JWT BCP could suggest the use of "crit" in conjunction with a > profile/application/type specific header. Or it could provide a bit more of > a framework like defining a registering a new JOSE header "p" (strawman of > p as a very short name for profile) and create a registry for its values. A > JWT header using that approach might look like the following where the > value 1 is registered as some cool new JWT profile/application. The > consumer of such a JWT would have to understand and process the "p" header, > which would mean checking that it had the value expected. > > { > "alg":"ES256", > "crit":["p"], > "p":1 > } > > A JOSE compliant JWT validator would reject such a JWT even for an OAuth > access token or OIDC id_token because the "p" header isn't known or > understood but is marked as critical. > > To me, that seems like an approach to preventing confusion that has more > teeth than the "typ" header. Which is why I asked about it last week and am > now bringing it to the list. > > > > > > > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > -- Subscribe to the HARDTWARE mail list to learn about projects I am working on! --001a1146e496b11e36055553428c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian: I did not think that 'crit' processing is r= equired in JWT=C2=A0https:/= /tools.ietf.org/html/rfc7519

We have two goals:=C2= =A0

Preventing new JWT profiles from being confuse= d with older JWTs, which 'typ' solves (as does your proposal of = 9;crit' and 'p', but requires more bytes)

<= div>Preventing existing JWT implementations from being confused with new JW= T profiles. 'crit' can solve that for JOSE JWTs, but not other JWTs= .



<= div class=3D"gmail_quote">On Thu, Jul 27, 2017 at 7:49 PM, Brian Campbell <= span dir=3D"ltr"><bcampbell@pingidentity.com> wrote:
During the first WG meeting last week I asked if use of the JOSE "crit&qu= ot; (Critical) Header Parameter had been considered as a recommendation for= preventing confusion of one kind of JWT for another. Time was running shor= t in the meeting so there wasn't much discussion and it was requested t= hat I take the question to the list. And so here on the list is that.
<= br>
Section 3.9 of the JWT BCP draft now= recommends explicit typing using the "typ" JWS/JWE header parame= ter but does concede that 'the use of explicit typing may not achieve d= isambiguation from existing kinds of JWTs, as the validation rules for exis= ting kinds JWTs often do not use the "typ" header parameter value= .'=C2=A0 And the recommendations for how to use the Type Header Para= meter in JWT strongly suggest that it's not currently being used fo= r any validation.

Alternatively using the JWS/JWE "= ;crit" (Critical) Header Parameter to signal the type/intent/profi= le/application of a JWT could achieve disambiguation even in validatio= n of existing kinds of JWTs. The critical header lists other headers which = must be understood and processed by the receiver and that the JWS/JWE is in= valid if those listed aren't understood. So a new type/profile of JWT t= hat uses the "crit" header would produce JWTs that would be rejec= ted even by existing applications of JWT validation (that actually implemen= t "crit" properly anyway).

The JWT BCP could suggest= the use of "crit" in conjunction with a profile/application/type= specific header. Or it could provide a bit more of a framework like defini= ng a registering a new JOSE header "p" (strawman of p as a very s= hort name for profile) and create a registry for its values. A JWT header u= sing that approach might look like the following where the value 1 is regis= tered as some cool new JWT profile/application. The consumer of such a JWT = would have to understand and process the "p" header, which would = mean checking that it had the value expected.
=C2=A0
=C2=A0=C2=A0=C2= =A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "alg":"ES256&q= uot;,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "crit":["p"],=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "p":1
=C2=A0=C2=A0=C2=A0=C2= =A0 }

A JOSE compliant JWT validator would reject such a JWT e= ven for an OAuth access token or OIDC id_token because the "p" he= ader isn't known or understood but is marked as critical.

To me, that seems like an approach to preventing confusion that has more t= eeth than the "typ" header. Which is why I asked about it last we= ek and am now bringing it to the list.









=

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
____________________= ___________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose




--
=
Subscribe to the HARDTWARE mail list to learn abou= t projects I am working on!
--001a1146e496b11e36055553428c-- From nobody Thu Jul 27 14:40:28 2017 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 AFC2D131CEB for ; Thu, 27 Jul 2017 14:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQGJlfoLsWLe for ; Thu, 27 Jul 2017 14:40:12 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBF413170E for ; Thu, 27 Jul 2017 14:40:11 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id p3so68302256qtg.2 for ; Thu, 27 Jul 2017 14:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cxp9wXk9ykh5BfDv5Z2+pzBZpqu2XV2tTavHx+C264A=; b=Wu7KIExtHCdYHd+/jPecJM4qNN+RnI1Dj1VaL+HLwOAC9C1d3N6du7/MNqa1kprtDe m0bEwQaQEB0Qs4k+i7MA75Uj1QCjLHWE/m1pBtoANxbVkDeEDsXNMGuIvv+JLm0x5BtB wI8ewb5+wCAZmSbAo1ydTj9GHoGzIft+UIiVgVCO3abEqDoPQ3+7w7QXWqijdgqxF5li SRNfbUGKns3UBLFa3QAObUyt1JeqxpapKlzDiq0o2y5wy5GCGe2AwXwfoSe6R0eRl7Ij n4V5JmPbeLIbipTgOOTbE7tCVnzK7zeMAnghzKJCbbxj5absRijWYQDphLfeBVKOwOjN yBVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cxp9wXk9ykh5BfDv5Z2+pzBZpqu2XV2tTavHx+C264A=; b=ekPsJYTv5eH/KI4hED3imZvYKE8nmPuFQPJ1DXnRsd5Jl2ZxTbio+gNdcLLRRhxU/G Y3mEKwW1EH4X8cqTN5Xf9Ui1yn2o6NdlgRuhj/W+ik0a1lzWJsL9Gq66V+/Gt6FTU0WF CAIg/B0k454x6yx1aoqVcLA92BOz/vLhYSNki9HlMir2sFvFmE5kHfVWBsyP4Gsc+GFR eX5Izx6IjjvVKq6lPot8ubpampgMCGAazxfRtVszMvSBubUGpSgsH5g/5rYojPbFbPs3 HjzvEh7YiA1KCb2ufdLQ4a6Hp6ray9klIgH+EyTbqCLYYKIFsqJ3g3zOEhClC6Tjgr5T v9BQ== X-Gm-Message-State: AIVw112pfw0xdVbUx0BCy5n3yeotw3pcS6lEkG9bmxSqhP957CfxhkBJ 2heIlCaFTWHL2t/e X-Received: by 10.200.3.135 with SMTP id t7mr7593721qtg.216.1501191610483; Thu, 27 Jul 2017 14:40:10 -0700 (PDT) Received: from [192.168.86.103] ([191.115.36.222]) by smtp.gmail.com with ESMTPSA id m123sm13847245qke.12.2017.07.27.14.40.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 14:40:09 -0700 (PDT) From: John Bradley Message-Id: <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 27 Jul 2017 17:40:02 -0400 In-Reply-To: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> Cc: Nathaniel McCallum , oauth , "jose@ietf.org" To: Phil Hunt References: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f4030435c300b6252a05555368fd" Archived-At: Subject: Re: [jose] [OAUTH-WG] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 21:40:19 -0000 --f4030435c300b6252a05555368fd Content-Type: multipart/alternative; boundary="Apple-Mail=_88FC2852-5BA7-481E-92F6-396B90D2D313" --Apple-Mail=_88FC2852-5BA7-481E-92F6-396B90D2D313 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Not that I am against the general desire for JWT not to be confused, but = the attack surface for someone to take a sec event from one context and = replay it as a id_token to login is very small and if the client is = correctly configured would not work as it is now. The only way you could replay the sec event JWT is via the implicit = flow. The other flows would require a malicious AS and at that point = you have bigger problems with a compromised token endpoint. If you were to create a implicit response with the sec event token that = has the correct issuer and aud, connect requires that nonce value from = the request be present in the id_token. This would require that the = attacker somehow get the AS to put not only the claim but the correct = value from the request into the token. All in all I think that it is more likely (not 100% I admit) that a = client will do that rather than checking the typ or a new crit JWT = header parameter. I am all for a general solution for this but I think the issue with = Connect is overstated sometimes. John B. =20 > On Jul 27, 2017, at 5:19 PM, Phil Hunt wrote: >=20 > We have the use case in SECEVENTS where a logout event (e.g. OIDF = backchannel logout) is extremely close to an ID_TOKEN.=20 >=20 > Older relying parties who are do not yet support logout could be = tricked into accepting a logout assertion as an ID_TOKEN since they are = too similar, and because a valid ID_TOKEN parser is in theory allowed = to ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) = - leading to a possible erroneous acceptance of the logout event AS and = ID_TOKEN. >=20 > Because of this the issue of distinguishing classes or types of JWTs = emerged. >=20 > We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, = =E2=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc that would help. But that = really lead to the idea there there should be some best practices in the = JWT BCP covering the issue(s). >=20 > Phil >=20 > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com = phil.hunt@oracle.com = >> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum = > wrote: >>=20 >> Even after reading the whole section, I still don't understand the >> problem. Yes, a class of attack could exist where an attacker >> substitutes a valid JWT from one security context into another >> context. But isn't this resolved by audience validation? >>=20 >> On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell >> > = wrote: >>> The draft describes it in >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html= _draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=3DDwICAg&c=3DR= oP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEiv= zjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPC= ouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D = =20 >>>=20 >>> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum = > >>> wrote: >>>>=20 >>>> What class of attacks is this trying to prevent? I frankly don't = see a >>>> problem with confusing different types of JWT. But I may just be >>>> ignorant. >>>>=20 >>>> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell >>>> > = wrote: >>>>> During the first WG meeting last week I asked if use of the JOSE = "crit" >>>>> (Critical) Header Parameter had been considered as a = recommendation for >>>>> preventing confusion of one kind of JWT for another. Time was = running >>>>> short >>>>> in the meeting so there wasn't much discussion and it was = requested that >>>>> I >>>>> take the question to the list. And so here on the list is that. >>>>>=20 >>>>> Section 3.9 of the JWT BCP draft now recommends explicit typing = using >>>>> the >>>>> "typ" JWS/JWE header parameter but does concede that 'the use of >>>>> explicit >>>>> typing may not achieve disambiguation from existing kinds of JWTs, = as >>>>> the >>>>> validation rules for existing kinds JWTs often do not use the = "typ" >>>>> header >>>>> parameter value.' And the recommendations for how to use the Type >>>>> Header >>>>> Parameter in JWT strongly suggest that it's not currently being = used for >>>>> any >>>>> validation. >>>>>=20 >>>>> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter = to >>>>> signal >>>>> the type/intent/profile/application of a JWT could achieve >>>>> disambiguation >>>>> even in validation of existing kinds of JWTs. The critical header = lists >>>>> other headers which must be understood and processed by the = receiver and >>>>> that the JWS/JWE is invalid if those listed aren't understood. So = a new >>>>> type/profile of JWT that uses the "crit" header would produce JWTs = that >>>>> would be rejected even by existing applications of JWT validation = (that >>>>> actually implement "crit" properly anyway). >>>>>=20 >>>>> The JWT BCP could suggest the use of "crit" in conjunction with a >>>>> profile/application/type specific header. Or it could provide a = bit more >>>>> of >>>>> a framework like defining a registering a new JOSE header "p" = (strawman >>>>> of p >>>>> as a very short name for profile) and create a registry for its = values. >>>>> A >>>>> JWT header using that approach might look like the following where = the >>>>> value >>>>> 1 is registered as some cool new JWT profile/application. The = consumer >>>>> of >>>>> such a JWT would have to understand and process the "p" header, = which >>>>> would >>>>> mean checking that it had the value expected. >>>>>=20 >>>>> { >>>>> "alg":"ES256", >>>>> "crit":["p"], >>>>> "p":1 >>>>> } >>>>>=20 >>>>> A JOSE compliant JWT validator would reject such a JWT even for an = OAuth >>>>> access token or OIDC id_token because the "p" header isn't known = or >>>>> understood but is marked as critical. >>>>>=20 >>>>> To me, that seems like an approach to preventing confusion that = has more >>>>> teeth than the "typ" header. Which is why I asked about it last = week and >>>>> am >>>>> now bringing it to the list. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged >>>>> material for the sole use of the intended recipient(s). Any = review, use, >>>>> distribution or disclosure by others is strictly prohibited. If = you >>>>> have >>>>> received this communication in error, please notify the sender >>>>> immediately >>>>> by e-mail and delete the message and any file attachments from = your >>>>> computer. Thank you. >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10= &r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSn= cXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D= =20 >>>>>=20 >>>=20 >>>=20 >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged >>> material for the sole use of the intended recipient(s). Any review, = use, >>> distribution or disclosure by others is strictly prohibited. If you = have >>> received this communication in error, please notify the sender = immediately >>> by e-mail and delete the message and any file attachments from your >>> computer. Thank you. >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10= &r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSn= cXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D= =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_88FC2852-5BA7-481E-92F6-396B90D2D313 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Not that I am against the general desire for JWT not to be = confused, but the attack surface for someone to take a sec event from = one context and replay it as a id_token to login is very small and if = the client is correctly configured would not work as it is now.

The only way you could = replay the sec event JWT is via the implicit flow.   The other = flows would require a malicious AS and at that point you have bigger = problems with a compromised token endpoint.

If you were to create a implicit = response with the sec event token that has the correct issuer and aud, = connect requires that nonce value from the request be present in the = id_token.   This would require that the attacker somehow get the AS = to put not only the claim but the correct value from the request into = the token.

All = in all I think that it is more likely (not 100% I admit) that a client = will do that rather than checking the typ or a new crit JWT header = parameter.

I = am all for a general solution for this but I think the issue with = Connect is overstated sometimes.

John B.
 
On = Jul 27, 2017, at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

We have the = use case in SECEVENTS where a logout event (e.g. OIDF backchannel = logout) is extremely close to an ID_TOKEN. 

Older relying parties who are do not = yet support logout could be tricked into accepting a logout assertion as = an ID_TOKEN since they are too similar, and  because a valid = ID_TOKEN parser is in theory allowed to ignore claims it does not = understand (e.g. =E2=80=9Cevents=E2=80=9D) - leading to a possible = erroneous acceptance of the logout event AS and ID_TOKEN.

Because of this the = issue of distinguishing classes or types of JWTs emerged.

We discussed a number of = differentiators like =E2=80=9Caud=E2=80=9D, =E2=80=9Ctyp=E2=80=9D, = =E2=80=9Ccrit", etc that would help.  But that really lead to the = idea there there should be some best practices in the JWT BCP covering = the issue(s).

Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:

Even = after reading the whole section, I still don't understand the
problem. Yes, a class of attack could exist where an = attacker
substitutes a valid JWT from one security context = into another
context. But isn't this resolved by audience = validation?

On Thu, Jul 27, 2017 at 3:34 = PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
The draft describes it = in
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ie= tf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d= =3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5= biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b= 9sbh5pTrtBfQsC52A&s=3D9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&= e=3D

On Thu, Jul 27, 2017 at 1:30 PM, = Nathaniel McCallum <npmccallum@redhat.com>
wrote:

What = class of attacks is this trying to prevent? I frankly don't see a
problem with confusing different types of JWT. But I may just = be
ignorant.

On Thu, Jul 27, = 2017 at 2:49 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
During the first WG = meeting last week I asked if use of the JOSE "crit"
(Critical) Header Parameter had been considered as a = recommendation for
preventing confusion of one kind of JWT = for another. Time was running
short
in the = meeting so there wasn't much discussion and it was requested that
I
take the question to the list. And so here on = the list is that.

Section 3.9 of the JWT = BCP draft now recommends explicit typing using
the
"typ" JWS/JWE header parameter but does concede that 'the use = of
explicit
typing may not achieve = disambiguation from existing kinds of JWTs, as
the
validation rules for existing kinds JWTs often do not use the = "typ"
header
parameter value.'  And the = recommendations for how to use the Type
Header
Parameter in JWT strongly suggest that it's not currently = being used for
any
validation.

Alternatively using the JWS/JWE "crit" = (Critical) Header Parameter to
signal
the = type/intent/profile/application of a JWT could achieve
disambiguation
even in validation of existing = kinds of JWTs. The critical header lists
other headers = which must be understood and processed by the receiver and
that the JWS/JWE is invalid if those listed aren't = understood. So a new
type/profile of JWT that uses the = "crit" header would produce JWTs that
would be rejected = even by existing applications of JWT validation (that
actually implement "crit" properly anyway).

The JWT BCP could suggest the use of "crit" in conjunction = with a
profile/application/type specific header. Or it = could provide a bit more
of
a framework like = defining a registering a new JOSE header "p" (strawman
of = p
as a very short name for profile) and create a registry = for its values.
A
JWT header using that = approach might look like the following where the
value
1 is registered as some cool new JWT profile/application. The = consumer
of
such a JWT would have to = understand and process the "p" header, which
would
mean checking that it had the value expected.
    {
=      "alg":"ES256",
=      "crit":["p"],
=      "p":1
=     }

A JOSE compliant = JWT validator would reject such a JWT even for an OAuth
access token or OIDC id_token because the "p" header isn't = known or
understood but is marked as critical.

To me, that seems like an approach to = preventing confusion that has more
teeth than the "typ" = header. Which is why I asked about it last week and
am
now bringing it to the list.









CONFIDENTIALITY = NOTICE: This email may contain confidential and
privileged
material for the sole use of the = intended recipient(s). Any review, use,
distribution or = disclosure by others is strictly prohibited.  If you
have
received this communication in error, = please notify the sender
immediately
by = e-mail and delete the message and any file attachments from your
computer. Thank you.
_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcx= BKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&am= p;m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_= E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D




CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged
material for the sole use of the intended = recipient(s). Any review, use,
distribution or disclosure = by others is strictly prohibited.  If you have
received= this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments = from your
computer. Thank you.

_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcx= BKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&am= p;m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_= E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D

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

= --Apple-Mail=_88FC2852-5BA7-481E-92F6-396B90D2D313-- --f4030435c300b6252a05555368fd Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIJ1xFYS7MrgF3lLk36gSb/KECXXU 9knFVYcWAFZhr0TUMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDcyNzIxNDAxMFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQA+AqAwENp4pGqubUlPK8rVZ2OODqhZH2gS6g47YwZEHti9 Y8I0us0GekHX/HbV3wII0DtVlpQN0RxBzvjcJYh/rs+Kzwpo5Pv4pKV+5vd5zHRHQN84h1chJqYb 1d/9Bd1CKGPEsQAEQNBrFNvvdNm1vBpqm644XuYDI4hLzvN7TPcL6yLGt5+oMBqWi5cppmjIhwlH 7IOoLUGQc53GBGemCtLKMfxtWOkI6QIaen8L5TrBxi9qPOQ1YCikkR76UnA7Gal4JHziaLu/I7cl DdIxG1UCWWE/Kca48sUWxprz6fcp4kkLDgdq4dRb+XaQZzeuo83ZrmdyXABdDfcKrAe7 --f4030435c300b6252a05555368fd-- From nobody Thu Jul 27 14:41:06 2017 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 E788D131E7B for ; Thu, 27 Jul 2017 14:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsHBTx6P-66K for ; Thu, 27 Jul 2017 14:40:42 -0700 (PDT) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51A81321C9 for ; Thu, 27 Jul 2017 14:40:34 -0700 (PDT) Received: by mail-io0-f179.google.com with SMTP id m88so75261732iod.2 for ; Thu, 27 Jul 2017 14:40:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bTj0GreIjY2Z6CAFJXyQ4sMJxFw7xj2vJ6jiSeYE8pA=; b=gRpx1NJj6KNKp9+T9fp2Z5ui3GFc0ePfq+yrKpvyQVq0H/B4VheJE5iKLT48A7jacw QtFrMT/EVJleOqPjBl/mU8dCT4m96uL2z0svbC4sCHTrgB1IVkLtjt51MGOCF0l3e4Ir l10s8UAB0V8+USB7VqkdHatzBEaMaXSbChN8C3f3ZmwOIOBg/W5XJqlaMYdMbUg1wGGM 1pI1WweKPbPyzj6jqyvVgIwrS9LNK2GS5D4n/3tt6qntH0BI7vGZ8ILR7/TEqtdO2ITL OrIYPeAH+yXXYBx34JlCohlIDeWjptFNS22J7D9Fea0k92+UmnaeZ465sQs3pBGAlxWg EC3A== X-Gm-Message-State: AIVw1104mR1esXde3sJIYQiafJiTgIpnIrY0g58nuyoVTlqbqdSNw4j3 FIpSHn7sz8GchDV4tbf8BwCNui+pA+Q0 X-Received: by 10.107.40.212 with SMTP id o203mr6559216ioo.181.1501191633862; Thu, 27 Jul 2017 14:40:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.21.6 with HTTP; Thu, 27 Jul 2017 14:40:33 -0700 (PDT) In-Reply-To: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> References: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> From: Nathaniel McCallum Date: Thu, 27 Jul 2017 17:40:33 -0400 Message-ID: To: Phil Hunt Cc: Brian Campbell , oauth , "jose@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [jose] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 21:40:56 -0000 Right. And this is precisely what I find strange. We are attempting to define the differentiation between state transitions without defining the state transitions themselves. I want to be clear that I think there is a real need here. But it seems to me that this need is not well defined. So I'm not against it in theory. I'm just against ambiguous standards. On Thu, Jul 27, 2017 at 5:19 PM, Phil Hunt wrote: > We have the use case in SECEVENTS where a logout event (e.g. OIDF > backchannel logout) is extremely close to an ID_TOKEN. > > Older relying parties who are do not yet support logout could be tricked > into accepting a logout assertion as an ID_TOKEN since they are too simil= ar, > and because a valid ID_TOKEN parser is in theory allowed to ignore claim= s > it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) - leading to a pos= sible erroneous > acceptance of the logout event AS and ID_TOKEN. > > Because of this the issue of distinguishing classes or types of JWTs > emerged. > > We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, =E2= =80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc that > would help. But that really lead to the idea there there should be some > best practices in the JWT BCP covering the issue(s). > > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum > wrote: > > Even after reading the whole section, I still don't understand the > problem. Yes, a class of attack could exist where an attacker > substitutes a valid JWT from one security context into another > context. But isn't this resolved by audience validation? > > On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell > wrote: > > The draft describes it in > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=3DDwICAg&c=3DR= oP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivz= jWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPCou= CMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D > > On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum > wrote: > > > What class of attacks is this trying to prevent? I frankly don't see a > problem with confusing different types of JWT. But I may just be > ignorant. > > On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell > wrote: > > During the first WG meeting last week I asked if use of the JOSE "crit" > (Critical) Header Parameter had been considered as a recommendation for > preventing confusion of one kind of JWT for another. Time was running > short > in the meeting so there wasn't much discussion and it was requested that > I > take the question to the list. And so here on the list is that. > > Section 3.9 of the JWT BCP draft now recommends explicit typing using > the > "typ" JWS/JWE header parameter but does concede that 'the use of > explicit > typing may not achieve disambiguation from existing kinds of JWTs, as > the > validation rules for existing kinds JWTs often do not use the "typ" > header > parameter value.' And the recommendations for how to use the Type > Header > Parameter in JWT strongly suggest that it's not currently being used for > any > validation. > > Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to > signal > the type/intent/profile/application of a JWT could achieve > disambiguation > even in validation of existing kinds of JWTs. The critical header lists > other headers which must be understood and processed by the receiver and > that the JWS/JWE is invalid if those listed aren't understood. So a new > type/profile of JWT that uses the "crit" header would produce JWTs that > would be rejected even by existing applications of JWT validation (that > actually implement "crit" properly anyway). > > The JWT BCP could suggest the use of "crit" in conjunction with a > profile/application/type specific header. Or it could provide a bit more > of > a framework like defining a registering a new JOSE header "p" (strawman > of p > as a very short name for profile) and create a registry for its values. > A > JWT header using that approach might look like the following where the > value > 1 is registered as some cool new JWT profile/application. The consumer > of > such a JWT would have to understand and process the "p" header, which > would > mean checking that it had the value expected. > > { > "alg":"ES256", > "crit":["p"], > "p":1 > } > > A JOSE compliant JWT validator would reject such a JWT even for an OAuth > access token or OIDC id_token because the "p" header isn't known or > understood but is marked as critical. > > To me, that seems like an approach to preventing confusion that has more > teeth than the "typ" header. Which is why I asked about it last week and > am > now bringing it to the list. > > > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you > have > received this communication in error, please notify the sender > immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. > _______________________________________________ > jose mailing list > jose@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10= &r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSnc= Xu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediatel= y > by e-mail and delete the message and any file attachments from your > computer. Thank you. > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10= &r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSnc= Xu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From nobody Thu Jul 27 15:00:01 2017 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 557171321D7 for ; Thu, 27 Jul 2017 14:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymfkNUdaLvm4 for ; Thu, 27 Jul 2017 14:59:56 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF4C1321D0 for ; Thu, 27 Jul 2017 14:59:56 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id e75so10087224pfj.2 for ; Thu, 27 Jul 2017 14:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5+8ihVdfpE82C+K9989j7igeQWSH9Y49ZkzM6qwHd6E=; b=i0BcDjDjEIuJrzjv+Ynp0nK46UO66NdNzgV+IspqDxjrUJ72ut60mL1sUZOtbLD/K3 13FlVWDtxx/VILXYBVnwOVQwD5Y51dy4e3XJRnqdYEvpKLprPA9fxpFGQduQayAolXX3 MNOFLSrNNxMkUf6YHzuqovB7J8RiAWouu6ZmQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5+8ihVdfpE82C+K9989j7igeQWSH9Y49ZkzM6qwHd6E=; b=qgU/ZLQKX+znD3fuMjtzyd9ohqTHNGriCthLCwMtG0vjIGvD4O/uycwbOOVp2EZmqF 9LcfRgZwRYoOAdANjIw5C1Uf7cZr382NglP1Ia15LK2pqwUZrzfIHVeJUBa7b3eUbIcD ++KsIU6jynJAl9HHAO9aJAFaxnVYG8SyI8xAjg8ITME0JBurXLEkDvqrCcZOCqTC3AVy sY0yLfGVahXT4XW/q6C8Lx2nkdF8hmTFNNMN7AIaKoTL1J4gnHkQb37WfrrjsJHsyXG3 BHrVWcTossHdyTPWr6/7sbIwgSq4jeYJqUhmFdrQO7wPwuKLBHYujREpNejz5zD4Vpk3 3CWg== X-Gm-Message-State: AIVw111qPT9i2IARYeIoYvCm+k5h4HRxDOOeZUGKaLUhO2MtKD3d2dqw fOL7gjqvV5pcxChT1uf2XLplLvjk4LciNRsaIVPemnsu/YWt+p+HydVHDz8cUTbWVKvrXd6b3A4 pI1c= X-Received: by 10.84.167.230 with SMTP id i35mr5817268plg.181.1501192796316; Thu, 27 Jul 2017 14:59:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Thu, 27 Jul 2017 14:59:25 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 27 Jul 2017 15:59:25 -0600 Message-ID: To: Dick Hardt Cc: oauth , "jose@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c145cd65d468a055553af8b" Archived-At: Subject: Re: [jose] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 21:59:59 -0000 --94eb2c145cd65d468a055553af8b Content-Type: text/plain; charset="UTF-8" What other JWTs are there? All JWTs use JWS and/or JWE. So a JWT is a JOSE JWT by definition. JWT requires 'crit' processing by virtue of using JWS and JWE for signing and encryption. The extent to which that processing is actually implemented is a different and fair question but it's normative requirement per spec and implementations that don't would be non-compliant. The byte usage actually is pretty similar depending on the the values used (admittedly because I chose very compact names/values). Compare to secevent, for example, "crit":["p"],"p":1 "typ":"secevent+jwt" On Thu, Jul 27, 2017 at 3:29 PM, Dick Hardt wrote: > Brian: I did not think that 'crit' processing is required in JWT > https://tools.ietf.org/html/rfc7519 > > We have two goals: > > Preventing new JWT profiles from being confused with older JWTs, which > 'typ' solves (as does your proposal of 'crit' and 'p', but requires more > bytes) > > Preventing existing JWT implementations from being confused with new JWT > profiles. 'crit' can solve that for JOSE JWTs, but not other JWTs. > > > > On Thu, Jul 27, 2017 at 7:49 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> During the first WG meeting last week >> I asked if use of >> the JOSE "crit" (Critical) Header Parameter had been considered as a >> recommendation for preventing confusion of one kind of JWT for another. >> Time was running short in the meeting so there wasn't much discussion and >> it was requested that I take the question to the list. And so here on the >> list is that. >> >> Section 3.9 >> >> of the JWT BCP draft now recommends explicit typing using the "typ" JWS/JWE >> header parameter but does concede that 'the use of explicit typing may not >> achieve disambiguation from existing kinds of JWTs, as the validation rules >> for existing kinds JWTs often do not use the "typ" header parameter >> value.' And the recommendations for how to use the Type Header >> Parameter in JWT >> strongly suggest that it's not currently being used for any validation. >> >> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter >> to signal the >> type/intent/profile/application of a JWT could achieve disambiguation >> even in validation of existing kinds of JWTs. The critical header lists >> other headers which must be understood and processed by the receiver and >> that the JWS/JWE is invalid if those listed aren't understood. So a new >> type/profile of JWT that uses the "crit" header would produce JWTs that >> would be rejected even by existing applications of JWT validation (that >> actually implement "crit" properly anyway). >> >> The JWT BCP could suggest the use of "crit" in conjunction with a >> profile/application/type specific header. Or it could provide a bit more of >> a framework like defining a registering a new JOSE header "p" (strawman of >> p as a very short name for profile) and create a registry for its values. A >> JWT header using that approach might look like the following where the >> value 1 is registered as some cool new JWT profile/application. The >> consumer of such a JWT would have to understand and process the "p" header, >> which would mean checking that it had the value expected. >> >> { >> "alg":"ES256", >> "crit":["p"], >> "p":1 >> } >> >> A JOSE compliant JWT validator would reject such a JWT even for an OAuth >> access token or OIDC id_token because the "p" header isn't known or >> understood but is marked as critical. >> >> To me, that seems like an approach to preventing confusion that has more >> teeth than the "typ" header. Which is why I asked about it last week and am >> now bringing it to the list. >> >> >> >> >> >> >> >> >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.* >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > > > -- > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c145cd65d468a055553af8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What other JWTs are there?
=C2=A0
All JWTs use = JWS and/or JWE. So a JWT is a JOSE JWT by definition. JWT requires 'cr= it' processing by virtue of using JWS and JWE for signing and encryptio= n. The extent to which that processing is actually implemented is a differe= nt and fair question but it's normative requirement per spec and implem= entations that don't would be non-compliant.

The byte usa= ge actually is pretty similar depending on the the values used (admittedly = because I chose very compact names/values).=C2=A0 Compare to secevent, for = example,

=C2=A0=C2=A0 "crit":["p"],&q= uot;p":1
=C2=A0=C2=A0 "typ":"secevent+jwt"
=
=C2=A0
On= Thu, Jul 27, 2017 at 3:29 PM, Dick Hardt <dick.hardt@gmail.com>= wrote:
Brian: I did not think that 'crit' processing is required= in JWT=C2=A0https://tools.ietf.org/html/rfc7519

We have= two goals:=C2=A0

Preventing new JWT profiles from= being confused with older JWTs, which 'typ' solves (as does your p= roposal of 'crit' and 'p', but requires more bytes)

Preventing existing JWT implementations from being confus= ed with new JWT profiles. 'crit' can solve that for JOSE JWTs, but = not other JWTs.



On Thu= , Jul 27, 2017 at 7:49 PM, Brian Campbell <bcampbell@pingidentity= .com> wrote:
During the first WG meeting last week I asked if use= of the JOSE "crit" (Critical) Header Parameter had been consider= ed as a recommendation for preventing confusion of one kind of JWT for anot= her. Time was running short in the meeting so there wasn't much discuss= ion and it was requested that I take the question to the list. And so here = on the list is that.

Section 3.9 of the JWT BCP draft now recommends explicit typing using the "typ&q= uot; JWS/JWE header parameter but does concede that 'the use of explici= t typing may not achieve disambiguation from existing kinds of JWTs, as the= validation rules for existing kinds JWTs often do not use the "typ&qu= ot; header parameter value.'=C2=A0 And the recommendations for how to u= se the Type Header Parameter in JWT strongly suggest that it's= not currently being used for any validation.

Alternatively u= sing the JWS/JWE "crit" (Critical) Header Parameter to = signal the type/intent/profile/application of a JWT could achieve disa= mbiguation even in validation of existing kinds of JWTs. The critical heade= r lists other headers which must be understood and processed by the receive= r and that the JWS/JWE is invalid if those listed aren't understood. So= a new type/profile of JWT that uses the "crit" header would prod= uce JWTs that would be rejected even by existing applications of JWT valida= tion (that actually implement "crit" properly anyway).

The JWT BCP could suggest the use of "crit" in conjunction wit= h a profile/application/type specific header. Or it could provide a bit mor= e of a framework like defining a registering a new JOSE header "p"= ; (strawman of p as a very short name for profile) and create a registry fo= r its values. A JWT header using that approach might look like the followin= g where the value 1 is registered as some cool new JWT profile/application.= The consumer of such a JWT would have to understand and process the "= p" header, which would mean checking that it had the value expected. <= br>=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &= quot;alg":"ES256",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "c= rit":["p"],
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "p":= 1
=C2=A0=C2=A0=C2=A0=C2=A0 }

A JOSE compliant JWT validator= would reject such a JWT even for an OAuth access token or OIDC id_token be= cause the "p" header isn't known or understood but is marked = as critical.

To me, that seems like an approach to preventing= confusion that has more teeth than the "typ" header. Which is wh= y I asked about it last week and am now bringing it to the list.
<= div>









CONFIDENTIAL= ITY NOTICE: This email may contain confidential and privileged material for= the sole use of the intended recipient(s). Any review, use, distribution o= r disclosure by others is strictly prohibited.=C2=A0 If you have received t= his communication in error, please notify the sender immediately by e-mail = and delete the message and any file attachments from your computer. Thank y= ou.
_____________________________________________= __
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose=



--
Subscribe to the= HARDTWARE mail lis= t to learn about projects I am working on!


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c145cd65d468a055553af8b-- From nobody Thu Jul 27 15:10:47 2017 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 13CA5131E5E for ; Thu, 27 Jul 2017 15:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufk-y_maqj0x for ; Thu, 27 Jul 2017 15:10:35 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F358131CF3 for ; Thu, 27 Jul 2017 15:10:35 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id v190so103143705pgv.2 for ; Thu, 27 Jul 2017 15:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AcxLqZz/P4+/aAq9qy4XRTUmORo0OGhpqeDbgsW/s8E=; b=bjl8i45/6duFsOUg3VjzRI7evGq1ULwCNAlLgwll6oquNpBIJhPNsJsVLLAt0QbmQm Fx3ostUvswKcSgecVsFl846p/PfYTjDkd4+L+HcbtoWGUP6A38Nua+uIrJpFCDJ9GCie cCaeNab659lDmLJY1AflujGxSCHDnv0fjuG2c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AcxLqZz/P4+/aAq9qy4XRTUmORo0OGhpqeDbgsW/s8E=; b=fTxhr2FOaeywFejTEy5PUzo45KBnR0nIMWbbU8rLbQLDz/AFU58+Nnu1b2Jwy01pyN U+QoK4mJzAXlhljev+vmiqNIbSeu1LVUOnpCfuiF9MUtNSptfEknAa2IjZbI7LjB2Lzg U5FErDcupVO22EDmKgbOesQdvJVh4SHsdp07ZwAW1q1rcNOPt/5K97aNEa8Oo3Hw9o7f Igmy4wPewxBUPU2375FcF6qEYsTjWHUMxboHeNL4rT9Obs2JafLqbIg/gSC+b2i0mR0N 4OMpLVrfGr4+OLhWPX/FkQ7SdIZbmvCNk9zubT9MZ8GvsEsnnaBJDJjgyV3qpCXRdDpf A3jg== X-Gm-Message-State: AIVw112F4tArM/PUECtvy3/4t2pRCurdFAIYOZtYIxN1+RRrBRniyhFX MQRhynKSznQHaDU7nKDBof1I7M/bGRJt3bYF8faFicC6QwvmLaBDeO4Dy9drBkhTCWOA4NQlQcD Ibiyfaw== X-Received: by 10.99.117.68 with SMTP id f4mr5397586pgn.56.1501193434456; Thu, 27 Jul 2017 15:10:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Thu, 27 Jul 2017 15:10:03 -0700 (PDT) In-Reply-To: <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com> References: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com> From: Brian Campbell Date: Thu, 27 Jul 2017 16:10:03 -0600 Message-ID: To: John Bradley Cc: Phil Hunt , Nathaniel McCallum , oauth , "jose@ietf.org" Content-Type: multipart/alternative; boundary="f403045cdcc4668e18055553d548" Archived-At: Subject: Re: [jose] [OAUTH-WG] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 22:10:40 -0000 --f403045cdcc4668e18055553d548 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wouldn't disagree that the issue with Connect is overstated sometimes. And it's a non-issue with sec event due to the "nonce" claim (as you point out) as well as the omission of the "exp" claim. Assuming correct validation anyway. The BCP draft suggests explicit typing to prevent Cross-JWT Confusion more generally (not just sec events and id tokens). I was wondering if some use of "crit" might accomplish the same thing but also cover the case of existing JWT implementations being confused with new JWT profiles. On Thu, Jul 27, 2017 at 3:40 PM, John Bradley wrote: > Not that I am against the general desire for JWT not to be confused, but > the attack surface for someone to take a sec event from one context and > replay it as a id_token to login is very small and if the client is > correctly configured would not work as it is now. > > The only way you could replay the sec event JWT is via the implicit flow. > The other flows would require a malicious AS and at that point you have > bigger problems with a compromised token endpoint. > > If you were to create a implicit response with the sec event token that > has the correct issuer and aud, connect requires that nonce value from th= e > request be present in the id_token. This would require that the attacke= r > somehow get the AS to put not only the claim but the correct value from t= he > request into the token. > > All in all I think that it is more likely (not 100% I admit) that a clien= t > will do that rather than checking the typ or a new crit JWT header > parameter. > > I am all for a general solution for this but I think the issue with > Connect is overstated sometimes. > > John B. > > > On Jul 27, 2017, at 5:19 PM, Phil Hunt wrote: > > We have the use case in SECEVENTS where a logout event (e.g. OIDF > backchannel logout) is extremely close to an ID_TOKEN. > > Older relying parties who are do not yet support logout could be tricked > into accepting a logout assertion as an ID_TOKEN since they are too > similar, and because a valid ID_TOKEN parser is in theory allowed to > ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) - le= ading to a > possible erroneous acceptance of the logout event AS and ID_TOKEN. > > Because of this the issue of distinguishing classes or types of JWTs > emerged. > > We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, =E2= =80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc > that would help. But that really lead to the idea there there should be > some best practices in the JWT BCP covering the issue(s). > > Phil > > Oracle Corporation, Identity Cloud Services Architect & Standards > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum > wrote: > > Even after reading the whole section, I still don't understand the > problem. Yes, a class of attack could exist where an attacker > substitutes a valid JWT from one security context into another > context. But isn't this resolved by audience validation? > > On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell > wrote: > > The draft describes it in > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools. > ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01- > 23section-2D2.7&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK1= 0&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D > 9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D > > On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum > > wrote: > > > What class of attacks is this trying to prevent? I frankly don't see a > problem with confusing different types of JWT. But I may just be > ignorant. > > On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell > wrote: > > During the first WG meeting last week I asked if use of the JOSE "crit" > (Critical) Header Parameter had been considered as a recommendation for > preventing confusion of one kind of JWT for another. Time was running > short > in the meeting so there wasn't much discussion and it was requested that > I > take the question to the list. And so here on the list is that. > > Section 3.9 of the JWT BCP draft now recommends explicit typing using > the > "typ" JWS/JWE header parameter but does concede that 'the use of > explicit > typing may not achieve disambiguation from existing kinds of JWTs, as > the > validation rules for existing kinds JWTs often do not use the "typ" > header > parameter value.' And the recommendations for how to use the Type > Header > Parameter in JWT strongly suggest that it's not currently being used for > any > validation. > > Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to > signal > the type/intent/profile/application of a JWT could achieve > disambiguation > even in validation of existing kinds of JWTs. The critical header lists > other headers which must be understood and processed by the receiver and > that the JWS/JWE is invalid if those listed aren't understood. So a new > type/profile of JWT that uses the "crit" header would produce JWTs that > would be rejected even by existing applications of JWT validation (that > actually implement "crit" properly anyway). > > The JWT BCP could suggest the use of "crit" in conjunction with a > profile/application/type specific header. Or it could provide a bit more > of > a framework like defining a registering a new JOSE header "p" (strawman > of p > as a very short name for profile) and create a registry for its values. > A > JWT header using that approach might look like the following where the > value > 1 is registered as some cool new JWT profile/application. The consumer > of > such a JWT would have to understand and process the "p" header, which > would > mean checking that it had the value expected. > > { > "alg":"ES256", > "crit":["p"], > "p":1 > } > > A JOSE compliant JWT validator would reject such a JWT even for an OAuth > access token or OIDC id_token because the "p" header isn't known or > understood but is marked as critical. > > To me, that seems like an approach to preventing confusion that has more > teeth than the "typ" header. Which is why I asked about it last week and > am > now bringing it to the list. > > > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you > have > received this communication in error, please notify the sender > immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. > _______________________________________________ > jose mailing list > jose@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC= X5Y > TpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO- > RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediatel= y > by e-mail and delete the message and any file attachments from your > computer. Thank you. > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC= X5Y > TpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO- > RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited. If you have= =20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you.* --f403045cdcc4668e18055553d548 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wouldn't disagree that the issue with Connect = is overstated sometimes. And it's a non-issue with sec event due to the= "nonce" claim (as you point out) as well as the omission of the = "exp" claim. Assuming correct validation anyway.

Th= e BCP draft suggests explicit typing to prevent Cross-JWT Confusion more ge= nerally (not just sec events and id tokens). I was wondering if some use of= "crit" might accomplish the same thing but also cover the case o= f existing JWT implementations being confused with new JWT profiles.

On Thu, Jul 2= 7, 2017 at 3:40 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:<= br>
Not t= hat I am against the general desire for JWT not to be confused, but the att= ack surface for someone to take a sec event from one context and replay it = as a id_token to login is very small and if the client is correctly configu= red would not work as it is now.

The only way you could = replay the sec event JWT is via the implicit flow. =C2=A0 The other flows w= ould require a malicious AS and at that point you have bigger problems with= a compromised token endpoint.

If you were to crea= te a implicit response with the sec event token that has the correct issuer= and aud, connect requires that nonce value from the request be present in = the id_token. =C2=A0 This would require that the attacker somehow get the A= S to put not only the claim but the correct value from the request into the= token.

All in all I think that it is more likely = (not 100% I admit) that a client will do that rather than checking the typ = or a new crit JWT header parameter.

I am all for a= general solution for this but I think the issue with Connect is overstated= sometimes.

John B.
=C2=A0
On Jul 27, 2017, at 5:19 P= M, Phil Hunt <= phil.hunt@oracle.com> wrote:

We have the use case in SECEVENTS where a logout= event (e.g. OIDF backchannel logout) is extremely close to an ID_TOKEN.=C2= =A0

Older relying parties who are do not yet support log= out could be tricked into accepting a logout assertion as an ID_TOKEN since= they are too similar, and =C2=A0because a valid ID_TOKEN parser is in theo= ry allowed to ignore claims it does not understand (e.g. =E2=80=9Cevents=E2= =80=9D) - leading to a possible erroneous acceptance of the logout event AS= and ID_TOKEN.

Because of this the issue of distin= guishing classes or types of JWTs emerged.

We disc= ussed a number of differentiators like =E2=80=9Caud=E2=80=9D, =E2=80=9Ctyp= =E2=80=9D, =E2=80=9Ccrit", etc that would help.=C2=A0 But that really = lead to the idea there there should be some best practices in the JWT BCP c= overing the issue(s).

Phil

Oracle Corporation, Identity Cloud Services = Architect & Standards
@independentid
phil.hunt@oracle.com

On Jul 27, 2017, at 2:00 PM, Nathan= iel McCallum <npmccallum@redhat.com> wrote:

Even after reading the whole section,= I still don't understand the
problem. Yes, a class of attack could = exist where an attacker
substitutes a valid JWT from one security contex= t into another
context. But isn't this resolved by audience validati= on?

On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
<bcampbell@pingiden= tity.com> wrote:
The draft describes it= in
https://urldefense.proofpoint.com/v2/url?u= =3Dhttps-3A__tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2D= bcp-2D01-23section-2D2.7&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZ= YR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjW= wlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQ= sC52A&s=3D9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e= =3D

On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <npmccallum@redhat.c= om>
wrote:

What class of attacks= is this trying to prevent? I frankly don't see a
problem with confu= sing different types of JWT. But I may just be
ignorant.

On Thu, = Jul 27, 2017 at 2:49 PM, Brian Campbell
<bcampbell@pingidentity.com> wrot= e:
During the first WG meeting last week I ask= ed if use of the JOSE "crit"
(Critical) Header Parameter had b= een considered as a recommendation for
preventing confusion of one kind = of JWT for another. Time was running
short
in the meeting so there wa= sn't much discussion and it was requested that
I
take the questio= n to the list. And so here on the list is that.

Section 3.9 of the J= WT BCP draft now recommends explicit typing using
the
"typ"= JWS/JWE header parameter but does concede that 'the use of
explicit=
typing may not achieve disambiguation from existing kinds of JWTs, asthe
validation rules for existing kinds JWTs often do not use the &quo= t;typ"
header
parameter value.' =C2=A0And the recommendation= s for how to use the Type
Header
Parameter in JWT strongly suggest th= at it's not currently being used for
any
validation.

Alter= natively using the JWS/JWE "crit" (Critical) Header Parameter to<= br>signal
the type/intent/profile/application of a JWT could achiev= e
disambiguation
even in validation of existing kinds of JWTs. The cr= itical header lists
other headers which must be understood and processed= by the receiver and
that the JWS/JWE is invalid if those listed aren= 9;t understood. So a new
type/profile of JWT that uses the "crit&qu= ot; header would produce JWTs that
would be rejected even by existing ap= plications of JWT validation (that
actually implement "crit" p= roperly anyway).

The JWT BCP could suggest the use of "crit&quo= t; in conjunction with a
profile/application/type specific header. Or it= could provide a bit more
of
a framework like defining a registering = a new JOSE header "p" (strawman
of p
as a very short name f= or profile) and create a registry for its values.
A
JWT header using = that approach might look like the following where the
value
1 is regi= stered as some cool new JWT profile/application. The consumer
of
such= a JWT would have to understand and process the "p" header, which=
would
mean checking that it had the value expected.

=C2=A0= =C2=A0=C2=A0=C2=A0{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"alg":"= ;ES256",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"crit":["p&q= uot;],
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"p":1
=C2=A0=C2=A0= =C2=A0=C2=A0}

A JOSE compliant JWT validator would reject such a JWT= even for an OAuth
access token or OIDC id_token because the "p&quo= t; header isn't known or
understood but is marked as critical.
To me, that seems like an approach to preventing confusion that has more<= br>teeth than the "typ" header. Which is why I asked about it las= t week and
am
now bringing it to the list.









CONFIDENTIALITY NOTICE: This email may contain confidentia= l and
privileged
material for the sole use of the intended recipient(= s). Any review, use,
distribution or disclosure by others is strictly pr= ohibited.=C2=A0 If you
have
received this communication in error, ple= ase notify the sender
immediately
by e-mail and delete the message an= d any file attachments from your
computer. Thank you.
_______________= ________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/= v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jose&d=3DD= wICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r= =3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWn= zzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E1= 6U1q_KpobaeSRUP4Cp2W-_jJU&e=3D




CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged
material for the sole use of the intended recipient(s). A= ny review, use,
distribution or disclosure by others is strictly prohibi= ted.=C2=A0 If you have
received this communication in error, please noti= fy the sender immediately
by e-mail and delete the message and any file = attachments from your
computer. Thank you.

_________= ______________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jose&= ;d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&a= mp;r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D0= 2yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RD= l_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D

______________________= _________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth


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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f403045cdcc4668e18055553d548-- From nobody Thu Jul 27 15:24:14 2017 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 A0798131D14 for ; Thu, 27 Jul 2017 15:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMc2JpDurVVv for ; Thu, 27 Jul 2017 15:24:07 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142C5131D06 for ; Thu, 27 Jul 2017 15:24:06 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id a18so52439275qta.0 for ; Thu, 27 Jul 2017 15:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bHQ/3n3xTxgMQdA/CLZGBllzXdCGxoU+Tj48yNjba4E=; b=0KN/RVDBVj9cLVQbqTNKzEf/9SZTD19TDapTPFen0XhUhC9x6pHCiIHLUCgSqVhRQB GaOCkYVbNk9y4dXyKXm7Is0dTjCMksIU9SE2ha2C6NU3I/wEwe7/74y4gc0qStPbX/7l wPBTVSirZQtxCR8PHLeyESWhR60qlqny1VChABkinceG5ae7RoUFf6hPjwanSbC79VWr e+ENuL+Nw5aHdibHFWVY2GLotWzWt+JEissQJfQ9I+qsSfwUqFUSCuQawH1aMuDHfIm+ bBAe52sGIK+TcinIyX78z2uo8qSn8YCjg9MR6CqJTDC+dZZOjh/8bNT5x330MQCuUTzX /goQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bHQ/3n3xTxgMQdA/CLZGBllzXdCGxoU+Tj48yNjba4E=; b=hC+MZh6pYXqNvDrqcChThG/bVznUBv2+RfT5fOGt1Q1dFD0pmYGfKK+/yyNWRXGgwm LCRNF1KQA2ZQ+AvxYbzONx/nW1wdDsx04Feir7d+F7Ui6bfhO1mXgUOdLGYPgd28V+JM xGx2uDt/7y16q8MxYuOoXXt7hwA5lIU9z0h5ZTJ1iwTGqAbxWqeDvKJIER0dlju6stLy IDXeFvwF76ZW4v1vZBPO654EI47w25F+GfHhVl5Y0BlaFte7ltF1Yi2zsWw6u8eTg+db bdCyw9qGkdKgycHqY2YS3yKEQoqxSy35w/96+fJsUEX5eNLbpBRqhyTe4YfJOJG8urmS Ih1Q== X-Gm-Message-State: AIVw1129UZAXd1urrmTaraUaB7HaKUYtxyuAsahlFOfhuCI2i5dF4qCp d6r9GAYHmiMr3zRM X-Received: by 10.200.47.93 with SMTP id k29mr8230563qta.18.1501194245859; Thu, 27 Jul 2017 15:24:05 -0700 (PDT) Received: from johns-mbp.lan ([191.115.36.222]) by smtp.gmail.com with ESMTPSA id j95sm5797721qte.4.2017.07.27.15.23.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 15:24:05 -0700 (PDT) From: John Bradley Message-Id: <81AD4E5B-BBC7-4E7A-8075-EB43BC3962F8@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 27 Jul 2017 18:23:55 -0400 In-Reply-To: Cc: Phil Hunt , Nathaniel McCallum , oauth , "jose@ietf.org" To: Brian Campbell References: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com> X-Mailer: Apple Mail (2.3273) Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11356e54ca28c00555540539" Archived-At: Subject: Re: [jose] [OAUTH-WG] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 22:24:12 -0000 --001a11356e54ca28c00555540539 Content-Type: multipart/alternative; boundary="Apple-Mail=_6C8C6C72-8D1C-4303-919C-CA9F66FEBFDB" --Apple-Mail=_6C8C6C72-8D1C-4303-919C-CA9F66FEBFDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My only concern with a crit header is that it is potentially another = layering violation. It really should be the application and not JWS/JWE that determines if = the content of the JWT is correct at a application layer. To get your idea to work the application would need to push down to the = JWT layer some value/s of p that it was willing to accept. Without = crit the application could just pass along typ or p to the application = layer for matching. I don=E2=80=99t hate the idea but it seems like it is likely to work = against having generic JOSE libs separate from JWT. Perhaps that is the = reality anyway. How would you implement it? John B. > On Jul 27, 2017, at 6:10 PM, Brian Campbell = wrote: >=20 > I wouldn't disagree that the issue with Connect is overstated = sometimes. And it's a non-issue with sec event due to the "nonce" claim = (as you point out) as well as the omission of the "exp" claim. Assuming = correct validation anyway.=20 >=20 > The BCP draft suggests explicit typing to prevent Cross-JWT Confusion = more generally (not just sec events and id tokens). I was wondering if = some use of "crit" might accomplish the same thing but also cover the = case of existing JWT implementations being confused with new JWT = profiles.=20 >=20 > On Thu, Jul 27, 2017 at 3:40 PM, John Bradley > wrote: > Not that I am against the general desire for JWT not to be confused, = but the attack surface for someone to take a sec event from one context = and replay it as a id_token to login is very small and if the client is = correctly configured would not work as it is now. >=20 > The only way you could replay the sec event JWT is via the implicit = flow. The other flows would require a malicious AS and at that point = you have bigger problems with a compromised token endpoint. >=20 > If you were to create a implicit response with the sec event token = that has the correct issuer and aud, connect requires that nonce value = from the request be present in the id_token. This would require that = the attacker somehow get the AS to put not only the claim but the = correct value from the request into the token. >=20 > All in all I think that it is more likely (not 100% I admit) that a = client will do that rather than checking the typ or a new crit JWT = header parameter. >=20 > I am all for a general solution for this but I think the issue with = Connect is overstated sometimes. >=20 > John B. > =20 >> On Jul 27, 2017, at 5:19 PM, Phil Hunt > wrote: >>=20 >> We have the use case in SECEVENTS where a logout event (e.g. OIDF = backchannel logout) is extremely close to an ID_TOKEN.=20 >>=20 >> Older relying parties who are do not yet support logout could be = tricked into accepting a logout assertion as an ID_TOKEN since they are = too similar, and because a valid ID_TOKEN parser is in theory allowed = to ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) = - leading to a possible erroneous acceptance of the logout event AS and = ID_TOKEN. >>=20 >> Because of this the issue of distinguishing classes or types of JWTs = emerged. >>=20 >> We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, = =E2=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc that would help. But that = really lead to the idea there there should be some best practices in the = JWT BCP covering the issue(s). >>=20 >> Phil >>=20 >> Oracle Corporation, Identity Cloud Services Architect & Standards >> @independentid >> www.independentid.com = phil.hunt@oracle.com = >>> On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum = > wrote: >>>=20 >>> Even after reading the whole section, I still don't understand the >>> problem. Yes, a class of attack could exist where an attacker >>> substitutes a valid JWT from one security context into another >>> context. But isn't this resolved by audience validation? >>>=20 >>> On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell >>> > = wrote: >>>> The draft describes it in >>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html= _draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=3DDwICAg&c=3DR= oP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEiv= zjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPC= ouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D = =20 >>>>=20 >>>> On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum = > >>>> wrote: >>>>>=20 >>>>> What class of attacks is this trying to prevent? I frankly don't = see a >>>>> problem with confusing different types of JWT. But I may just be >>>>> ignorant. >>>>>=20 >>>>> On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell >>>>> > = wrote: >>>>>> During the first WG meeting last week I asked if use of the JOSE = "crit" >>>>>> (Critical) Header Parameter had been considered as a = recommendation for >>>>>> preventing confusion of one kind of JWT for another. Time was = running >>>>>> short >>>>>> in the meeting so there wasn't much discussion and it was = requested that >>>>>> I >>>>>> take the question to the list. And so here on the list is that. >>>>>>=20 >>>>>> Section 3.9 of the JWT BCP draft now recommends explicit typing = using >>>>>> the >>>>>> "typ" JWS/JWE header parameter but does concede that 'the use of >>>>>> explicit >>>>>> typing may not achieve disambiguation from existing kinds of = JWTs, as >>>>>> the >>>>>> validation rules for existing kinds JWTs often do not use the = "typ" >>>>>> header >>>>>> parameter value.' And the recommendations for how to use the = Type >>>>>> Header >>>>>> Parameter in JWT strongly suggest that it's not currently being = used for >>>>>> any >>>>>> validation. >>>>>>=20 >>>>>> Alternatively using the JWS/JWE "crit" (Critical) Header = Parameter to >>>>>> signal >>>>>> the type/intent/profile/application of a JWT could achieve >>>>>> disambiguation >>>>>> even in validation of existing kinds of JWTs. The critical header = lists >>>>>> other headers which must be understood and processed by the = receiver and >>>>>> that the JWS/JWE is invalid if those listed aren't understood. So = a new >>>>>> type/profile of JWT that uses the "crit" header would produce = JWTs that >>>>>> would be rejected even by existing applications of JWT validation = (that >>>>>> actually implement "crit" properly anyway). >>>>>>=20 >>>>>> The JWT BCP could suggest the use of "crit" in conjunction with a >>>>>> profile/application/type specific header. Or it could provide a = bit more >>>>>> of >>>>>> a framework like defining a registering a new JOSE header "p" = (strawman >>>>>> of p >>>>>> as a very short name for profile) and create a registry for its = values. >>>>>> A >>>>>> JWT header using that approach might look like the following = where the >>>>>> value >>>>>> 1 is registered as some cool new JWT profile/application. The = consumer >>>>>> of >>>>>> such a JWT would have to understand and process the "p" header, = which >>>>>> would >>>>>> mean checking that it had the value expected. >>>>>>=20 >>>>>> { >>>>>> "alg":"ES256", >>>>>> "crit":["p"], >>>>>> "p":1 >>>>>> } >>>>>>=20 >>>>>> A JOSE compliant JWT validator would reject such a JWT even for = an OAuth >>>>>> access token or OIDC id_token because the "p" header isn't known = or >>>>>> understood but is marked as critical. >>>>>>=20 >>>>>> To me, that seems like an approach to preventing confusion that = has more >>>>>> teeth than the "typ" header. Which is why I asked about it last = week and >>>>>> am >>>>>> now bringing it to the list. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>> privileged >>>>>> material for the sole use of the intended recipient(s). Any = review, use, >>>>>> distribution or disclosure by others is strictly prohibited. If = you >>>>>> have >>>>>> received this communication in error, please notify the sender >>>>>> immediately >>>>>> by e-mail and delete the message and any file attachments from = your >>>>>> computer. Thank you. >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10= &r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSn= cXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D= = =20 >>>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged >>>> material for the sole use of the intended recipient(s). Any review, = use, >>>> distribution or disclosure by others is strictly prohibited. If = you have >>>> received this communication in error, please notify the sender = immediately >>>> by e-mail and delete the message and any file attachments from your >>>> computer. Thank you. >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10= &r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSn= cXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D= = =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_6C8C6C72-8D1C-4303-919C-CA9F66FEBFDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My only concern with a crit header is that it is potentially = another layering violation.

It really should be the application and not JWS/JWE that = determines if the content of the JWT is correct at a application = layer.

To get = your idea to work the application would need to push down to the JWT = layer some value/s of p that it was willing to accept.   Without = crit the application could just pass along typ or p to the application = layer for matching.

I don=E2=80=99t hate the idea but it seems like it is likely = to work against having generic JOSE libs separate from JWT. Perhaps that = is the reality anyway.

How would you implement it?

John B.

On = Jul 27, 2017, at 6:10 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

I wouldn't disagree that the issue with = Connect is overstated sometimes. And it's a non-issue with sec event due = to the "nonce" claim (as you point out) as well as the omission of the = "exp" claim. Assuming correct validation anyway.

The BCP draft suggests explicit typing to prevent = Cross-JWT Confusion more generally (not just sec events and id tokens). = I was wondering if some use of "crit" might accomplish the same thing = but also cover the case of existing JWT implementations being confused = with new JWT profiles.
On Thu, Jul 27, 2017 at 3:40 PM, = John Bradley <ve7jtb@ve7jtb.com> wrote:
Not that I am against the = general desire for JWT not to be confused, but the attack surface for = someone to take a sec event from one context and replay it as a id_token = to login is very small and if the client is correctly configured would = not work as it is now.

The only way you could replay the sec event JWT is via the = implicit flow.   The other flows would require a malicious AS and = at that point you have bigger problems with a compromised token = endpoint.

If = you were to create a implicit response with the sec event token that has = the correct issuer and aud, connect requires that nonce value from the = request be present in the id_token.   This would require that the = attacker somehow get the AS to put not only the claim but the correct = value from the request into the token.

All in all I think that it is more = likely (not 100% I admit) that a client will do that rather than = checking the typ or a new crit JWT header parameter.

I am all for a general = solution for this but I think the issue with Connect is overstated = sometimes.

John = B.
 
On Jul 27, 2017, at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

We have the use case in = SECEVENTS where a logout event (e.g. OIDF backchannel logout) is = extremely close to an ID_TOKEN. 

Older relying parties who are do not = yet support logout could be tricked into accepting a logout assertion as = an ID_TOKEN since they are too similar, and  because a valid = ID_TOKEN parser is in theory allowed to ignore claims it does not = understand (e.g. =E2=80=9Cevents=E2=80=9D) - leading to a possible = erroneous acceptance of the logout event AS and ID_TOKEN.

Because of this the = issue of distinguishing classes or types of JWTs emerged.

We discussed a number of = differentiators like =E2=80=9Caud=E2=80=9D, =E2=80=9Ctyp=E2=80=9D, = =E2=80=9Ccrit", etc that would help.  But that really lead to the = idea there there should be some best practices in the JWT BCP covering = the issue(s).

<= div style=3D"word-wrap:break-word" class=3D"">
Phil

Oracle Corporation, Identity Cloud = Services Architect & Standards
@independentid
www.independentid.com
phil.hunt@oracle.com

On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:

Even after reading the whole section, I still = don't understand the
problem. Yes, a class of attack could = exist where an attacker
substitutes a valid JWT from one = security context into another
context. But isn't this = resolved by audience validation?

On Thu, = Jul 27, 2017 at 3:34 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
The draft describes it = in
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D

On = Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum <npmccallum@redhat.com>
wrote:

What = class of attacks is this trying to prevent? I frankly don't see a
problem with confusing different types of JWT. But I may just = be
ignorant.

On Thu, Jul 27, = 2017 at 2:49 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:
During the first WG = meeting last week I asked if use of the JOSE "crit"
(Critical) Header Parameter had been considered as a = recommendation for
preventing confusion of one kind of JWT = for another. Time was running
short
in the = meeting so there wasn't much discussion and it was requested that
I
take the question to the list. And so here on = the list is that.

Section 3.9 of the JWT = BCP draft now recommends explicit typing using
the
"typ" JWS/JWE header parameter but does concede that 'the use = of
explicit
typing may not achieve = disambiguation from existing kinds of JWTs, as
the
validation rules for existing kinds JWTs often do not use the = "typ"
header
parameter value.'  And the = recommendations for how to use the Type
Header
Parameter in JWT strongly suggest that it's not currently = being used for
any
validation.

Alternatively using the JWS/JWE "crit" = (Critical) Header Parameter to
signal
the = type/intent/profile/application of a JWT could = achieve
disambiguation
even in validation of = existing kinds of JWTs. The critical header lists
other = headers which must be understood and processed by the receiver and
that the JWS/JWE is invalid if those listed aren't = understood. So a new
type/profile of JWT that uses the = "crit" header would produce JWTs that
would be rejected = even by existing applications of JWT validation (that
actually implement "crit" properly anyway).

The JWT BCP could suggest the use of "crit" in conjunction = with a
profile/application/type specific header. Or it = could provide a bit more
of
a framework like = defining a registering a new JOSE header "p" (strawman
of = p
as a very short name for profile) and create a registry = for its values.
A
JWT header using that = approach might look like the following where the
value
1 is registered as some cool new JWT profile/application. The = consumer
of
such a JWT would have to = understand and process the "p" header, which
would
mean checking that it had the value expected.
    {
=      "alg":"ES256",
=      "crit":["p"],
=      "p":1
=     }

A JOSE compliant = JWT validator would reject such a JWT even for an OAuth
access token or OIDC id_token because the "p" header isn't = known or
understood but is marked as critical.

To me, that seems like an approach to = preventing confusion that has more
teeth than the "typ" = header. Which is why I asked about it last week and
am
now bringing it to the list.









CONFIDENTIALITY = NOTICE: This email may contain confidential and
privileged
material for the sole use of the = intended recipient(s). Any review, use,
distribution or = disclosure by others is strictly prohibited.  If you
have
received this communication in error, = please notify the sender
immediately
by = e-mail and delete the message and any file attachments from your
computer. Thank you.
_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D =



CONFIDENTIALITY NOTICE: This email may = contain confidential and privileged
material for the sole = use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly = prohibited.  If you have
received this communication = in error, please notify the sender immediately
by e-mail = and delete the message and any file attachments from your
computer. Thank you.

_______________________________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D =

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


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



CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.

= --Apple-Mail=_6C8C6C72-8D1C-4303-919C-CA9F66FEBFDB-- --001a11356e54ca28c00555540539 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIF83m8R13XOmBGOo6sruG+fqc4yK pfdJWmVpQZ7bS1blMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDcyNzIyMjQwNlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQC10Ju56P9mVjQInaY5UU0xepweILOK4wYXBGHKY1/30MIs kg5coT54EsawpVfqG/Y/1Bb45VgJAJ6K9ahkkZdaUWaV5vEb9U6dEb/phDrgcAqIVf4HEg1iMxfF qAbV+BugMTs3ugVN7sNH3edqDeW6JB7gAfOAFTnp156zucFVOZgey6BJYduhHcRqzQniCJENr32B SvYHOsrH7b6cuXq7kytbYjbOdifuH24ocaC/7wOfJIFTFYFNvnSyTeYV79TXWRS91+/LAwkUfdzo qphnghFppirPr3t1PzjxSPc4vq1VrPPwwDI561JM46F1dFXgPcdtyM0sYTD6Xl6Nt/S/ --001a11356e54ca28c00555540539-- From nobody Thu Jul 27 15:57:08 2017 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 09D4A1321F6; Thu, 27 Jul 2017 15:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fCVa4EUm6Y3; Thu, 27 Jul 2017 15:56:53 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1CA1321F3; Thu, 27 Jul 2017 15:56:53 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_022F_01D306F0.ED22B9B0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1501196183; h=from:subject:to:date:message-id; bh=PhfY0UlwMtbO14uZbH5xY1zDC3lAf3oSHjYmbwGP5Uc=; b=EaVaYdrUZUjVo+38y8NHqO2pCpPT/1GI5oPWOonlS5+40zbyWTS9XpRSffJ2hfL4NBRhsLyBgaz 9i+UQOBt7Vz5i/PJwqV3gP1pZqGYAbNV22x59fdGAf7joYkeT+yJgO6BktEMjp4JKrJO7klZKCMEC op2r6cbJtiU3p4+NBJZ7dW6FGBQfHRx8qgvGQsIieWH4xwK0pARiGFF+5+NqueE06ZYoVgVV0Z/LO oqxgV31lDE/8HVC1AFENsLEdB5cULP0AYR84qn8jPIiFHCkZEmmrzCFZk4NllNtc4uQc3STVWkL+P 7whX31V8l1c6qIYSmRc6WodGvvWNpiIZv69g== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 15:56:22 -0700 Received: from Hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 15:56:16 -0700 From: Jim Schaad To: 'John Bradley' , 'Brian Campbell' CC: 'Nathaniel McCallum' , 'oauth' , , 'Phil Hunt' References: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com> <81AD4E5B-BBC7-4E7A-8075-EB43BC3962F8@ve7jtb.com> In-Reply-To: <81AD4E5B-BBC7-4E7A-8075-EB43BC3962F8@ve7jtb.com> Date: Thu, 27 Jul 2017 15:56:31 -0700 Message-ID: <022e01d3072b$997eab80$cc7c0280$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKHH2VI+OeMwPc+ZUkxtnVaGSt4zgKKIEysAp0kgMUCgqvlGAE7vSrFAkDebrACu261lgGhbu7joIP805A= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [jose] [OAUTH-WG] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 22:56:58 -0000 ------=_NextPart_000_022F_01D306F0.ED22B9B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable One simple way to implement it would be to have an call which says = =E2=80=9CI will deal with the following items if they exist=E2=80=9D. = This means that all the application needs to do is to say that it will = process p and not what values are acceptable. =20 Jim =20 =20 From: jose [mailto:jose-bounces@ietf.org] On Behalf Of John Bradley Sent: Thursday, July 27, 2017 3:24 PM To: Brian Campbell Cc: Nathaniel McCallum ; oauth ; = jose@ietf.org; Phil Hunt Subject: Re: [jose] [OAUTH-WG] preventing confusion of one kind of JWT = for another in JWT BCP =20 My only concern with a crit header is that it is potentially another = layering violation. =20 It really should be the application and not JWS/JWE that determines if = the content of the JWT is correct at a application layer. =20 To get your idea to work the application would need to push down to the = JWT layer some value/s of p that it was willing to accept. Without = crit the application could just pass along typ or p to the application = layer for matching. =20 I don=E2=80=99t hate the idea but it seems like it is likely to work = against having generic JOSE libs separate from JWT. Perhaps that is the = reality anyway. =20 How would you implement it? =20 John B. =20 On Jul 27, 2017, at 6:10 PM, Brian Campbell > wrote: =20 I wouldn't disagree that the issue with Connect is overstated sometimes. = And it's a non-issue with sec event due to the "nonce" claim (as you = point out) as well as the omission of the "exp" claim. Assuming correct = validation anyway.=20 The BCP draft suggests explicit typing to prevent Cross-JWT Confusion = more generally (not just sec events and id tokens). I was wondering if = some use of "crit" might accomplish the same thing but also cover the = case of existing JWT implementations being confused with new JWT = profiles.=20 =20 On Thu, Jul 27, 2017 at 3:40 PM, John Bradley > wrote: Not that I am against the general desire for JWT not to be confused, but = the attack surface for someone to take a sec event from one context and = replay it as a id_token to login is very small and if the client is = correctly configured would not work as it is now. =20 The only way you could replay the sec event JWT is via the implicit = flow. The other flows would require a malicious AS and at that point = you have bigger problems with a compromised token endpoint. =20 If you were to create a implicit response with the sec event token that = has the correct issuer and aud, connect requires that nonce value from = the request be present in the id_token. This would require that the = attacker somehow get the AS to put not only the claim but the correct = value from the request into the token. =20 All in all I think that it is more likely (not 100% I admit) that a = client will do that rather than checking the typ or a new crit JWT = header parameter. =20 I am all for a general solution for this but I think the issue with = Connect is overstated sometimes. =20 John B. =20 On Jul 27, 2017, at 5:19 PM, Phil Hunt > wrote: =20 We have the use case in SECEVENTS where a logout event (e.g. OIDF = backchannel logout) is extremely close to an ID_TOKEN.=20 =20 Older relying parties who are do not yet support logout could be tricked = into accepting a logout assertion as an ID_TOKEN since they are too = similar, and because a valid ID_TOKEN parser is in theory allowed to = ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) - = leading to a possible erroneous acceptance of the logout event AS and = ID_TOKEN. =20 Because of this the issue of distinguishing classes or types of JWTs = emerged. =20 We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, = =E2=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc that would help. But that = really lead to the idea there there should be some best practices in the = JWT BCP covering the issue(s). =20 Phil =20 Oracle Corporation, Identity Cloud Services Architect & Standards @independentid www.independentid.com =20 phil.hunt@oracle.com =20 =20 On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum > wrote: =20 Even after reading the whole section, I still don't understand the problem. Yes, a class of attack could exist where an attacker substitutes a valid JWT from one security context into another context. But isn't this resolved by audience validation? On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell > wrote: The draft describes it in https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7 = = &d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrK= ugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTr= tBfQsC52A&s=3D9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D=20 On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum = > wrote: What class of attacks is this trying to prevent? I frankly don't see a problem with confusing different types of JWT. But I may just be ignorant. On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell > wrote: During the first WG meeting last week I asked if use of the JOSE "crit" (Critical) Header Parameter had been considered as a recommendation for preventing confusion of one kind of JWT for another. Time was running short in the meeting so there wasn't much discussion and it was requested that I take the question to the list. And so here on the list is that. Section 3.9 of the JWT BCP draft now recommends explicit typing using the "typ" JWS/JWE header parameter but does concede that 'the use of explicit typing may not achieve disambiguation from existing kinds of JWTs, as the validation rules for existing kinds JWTs often do not use the "typ" header parameter value.' And the recommendations for how to use the Type Header Parameter in JWT strongly suggest that it's not currently being used for any validation. Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to signal the type/intent/profile/application of a JWT could achieve disambiguation even in validation of existing kinds of JWTs. The critical header lists other headers which must be understood and processed by the receiver and that the JWS/JWE is invalid if those listed aren't understood. So a new type/profile of JWT that uses the "crit" header would produce JWTs that would be rejected even by existing applications of JWT validation (that actually implement "crit" properly anyway). The JWT BCP could suggest the use of "crit" in conjunction with a profile/application/type specific header. Or it could provide a bit more of a framework like defining a registering a new JOSE header "p" (strawman of p as a very short name for profile) and create a registry for its values. A JWT header using that approach might look like the following where the value 1 is registered as some cool new JWT profile/application. The consumer of such a JWT would have to understand and process the "p" header, which would mean checking that it had the value expected. { "alg":"ES256", "crit":["p"], "p":1 } A JOSE compliant JWT validator would reject such a JWT even for an OAuth access token or OIDC id_token because the "p" header isn't known or understood but is marked as critical. To me, that seems like an approach to preventing confusion that has more teeth than the "typ" header. Which is why I asked about it last week and am now bringing it to the list. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________ jose mailing list jose@ietf.org =20 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_jose = = &d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrK= ugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTr= tBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D=20 CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you = have received this communication in error, please notify the sender = immediately by e-mail and delete the message and any file attachments from your computer. Thank you. _______________________________________________ jose mailing list jose@ietf.org =20 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_jose = = &d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrK= ugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTr= tBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D=20 =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. =20 ------=_NextPart_000_022F_01D306F0.ED22B9B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

One simple = way to implement it would be to have an call which says =E2=80=9CI will = deal with the following items if they exist=E2=80=9D.=C2=A0 This means = that all the application needs to do is to say that it will process p = and not what values are acceptable.

 

Jim

 

 

From: jose = [mailto:jose-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Thursday, July 27, 2017 3:24 PM
To: = Brian Campbell <bcampbell@pingidentity.com>
Cc: = Nathaniel McCallum <npmccallum@redhat.com>; oauth = <oauth@ietf.org>; jose@ietf.org; Phil Hunt = <phil.hunt@oracle.com>
Subject: Re: [jose] [OAUTH-WG] = preventing confusion of one kind of JWT for another in JWT = BCP

 

My only = concern with a crit header is that it is potentially another layering = violation.

 

It really should be the application and not JWS/JWE = that determines if the content of the JWT is correct at a application = layer.

 

To get your idea to work the application would need to = push down to the JWT layer some value/s of p that it was willing to = accept.   Without crit the application could just pass along typ or = p to the application layer for matching.

 

I = don=E2=80=99t hate the idea but it seems like it is likely to work = against having generic JOSE libs separate from JWT. Perhaps that is the = reality anyway.

 

How would you implement = it?

 

John B.

 

On Jul 27, 2017, at 6:10 PM, Brian Campbell <bcampbell@pingidentity.com= > wrote:

 

I wouldn't disagree = that the issue with Connect is overstated sometimes. And it's a = non-issue with sec event due to the "nonce" claim (as you = point out) as well as the omission of the "exp" claim. = Assuming correct validation anyway.

The BCP draft suggests explicit typing to prevent = Cross-JWT Confusion more generally (not just sec events and id tokens). = I was wondering if some use of "crit" might accomplish the = same thing but also cover the case of existing JWT implementations being = confused with new JWT profiles.

 

On Thu, = Jul 27, 2017 at 3:40 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

Not = that I am against the general desire for JWT not to be confused, but the = attack surface for someone to take a sec event from one context and = replay it as a id_token to login is very small and if the client is = correctly configured would not work as it is now.

 

The only way you could replay the sec event JWT is via = the implicit flow.   The other flows would require a malicious AS = and at that point you have bigger problems with a compromised token = endpoint.

 

If you were to create a implicit response with the sec = event token that has the correct issuer and aud, connect requires that = nonce value from the request be present in the id_token.   This = would require that the attacker somehow get the AS to put not only the = claim but the correct value from the request into the = token.

 

All in all I think that it is more likely (not 100% I = admit) that a client will do that rather than checking the typ or a new = crit JWT header parameter.

 

I = am all for a general solution for this but I think the issue with = Connect is overstated sometimes.

 

John B.

 

On Jul 27, 2017, at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

 

We have the use case in SECEVENTS where a logout = event (e.g. OIDF backchannel logout) is extremely close to an = ID_TOKEN. 

 

Older relying parties who are do not yet support = logout could be tricked into accepting a logout assertion as an ID_TOKEN = since they are too similar, and  because a valid ID_TOKEN parser is = in theory allowed to ignore claims it does not understand (e.g. = =E2=80=9Cevents=E2=80=9D) - leading to a possible erroneous acceptance = of the logout event AS and ID_TOKEN.

 

Because of this the issue of distinguishing classes or = types of JWTs emerged.

 

We discussed a number of differentiators like = =E2=80=9Caud=E2=80=9D, =E2=80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc = that would help.  But that really lead to the idea there there = should be some best practices in the JWT BCP covering the = issue(s).

 

Phil

 

Oracle Corporation, Identity Cloud Services Architect = & Standards

@independentid

phil.hunt@oracle.com

 

On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum <npmccallum@redhat.com> = wrote:

 

Even after reading the whole section, I still don't = understand the
problem. Yes, a class of attack could exist where an = attacker
substitutes a valid JWT from one security context into = another
context. But isn't this resolved by audience = validation?

On Thu, Jul 27, 2017 at 3:34 PM, Brian = Campbell
<bcampbell@pingidentity.com> = wrote:

The = draft describes it in
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= tools.ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D= 2.7&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&am= p;r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefgV= regxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQ= CVja_kY&e=3D

On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel = McCallum <npmccallum@redhat.com>
wrote:


What class of attacks is this trying to prevent? I = frankly don't see a
problem with confusing different types of JWT. = But I may just be
ignorant.

On Thu, Jul 27, 2017 at 2:49 PM, = Brian Campbell
<bcampbell@pingidentity.com> = wrote:

During the first WG meeting last week I = asked if use of the JOSE "crit"
(Critical) Header Parameter = had been considered as a recommendation for
preventing confusion of = one kind of JWT for another. Time was running
short
in the meeting = so there wasn't much discussion and it was requested that
I
take = the question to the list. And so here on the list is = that.

Section 3.9 of the JWT BCP draft now recommends explicit = typing using
the
"typ" JWS/JWE header parameter but does = concede that 'the use of
explicit
typing may not achieve = disambiguation from existing kinds of JWTs, as
the
validation = rules for existing kinds JWTs often do not use the = "typ"
header
parameter value.'  And the = recommendations for how to use the Type
Header
Parameter in JWT = strongly suggest that it's not currently being used = for
any
validation.

Alternatively using the JWS/JWE = "crit" (Critical) Header Parameter to
signal
the = type/intent/profile/application of a JWT could = achieve
disambiguation
even in validation of existing kinds of = JWTs. The critical header lists
other headers which must be = understood and processed by the receiver and
that the JWS/JWE is = invalid if those listed aren't understood. So a new
type/profile of = JWT that uses the "crit" header would produce JWTs = that
would be rejected even by existing applications of JWT = validation (that
actually implement "crit" properly = anyway).

The JWT BCP could suggest the use of "crit" in = conjunction with a
profile/application/type specific header. Or it = could provide a bit more
of
a framework like defining a = registering a new JOSE header "p" (strawman
of p
as a = very short name for profile) and create a registry for its = values.
A
JWT header using that approach might look like the = following where the
value
1 is registered as some cool new JWT = profile/application. The consumer
of
such a JWT would have to = understand and process the "p" header, which
would
mean = checking that it had the value = expected.

    {
    &nb= sp;"alg":"ES256",
     &q= uot;crit":["p"],
     "p&= quot;:1
    }

A JOSE compliant JWT = validator would reject such a JWT even for an OAuth
access token or = OIDC id_token because the "p" header isn't known = or
understood but is marked as critical.

To me, that seems = like an approach to preventing confusion that has more
teeth than the = "typ" header. Which is why I asked about it last week = and
am
now bringing it to the = list.










CONFIDENTIALITY NOTICE: = This email may contain confidential and
privileged
material for = the sole use of the intended recipient(s). Any review, = use,
distribution or disclosure by others is strictly = prohibited.  If you
have
received this communication in = error, please notify the sender
immediately
by e-mail and delete = the message and any file attachments from your
computer. Thank = you.
_______________________________________________
jose mailing = list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= www.ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHv= lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4= C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZ= Bwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D =




CONFIDENTIALITY NOTICE: This email may = contain confidential and privileged
material for the sole use of the = intended recipient(s). Any review, use,
distribution or disclosure by = others is strictly prohibited.  If you have
received this = communication in error, please notify the sender immediately
by = e-mail and delete the message and any file attachments from = your
computer. Thank you.


_______________________________________________
= jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= www.ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHv= lZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4= C_lLIGk&m=3D02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZ= Bwe5AO-RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D =

 

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

 


______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 


CONFIDENTIALITY NOTICE: This email may contain = confidential and privileged material for the sole use of the intended = recipient(s). Any review, use, distribution or disclosure by others is = strictly prohibited.  If you have received this communication in = error, please notify the sender immediately by e-mail and delete the = message and any file attachments from your computer. Thank = you.

 

------=_NextPart_000_022F_01D306F0.ED22B9B0-- From nobody Fri Jul 28 05:23:19 2017 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 03580131FE1 for ; Fri, 28 Jul 2017 05:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUKNPgcfoFpt for ; Fri, 28 Jul 2017 05:23:13 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743D0131945 for ; Fri, 28 Jul 2017 05:23:13 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id z129so55986612pfb.3 for ; Fri, 28 Jul 2017 05:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1VHFSh1xJRM1p8np8Su+U7MoO8GhVpMrH5tkhPSx9iM=; b=G1KiyyPyCuhZ2g1dKc83ML+AOonyit3aw8Z19fReLuAZ2UE5BMw9gqf1s5ITczaQb0 yxOSjO58GJO3hAPRNBjkxXgksfWAmDJHmXyZYbt1CyenqmlUvDfkw8a9RkPXWqmIIuZk S9rPwXL+Mt7YgkdpRs+N3m11JeMp8XukA7sCA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1VHFSh1xJRM1p8np8Su+U7MoO8GhVpMrH5tkhPSx9iM=; b=MgqQyNTOcKEtqBKCya/hGBkinUyTg0GTs46cYqrRlHzMhglLi/VqJb3Z3fw11+tlSs 6XeBVyEKeu4wq3mtnfmyvNd99i2AgKFePoNsdjA24WF/Y2KERqrFGKfcZ2Z+r1MqYF5u 7N9aO6jUkggQRBk+xSLfcO9i9Pp+s63+nDW5vr2A3oZ+NxJlxA2w4jr/RO3e1fhaTxU8 /RyY8qkUXz0FklP8nxro7sp6cit2Ga5q919YWr5GxFk9BYa7DuxyDWOptgsnn3WDcfWD GKKEVFFCIlJ+qRtZ8hRJPOn1IyXLUkqUPOzpgw/Le8Mh9pqlpoGqJAX5IEc9hCTEZ2ec r/7w== X-Gm-Message-State: AIVw111GAH+8IQ/lZnUKBRs/rC/ej7f7/72GIQUBafM2rI0R46fp/6Oh HxSjrcRGxhJ5N8yU545wvhGS7Ahp4527VPxR+ZCZnnTLCGboytj6EeemATcsNWhZv15hFqsQ2OJ tswI= X-Received: by 10.84.236.4 with SMTP id q4mr7667987plk.423.1501244592887; Fri, 28 Jul 2017 05:23:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Fri, 28 Jul 2017 05:22:42 -0700 (PDT) In-Reply-To: <022e01d3072b$997eab80$cc7c0280$@augustcellars.com> References: <91B882A0-48A0-4F08-8ADB-B675D9F1C08F@oracle.com> <7041D358-E4C8-4D8C-BD94-0D65C238B449@ve7jtb.com> <81AD4E5B-BBC7-4E7A-8075-EB43BC3962F8@ve7jtb.com> <022e01d3072b$997eab80$cc7c0280$@augustcellars.com> From: Brian Campbell Date: Fri, 28 Jul 2017 06:22:42 -0600 Message-ID: To: Jim Schaad Cc: John Bradley , Nathaniel McCallum , oauth , "jose@ietf.org" , Phil Hunt Content-Type: multipart/alternative; boundary="f403045fe2d4ae3b3605555fbe89" Archived-At: Subject: Re: [jose] [OAUTH-WG] preventing confusion of one kind of JWT for another in JWT BCP X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 12:23:19 -0000 --f403045fe2d4ae3b3605555fbe89 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yeah, I've implemented it in pretty much in the way Jim describes. In my implementation of JWT validation the application sets things up by pushing down all the info needed for validation (things like expected audience & issuer, keys, allowed algorithms, etc.). So I'm probably biased by that but also telling it that 'p' is okay as a critical header doesn't feel like any more of a layering violation than anything else. This example shows how to use the library for regular JWT validation. This method would be used to tell the JWT validator/consumer that the 'p' as a critical header should be accepted. And then the JWT validator/consumer could be told what value of 'p' is acceptable or required by adding a validator for it or the application code could just look at the headers after and check it that way. That's how it could be done now with the existing general API. If the BCP was to formalize something, I'd probably enhance the API with something specific for it to make it even easier. On Thu, Jul 27, 2017 at 4:56 PM, Jim Schaad wrote: > One simple way to implement it would be to have an call which says =E2=80= =9CI will > deal with the following items if they exist=E2=80=9D. This means that al= l the > application needs to do is to say that it will process p and not what > values are acceptable. > > > > Jim > > > > > > *From:* jose [mailto:jose-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Thursday, July 27, 2017 3:24 PM > *To:* Brian Campbell > *Cc:* Nathaniel McCallum ; oauth ; > jose@ietf.org; Phil Hunt > *Subject:* Re: [jose] [OAUTH-WG] preventing confusion of one kind of JWT > for another in JWT BCP > > > > My only concern with a crit header is that it is potentially another > layering violation. > > > > It really should be the application and not JWS/JWE that determines if th= e > content of the JWT is correct at a application layer. > > > > To get your idea to work the application would need to push down to the > JWT layer some value/s of p that it was willing to accept. Without crit > the application could just pass along typ or p to the application layer f= or > matching. > > > > I don=E2=80=99t hate the idea but it seems like it is likely to work agai= nst > having generic JOSE libs separate from JWT. Perhaps that is the reality > anyway. > > > > How would you implement it? > > > > John B. > > > > On Jul 27, 2017, at 6:10 PM, Brian Campbell > wrote: > > > > I wouldn't disagree that the issue with Connect is overstated sometimes. > And it's a non-issue with sec event due to the "nonce" claim (as you poin= t > out) as well as the omission of the "exp" claim. Assuming correct > validation anyway. > > The BCP draft suggests explicit typing to prevent Cross-JWT Confusion mor= e > generally (not just sec events and id tokens). I was wondering if some us= e > of "crit" might accomplish the same thing but also cover the case of > existing JWT implementations being confused with new JWT profiles. > > > > On Thu, Jul 27, 2017 at 3:40 PM, John Bradley wrote: > > Not that I am against the general desire for JWT not to be confused, but > the attack surface for someone to take a sec event from one context and > replay it as a id_token to login is very small and if the client is > correctly configured would not work as it is now. > > > > The only way you could replay the sec event JWT is via the implicit flow. > The other flows would require a malicious AS and at that point you have > bigger problems with a compromised token endpoint. > > > > If you were to create a implicit response with the sec event token that > has the correct issuer and aud, connect requires that nonce value from th= e > request be present in the id_token. This would require that the attacke= r > somehow get the AS to put not only the claim but the correct value from t= he > request into the token. > > > > All in all I think that it is more likely (not 100% I admit) that a clien= t > will do that rather than checking the typ or a new crit JWT header > parameter. > > > > I am all for a general solution for this but I think the issue with > Connect is overstated sometimes. > > > > John B. > > > > On Jul 27, 2017, at 5:19 PM, Phil Hunt wrote: > > > > We have the use case in SECEVENTS where a logout event (e.g. OIDF > backchannel logout) is extremely close to an ID_TOKEN. > > > > Older relying parties who are do not yet support logout could be tricked > into accepting a logout assertion as an ID_TOKEN since they are too > similar, and because a valid ID_TOKEN parser is in theory allowed to > ignore claims it does not understand (e.g. =E2=80=9Cevents=E2=80=9D) - le= ading to a > possible erroneous acceptance of the logout event AS and ID_TOKEN. > > > > Because of this the issue of distinguishing classes or types of JWTs > emerged. > > > > We discussed a number of differentiators like =E2=80=9Caud=E2=80=9D, =E2= =80=9Ctyp=E2=80=9D, =E2=80=9Ccrit", etc > that would help. But that really lead to the idea there there should be > some best practices in the JWT BCP covering the issue(s). > > > > Phil > > > > Oracle Corporation, Identity Cloud Services Architect & Standards > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > On Jul 27, 2017, at 2:00 PM, Nathaniel McCallum > wrote: > > > > Even after reading the whole section, I still don't understand the > problem. Yes, a class of attack could exist where an attacker > substitutes a valid JWT from one security context into another > context. But isn't this resolved by audience validation? > > On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell > wrote: > > The draft describes it in > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools. > ietf.org_html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01- > 23section-2D2.7&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK1= 0&r=3D > JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D > 9GmPCouCMXE4enC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D > > On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum > > wrote: > > > What class of attacks is this trying to prevent? I frankly don't see a > problem with confusing different types of JWT. But I may just be > ignorant. > > On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell > wrote: > > During the first WG meeting last week I asked if use of the JOSE "crit" > (Critical) Header Parameter had been considered as a recommendation for > preventing confusion of one kind of JWT for another. Time was running > short > in the meeting so there wasn't much discussion and it was requested that > I > take the question to the list. And so here on the list is that. > > Section 3.9 of the JWT BCP draft now recommends explicit typing using > the > "typ" JWS/JWE header parameter but does concede that 'the use of > explicit > typing may not achieve disambiguation from existing kinds of JWTs, as > the > validation rules for existing kinds JWTs often do not use the "typ" > header > parameter value.' And the recommendations for how to use the Type > Header > Parameter in JWT strongly suggest that it's not currently being used for > any > validation. > > Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to > signal > the type/intent/profile/application of a JWT could achieve > disambiguation > even in validation of existing kinds of JWTs. The critical header lists > other headers which must be understood and processed by the receiver and > that the JWS/JWE is invalid if those listed aren't understood. So a new > type/profile of JWT that uses the "crit" header would produce JWTs that > would be rejected even by existing applications of JWT validation (that > actually implement "crit" properly anyway). > > The JWT BCP could suggest the use of "crit" in conjunction with a > profile/application/type specific header. Or it could provide a bit more > of > a framework like defining a registering a new JOSE header "p" (strawman > of p > as a very short name for profile) and create a registry for its values. > A > JWT header using that approach might look like the following where the > value > 1 is registered as some cool new JWT profile/application. The consumer > of > such a JWT would have to understand and process the "p" header, which > would > mean checking that it had the value expected. > > { > "alg":"ES256", > "crit":["p"], > "p":1 > } > > A JOSE compliant JWT validator would reject such a JWT even for an OAuth > access token or OIDC id_token because the "p" header isn't known or > understood but is marked as critical. > > To me, that seems like an approach to preventing confusion that has more > teeth than the "typ" header. Which is why I asked about it last week and > am > now bringing it to the list. > > > > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you > have > received this communication in error, please notify the sender > immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. > _______________________________________________ > jose mailing list > jose@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC= X5Y > TpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO- > RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privilege= d > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediatel= y > by e-mail and delete the message and any file attachments from your > computer. Thank you. > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_jose&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKC= X5Y > TpkKY057SbK10&r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D > 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO- > RDl_E16U1q_KpobaeSRUP4Cp2W-_jJU&e=3D > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > --=20 *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited. If you have= =20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you.* --f403045fe2d4ae3b3605555fbe89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, I've implemented it in pretty much in the w= ay Jim describes.=C2=A0

In my implementation of JWT vali= dation the application sets things up by pushing down all the info needed f= or validation (things like expected audience & issuer, keys, allowed al= gorithms, etc.). So I'm probably biased by that but also telling it tha= t 'p' is okay as a critical header doesn't feel like any more o= f a layering violation than anything else.

This example shows how to use the library for regula= r JWT validation. This method would be used t= o tell the JWT validator/consumer that the 'p' as a critical header= should be accepted. And then the JWT validator/consumer could be told what= value of 'p' is acceptable or required by adding a validator for it or the application code could just look at the hea= ders after and check it that way. That's how it could be done now with = the existing general API. If the BCP was to formalize something, I'd pr= obably enhance the API with something specific for it to make it even easie= r.




On Thu, Jul 27, 2017 at 4:56 PM, Jim Sc= haad <ietf@augustcellars.com> wrote:

One simple= way to implement it would be to have an call which says =E2=80=9CI will de= al with the following items if they exist=E2=80=9D.=C2=A0 This means that a= ll the application needs to do is to say that it will process p and not wha= t values are acceptable.

=C2= =A0

Jim

=C2=A0

=C2=A0

From: jose [mailto:jose-bounces@ietf.o= rg] On Behalf Of John Bradley
Sent: Thursday, July 27,= 2017 3:24 PM
To: Brian Campbell <bcampbell@pingidentity.com>
<= b>Cc: Nathaniel McCallum <npmccallum@redhat.com>; oauth <oauth@ietf.org>; jose@ietf.org; Phil Hunt <phil.hunt@oracle.com= >
Subject: Re: [jose] [OAUTH-WG] preventing confusion of one k= ind of JWT for another in JWT BCP

=C2=A0

My only concern with a crit header is that it is potentially another = layering violation.

=C2= =A0

It really should be the app= lication and not JWS/JWE that determines if the content of the JWT is corre= ct at a application layer.

=C2=A0

To get your id= ea to work the application would need to push down to the JWT layer some va= lue/s of p that it was willing to accept. =C2=A0 Without crit the applicati= on could just pass along typ or p to the application layer for matching.=

=C2=A0

I don=E2=80=99t hate the idea but it seems = like it is likely to work against having generic JOSE libs separate from JW= T. Perhaps that is the reality anyway.

=C2=A0

Ho= w would you implement it?

=C2=A0

John B.<= u>

=C2=A0

On Jul 27, 2017, at 6:10 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

=C2=A0

=C2=A0=

On Thu, Jul 27, 2017 at 3:40 PM, John B= radley <ve7jtb@ve= 7jtb.com> wrote:

Not that I am against the gen= eral desire for JWT not to be confused, but the attack surface for someone = to take a sec event from one context and replay it as a id_token to login i= s very small and if the client is correctly configured would not work as it= is now.

=C2=A0<= /p>

The only way you could replay the sec = event JWT is via the implicit flow. =C2=A0 The other flows would require a = malicious AS and at that point you have bigger problems with a compromised = token endpoint.

= =C2=A0

If you were to create a = implicit response with the sec event token that has the correct issuer and = aud, connect requires that nonce value from the request be present in the i= d_token. =C2=A0 This would require that the attacker somehow get the AS to = put not only the claim but the correct value from the request into the toke= n.

=C2=A0<= /p>

All in all I think that it is more lik= ely (not 100% I admit) that a client will do that rather than checking the = typ or a new crit JWT header parameter.

=C2=A0

I= am all for a general solution for this but I think the issue with Connect = is overstated sometimes.

=C2=A0

John B.

=C2=A0

On Jul 27, 2017, at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> w= rote:

=C2=A0

We have the use cas= e in SECEVENTS where a logout event (e.g. OIDF backchannel logout) is extre= mely close to an ID_TOKEN.=C2=A0

=C2=A0

Older relying = parties who are do not yet support logout could be tricked into accepting a= logout assertion as an ID_TOKEN since they are too similar, and =C2=A0beca= use a valid ID_TOKEN parser is in theory allowed to ignore claims it does n= ot understand (e.g. =E2=80=9Cevents=E2=80=9D) - leading to a possible erron= eous acceptance of the logout event AS and ID_TOKEN.

=C2=A0

Because of this the issue of distinguishing classes or types of= JWTs emerged.

= =C2=A0

We discussed a number of= differentiators like =E2=80=9Caud=E2=80=9D, =E2=80=9Ctyp=E2=80=9D, =E2=80= =9Ccrit", etc that would help.=C2=A0 But that really lead to the idea = there there should be some best practices in the JWT BCP covering the issue= (s).

=C2=A0

=

Phil

=C2=A0

Oracle Corporation, Identity Cloud Services Architect & Standards<= /u>

@independentid

phil.hunt@oracle.com

=C2=A0

On Jul 27, 2017, at= 2:00 PM, Nathaniel McCallum <npmccallum@redhat.com> wrote:

=C2=A0

Even after reading the whole section, I still don't understand t= he
problem. Yes, a class of attack could exist where an attacker
subs= titutes a valid JWT from one security context into another
context. But = isn't this resolved by audience validation?

On Thu, Jul 27, 2017= at 3:34 PM, Brian Campbell
<bcampbell@pingidentity.com> wrote:

=

The draft describes it in
http= s://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org= _html_draft-2Dsheffer-2Doauth-2Djwt-2Dbcp-2D01-23section-2D2.7&am= p;d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&= amp;r=3DJBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D= 02yWnzzFGNlefgVregxSncXu0b9sbh5pTrtBfQsC52A&s=3D9GmPCouCMXE4e= nC48gfq0l0yc7ZlIxvEBAnQCVja_kY&e=3D

On Thu, Jul 27, 20= 17 at 1:30 PM, Nathaniel McCallum <npmccallum@redhat.com>
wrote:


What class of attacks is this trying to prevent? I f= rankly don't see a
problem with confusing different types of JWT. Bu= t I may just be
ignorant.

On Thu, Jul 27, 2017 at 2:49 PM, Brian = Campbell
<bcampbell@pingidentity.com> wrote:

During the first WG meeting last week I = asked if use of the JOSE "crit"
(Critical) Header Parameter ha= d been considered as a recommendation for
preventing confusion of one ki= nd of JWT for another. Time was running
short
in the meeting so there= wasn't much discussion and it was requested that
I
take the ques= tion to the list. And so here on the list is that.

Section 3.9 of th= e JWT BCP draft now recommends explicit typing using
the
"typ&qu= ot; JWS/JWE header parameter but does concede that 'the use of
expli= cit
typing may not achieve disambiguation from existing kinds of JWTs, a= s
the
validation rules for existing kinds JWTs often do not use the &= quot;typ"
header
parameter value.' =C2=A0And the recommendat= ions for how to use the Type
Header
Parameter in JWT strongly suggest= that it's not currently being used for
any
validation.

Al= ternatively using the JWS/JWE "crit" (Critical) Header Parameter = to
signal
the type/intent/profile/application of a JWT could ach= ieve
disambiguation
even in validation of existing kinds of JWTs. The= critical header lists
other headers which must be understood and proces= sed by the receiver and
that the JWS/JWE is invalid if those listed aren= 't understood. So a new
type/profile of JWT that uses the "crit= " header would produce JWTs that
would be rejected even by existing= applications of JWT validation (that
actually implement "crit"= ; properly anyway).

The JWT BCP could suggest the use of "crit&= quot; in conjunction with a
profile/application/type specific header. Or= it could provide a bit more
of
a framework like defining a registeri= ng a new JOSE header "p" (strawman
of p
as a very short nam= e for profile) and create a registry for its values.
A
JWT header usi= ng that approach might look like the following where the
value
1 is r= egistered as some cool new JWT profile/application. The consumer
of
s= uch a JWT would have to understand and process the "p" header, wh= ich
would
mean checking that it had the value expected.

=C2=A0= =C2=A0=C2=A0=C2=A0{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"alg":"= ES256",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"crit":["p&quo= t;],
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"p":1
=C2=A0=C2=A0=C2=A0= =C2=A0}

A JOSE compliant JWT validator would reject such a JWT even = for an OAuth
access token or OIDC id_token because the "p" hea= der isn't known or
understood but is marked as critical.

To m= e, that seems like an approach to preventing confusion that has more
tee= th than the "typ" header. Which is why I asked about it last week= and
am
now bringing it to the list.







<= br>

CONFIDENTIALITY NOTICE: This email may contain confidential and<= br>privileged
material for the sole use of the intended recipient(s). An= y review, use,
distribution or disclosure by others is strictly prohibit= ed.=C2=A0 If you
have
received this communication in error, please no= tify the sender
immediately
by e-mail and delete the message and any = file attachments from your
computer. Thank you.
_____________________= __________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url= ?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jose&d=3DDwICAg&= amp;c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D= JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlef= gVregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_Kpo= baeSRUP4Cp2W-_jJU&e=3D




CONFIDENTIALITY NOTICE: This email = may contain confidential and privileged
material for the sole use of the= intended recipient(s). Any review, use,
distribution or disclosure by o= thers is strictly prohibited.=C2=A0 If you have
received this communicat= ion in error, please notify the sender immediately
by e-mail and delete = the message and any file attachments from your
computer. Thank you.


______________________= _________________________
jose mailing list
jose@ietf.org
https://urldefense.proofpoint.com/v2/url?= u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jose&d=3DDwICAg&a= mp;c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3DJ= Bm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3D02yWnzzFGNlefg= VregxSncXu0b9sbh5pTrtBfQsC52A&s=3DeJ8QZBwe5AO-RDl_E16U1q_Kpob= aeSRUP4Cp2W-_jJU&e=3D

=C2=A0

<= /div>

__________________________________________= _____
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th

= =C2=A0


_______________________________________________
OAu= th mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=C2=A0<= /p>


CONFIDENTIALITY NOTICE: This email may contain conf= idential and privileged material for the sole use of the intended recipient= (s). Any review, use, distribution or disclosure by others is strictly proh= ibited.=C2=A0 If you have received this communication in error, please noti= fy the sender immediately by e-mail and delete the message and any file att= achments from your computer. Thank you.

=C2=A0

=

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --f403045fe2d4ae3b3605555fbe89-- From nobody Fri Jul 28 13:00:16 2017 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 7BA8E1320E3 for ; Fri, 28 Jul 2017 13:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvM-_CpjwKdK for ; Fri, 28 Jul 2017 13:00:05 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64FD1317E3 for ; Fri, 28 Jul 2017 13:00:05 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id z129so59981301pfb.3 for ; Fri, 28 Jul 2017 13:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=pjO7hzbo6zNlaPUI7+nwEY7wkHZlb6ExrDTXlZ7WVUw=; b=ROtyYfacZ2MKvHMbuyxuDFIst1Q9qCuYopAaK1OIqH0WQ8V7ppNO7tzTm7xnyXJT1q y2Vtlp/HwskH91XF2w7A/lRBQ7dE4WRbQxpp72iVjcdKQ9bBCUQ87glnX37dKtoBK5kY 1lebDw9OVeGqb2q8uIfh0OJ+20WaAM1/8gJMM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pjO7hzbo6zNlaPUI7+nwEY7wkHZlb6ExrDTXlZ7WVUw=; b=Q3R2UlKlGtK64RxNHYx3dqlIL400EahwXSSlZ9ZMSC4fnWGN1siYfFUk8p0cA0Htv/ DzF02VVz4QavoRCOnRfLNjFUzssgw81I6E/m0Dls8PKWLodjVYnNYJBDUOtxpgqy+jp+ Eq2hZLluWsCNRS7eXFX3TKbIwVXkpQQEb60+Z8IqO4FiWVFyyGa+NkIS8heTNr9G1wmA EeJgrGEFiHWYBr09v6k0dyRnn//pkN3XKZs3ulJPGJaYNGFMzFIUKI2bB8AJh+OT8XFC MX2JDlmAABTXdhZC+tl+7tEWwyx8TXetGsiaDSChL52LbGaBBqLIWxTp5GbEB2McKD6p lRKA== X-Gm-Message-State: AIVw113+kzcDA/sruyDcBJ7LvYGBk1lQLNzLyUZqm6oAbnHAnpuwJL4r xaWhktn7LAzc66dQkqTDjTiEtdPFwRNLCO1TF2XCPFz+4xZv9R30sAKZxJdnDrMso9p34RufBHx tyYo= X-Received: by 10.98.204.144 with SMTP id j16mr8641324pfk.25.1501272005267; Fri, 28 Jul 2017 13:00:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.87 with HTTP; Fri, 28 Jul 2017 12:59:34 -0700 (PDT) From: Brian Campbell Date: Fri, 28 Jul 2017 13:59:34 -0600 Message-ID: To: oauth , "jose@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c11d6e295f60d0555662028" Archived-At: Subject: [jose] JWT BCP on Compression in JWE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 20:00:10 -0000 --94eb2c11d6e295f60d0555662028 Content-Type: text/plain; charset="UTF-8" On critique of JWT I've seen a few times can be paraphrased as "JWT supports compressed plaintext so, because of CRIME and BREACH, it is dangerous and stupid." It's very possible that I am stupid (many on this list will likely attest to it) but I don't see the applicability of those kinds of chosen plaintext attacks aimed at recovering sensitive data to how JWT/JWE are typically used. I think it would be useful, if during the development of the JWT BCP, the authors or chairs or WG could somehow engage some experts (CFRG?) to understand if there's any real practical advice that can be given about using compression with JWE and the risks involved. -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --94eb2c11d6e295f60d0555662028 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On critique of JWT I've seen a few times can be p= araphrased as "JWT supports compressed plaintext so, because of CRIME and BREACH, it is dangerous and stupid."= =C2=A0 It's very possible that I am stupid (many on this list will like= ly attest to it) but I don't see the applicability of those kinds of ch= osen plaintext attacks aimed at recovering sensitive data to how JWT/JWE ar= e typically used.=C2=A0

I think it would be useful, if during= the development of the JWT BCP, the authors or chairs or WG could somehow = engage some experts (CFRG?) to understand if there's any real practical= advice that can be given about using compression with JWE and the risks in= volved.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --94eb2c11d6e295f60d0555662028--