Re: [jose] Issue #76 - x5t

Mike Jones <Michael.Jones@microsoft.com> Wed, 02 October 2013 21:44 UTC

Return-Path: <Michael.Jones@microsoft.com>
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 0F00B21F92B7 for <jose@ietfa.amsl.com>; Wed, 2 Oct 2013 14:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9afqsPXinuzu for <jose@ietfa.amsl.com>; Wed, 2 Oct 2013 14:43:54 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id A68F121F967F for <jose@ietf.org>; Wed, 2 Oct 2013 14:43:46 -0700 (PDT)
Received: from BL2PR03CA016.namprd03.prod.outlook.com (10.141.66.24) by BL2PR03MB145.namprd03.prod.outlook.com (10.255.230.13) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 2 Oct 2013 21:43:44 +0000
Received: from BY2FFO11FD011.protection.gbl (2a01:111:f400:7c0c::187) by BL2PR03CA016.outlook.office365.com (2a01:111:e400:c1b::24) with Microsoft SMTP Server (TLS) id 15.0.785.10 via Frontend Transport; Wed, 2 Oct 2013 21:43:44 +0000
Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD011.mail.protection.outlook.com (10.1.14.129) with Microsoft SMTP Server (TLS) id 15.0.785.10 via Frontend Transport; Wed, 2 Oct 2013 21:43:43 +0000
Received: from TK5EX14MBXC290.redmond.corp.microsoft.com ([169.254.1.157]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0136.001; Wed, 2 Oct 2013 21:42:49 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Jim Schaad <ietf@augutscellars.com>
Thread-Topic: Issue #76 - x5t
Thread-Index: Ac69kRsaL3oXzmKfRBW2Jl8Dkqt8BQAHZFGwAFNT/gAALvFxMA==
Date: Wed, 02 Oct 2013 21:42:48 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739437201A29A@TK5EX14MBXC290.redmond.corp.microsoft.com>
References: <018001cebd91$722a85a0$567f90e0$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739437200DB6A@TK5EX14MBXC290.redmond.corp.microsoft.com> <02db01cebefb$fcddb4e0$f6991ea0$@augutscellars.com>
In-Reply-To: <02db01cebefb$fcddb4e0$f6991ea0$@augutscellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.72]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739437201A29ATK5EX14MBXC290r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454003)(5383001)(199002)(189002)(164054003)(51856001)(33656001)(80976001)(46102001)(59766001)(19580405001)(83322001)(77982001)(71186001)(79102001)(54316002)(49866001)(56776001)(50986001)(76482001)(47976001)(74366001)(81342001)(47736001)(4396001)(512954002)(16236675002)(84326002)(77096001)(81816001)(15975445006)(85306001)(76796001)(76786001)(19580395003)(69226001)(44976005)(74876001)(56816003)(74706001)(74502001)(53806001)(81686001)(63696002)(20776003)(31966008)(15202345003)(47446002)(74662001)(54356001)(80022001)(65816001)(66066001)(81542001)(19300405004)(6806004)(83072001)(55846006); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB145; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0987ACA2E2
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
Cc: "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Issue #76 - x5t
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Oct 2013 21:44:07 -0000

The presence of the xt* JWK fields doesn't change what fields must be populated for a JWK.  The spec also already says: "The key in the certificate MUST match the bare public key represented by other members of the JWK."  This is the text requiring that a normal JWK representation also be present.

You can suggest wordsmithing, but I believe the normative meaning is already clear.

                                                                -- Mike

From: Jim Schaad [mailto:ietf@augutscellars.com]
Sent: Tuesday, October 01, 2013 4:15 PM
To: Mike Jones
Cc: jose@ietf.org
Subject: RE: Issue #76 - x5t

I guess the question is then which of the fields are required to be populated.  From what you say the key is required to be populated.  Are the alg and use fields required to be populated if there are such restrictions in the certificate or not?

Jim


From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Monday, September 30, 2013 12:32 AM
To: Jim Schaad
Cc: jose@ietf.org<mailto:jose@ietf.org>
Subject: RE: Issue #76 - x5t

The working group was clear in Denver that the normal JWK bare key elements MUST be present in the JWK and that the x5* fields are supplemental information that must align with their content.

Therefore, can you reword your suggested sentence below to remove the "if" clause and instead talk about the consistency between those fields that must be present?

                                                            Thanks,
                                                            -- Mike

From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: Sunday, September 29, 2013 8:59 PM
To: Mike Jones
Cc: jose@ietf.org<mailto:jose@ietf.org>
Subject: Issue #76 - x5t

Mike,

This is the suggested text modification that I have for dealing with bullet B in for this issue.

OLD
The key in the certificate MUST match the bare public key represented by the other members of the JWK.

NEW
If other members in the JWK representing portions of the certificate are present, they MUST be consistent with the same fields in the certificate.  Additional details can be found in <xref target="x5c"/>.


Jim