From nobody Sun Jun 4 06:14:41 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 9EBE5129B26 for ; Sun, 4 Jun 2017 06:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 cW4QNuj3zYKp for ; Sun, 4 Jun 2017 06:14:38 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0120.outbound.protection.outlook.com [104.47.37.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74D3129B1E for ; Sun, 4 Jun 2017 06:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cxJiroMt5XdbVzG+oOt5hXK9QTceUueQLF1NqiSRKu8=; b=oAYpxP0IL5SIwnTwLyQ0pbwD7Dg/ku5XLjrd+YNM6HSFoRErgfTtmNRbCAC3KP8ZFLQ4GLWQDaj0OV7MaLv//zJO5tbeC5P1AldtUcZIpFlvf1OXnHMQ/CA7/9VtSQO9UgQEuNJ0ApZsVNZiSF3HjPUofmpVmFT0vPVV6/pREiI= Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0471.namprd21.prod.outlook.com (10.172.121.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.0; Sun, 4 Jun 2017 13:14:36 +0000 Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.1178.000; Sun, 4 Jun 2017 13:14:36 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Initial JSON Web Token Best Current Practices Draft Thread-Index: AdLdLiuU8v8bzUlIS+Ocr4mmEw/lEAABjddw Date: Sun, 4 Jun 2017 13:14:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Ref=https://api.informationprotection.azure.com/api/72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetBy=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-06-04T06:12:36.1315142-07:00; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.93.167] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0471; 7:jvGhYQy1OLEoFPQl5mCKsv/bhQlpbu8CMC79f7konEc1qyzX1TCawh0qvkkc+762gDtxMecJxfOBU0FkXxN3vLZ8MvwDIX5EwGeqSNTg4RaqtBuYFYU87CEeTFsy2pMJkw5hL/+RDXtmvxVkrtiLaPGk65k4GTLsZykyD0MoTL7beabqMDJMfZGzkh8Uorb2Dfm5IrKFUxnNBM5fT1OSEfMv5VMA6q82I+gSDyIVc4kn92zFxlYbQlc1bUSo8Mup1MCz90qiIgHrkboYEUn/mDWWVQKAKlTFAjZ5WOFjK+qE261TAiPjoAMKkHM261TCaZAXodQQ1j5nrglQVipSVNpdzfGsprhFZvY9WLkgLM0= x-ms-office365-filtering-correlation-id: 9f8a5d63-1b62-415e-9236-08d4ab4ba674 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR21MB0471; x-ms-traffictypediagnostic: CY4PR21MB0471: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(278428928389397)(192374486261705)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0471; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0471; x-forefront-prvs: 03283976A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39860400002)(39450400003)(39400400002)(39410400002)(39850400002)(209900001)(377454003)(69234005)(33656002)(6506006)(3660700001)(122556002)(8936002)(77096006)(556974002)(1730700003)(81166006)(8676002)(5630700001)(236005)(55016002)(2473003)(6306002)(99286003)(9686003)(54896002)(6116002)(53936002)(2900100001)(189998001)(6436002)(606005)(54356999)(229853002)(5640700003)(76176999)(50986999)(2351001)(3846002)(102836003)(10290500003)(10090500001)(25786009)(478600001)(53376002)(53546009)(790700001)(14454004)(2501003)(7736002)(74316002)(7906003)(72206003)(5005710100001)(5660300001)(8990500004)(966005)(38730400002)(110136004)(2950100002)(66066001)(6916009)(86362001)(7696004)(3280700002)(86612001)(2906002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0471; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504BC79081E0E1D699A3938F5F50CY4PR21MB0504namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2017 13:14:36.7585 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0471 Archived-At: Subject: [jose] FW: Initial JSON Web Token Best Current Practices Draft 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, 04 Jun 2017 13:14:41 -0000 --_000_CY4PR21MB0504BC79081E0E1D699A3938F5F50CY4PR21MB0504namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Sent as an FYI. Please send responses to oauth@ietf.org.] From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Sunday, June 4, 2017 6:13 AM To: oauth@ietf.org Subject: [OAUTH-WG] Initial JSON Web Token Best Current Practices Draft JSON Web Tokens (JWTs) and the JSON Object Signing and Encryption (JOSE) fu= nctions underlying them are now being widely used in diverse sets of applic= ations. During IETF 98 in Chicago, we discus= sed reports of people implementing and using JOSE and JWTs insecurely, the = causes of these problems, and ways to address them. Part of this discussio= n was an invited JOSE/JWT Security Update presentation th= at I gave to two working groups, which included links to problem reports an= d describes mitigations. Citing the widespread use of JWTs in new IETF app= lications, Security Area Director Kathleen Moriarty suggested during these = discussions that a Best Current Practices (BCP) document be written for JSO= N Web Tokens (JWTs). I'm happy to report that Yaron Sheffer, Dick Hardt, and myself have produce= d an initial draft of a JWT BCP. Its abstract is: JSON Web Tokens, also known as JWTs [RFC7519], are URL-safe JSON-based security tokens that contain a set of clai= ms that can be signed and/or encrypted. JWTs are being widely used and depl= oyed as a simple security token format in numerous protocols and applicatio= ns, both in the area of digital identity, and in other application areas. T= he goal of this Best Current Practices document is to provide actionable gu= idance leading to secure implementation and deployment of JWTs. In Section 2, we describe threats and vulnerabilities. In Section 3, we de= scribe best practices addressing those threats and vulnerabilities. We bel= ieve that the best practices in Sections 3.1 through 3.8 are ready to apply= today. Section 3.9 (Use Mutually Exclusive Validation Rules for Different= Kinds of JWTs) describes several possible best practices on that topic to = serve as a starting point for a discussion on which of them we want to reco= mmend under what circumstances. We invite input from the OAuth Working Group and other interested parties o= n what best practices for JSON Web Tokens and the JOSE functions underlying= them should be. We look forward to hearing your thoughts and working on t= his specification together. The specification is available at: * https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1690 and a= s @selfissued. --_000_CY4PR21MB0504BC79081E0E1D699A3938F5F50CY4PR21MB0504namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Sent as an FYI. = Please send responses to oauth@ietf.org.]

 

From: OAuth [mailto:oauth-bounces@ietf.org] <= b>On Behalf Of Mike Jones
Sent: Sunday, June 4, 2017 6:13 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Initial JSON Web Token Best Current Practices Dr= aft

 

JSON Web Tokens (JWTs) and the JSON Object Signing a= nd Encryption (JOSE) functions underlying them are now being widely used in= diverse sets of applications.  During IETF 98 in Chicago, we discuss= ed reports of people implementing and using JOSE and JWTs insecurely, the c= auses of these problems, and ways to address them.  Part of this discu= ssion was an invited JOSE/JWT Security Update presentation that I gave to two working groups= , which included links to problem reports and describes mitigations.  = Citing the widespread use of JWTs in new IETF applications, Security Area D= irector Kathleen Moriarty suggested during these discussions that a Best Current Practices (BCP) document be written = for JSON Web Tokens (JWTs).

 

I’m happy to report that Yaron Sheffer, Dick H= ardt, and myself have produced an initial draft of a JWT BCP.  Its abs= tract is:

JSON Web Tokens, also kno= wn as JWTs [RFC7519], a= re URL-safe JSON-based security tokens that contain a set of claims that ca= n be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numero= us protocols and applications, both in the area of digital identity, and in= other application areas. The goal of this Best Current Practices document = is to provide actionable guidance leading to secure implementation and deployment of JWTs.

 

In Section 2, we describe threats and vulnerabilitie= s.  In Section 3, we describe best practices addressing those threats = and vulnerabilities.  We believe that the best practices in Sections 3= .1 through 3.8 are ready to apply today.  Section 3.9 (Use Mutually Exclusive Validation Rules for Different Kinds of JWTs) = describes several possible best practices on that topic to serve as a start= ing point for a discussion on which of them we want to recommend under what= circumstances.

 

We invite input from the OAuth Working Group and oth= er interested parties on what best practices for JSON Web Tokens and the JO= SE functions underlying them should be.  We look forward to hearing yo= ur thoughts and working on this specification together.

 

The specification is available at:

  • <= a href=3D"https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00">https= ://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-00

    •  

    An HTML-formatted version is also available at:=

    • <= a href=3D"http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html"= >http://self-issued.info/docs/draft-sheffer-oauth-jwt-bcp-00.html<= /o:p>

     

            &nbs= p;             =             &nb= sp;            =         -- Mike

     

    P.S. This notice was also posted at http://self-issued.info/?p=3D1690 and as @selfissued.

--_000_CY4PR21MB0504BC79081E0E1D699A3938F5F50CY4PR21MB0504namp_-- From nobody Mon Jun 12 11:20: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 92CD512DFE0 for ; Mon, 12 Jun 2017 11:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 57R56zkccxup for ; Mon, 12 Jun 2017 11:19:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 0AC1A12EB5B for ; Mon, 12 Jun 2017 11:19:55 -0700 (PDT) Received: from [192.168.91.196] ([80.92.114.129]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M8mCe-1d8Pf61xHg-00CEWt; Mon, 12 Jun 2017 20:19:48 +0200 To: "jose@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Cc: Hannes Tschofenig , Kepeng Li Message-ID: Date: Mon, 12 Jun 2017 20:19:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:g3gj9h6C55vlakt7f+Gdgcp2FDEs+3qfQfTNuCwz9u9ELH9esun QTC+H9vT16MwJnnLe2AIp1DkiHcj9YROGUsRVd8Xtck6r6hBt+dUC2WROYh3osHzfPPUoht 6drI/GFbtf4aFEh5Yp1pUTfiIUK0KaoLuqwGNH/CVq5geXt5P+AMMSCIM/F2GxNU22mAmkx H08ASDlocLHW8AJr/7X2w== X-UI-Out-Filterresults: notjunk:1;V01:K0:hgvIh19QYYg=:ZA9khfcTebHBsVoaH+s2iv 7UPORqItdBSdBi/Y1XW+BMEDMcA+7vaACO1h3mmELjPLOHRq45G9KHJfWtBHH0vShXwZYDnr1 H6XsaQbE+B5VqdJ2JZ9h8V++a9ArdX7WLsi99f15AWRLJwbD3FeU6S3tEeXKWUnAPRPjhzpau we0kPUM5dE0TA/TmHDZ4ci9F1LLQ2EX7buM3NkVax0EoZM8zGJApsVURLFYsf4pGDWFlByIrZ FWFS03p3wdTbFqI1W4UWswhazTf3xrsWzexzHuj50EtiP0BsIVmT1wsLBH068F+pdenb+X1ep p+SkHoDmiq0EyI1JulyPn236zQCOgvKA5N7w8L7eWha1XIMDSq6EmiBOOM33/+sNsQfUdETLx mibRpH721ZW8abG1B41UEqn5spxn8psbHDG0yhglGvjSUKqyS46GssXn9AH1ollJeE/bnzO8m hLVrZdnIXAQX6OEogufVWOV+avOHkK/aLx9FlKhy/hcfdY77QPjR0jodc8srQcqznqWDdd/J5 PHn+6Y1lPZVJwHOf2mefrPcHzs9b6KuaI/A/T4OM+QxqIf0dtaCaL0g6c9sWECIYKR2ctMMRi vapRSs3ZVYnSLgipzDjKmkbKaIjPgrdeOwxthpCmVnrDid011RghMcBLPIxrwIOBnzuS4mXPQ 01xP2Pr82fIGN+GnO52eEU9IsNwmaek97isIasYGo6MVYNYz2NkAuZQGhTCPeoa7gM5VTFIpl 62gThEjFYFaKnDsXi0a2sQbZjBLvThNYy5kJp+/3dgKGBkpqpW5nqdQyzDcwRv5yDUIuYw2pQ eWZTYAw Archived-At: Subject: [jose] Potential uses of PoP keys in CBOR Web Tokens (CWTs) 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, 12 Jun 2017 18:20:01 -0000 Hi all, RFC 7800 defines how to communicate Proof of Possession (PoP) keys for JSON Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT) draft-ietf-ace-cbor-web-token spec defines the CBOR/COSE equivalent of the JSON/JOSE JWT spec. The ACE working group is planning to also define a CBOR/COSE equivalent of RFC 7800 and is interested in knowing how you might use CBOR proof-of-possession keys for CWTs. Please drop us a message if you are using CBOR PoP keys for CWTs. We would like to learn more about your usage. Ciao Hannes & Kepeng From nobody Fri Jun 16 19:21:43 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 A59ED12E03B for ; Fri, 16 Jun 2017 19:21:41 -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 RtEn3-18__A0 for ; Fri, 16 Jun 2017 19:21:39 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 99DCE126557 for ; Fri, 16 Jun 2017 19:21:39 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id r103so46512530wrb.0 for ; Fri, 16 Jun 2017 19:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=l8RR3ybLTA+7t17Ol2d7cJkMuxRw+d3gufMaMuCIhIM=; b=b2e47KUCdWT4XcrSFNQYaCne4/dE3l8JDmWjXNYfPnAZ+oL/iHv15Y7xrpXdrj1tTV 4x5tnQYZgOeqTekByrCa67oOeB0SIn0b7hURJLHpszzHhAR9K3R85deBmEEFcupxMjIQ WeofZf7BRmZ1Vf/tCog8KGBJs1FMYxeVFgQYvTwFsMjEVjUqsHZnDdwvOMihiM7QdOwP ULrd3f7HI1dlDmR4TmSl9LD0fKS2ZGobMe5wtoym01uGp3Ae14UsTj64VeU8lMtnwSko blCikLaDoN5w2R/f60KBjOKgtB9LWDkGhMlu7LAzTzhtJZQz/3V8F8BEGg4JemK4MIIl maSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=l8RR3ybLTA+7t17Ol2d7cJkMuxRw+d3gufMaMuCIhIM=; b=jUg0WcbOp1/9IVDgQ7SI69FbIU6me/NcZm+PsI6AhcMODdE0pmjC/YMXXh3+iSUeiQ snDKtTmf8Rr4tlR2fdJsh9y1TT/cqR4Wnbi0OolDtinV99Wa6ojEuCSW8prz5GzKFWcA 0hdikyc/Xjc11DNSi9oQTsODXnIz1fEXs7BDb6nYwr773fmFHO3n84YpRM/dMQ4v3Ro8 n1el6sq1j8w2hD7gfemjitT3BDGM9RW3TZC4UHPYiovZvTgtpyvR9ofyLsrSXqcSoYGi IOFM0IJOtL32sX44ii3Li0oUJ2bsg2khSDD0LquxgAbpfj3HzH6Pm3LiFaPNzX8dlEde 3Vow== X-Gm-Message-State: AKS2vOzo4wtU+TEHxIBsXZQxqWkxKFK0YkDAIDKDLb6E8NIO8FAmyYCW BJyDOKcVW+A2URCl X-Received: by 10.223.141.146 with SMTP id o18mr6051737wrb.110.1497666098020; Fri, 16 Jun 2017 19:21:38 -0700 (PDT) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id v13sm645123wmd.5.2017.06.16.19.21.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 19:21:37 -0700 (PDT) To: "jose@ietf.org" From: Anders Rundgren Message-ID: <9723bd08-51ae-62a2-3065-a12aed803eda@gmail.com> Date: Sat, 17 Jun 2017 04:21:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [jose] RFC: Java support for CURDLE 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, 17 Jun 2017 02:21:42 -0000 https://github.com/bcgit/bc-java/issues/193#issuecomment-309183825 Anders From nobody Sat Jun 24 05:06:54 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 741501293E4; Sat, 24 Jun 2017 05:06:47 -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, FREEMAIL_FROM=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 (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 S3WSHbCsCALJ; Sat, 24 Jun 2017 05:06:46 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 BF884128D6F; Sat, 24 Jun 2017 05:06:45 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id 77so96646682wrb.1; Sat, 24 Jun 2017 05:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=4BbWtbZ6v3Mv8cwlgw8IrCStlDTnGZWAOz2oApIK2Kk=; b=Ag763WJsNXkW7UhpAOSfXMCM6EYgHkGFXO0Q5pkInphDoDwtOQgVtKF+R1RQIB9Q04 q1T9oKmYEX3zlp8fYaWlRwPdqQ68LvG5AiYSUch/Vga/n5/as52GUaksntqq210emZaT 0JbZZ+gDoMgucBhQA7mWXA08JBts5qcLJyCFnxkTiUlj4r0WOJtE3FyD92DuJBkyV0WU pi7525liZyVjDEfcgVgBlP2WeHIDZbyNxg7A4kZQAeVOH8tgmW9c6l8ANtFf9JUleRR3 jNLckhEpfvzZuotpgag13Afsnj4US2FibLO5a3Kl7iO8okdulUPJ9ZZfn1NDp85mBahm /CgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=4BbWtbZ6v3Mv8cwlgw8IrCStlDTnGZWAOz2oApIK2Kk=; b=WFJcpXc9Yx/TxTYlxv9L1MtX7dszYuPmswwI36SmnNgXRhxYqvzi3y2ApJkPIkskuH T53mD6AqOH6mzGYlTMcvmkFVi4MUD6OM5MxeGfPASHVk8sww0B0rg7iKetq7wgQX57dx rx7siKp+Y9m/0XJGlHk5A5OWRZ97Ij+R8JISGrk1lF5PBCFnStuboaeP3B/gvEW4OyHU utg+BSvV0grEDgRQeBNQqd6KT9A7YWmKjND/CC0WNKSwxSOk49AzcxNPuCjvNOBR7Lwf 0nSyn3RjlWCw6gQnn7TTGvbq7x83krhA88Y//aQpu7O/VVxy/sXFgk53eCyxWGLGUr+9 C4eQ== X-Gm-Message-State: AKS2vOxztVpmrWPGu5r1nO1cb/i1Z+XqR/jJCUN73urdrkrqhpNkTIsU HrFWUhYho2NoJ1ps X-Received: by 10.80.179.181 with SMTP id s50mr9386306edd.57.1498306004181; Sat, 24 Jun 2017 05:06:44 -0700 (PDT) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id n26sm1371475edd.51.2017.06.24.05.06.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jun 2017 05:06:42 -0700 (PDT) To: curdle@ietf.org, jose@ietf.org From: Anders Rundgren Message-ID: <490f2735-0d76-2104-039f-e05e87536ee9@gmail.com> Date: Sat, 24 Jun 2017 14:06:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [jose] java-cfrg-spec 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, 24 Jun 2017 12:06:47 -0000 Since I'm only a user of cryptography rather than a cryptographer, I would be very happy to get some feedback on this proposal, including pull requests. https://github.com/cyberphone/java-cfrg-spec Anders From nobody Wed Jun 28 05:41:25 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 43914129AB8 for ; Wed, 28 Jun 2017 05:41:23 -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 z6q9D4gk7num for ; Wed, 28 Jun 2017 05:41:21 -0700 (PDT) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) (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 22DA91242F5 for ; Wed, 28 Jun 2017 05:41:21 -0700 (PDT) Received: by mail-io0-f170.google.com with SMTP id h134so34721235iof.2 for ; Wed, 28 Jun 2017 05:41:21 -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:from:date:message-id:subject:to; bh=N3svYP4f1M/55ANCzZskbdwi1FRPpYLgPQPDzZX5lrI=; b=V1UDXfhKmEXzF0jAgol6VU+kJQ+k04wYrCMl9kGrmb9qOilBWArps+vOpVszqOe8Ly waSi2T568kP/GOITjJEc+RV9XrwzklCMnPXmpmeMQpGCODo5zMU8cLg8IWa3xojXazP0 EKYbLuMmxiGZCIHnljfJFXT0kpBwcOUw7yLp11kLQjCQXa+7pmTvDFEOVJb8Z2fKxw6p aYLj/Q1kX4uG4QV7eUpphUKq7LvA7ChjCmeMTC+HzHDeAhMfGzZtUUuVYMoshoknA2WN PRp1hTPu+csB8Aaqwf4SX2EGOEQmzN2YIl6DYlD8VUYAT8PdIbZARf9DG/8EOwRWSs81 gKWQ== X-Gm-Message-State: AKS2vOy3oF7okDWCHiXtOUAlK79Nc2XiieC0RMYgOKClNRBN7vUTqbJ9 Ee70WfUB9XM3lIMKy7gXipGbvATAcqVQfZfsOw== X-Received: by 10.107.173.66 with SMTP id w63mr12213506ioe.24.1498653680276; Wed, 28 Jun 2017 05:41:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.79 with HTTP; Wed, 28 Jun 2017 05:41:19 -0700 (PDT) From: Nathaniel McCallum Date: Wed, 28 Jun 2017 08:41:19 -0400 Message-ID: To: jose@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [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: Wed, 28 Jun 2017 12:41:23 -0000 Has there been any interest in standardizing this? The Jose project[0] has some initial working code (not yet published). We are using the (new, standardized) "p11" attribute in JWKs to replace the absence of private key material. The value of this attribute is the URI to the key as defined by p11-kit[1]. Thus, when a JWK which lacks private key material but contains "p11" is used for a decryption or signing process, we forward this request to the PKCS#11 module. Does anyone have interest in working with me on a standard for this (or something similar)? Nathaniel [0]: https://github.com/latchset/jose [1]: https://github.com/p11-glue/p11-kit From nobody Wed Jun 28 11:23:30 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 E606012EA97 for ; Wed, 28 Jun 2017 11:23:27 -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 Th72lU0dsTS7 for ; Wed, 28 Jun 2017 11:23:25 -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 C17B8129C34 for ; Wed, 28 Jun 2017 11:23:25 -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=1498674191; h=from:subject:to:date:message-id; bh=Bk1A7CO0HMZezpIJ/OhmK0sjNDcUuSxj9gOu1N8lvWg=; b=cE5oBrDAQQ+GdlJyxaqlwLFfYeqx8eqv0TYdSapDPgCp9UJwjDP+l0lsh2whWclTxoVT9K83dG9 bcAm7uuqRRl9MgqmsI1d9//kj1pYzh9yonFvBGr01pxTb3kMtInaDiChi63ziydBZte4+r4g2eIpA ahzr8Kdoj4CG2LpMa+BmfCmbvJp8P/4x+GcD+ihaM9yhe0ydX7FwhiDJgYr7SGng6+hRun/4uYWQH XYyX5+wyYa69gZFnCvCHqbOrBOxLswih/DH1iscnjXLDZB8a8CgRXrTJyT2q4ZTr11T6sg+/myTeM llUwfMdo433yBeERp0ZgfjE4VoAf62gpfcLg== 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; Wed, 28 Jun 2017 11:23:10 -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; Wed, 28 Jun 2017 11:22:48 -0700 From: Jim Schaad To: 'Nathaniel McCallum' , References: In-Reply-To: Date: Wed, 28 Jun 2017 11:22:51 -0700 Message-ID: <010301d2f03b$8f1a7c20$ad4f7460$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIh0tw3bEdZEh0b5Yd1mAFJlc0Ch6Gc0M6w X-Originating-IP: [24.21.96.37] 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: Wed, 28 Jun 2017 18:23:28 -0000 I am not aware of any work being done for that purpose. I am not sure why you would use a JWK rather than a URI, but I can see some possibilities. Jim -----Original Message----- From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Nathaniel McCallum Sent: Wednesday, June 28, 2017 5:41 AM To: jose@ietf.org Subject: [jose] PKCS#11 Support for JWKs Has there been any interest in standardizing this? The Jose project[0] has some initial working code (not yet published). We are using the (new, standardized) "p11" attribute in JWKs to replace the absence of private key material. The value of this attribute is the URI to the key as defined by p11-kit[1]. Thus, when a JWK which lacks private key material but contains "p11" is used for a decryption or signing process, we forward this request to the PKCS#11 module. Does anyone have interest in working with me on a standard for this (or something similar)? Nathaniel [0]: https://github.com/latchset/jose [1]: https://github.com/p11-glue/p11-kit _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From nobody Wed Jun 28 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 304D012EB10 for ; Wed, 28 Jun 2017 13:23:46 -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 T9YdnsTOYNv8 for ; Wed, 28 Jun 2017 13:23:43 -0700 (PDT) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (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 A044912EAF2 for ; Wed, 28 Jun 2017 13:23:43 -0700 (PDT) Received: by mail-io0-f176.google.com with SMTP id h134so42517877iof.2 for ; Wed, 28 Jun 2017 13:23: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=hUG1JHbYMj0HzuHJPcwNyH8/eu4GANRBuTI3kgaA70o=; b=eGwP+SPUHkFK40Fl4paYTmygmeRtCtMp9Xzcto+mzNOc+REN40dWrTSDWZqZIM2L3e 6WrwTLRSdn2YDCmW4SPcAYqe6pIkFh5Viv8Vs89KGSbX9NXpRel8qoO2mwJHSCICbndU 2F5mJtGb90YpeeqI8luXnLw/qPNuDcaIfMjtiT2QFW6eGrkV09xFYw337GO1s0xD6kMM z22aLJqJuhCPJ9cKFo/pyYrT72TlPnhK9qDp6atP5OeGJe9AKVu5KBv+ar9iwoN13wUk hhrSTCPGOAct0DOhF5SIs7TGrzcYdNDzeN9eTLJL/v2uzB200K9lEfMVDd5dSbsJ9wAt oMFw== X-Gm-Message-State: AKS2vOyZ9PJiBzXIjRWGVt8fvgy5GyrbXZ2Y/oqfHLfnz79sL+J+J52m W2eovrOgSKdzMDDUllqJ5ZLiTzRuU3B0hQloAw== X-Received: by 10.107.173.66 with SMTP id w63mr14698780ioe.24.1498681422914; Wed, 28 Jun 2017 13:23:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.79 with HTTP; Wed, 28 Jun 2017 13:23:42 -0700 (PDT) In-Reply-To: <010301d2f03b$8f1a7c20$ad4f7460$@augustcellars.com> References: <010301d2f03b$8f1a7c20$ad4f7460$@augustcellars.com> From: Nathaniel McCallum Date: Wed, 28 Jun 2017 16:23:42 -0400 Message-ID: To: Jim Schaad Cc: jose@ietf.org Content-Type: text/plain; charset="UTF-8" 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: Wed, 28 Jun 2017 20:23:46 -0000 We're using a JWK with a "p11" property because the public key material is still usable without the private key. For example, verification of signatures or encrypting data. So, for example: $ jose jwk gen -o test.jwk -i '{"p11":"pkcs11:..."}' $ cat test.jwk {"crv":"P-256","kty":"EC","p11":"pkcs11:...","x":"...","y":"..."} This JWK can be passed directly to most JOSE implementations and be successfully used for encryption or verification and the "p11" property will be ignored (or it can be stripped before sharing the key). For implementations that support PKCS#11, they can detect the absence of a private key during signing or decryption and fall back to evaluating the "p11" property. That is to say, PKCS#11 is not a replacement for a JWK but for the missing private (or symmetric) key. On Wed, Jun 28, 2017 at 2:22 PM, Jim Schaad wrote: > I am not aware of any work being done for that purpose. I am not sure why > you would use a JWK rather than a URI, but I can see some possibilities. > > Jim > > > -----Original Message----- > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Nathaniel McCallum > Sent: Wednesday, June 28, 2017 5:41 AM > To: jose@ietf.org > Subject: [jose] PKCS#11 Support for JWKs > > Has there been any interest in standardizing this? > > The Jose project[0] has some initial working code (not yet published). > We are using the (new, standardized) "p11" attribute in JWKs to replace the > absence of private key material. The value of this attribute is the URI to > the key as defined by p11-kit[1]. > > Thus, when a JWK which lacks private key material but contains "p11" > is used for a decryption or signing process, we forward this request to the > PKCS#11 module. > > Does anyone have interest in working with me on a standard for this (or > something similar)? > > Nathaniel > > [0]: https://github.com/latchset/jose > [1]: https://github.com/p11-glue/p11-kit > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From nobody Wed Jun 28 13:47: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 3CC9C1270AC for ; Wed, 28 Jun 2017 13:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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] 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 l-ZqRvpMeehv for ; Wed, 28 Jun 2017 13:47:28 -0700 (PDT) Received: from p3plsmtpa09-07.prod.phx3.secureserver.net (p3plsmtpa09-07.prod.phx3.secureserver.net [173.201.193.236]) (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 5DF0F12EB40 for ; Wed, 28 Jun 2017 13:47:28 -0700 (PDT) Received: from [192.168.43.252] ([212.5.158.236]) by :SMTPAUTH: with SMTP id QJrSdMKnmaTK5QJrTdUWRI; Wed, 28 Jun 2017 13:46:57 -0700 To: jose@ietf.org References: <010301d2f03b$8f1a7c20$ad4f7460$@augustcellars.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Wed, 28 Jun 2017 22:46:53 +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: MS4wfGqHyw/ZGccUShcBhOif07T/ousQeSiailjApevwl+Av5/7DICrdaPwgwv5rKBryNVBygDEBA+9DrIWYQp/4dVWUtsxqj4vYc0W+/8hIO3qteyP1HyW8 5/7bTohhYl1oGOjqiIzqQyBLvU+DW6aQpT/6u8VVgpDGxrPHmfssp/lO 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: Wed, 28 Jun 2017 20:47:30 -0000 Hi Nathaniel, So what you wish to propose is a new "p11" parameter which is a PKCS#11 URI (RFC 7512)? Vladimir On 28/06/17 22:23, Nathaniel McCallum wrote:z > We're using a JWK with a "p11" property because the public key > material is still usable without the private key. For example, > verification of signatures or encrypting data. So, for example: > > $ jose jwk gen -o test.jwk -i '{"p11":"pkcs11:..."}' > $ cat test.jwk > {"crv":"P-256","kty":"EC","p11":"pkcs11:...","x":"...","y":"..."} > > This JWK can be passed directly to most JOSE implementations and be > successfully used for encryption or verification and the "p11" > property will be ignored (or it can be stripped before sharing the > key). For implementations that support PKCS#11, they can detect the > absence of a private key during signing or decryption and fall back to > evaluating the "p11" property. > > That is to say, PKCS#11 is not a replacement for a JWK but for the > missing private (or symmetric) key. > > On Wed, Jun 28, 2017 at 2:22 PM, Jim Schaad wrote: >> I am not aware of any work being done for that purpose. I am not sure why >> you would use a JWK rather than a URI, but I can see some possibilities. >> >> Jim >> >> >> -----Original Message----- >> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Nathaniel McCallum >> Sent: Wednesday, June 28, 2017 5:41 AM >> To: jose@ietf.org >> Subject: [jose] PKCS#11 Support for JWKs >> >> Has there been any interest in standardizing this? >> >> The Jose project[0] has some initial working code (not yet published). >> We are using the (new, standardized) "p11" attribute in JWKs to replace the >> absence of private key material. The value of this attribute is the URI to >> the key as defined by p11-kit[1]. >> >> Thus, when a JWK which lacks private key material but contains "p11" >> is used for a decryption or signing process, we forward this request to the >> PKCS#11 module. >> >> Does anyone have interest in working with me on a standard for this (or >> something similar)? >> >> Nathaniel >> >> [0]: https://github.com/latchset/jose >> [1]: https://github.com/p11-glue/p11-kit >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From nobody Wed Jun 28 14:00:53 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 2C8B212EABA for ; Wed, 28 Jun 2017 14:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 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] 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 ji8ugBkjGnMq for ; Wed, 28 Jun 2017 14:00:50 -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 5B6281270AC for ; Wed, 28 Jun 2017 14:00:50 -0700 (PDT) Received: by mail-it0-f49.google.com with SMTP id v202so36074253itb.0 for ; Wed, 28 Jun 2017 14:00:50 -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=JVui6DjurkMYhF8V1MeM7WqSe8x+EvupBhBTXdc7QLU=; b=MOzof2CT1pq95u2WEyQBjWgbKOmkHSyoxU8KMHvGO47+owuT2ib6hqDTUfQYcAbJu0 RBapMMZmQNN9myJC+8sGiPhZsrYmjiOR/mfWoU15Lalmv48KfMISvbNjCSF93X7VBxTm cVoDvacJ5w9js50YDbvwvIYH0DrmdDiLeiiNffq46ABteJAZeYs6JQcBCFzZ/aICrA0s w2h5lgpfAfTbVdB39b7J+OWiPxN760yCS0QZgD8PB3mwuz1Z7EIKIiuVxGGlNM73RjVO 9WgclYkyn7xLV8F3Jnd5DYPMrpLjytwW5nph1kL2IpGGBI0EYHYBvllMyXeZWWdSuDCP A2og== X-Gm-Message-State: AKS2vOwS3hsb8ysukYbXyAaetyuCrfkhcOz6LzHmdmGuWRnTq/u8/DUy lllOAWN2m5iigd9rBm01m8LJ2KdMxs1j X-Received: by 10.36.248.131 with SMTP id a125mr9807761ith.50.1498683649483; Wed, 28 Jun 2017 14:00:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.79 with HTTP; Wed, 28 Jun 2017 14:00:48 -0700 (PDT) In-Reply-To: References: <010301d2f03b$8f1a7c20$ad4f7460$@augustcellars.com> From: Nathaniel McCallum Date: Wed, 28 Jun 2017 17:00:48 -0400 Message-ID: To: Vladimir Dzhuvinov Cc: jose@ietf.org Content-Type: text/plain; charset="UTF-8" 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: Wed, 28 Jun 2017 21:00:52 -0000 Correct. This parameter can be consulted for private key operations when the private key material is unavailable. On Wed, Jun 28, 2017 at 4:46 PM, Vladimir Dzhuvinov wrote: > Hi Nathaniel, > > So what you wish to propose is a new "p11" parameter which is a PKCS#11 > URI (RFC 7512)? > > Vladimir > > > On 28/06/17 22:23, Nathaniel McCallum wrote:z >> We're using a JWK with a "p11" property because the public key >> material is still usable without the private key. For example, >> verification of signatures or encrypting data. So, for example: >> >> $ jose jwk gen -o test.jwk -i '{"p11":"pkcs11:..."}' >> $ cat test.jwk >> {"crv":"P-256","kty":"EC","p11":"pkcs11:...","x":"...","y":"..."} >> >> This JWK can be passed directly to most JOSE implementations and be >> successfully used for encryption or verification and the "p11" >> property will be ignored (or it can be stripped before sharing the >> key). For implementations that support PKCS#11, they can detect the >> absence of a private key during signing or decryption and fall back to >> evaluating the "p11" property. >> >> That is to say, PKCS#11 is not a replacement for a JWK but for the >> missing private (or symmetric) key. >> >> On Wed, Jun 28, 2017 at 2:22 PM, Jim Schaad wrote: >>> I am not aware of any work being done for that purpose. I am not sure why >>> you would use a JWK rather than a URI, but I can see some possibilities. >>> >>> Jim >>> >>> >>> -----Original Message----- >>> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Nathaniel McCallum >>> Sent: Wednesday, June 28, 2017 5:41 AM >>> To: jose@ietf.org >>> Subject: [jose] PKCS#11 Support for JWKs >>> >>> Has there been any interest in standardizing this? >>> >>> The Jose project[0] has some initial working code (not yet published). >>> We are using the (new, standardized) "p11" attribute in JWKs to replace the >>> absence of private key material. The value of this attribute is the URI to >>> the key as defined by p11-kit[1]. >>> >>> Thus, when a JWK which lacks private key material but contains "p11" >>> is used for a decryption or signing process, we forward this request to the >>> PKCS#11 module. >>> >>> Does anyone have interest in working with me on a standard for this (or >>> something similar)? >>> >>> Nathaniel >>> >>> [0]: https://github.com/latchset/jose >>> [1]: https://github.com/p11-glue/p11-kit >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From nobody Fri Jun 30 11:31:20 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 AE021131458 for ; Fri, 30 Jun 2017 11:31:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5] 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 axteoQwVTQTt for ; Fri, 30 Jun 2017 11:31:16 -0700 (PDT) Received: from p3plsmtpa06-05.prod.phx3.secureserver.net (p3plsmtpa06-05.prod.phx3.secureserver.net [173.201.192.106]) (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 60702131490 for ; Fri, 30 Jun 2017 11:31:16 -0700 (PDT) Received: from [192.168.43.252] ([212.5.158.24]) by :SMTPAUTH: with SMTP id R0gkdnuscoed8R0gldGyM1; Fri, 30 Jun 2017 11:30:45 -0700 To: Nathaniel McCallum Cc: jose@ietf.org References: <010301d2f03b$8f1a7c20$ad4f7460$@augustcellars.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Fri, 30 Jun 2017 20:30:38 +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="------------ms030507040508090103000508" X-CMAE-Envelope: MS4wfMF2zXW78sTlkw6Fq59L4wvuW+4jbrF0b9mdqefWeV64KcPDMsrVGx6cjbKZigLKJASCtcm8NZZzOI8edmjHNcT/ctEw1BVysnXfozXwVVRILtzf0FTZ 21eEiR9JpkBwx3qi/w7VXJYS07IVEWwGSXo2VIgfmLcxf7DhG+idA5yRQmyEgbU6wfd+EAfFB9zpndoMD4IEVyQ5yNiDKB13WC0= 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: Fri, 30 Jun 2017 18:31:19 -0000 This is a cryptographically signed message in MIME format. --------------ms030507040508090103000508 Content-Type: multipart/alternative; boundary="------------E5934C001AE21FD6A2609297" Content-Language: en-US This is a multi-part message in MIME format. --------------E5934C001AE21FD6A2609297 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I was unaware of this spec until you mentioned it here. I had a look at it last night. Am I correct that the pkcs11 URIs are simply a representation 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 URIs seem to contain a lot of details that are not about the key, but about drivers, hardware, the OS. Also, parameters that can change, e.g. the HSM slots. We have a machine with two HSMs, and after a reboot the HSMs can get a different slot assigned, which can be nuisance. When we used JWK sets backed by Cryptoki before we took the following approach (in Java): 1. Load PKCS#11 KeyStore. 2. Export the found PKCS#11 keys into a JWK set, where the key alias becomes the JWK "kid", the certificate is included as an option; each JWK keeps a reference to the private key in the store. 3. If the private key is needed, that same reference is used to get at i= t. On 28/06/17 23:00, Nathaniel McCallum wrote: > Correct. This parameter can be consulted for private key operations > when the private key material is unavailable. > > On Wed, Jun 28, 2017 at 4:46 PM, Vladimir Dzhuvinov > wrote: >> Hi Nathaniel, >> >> So what you wish to propose is a new "p11" parameter which is a PKCS#1= 1 >> URI (RFC 7512)? >> >> Vladimir >> >> >> On 28/06/17 22:23, Nathaniel McCallum wrote:z >>> We're using a JWK with a "p11" property because the public key >>> material is still usable without the private key. For example, >>> verification of signatures or encrypting data. So, for example: >>> >>> $ jose jwk gen -o test.jwk -i '{"p11":"pkcs11:..."}' >>> $ cat test.jwk >>> {"crv":"P-256","kty":"EC","p11":"pkcs11:...","x":"...","y":"..."}= >>> >>> This JWK can be passed directly to most JOSE implementations and be >>> successfully used for encryption or verification and the "p11" >>> property will be ignored (or it can be stripped before sharing the >>> key). For implementations that support PKCS#11, they can detect the >>> absence of a private key during signing or decryption and fall back t= o >>> evaluating the "p11" property. >>> >>> That is to say, PKCS#11 is not a replacement for a JWK but for the >>> missing private (or symmetric) key. >>> >>> On Wed, Jun 28, 2017 at 2:22 PM, Jim Schaad = wrote: >>>> I am not aware of any work being done for that purpose. I am not su= re why >>>> you would use a JWK rather than a URI, but I can see some possibilit= ies. >>>> >>>> Jim >>>> >>>> >>>> -----Original Message----- >>>> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Nathaniel McC= allum >>>> Sent: Wednesday, June 28, 2017 5:41 AM >>>> To: jose@ietf.org >>>> Subject: [jose] PKCS#11 Support for JWKs >>>> >>>> Has there been any interest in standardizing this? >>>> >>>> The Jose project[0] has some initial working code (not yet published= ). >>>> We are using the (new, standardized) "p11" attribute in JWKs to repl= ace the >>>> absence of private key material. The value of this attribute is the = URI to >>>> the key as defined by p11-kit[1]. >>>> >>>> Thus, when a JWK which lacks private key material but contains "p11"= >>>> is used for a decryption or signing process, we forward this request= to the >>>> PKCS#11 module. >>>> >>>> Does anyone have interest in working with me on a standard for this = (or >>>> something similar)? >>>> >>>> Nathaniel >>>> >>>> [0]: https://github.com/latchset/jose >>>> [1]: https://github.com/p11-glue/p11-kit >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose --------------E5934C001AE21FD6A2609297 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I was unaware of this spec until you mentioned it here. I had a look at it last night. Am I correct that the pkcs11 URIs are simply a representation 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 URIs seem to contain a lot of details that are not about the key, but about drivers, hardware, the OS. Also, parameters that can change, e.g. the HSM slots. We have a machine with two HSMs, and after a reboot the HSMs can get a different slot assigned, which can be nuisance.

When we used JWK sets backed by Cryptoki before we took the following approach (in Java):

  1. Load PKCS#11 KeyStore.
  2. Export the found PKCS#11 keys into a JWK set, where the key alias becomes the JWK "kid", the certificate is included as an option; each JWK keeps a reference to the private key in the store.
  3. If the private key is needed, that same reference is used to get at it.

On 28/06/17 23:00, Nathaniel McCallum wrote:
Correct. This parameter can be consulted for private=
 key operations
when the private key material is unavailable.

On Wed, Jun 28, 2017 at 4:46 PM, Vladimir Dzhuvinov
<vladimir@connect2id.com> wrote:

Hi Nathaniel,

So what you wish to propose is a new "p11" parameter which is a PKCS#11
URI (RFC 7512)?

Vladimir


On 28/06/17 22:23, Nathaniel McCallum wrote:z

We're using a JWK with a "p11" property because =
the public key
material is still usable without the private key. For example,
verification of signatures or encrypting data. So, for example:

    $ jose jwk gen -o test.jwk -i '{"p11":"pkcs11:..."}'
    $ cat test.jwk
    {"crv":"P-256","kty":"EC","p11":"pkcs11:...","x":"...","y":"..."}

This JWK can be passed directly to most JOSE implementations and be
successfully used for encryption or verification and the "p11"
property will be ignored (or it can be stripped before sharing the
key). For implementations that support PKCS#11, they can detect the
absence of a private key during signing or decryption and fall back to
evaluating the "p11" property.

That is to say, PKCS#11 is not a replacement for a JWK but for the
missing private (or symmetric) key.

On Wed, Jun 28, 2017 at 2:22 PM, Jim Schaad <ietf@augustcellars.com&g=
t; wrote:

I am not aware of any work being done for that=
 purpose.  I am not sure why
you would use a JWK rather than a URI, but I can see some possibilities.

Jim


-----Original Message-----
From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Nathaniel McCa=
llum
Sent: Wednesday, June 28, 2017 5:41 AM
To: j=
ose@ietf.org
Subject: [jose] PKCS#11 Support for JWKs

Has there been any interest in standardizing this?

The Jose project[0] has some initial working code (not yet published).
We are using the (new, standardized) "p11" attribute in JWKs to replace t=
he
absence of private key material. The value of this attribute is the URI t=
o
the key as defined by p11-kit[1].

Thus, when a JWK which lacks private key material but contains "p11"
is used for a decryption or signing process, we forward this request to t=
he
PKCS#11 module.

Does anyone have interest in working with me on a standard for this (or
something similar)?

Nathaniel

[0]: https://github.com/latchset/jose
[1]: https://github.com/p11-glue/p11-kit

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

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

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

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

--------------E5934C001AE21FD6A2609297-- --------------ms030507040508090103000508 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 Fw0xNzA2MzAxODMwNDFaMC8GCSqGSIb3DQEJBDEiBCBnMRR/9/exYh9iEKZDNKo2lD4Q+YBv zJ08htvs5gKJNTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQAe0JfC3O+4 WHWgK7GBocks4PilYiwWAfqoeFCRj4xnHVLwKBebC3mYF+j3OJwMGrPhkLotVcmALe3s3SnT AgwHfXoJlbR3cApm1vUlDmpT0EnYJ6smj2GPEMoeXABWrOlNRUfFvvLXgOhC7oyJe26w/Rse cpBR1GaDX1DoopdXfvKEr9Y2OZFstin3kJ8Oh/mEUgZezeZ92Mj0y1BQ0dslBl+tJNiiqAOH aFVulCKdG5lSfHJfDVE0/j0NYq0OUBLGfpsZibl/X6RlVFdg3wD+o4Vd7T73/7RvMKAVWEYP k8dJTH0GLfjiMJRq0ohkT6HuIegYDbdygatO/qHhzeWWAAAAAAAA --------------ms030507040508090103000508-- From nobody Fri Jun 30 13:17:13 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 3B11C1243F6 for ; Fri, 30 Jun 2017 13:17:12 -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 sd0nY_zFooTv for ; Fri, 30 Jun 2017 13:17:10 -0700 (PDT) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (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 BC127126C3D for ; Fri, 30 Jun 2017 13:17:08 -0700 (PDT) Received: by mail-io0-f176.google.com with SMTP id z62so29960331ioi.3 for ; Fri, 30 Jun 2017 13:17:08 -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=ouoNX69cMCcvB1k+55iACs7k99IiKrbRh9lmYEFMQSg=; b=qf5NzYBV+Wgh7GBa+sc7DS0nYX+Ha+A4bxRrMZlB2qmCLJUVOHPintx4EjQP0tzMNC 3Q0EZ44MH7XFzX2wOXUqDG2hBg5NDqXoHUnNhe0iLa19vYO0iJCaxqBxd5jbhmRzMfmv NiGRqk6V0QO4nLRou9ApLC62HX+2Qmv4Eup3VJG/Q7RLB9gUEhiZTou+3DgIqqmR3XhU B8CiXOb68dN97y5hbWMxctKMG4ByavJPmc43I7XKxiv1HQbs/y7Ow7I1z8J3yVc3o1hI bnqKRoMaz+GghwdDd65LrX9afC7L0Nszhaw1ZH8BQdrBGEzbU5FhKGcvler+5Ae48dLl UXOg== X-Gm-Message-State: AKS2vOwgEuZqWk43/BWYTT3v7gnt7zrB98tbJysb4ujVH3OQSvFqCSP5 28vILWoLXTEflA2AXLltsIh67IQuRnva X-Received: by 10.107.4.70 with SMTP id 67mr12827104ioe.49.1498853827938; Fri, 30 Jun 2017 13:17:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.79 with HTTP; Fri, 30 Jun 2017 13:17:07 -0700 (PDT) In-Reply-To: References: <010301d2f03b$8f1a7c20$ad4f7460$@augustcellars.com> From: Nathaniel McCallum Date: Fri, 30 Jun 2017 16:17:07 -0400 Message-ID: To: Vladimir Dzhuvinov Cc: jose@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Fri, 30 Jun 2017 20:17:12 -0000 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 at i= t > last night. Am I correct that the pkcs11 URIs are simply a representation= 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 URIs s= eem > to contain a lot of details that are not about the key, but about drivers= , > hardware, the OS. Also, parameters that can change, e.g. the HSM slots. W= e > 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. 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. > 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 becomes > the JWK "kid", the certificate is included as an option; each JWK keeps a > reference to the private key in the store. > If the private key is needed, that same reference is used to get at it. 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. 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. From nobody Fri Jun 30 14:33:17 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 90F22129B8C for ; Fri, 30 Jun 2017 14:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 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] 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 YpFsUG26qeIX for ; Fri, 30 Jun 2017 14:33:14 -0700 (PDT) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) (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 D19AE129B75 for ; Fri, 30 Jun 2017 14:33:13 -0700 (PDT) Received: by mail-it0-f52.google.com with SMTP id m68so67239709ith.1 for ; Fri, 30 Jun 2017 14:33:13 -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:from:date:message-id:subject:to:cc; bh=/NIjd51T1ArNR5//7+rdD/u2LMnFzH6XMvl+2qN9TDI=; b=Pmk5E+QZywylcH6w9seQbxlWq6feN2pH8GaZfwl8SR5r1PfZfGpod8MEMJsrYsJaTB Z843qguGYigtVGaitWOhqOfWgI+SgaAuBT2XsU8+xgmcaM4Gu92h9ntdaV021tiJEvvG Y+GW/MdViE31HY78YwXja8GWpz9vlLmuHRiOarCH7ldGrBOuVEseEe6tG4vnGnXCnrEt 0Hkd6TfNnRayZOrPFcJ+ThCx/VPyvZdVE2gezokCb4PmN7qp+BfFSNZchpBdf/ehHirG WufX3rJbY3pTs5wrfSy+ioIvdGot1vYljtPCy6zHrRnAaPwCUzHsjr7M3orjVyb1K8/l LeXA== X-Gm-Message-State: AIVw112gEVT30kfslWqJVhE0dkztnh+mASVSmP41ZkGPAUcaMxiIw9jG HNrWm+AJkIolwshaKCWDndKJgHWXAD/DeAfuvg== X-Received: by 10.36.98.206 with SMTP id d197mr183503itc.50.1498858393042; Fri, 30 Jun 2017 14:33:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.152.79 with HTTP; Fri, 30 Jun 2017 14:33:12 -0700 (PDT) From: Nathaniel McCallum Date: Fri, 30 Jun 2017 17:33:12 -0400 Message-ID: To: jose@ietf.org Cc: "Sorce, Simo" , Nikos Mavrogiannopoulos , Daiki Ueno Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [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, 30 Jun 2017 21:33:15 -0000 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!