From nobody Sat Jan 16 04:31:55 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAF21A87CA for ; Sat, 16 Jan 2016 04:31:53 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 92eaIUBDXLKT for ; Sat, 16 Jan 2016 04:31:52 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 4E9851A87AF for ; Sat, 16 Jan 2016 04:31:52 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id 123so1520011wmz.0 for ; Sat, 16 Jan 2016 04:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=FHss84agrD64cBuvm2Fxkevl/NcucXK9//a7fTkrM+o=; b=EcMGlzaN5xE5K4l1DwtPPoopz+fzXrrAKwDeVcbz12TD19OuZlM4RZQUQelqbu8NdL azwDbBGUoaVENh3iBVx6/2KpoPurL0qC2rbH/VX58R2XvNzC53OPMjrVLB759VT7HrUr NfkkNMfUQ4Wbo5qEybvePaz30Vexmec4IUFvHk581s91bcmP+MpXUSI5dx0C7PnySTZN U8lMq97ifnFQ2D5d34xEX5zfAu3rKGXZxB66ck8DA5EACg8VARtPDOmtlwuJZIC8vycq w79bYLikWSQvCBKJppL3q1NDnPlrdO+fFpFkbXpSZy2hil1lp1LPvyASmwk/XjYhDiQH ru2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=FHss84agrD64cBuvm2Fxkevl/NcucXK9//a7fTkrM+o=; b=jcjUD/RuKC5tClSJ5Xc95vWA6Y9wvlUJekQmwxbnOYyPXmZODnyIJVTg/02gyb2Odo nqdoj/DrEN8SeSKN7NgUI0oH8s9BI9B0Zr9ZBfKc2KQpqWl5POc2XTIlRCl3y2eLCM4r X4TVBJnz6L13vOnS8pWC0HuD7e2/AsV3X4lesJfiXv2oPoB3TPpDVurwiz02XLl1p2GI Et2iQOPN0riYdCV0bRzu1MzR2elvEsgLv2N6IZ3vURLSWWRev//bSaTTVrnDCv6gW4gU qLhAkPwijpXGsEc+fFBaIMaSKcXsxUNtcAASe2FIYO0wqmb6AH/utec6mDjlo4Y5FmlP DfIA== X-Gm-Message-State: AG10YOQBJsWxVJvoEeh2JfumJU0jQvfe/Tmo0MJZFZyo61BAzdwO0F41lK3PWxRBVyxMXw== X-Received: by 10.28.139.205 with SMTP id n196mr3898827wmd.0.1452947510781; Sat, 16 Jan 2016 04:31:50 -0800 (PST) Received: from [192.168.1.79] (9.197.130.77.rev.sfr.net. [77.130.197.9]) by smtp.googlemail.com with ESMTPSA id o7sm14776778wjf.45.2016.01.16.04.31.49 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 16 Jan 2016 04:31:49 -0800 (PST) From: Anders Rundgren To: "pkix@ietf.org" Message-ID: <569A3832.4060700@gmail.com> Date: Sat, 16 Jan 2016 13:31:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [pkix] Signed JavaScript/JSON using ES6 + Google V8 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 12:31:54 -0000 By relying on Google's V8 for number serialization, the final interop hurdle was removed. The samples below should be comparable with respect to securing the integrity of the payload and the signature parameters, but they obviously differ a lot in the way they get the work done. JCS was developed to match information-rich, multi-signature schemes like https://www.w3.org/Payments/IG/wiki/Main_Page/ProposalsQ42015/SCAI#The_SCAI_line and similar. JCS has recently been upgraded to match ECMAScript revision 6/Google V8 making JCS compatible with node.js, Chrome, Firefox, Safari and [of course] my Java reference implementation JSON Cleartext Signature (JCS): https://cyberphone.github.io/openkeystore/resources/docs/jcs.html#ECMAScript_Compatibility_Mode var signedObject = { // The data statement: "Hello signed world!", otherProperties: [2000, true], // The signature signature: { algorithm: "ES256", publicKey: { type: "EC", curve: "P-256", x: "vlYxD4dtFJOp1_8_QUcieWCW-4KrLMmFL2rpkY1bQDs", y: "fxEF70yJenP3SPHM9hv-EnvhG6nXr3_S-fDqoj-F6yM" }, value: "2H__TkcV28QpGWPkyVbR1CW0I8L4xARrVGL0LjOeHJLOPozdzRqCTyYfmAippJXqdzgNAonnFPVCSI5A6novMQ" } }; JSON Web Signature (JWS): https://tools.ietf.org/rfc/rfc7515.txt var signedObject = { "payload": "eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ", "protected": "eyJhbGciOiJFUzI1NiJ9", "signature": "DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8IS lSApmWQxfKTUJqPP3-Kg6NU1Q" }; Anders From nobody Mon Jan 18 19:10:06 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4AD1A8980 for ; Mon, 18 Jan 2016 19:10:04 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 6U-vMm8kvb1q for ; Mon, 18 Jan 2016 19:10:03 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 272301A897E for ; Mon, 18 Jan 2016 19:10:03 -0800 (PST) Received: by mail-pa0-x22d.google.com with SMTP id yy13so350729993pab.3 for ; Mon, 18 Jan 2016 19:10:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nd8RwLhXimboECmChP6yDW+wQUmU+WmL9Ig2LVHqrAc=; b=oc+A7OonSUhf7wMmcjWOck/aWkZbuPKYUN4YoIJqVlUHVyL1kdh8HL3dQUx4wxxQIE 3eGWxGIGAbdLztNJZh569kActd7XmQmsohymyLqgG4gHIYbtLaRVL5p+Qq6eDtXYPsio ytVaj7RRTIAAOsTwIksiCLzq7tWFkWqwpoTJtbFQU6ZDacuTPyviR/3lhCrGt6qZtbXs WuD/DGxY+aNBAEvJmo2/JtSWSDp/EaTWBUdjaVAdH1wnfokFv4MolaP/2h2a868aFtyZ BcUaXEE1UVZ++sQLu/Q7Ht5bpBkSzCvI9gxO1VDCznHLe+/RfE+JVA67RflsbkvDww0B 3Prw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=nd8RwLhXimboECmChP6yDW+wQUmU+WmL9Ig2LVHqrAc=; b=R2poW+Qg+S+zGVr4leYUDnUpOL2jxe8apLeBpgPhea/P4KWcOdvJYys9egFN+2WlIJ msmS4HoA4b9eNJAVSozQ0h5OXnA6N3JIXgQ0xPZkoG3SOcyhhGqKYrRy3HWpZT8YLtxX hkCXzIanj64AXrF0v8/6ixlL408WuRpS0KWIflSUYU/KUFS5x8NKgbdTfPy0DY7y096H ret51JP7LE+JuvevE4UGIqI5NmhSbNRa1wrtyZFD6XtJ6LMmDa2EproJivD6ymm5Jb6O tDbj0/xCAS6vE0diFMPpyHEgwAXhgGxyn3Kxgllnqeknvf4dGScyKASAdgU9N2zV7T+X YpLQ== X-Gm-Message-State: ALoCoQmuJDyh/v4NFG4gQhgOZd7fhJNMrEX/Gbbtb2YpnHSkwKNLOeEoplLO0RnFTxAUkyRYEPa0FPOb/58nzTPNpG1lTt07Ww== MIME-Version: 1.0 X-Received: by 10.66.117.199 with SMTP id kg7mr41275250pab.105.1453173002767; Mon, 18 Jan 2016 19:10:02 -0800 (PST) Received: by 10.66.142.193 with HTTP; Mon, 18 Jan 2016 19:10:02 -0800 (PST) Date: Mon, 18 Jan 2016 19:10:02 -0800 Message-ID: From: Peter Bowen To: "" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [pkix] Strings in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 03:10:04 -0000 In writing certlint (https://github.com/awslabs/certlint), I ran across several items related to strings in certificates that are slightly unclear. I=E2=80=99m hoping that someone might be able to help clarify a few things: 1) TeletexString, BMPString, and UniversalString types of DirectoryStrings RFC 5280 says CAs should not use TeletexString, BMPString, and UniversalString types for DirectoryStrings. As early as 1999 (RFC 2459) these were flagged as deprecated. Is there anything that has moved these to SHALL NOT/MUST NOT or are we still at SHOULD NOT? 2) VisibleString and BMPString types of DisplayText RFC 5280 says: Conforming CAs SHOULD use the UTF8String encoding for explicitText, but MAY use IA5String. Conforming CAs MUST NOT encode explicitText as VisibleString or BMPString. However the organization field of noticeref also uses DisplayText. Do the same rules apply? 3) Unicode normalization A number of fields in certificates can take unicode strings. Is there any specification as to how (or if) they should be normalized? 4) Control characters Is there ever a valid use case for including control characters (e.g., U+0000 to U+001F and U+007F to U+009F) in a string? Thanks, Peter From nobody Tue Jan 19 00:33:11 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426CD1B2BB3 for ; Tue, 19 Jan 2016 00:33:10 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 3KLxvifzmBrV for ; Tue, 19 Jan 2016 00:33:08 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 9B1D41B2BB2 for ; Tue, 19 Jan 2016 00:33:08 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id x1so71696771qkc.1 for ; Tue, 19 Jan 2016 00:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7HtyHdMTpmohvzBSNNh9HDzNap+GRkP+yXwcMRzduOM=; b=DWgHllKj9XXox5fKmSMMZc7zRyvrgGZiuP0GxWHK+FqFAH/EwMP0jLb/tCe04uWrfk YFXjmwAhmkzpeEEMsjxoo6Ubb70cPVVd63owFYMjwmnkz3GDtBHUMcOPPeMrFVA7Aph7 sCjU8dA6AdIvoBMV9OAdKCALtZxAy65izd/iroJL+lxZZvdNMNhyYicQ4uj0PfCe/ijb Nr/O5dBtdu7hqf2fZMaQPARgoux93aUtmgmDum8TnzQl7KakYtHevEFd/gXed9tSZbQg Blu/xv30ZgcXjg4NiiUp11NovILbZyUJj8q25AEFzoAcHNeZU9WP13pMUdC6ff12l2t8 M8Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7HtyHdMTpmohvzBSNNh9HDzNap+GRkP+yXwcMRzduOM=; b=AGr+nxhZfGIODPT7tSLnKfh7r9HOmRep52qGzk2hwF0uLHfAIBr4gXnX+TFgVBbJ6r ofcxzwf/vuXvaz1epUrqBqKydOWxBUxcFnHw8qOnnFi7eX1q0McM5vCguhPmab/Y9d52 XonlkmSEmpCKWuo4pi8/nFsGectwP0NaTTZTR9WL0n4W1Pgh52qolZhzQtk+VxMGSGsd btMr0uKb5VUhppCcdudkmetw/t+nmARleXots+MOoeaGx0/6laUndpwQfWOEuwKnmdA3 /H/b1iVaoBUhDwX0EmtdruVahxc47FMP4tw0kHGHTnAeyPaqMUqe4hgT1WZ31EKeTtG6 n9gQ== X-Gm-Message-State: ALoCoQnDmIvy1QWrNTdeytpsPEng1oT+g+NXsfIPkCYo+gc+xS1jwF5J+Yf5fU2Z7S664TtIH5dquCI7nKU7j+sFsMX+3drSBA== MIME-Version: 1.0 X-Received: by 10.55.25.146 with SMTP id 18mr36293075qkz.41.1453192387854; Tue, 19 Jan 2016 00:33:07 -0800 (PST) Received: by 10.140.38.99 with HTTP; Tue, 19 Jan 2016 00:33:07 -0800 (PST) In-Reply-To: References: Date: Tue, 19 Jan 2016 09:33:07 +0100 Message-ID: From: Erwann Abalea To: Peter Bowen Content-Type: multipart/alternative; boundary=001a1147b2c01188f60529abb8ef Archived-At: Cc: "" Subject: Re: [pkix] Strings in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 08:33:10 -0000 --001a1147b2c01188f60529abb8ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bonjour Peter, 2016-01-19 4:10 GMT+01:00 Peter Bowen : > In writing certlint (https://github.com/awslabs/certlint), I ran > across several items related to strings in certificates that are > slightly unclear. I=E2=80=99m hoping that someone might be able to help > clarify a few things: > [...] > 3) Unicode normalization > > A number of fields in certificates can take unicode strings. Is there > any specification as to how (or if) they should be normalized? > > > 4) Control characters > > Is there ever a valid use case for including control characters (e.g., > U+0000 to U+001F and U+007F to U+009F) in a string? > This is described in X.520, in section 3 (matching rules and syntaxes), and more specifically at clause 7. But that's only for strings comparison (between certificates), not string storage inside certificates. --=20 Erwann. --001a1147b2c01188f60529abb8ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bonjour Peter,

2016-01-19 4:10 GMT+01:00 Peter Bowen <<= a href=3D"mailto:pzbowen@gmail.com" target=3D"_blank">pzbowen@gmail.com= >:
In writing certlint (https://github.com/awslabs/certlint), I ran
across several items related to strings in certificates that are
slightly unclear.=C2=A0 I=E2=80=99m hoping that someone might be able to he= lp
clarify a few things:

[...]
= =C2=A0
3) Unicode normalization

A number of fields in certificates can take unicode strings.=C2=A0 Is there=
any specification as to how (or if) they should be normalized?


4) Control characters

Is there ever a valid use case for including control characters (e.g.,
U+0000 to U+001F and U+007F to U+009F) in a string?
This is described in X.520, in section 3 (matching rules and s= yntaxes), and more specifically at clause 7. But that's only for string= s comparison (between certificates), not string storage inside certificates= .

--
Erwann.
--001a1147b2c01188f60529abb8ef-- From nobody Tue Jan 19 02:54:15 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACF01B2A71 for ; Tue, 19 Jan 2016 02:54:14 -0800 (PST) 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] autolearn=ham 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 nFOXhBc6w_FM for ; Tue, 19 Jan 2016 02:54:11 -0800 (PST) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 D37391B2A76 for ; Tue, 19 Jan 2016 02:54:10 -0800 (PST) Received: (qmail 25087 invoked by uid 1004); 19 Jan 2016 10:54:08 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 19 Jan 2016 10:54:08 +0000 Received: (qmail 19358 invoked by uid 1000); 19 Jan 2016 10:54:08 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 19 Jan 2016 10:54:08 +0000 To: Peter Bowen References: From: Rob Stradling Message-ID: <569E15D0.7050207@comodo.com> Date: Tue, 19 Jan 2016 10:54:08 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [pkix] Strings in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 10:54:14 -0000 On 19/01/16 08:33, Erwann Abalea wrote: > Bonjour Peter, > > 2016-01-19 4:10 GMT+01:00 Peter Bowen >: > > In writing certlint (https://github.com/awslabs/certlint), I ran > across several items related to strings in certificates that are > slightly unclear. I’m hoping that someone might be able to help > clarify a few things: > > > [...] > > 3) Unicode normalization > > A number of fields in certificates can take unicode strings. Is there > any specification as to how (or if) they should be normalized? > > > 4) Control characters > > Is there ever a valid use case for including control characters (e.g., > U+0000 to U+001F and U+007F to U+009F) in a string? > > > This is described in X.520, in section 3 (matching rules and syntaxes), > and more specifically at clause 7. But that's only for strings > comparison (between certificates), not string storage inside certificates. X.690 defines DER (and BER and CER). I'm looking at the December 1997 edition, which says: "8.20.10 For the "UTF8String" type, the octet string shall contain the octets specified in ISO/IEC 10646-1/Amd.2. Announcers and escape sequences shall not be used, and each character shall be encoded in the smallest number of octets available for that character." -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Jan 19 05:34:09 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778411B2E9E for ; Tue, 19 Jan 2016 05:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 TTS_NxWkOB4R for ; Tue, 19 Jan 2016 05:34:02 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 130CE1B2E96 for ; Tue, 19 Jan 2016 05:34:02 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id x1so74061384qkc.1 for ; Tue, 19 Jan 2016 05:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HzF/Si70rnELLBKXh/bWMqfcEmwdjyoyop16/FsZ3Cc=; b=iqpEMzeOWR/EWTu/ndhzBn2zm8S8fxKl+7KlZgf7Du7YFt3qVNy3XuaudJDpu4kDHL pPCMX0unPkOAF+gEdHMR/VOOlwnMn8NmmgMKjt8dIz/qcUxR54lyRmem26Eyn9g+1jtF sCy1Bpxn8H6+wPvcdOjNQH3W1qx8xw61rgeZwepUYRuuIqy/7ks+beyMU7aQ3L0PNPp4 Zho3uEZLP32l6z3GpjmAl2nYfy5ZlfFXoZSjBbGlIhYy3h0gh4dFYpuG+HZiTU1OKAzY +JQ+qxe15/2vf2lhv/ow+ykQlmTV44TeKcqlI71W3x+RRjVogq9+QuDsXq2s3n9JvcSJ miPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HzF/Si70rnELLBKXh/bWMqfcEmwdjyoyop16/FsZ3Cc=; b=hwb7FuBm+Q4whTE1tVgTvHvtVlS3exUBtJJsjcMFimyc/oZHPycnvDQKpXwOKnc2QJ ajm9z8KY3KjPZ8CCSqbdGRtM9UWc3p0EdGiNzku1MB4f2sVWRprg8Z4QWxhe60UdmNuh sYoWoPZziunUdI5OA4npuQvgmP5lbJ3APdbqzgWGZMerxweKd747qldv3tWuaILXkIDo wOuOfH9YJkJBc3v9EegNsJqe+vAreZpu+UeyAsN082iPau7ijeSQf6ptCG6H6wrt53Af VK9Cv/Dx0ylIjujkFnM04r3M8C4W+Pbi0ub5Bt11/MXJSbatiyTsG2EXIMkItTsUHQOj FRpQ== X-Gm-Message-State: ALoCoQkr8rE7VE5RFWW4A3jgrA+4FdDGOIRjqFnaOqIVQ0sKYJJQRvZQiuujSo3bfzbH9sFynWCFpUlylBfw02n8IRVSOpQNHw== MIME-Version: 1.0 X-Received: by 10.55.221.66 with SMTP id n63mr37496755qki.64.1453210441237; Tue, 19 Jan 2016 05:34:01 -0800 (PST) Received: by 10.140.38.99 with HTTP; Tue, 19 Jan 2016 05:34:01 -0800 (PST) In-Reply-To: <569E15D0.7050207@comodo.com> References: <569E15D0.7050207@comodo.com> Date: Tue, 19 Jan 2016 14:34:01 +0100 Message-ID: From: Erwann Abalea To: Rob Stradling Content-Type: multipart/alternative; boundary=001a11498e222262bc0529afec83 Archived-At: Cc: "" Subject: Re: [pkix] Strings in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 13:34:03 -0000 --001a11498e222262bc0529afec83 Content-Type: text/plain; charset=UTF-8 2016-01-19 11:54 GMT+01:00 Rob Stradling : > On 19/01/16 08:33, Erwann Abalea wrote: > >> Bonjour Peter, >> >> 2016-01-19 4:10 GMT+01:00 Peter Bowen > >: >> >> [...] >> >> 3) Unicode normalization >> >> A number of fields in certificates can take unicode strings. Is there >> any specification as to how (or if) they should be normalized? >> >> >> 4) Control characters >> >> Is there ever a valid use case for including control characters (e.g., >> U+0000 to U+001F and U+007F to U+009F) in a string? >> >> >> This is described in X.520, in section 3 (matching rules and syntaxes), >> and more specifically at clause 7. But that's only for strings >> comparison (between certificates), not string storage inside certificates. >> > > X.690 defines DER (and BER and CER). I'm looking at the December 1997 > edition, which says: > > "8.20.10 For the "UTF8String" type, the octet string shall contain the > octets specified in ISO/IEC 10646-1/Amd.2. Announcers and escape sequences > shall not be used, and each character shall be encoded in the smallest > number of octets available for that character." You're right, Rob. In the 2015 edition, the section has moved to 8.23.10, and "ISO/IEC 10646-1/Amd.2" is now "ISO/IEC 10646, Annex D". And it's not even limited to DER. -- Erwann. --001a11498e222262bc0529afec83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2016-01-19 11:54 GMT+01:00 Rob Stradling <rob.stradling@comodo= .com>:
On = 19/01/16 08:33, Erwann Abalea wrote:
Bonjour Peter,

2016-01-19 4:10 GMT+01:00 Peter Bowen <pzbowen@gmail.com
 <mailto:pzbowen@g= mail.com>>:

[...]

=C2=A0 =C2=A0 3) Unicode normalization

=C2=A0 =C2=A0 A number of fields in certificates can take unicode strings.= =C2=A0 Is there
=C2=A0 =C2=A0 any specification as to how (or if) they should be normalized= ?


=C2=A0 =C2=A0 4) Control characters

=C2=A0 =C2=A0 Is there ever a valid use case for including control characte= rs (e.g.,
=C2=A0 =C2=A0 U+0000 to U+001F and U+007F to U+009F) in a string?


This is described in X.520, in section 3 (matching rules and syntaxes),
and more specifically at clause 7. But that's only for strings
comparison (between certificates), not string storage inside certificates.<= br>

X.690 defines DER (and BER and CER).=C2=A0 I'm looking at the December = 1997 edition, which says:

"8.20.10 For the "UTF8String" type, the octet string shall c= ontain the octets specified in ISO/IEC 10646-1/Amd.2.=C2=A0 Announcers and = escape sequences shall not be used, and each character shall be encoded in = the smallest number of octets available for that character."

You're right, Rob. In the 2015 edition, the sect= ion has moved to 8.23.10, and "ISO/IEC 10646-1/Amd.2" is now &quo= t;ISO/IEC 10646, Annex D". And it's not even limited to DER.
=

--
Erwann.
--001a11498e222262bc0529afec83-- From nobody Fri Jan 22 17:50:02 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38E51B2EE2 for ; Fri, 22 Jan 2016 17:50:00 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 RJkMMQ9wlrUY for ; Fri, 22 Jan 2016 17:49:58 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 9B7711B2EDD for ; Fri, 22 Jan 2016 17:49:58 -0800 (PST) Received: by mail-pa0-x232.google.com with SMTP id yy13so50032264pab.3 for ; Fri, 22 Jan 2016 17:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W77mg+DxnMogZ5TkV5yOruiw4gS2k9uRvMt3SsHt6zg=; b=Wgk2yZn21kyUgDWkyh6gPWrEg5TsCdxFHJt0x/KxXwxuNhriGPh2qe7qHR4A/Gjasp SsjF4GiDXQS+hwjH/6p8kBmrsiX+PPSBFhyM3TBvHoEQpa8cj1aotGgBV11wfN4sRK0X 76optqzXF8ExqkNAT2N7X/6e0xvG9KvmOCophqJCglbcjjGRDzy8RbbqiiVQUBltIZ/v YIDhSVaoJVmBoqDFTsUA0WOlp8V2guBby5GykenAC/xwKZ/OfG9UwrFcniUbFBioNl7I TkIPzQRHU2CGgxOKX2IMFJ47hNVMQdSlycHEWj/E1h1hHr0/KbxV1YfaEcIvlgoMsNdw YqlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=W77mg+DxnMogZ5TkV5yOruiw4gS2k9uRvMt3SsHt6zg=; b=c+qYUZZYPQjB4+hxYLplqN9h4C5WE/YZmT/oj4leYygzlsi5yYNaI2VJr+vstZOncX K0zAaLGe0jtKY5aoc84kJGRQxMebtiq6fwEapM487oUdyLJrI4FZFpzZVYtt3dfauBr4 gPMexU2YcFpnn0upG7dkFBOXI0qw+MrrJYMK6JL6vl6QIeAb9N/q0iSBrEI+95BmxcoU q1tgBD6JcRwEEd1OcGtsmuXapoB/ZBF+NuGF11WooLbPoo4KDiTAzFUHVFm6EixHOrhJ WbiFkWnC04FkaTVlgAiLaiyvGpYih11Fn4bTOsSz7REDWx0eUY6YYKXxjYVyPT4hCG31 Gb7g== X-Gm-Message-State: AG10YOQoQ1atiwJkwTmz1jVEBOX90HygatbSGoNYxQJ1vqxfzc4tAP+cDUlHAUV8MykaULGlITHnAFhgB6REVg== MIME-Version: 1.0 X-Received: by 10.67.14.136 with SMTP id fg8mr8014564pad.105.1453513798198; Fri, 22 Jan 2016 17:49:58 -0800 (PST) Received: by 10.66.142.193 with HTTP; Fri, 22 Jan 2016 17:49:58 -0800 (PST) In-Reply-To: <000401d130e3$bdf08120$39d18360$@x500.eu> References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> Date: Fri, 22 Jan 2016 17:49:58 -0800 Message-ID: From: Peter Bowen To: Erik Andersen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Directory list , WG15@iectc57.org, PKIX Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 01:50:00 -0000 Erik, While I'm sure this is a contentious proposal, I would proposal that X.509 add language allowing usage of Extended Key Usage for constraints, joining certificate policies, name constraints, basic constraints, etc. Many widely deployed certificate path validation libraries already implement this even though it is unclear at best whether such is compliant with X.509 (10/2012). Thanks, Peter On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen wrote: > Hi Stephen, > > I will collect any comment on any list. The goal is to get the best technical specification. > > Regards, > > Erik > > -----Oprindelig meddelelse----- > Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sendt: 07 December 2015 11:45 > Til: Erik Andersen ; Directory list ; PKIX > Cc: WG15@iectc57.org > Emne: Re: [pkix] Next edition of X.509 > > > Thank you Erik! Do I understand correctly that comments from this list that you get before February are useful and that sending comments to the pkix list works well enough for you? > > If so, great, and I'd ask folks who care about RFC5280 or other PKIX RFCs to please review this to check for any glitches that might affect interop should new code be written based on the ISO doc. I'm sure other comments are also welcome, > > Cheers, > S. > > On 07/12/15 10:33, Erik Andersen wrote: >> In preparation for the next edition of X.509 (the 2016 edition), I >> have forwarded to the ISO/IEC JTC1/SC6 two documents for three months ballots: >> >> >> >> These two documents may be found as: >> >> >> >> 1. http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf, >> which is the 3rd PDAM text for an amendment to X.509. >> >> 2. http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, which a >> second draft technical corrigendum. This technical corrigendum is >> based on a set of defects reports, which include the justification for >> the changes. The Defect reports may be found on >> http://www.x500standard.com/index.php?n=Ig.DefectReports. >> >> >> >> An early corrigendum has been approved within ISO and ITU-T and may be >> found >> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. >> >> >> >> These three documents together with the seventh edition will provide >> the input to the next edition of X.509. The different >> X.recommendations, including X.509, may be found at >> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely available in the PDF version. >> >> >> >> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot >> comments on the two documents out for ballot. Others, which may have >> comments on the these document, may post them on the lists and after >> consolidation and consensus, they may be issued as ITU-T comments. >> >> >> >> It is important to check whether any of the suggested changes affects >> running codes. If that is a case, it is a mistake. >> >> >> >> The intension behind the changes has been: >> >> 1. A better separation between public-key certificates and attribute >> certificates. >> >> 2. Use of a consistent terminology. >> >> 3. Use of a consistent editing style in accordance with the ITU-T >> editing guidelines.. >> >> 4. A new PKI component called trust broker assists a relying party >> validating a public-key certificate is included. >> >> 5. IEC TC57 WG15 has identified a requirement for a feature first >> called whitelist but now the term is authorization and validation list >> is used. A proposal for such a feature is included in the amendment. >> >> The main goal has been to position X.509 for new challenges, such >> smart grid security and security for Internet of Things with battery >> driven devices, very short messages (can we put a 257 octets signature >> on a few octets message?) , short reaction time requirements, many >> millions of entities, etc. This is all very different from Web-based systems. >> >> Kind regards, >> >> Erik >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Sat Jan 23 02:19:57 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536211A028A for ; Sat, 23 Jan 2016 02:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DK=1.009, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 v5ZvF83B2mlz for ; Sat, 23 Jan 2016 02:19:54 -0800 (PST) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) (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 88BA01A0273 for ; Sat, 23 Jan 2016 02:19:53 -0800 (PST) Received: from Morten ([62.44.135.85]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201601231119482706; Sat, 23 Jan 2016 11:19:48 +0100 From: "Erik Andersen" To: "'Peter Bowen'" References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> In-Reply-To: Date: Sat, 23 Jan 2016 11:19:51 +0100 Message-ID: <000001d155c7$98b64530$ca22cf90$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIVSzUXZpx0TCzS4mpo4m9SkbHUeQJEdeqNAqiykAAB5gd5Ap5KXmcQ Content-Language: en-gb Archived-At: Cc: 'Directory list' , 'PKIX' Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 10:19:56 -0000 Hi Peter, I would like to explore whether there is support for such an addition to = X.509. Could I have your comments please? Regards, Erik -----Oprindelig meddelelse----- Fra: Peter Bowen [mailto:pzbowen@gmail.com]=20 Sendt: 23 January 2016 02:50 Til: Erik Andersen Cc: Stephen Farrell ; Directory list = ; PKIX ; WG15@iectc57.org Emne: Re: [pkix] Next edition of X.509 Erik, While I'm sure this is a contentious proposal, I would proposal that X.509 add language allowing usage of Extended Key Usage for constraints, = joining certificate policies, name constraints, basic constraints, etc. = Many widely deployed certificate path validation libraries already = implement this even though it is unclear at best whether such is = compliant with X.509 (10/2012). Thanks, Peter On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen wrote: > Hi Stephen, > > I will collect any comment on any list. The goal is to get the best = technical specification. > > Regards, > > Erik > > -----Oprindelig meddelelse----- > Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sendt: 07 December 2015 11:45 > Til: Erik Andersen ; Directory list=20 > ; PKIX > Cc: WG15@iectc57.org > Emne: Re: [pkix] Next edition of X.509 > > > Thank you Erik! Do I understand correctly that comments from this list = that you get before February are useful and that sending comments to the = pkix list works well enough for you? > > If so, great, and I'd ask folks who care about RFC5280 or other PKIX=20 > RFCs to please review this to check for any glitches that might affect = > interop should new code be written based on the ISO doc. I'm sure=20 > other comments are also welcome, > > Cheers, > S. > > On 07/12/15 10:33, Erik Andersen wrote: >> In preparation for the next edition of X.509 (the 2016 edition), I=20 >> have forwarded to the ISO/IEC JTC1/SC6 two documents for three months = ballots: >> >> >> >> These two documents may be found as: >> >> >> >> 1. = http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf, >> which is the 3rd PDAM text for an amendment to X.509. >> >> 2. http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, = which a >> second draft technical corrigendum. This technical corrigendum is=20 >> based on a set of defects reports, which include the justification=20 >> for the changes. The Defect reports may be found on=20 >> http://www.x500standard.com/index.php?n=3DIg.DefectReports. >> >> >> >> An early corrigendum has been approved within ISO and ITU-T and may=20 >> be found >> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. >> >> >> >> These three documents together with the seventh edition will provide=20 >> the input to the next edition of X.509. The different=20 >> X.recommendations, including X.509, may be found at=20 >> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely = available in the PDF version. >> >> >> >> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot=20 >> comments on the two documents out for ballot. Others, which may have=20 >> comments on the these document, may post them on the lists and after=20 >> consolidation and consensus, they may be issued as ITU-T comments. >> >> >> >> It is important to check whether any of the suggested changes affects = >> running codes. If that is a case, it is a mistake. >> >> >> >> The intension behind the changes has been: >> >> 1. A better separation between public-key certificates and = attribute >> certificates. >> >> 2. Use of a consistent terminology. >> >> 3. Use of a consistent editing style in accordance with the = ITU-T >> editing guidelines.. >> >> 4. A new PKI component called trust broker assists a relying = party >> validating a public-key certificate is included. >> >> 5. IEC TC57 WG15 has identified a requirement for a feature = first >> called whitelist but now the term is authorization and validation=20 >> list is used. A proposal for such a feature is included in the = amendment. >> >> The main goal has been to position X.509 for new challenges, such=20 >> smart grid security and security for Internet of Things with battery=20 >> driven devices, very short messages (can we put a 257 octets=20 >> signature on a few octets message?) , short reaction time=20 >> requirements, many millions of entities, etc. This is all very = different from Web-based systems. >> >> Kind regards, >> >> Erik >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Sat Jan 23 04:44:12 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8DE1A00A3 for ; Sat, 23 Jan 2016 04:44:10 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 KX4QuYdMAdOb for ; Sat, 23 Jan 2016 04:44:08 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 7DF561A00A1 for ; Sat, 23 Jan 2016 04:44:08 -0800 (PST) Received: by mail-pa0-x231.google.com with SMTP id cy9so55986180pac.0 for ; Sat, 23 Jan 2016 04:44:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AOsl2u2vN/rocTaDpWXvkK63/pKn35fRXkFa68dQaxU=; b=XRGcsq/B8SwYHdN11ee+qLtguuFWEeiWz7jmau+xDbsq7vDFmJ/lIArhnK8Fnkdd4t 5Eki7u+mTIR7S+XY59ZjhFymtZ4+dUchdhgRCuob1JLXCi2l0eMkj4Q71150pSa6Dx3E wDEae01noiptKxXdpCxhYwjQeaQSQaqvNcpB2U+UXcsI6rKhnRAfEP9proczgxXvQPhc wpZEWIZYOXZrCb58CUG2B6ppzYL0TlTK1z3Jy1LkyP+s5lFpj6deikqGf/+SxPpeIJqR PfTKtDx3wZq7pV6Wq1oK6P0IMrpsRPmmJjBgqG6a/236m9fQrPsLrshfGGWVlXLeWSEp X6+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AOsl2u2vN/rocTaDpWXvkK63/pKn35fRXkFa68dQaxU=; b=mf4JG8rto69D3E/eJote9jiYtbAImpuD/wKoSNzua+0/rvb5f2Vjl6aBphMrlFVNEG 02A+gWgl7oGhIpE0AAFvtzNihPMBd+ruGnQ9WtDKZGYzB7ITMd/s/SA7QTlN6ZKOzFSO zhMmhV/2MAJH7TfRPb9SrMncHTE7aTqf7sNASTmK4fTYLiFoeTchlmatWW6sPHOimgt5 WunUhw35XYB58SJgxS28pFq6LPMQp9oROFevHHKVnylxByTYkoLzMs0HXQ+x6tcuwfY5 4DS47kczukApKNnyI5F0BsusXMvus4fjE8CpZwJSLSscCkW3hCBpoqSDUBkZI692orPc OFqQ== X-Gm-Message-State: AG10YORIrOx7Hnr5qpWcJ3IYZCkOHvVqhgQ1VkxxYMBBg7oOhnNcnYKra2+KRM7D/FWaWJgC2ZXgl3eKS+OG6g== MIME-Version: 1.0 X-Received: by 10.67.14.136 with SMTP id fg8mr10827021pad.105.1453553048072; Sat, 23 Jan 2016 04:44:08 -0800 (PST) Received: by 10.66.142.193 with HTTP; Sat, 23 Jan 2016 04:44:08 -0800 (PST) In-Reply-To: <000001d155c7$98b64530$ca22cf90$@x500.eu> References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> Date: Sat, 23 Jan 2016 04:44:08 -0800 Message-ID: From: Peter Bowen To: Erik Andersen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Directory list , PKIX Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 12:44:10 -0000 In 8.2.2.4, replace the first sentence with: The presence of this extension in an end-entity certificate indicates one or more purposes for which the certified public key may be used, in addition to, or in place of the basic purposes indicated in the key usage extension field. The presence of this extension in a certificate issued by one CA to another CA constrains the key purposes in subsequent certificates in a certification path. If there is support for this addition, then additions will also be needed in section 10 to include key purposes in the input, output, and processing. Thanks, Peter On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen wrote: > Hi Peter, > > I would like to explore whether there is support for such an addition to = X.509. Could I have your comments please? > > Regards, > > Erik > > -----Oprindelig meddelelse----- > Fra: Peter Bowen [mailto:pzbowen@gmail.com] > Sendt: 23 January 2016 02:50 > Til: Erik Andersen > Cc: Stephen Farrell ; Directory list ; PKIX ; WG15@iectc57.org > Emne: Re: [pkix] Next edition of X.509 > > Erik, > > While I'm sure this is a contentious proposal, I would proposal that > X.509 add language allowing usage of Extended Key Usage for constraints, = joining certificate policies, name constraints, basic constraints, etc. Ma= ny widely deployed certificate path validation libraries already implement = this even though it is unclear at best whether such is compliant with X.509= (10/2012). > > Thanks, > Peter > > On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen wrote: >> Hi Stephen, >> >> I will collect any comment on any list. The goal is to get the best tech= nical specification. >> >> Regards, >> >> Erik >> >> -----Oprindelig meddelelse----- >> Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sendt: 07 December 2015 11:45 >> Til: Erik Andersen ; Directory list >> ; PKIX >> Cc: WG15@iectc57.org >> Emne: Re: [pkix] Next edition of X.509 >> >> >> Thank you Erik! Do I understand correctly that comments from this list t= hat you get before February are useful and that sending comments to the pki= x list works well enough for you? >> >> If so, great, and I'd ask folks who care about RFC5280 or other PKIX >> RFCs to please review this to check for any glitches that might affect >> interop should new code be written based on the ISO doc. I'm sure >> other comments are also welcome, >> >> Cheers, >> S. >> >> On 07/12/15 10:33, Erik Andersen wrote: >>> In preparation for the next edition of X.509 (the 2016 edition), I >>> have forwarded to the ISO/IEC JTC1/SC6 two documents for three months b= allots: >>> >>> >>> >>> These two documents may be found as: >>> >>> >>> >>> 1. http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.= pdf, >>> which is the 3rd PDAM text for an amendment to X.509. >>> >>> 2. http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, whi= ch a >>> second draft technical corrigendum. This technical corrigendum is >>> based on a set of defects reports, which include the justification >>> for the changes. The Defect reports may be found on >>> http://www.x500standard.com/index.php?n=3DIg.DefectReports. >>> >>> >>> >>> An early corrigendum has been approved within ISO and ITU-T and may >>> be found >>> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. >>> >>> >>> >>> These three documents together with the seventh edition will provide >>> the input to the next edition of X.509. The different >>> X.recommendations, including X.509, may be found at >>> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely avail= able in the PDF version. >>> >>> >>> >>> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot >>> comments on the two documents out for ballot. Others, which may have >>> comments on the these document, may post them on the lists and after >>> consolidation and consensus, they may be issued as ITU-T comments. >>> >>> >>> >>> It is important to check whether any of the suggested changes affects >>> running codes. If that is a case, it is a mistake. >>> >>> >>> >>> The intension behind the changes has been: >>> >>> 1. A better separation between public-key certificates and attrib= ute >>> certificates. >>> >>> 2. Use of a consistent terminology. >>> >>> 3. Use of a consistent editing style in accordance with the ITU-T >>> editing guidelines.. >>> >>> 4. A new PKI component called trust broker assists a relying part= y >>> validating a public-key certificate is included. >>> >>> 5. IEC TC57 WG15 has identified a requirement for a feature first >>> called whitelist but now the term is authorization and validation >>> list is used. A proposal for such a feature is included in the amendmen= t. >>> >>> The main goal has been to position X.509 for new challenges, such >>> smart grid security and security for Internet of Things with battery >>> driven devices, very short messages (can we put a 257 octets >>> signature on a few octets message?) , short reaction time >>> requirements, many millions of entities, etc. This is all very differen= t from Web-based systems. >>> >>> Kind regards, >>> >>> Erik >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > From nobody Sat Jan 23 09:32:03 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BCB1B39F5 for ; Sat, 23 Jan 2016 09:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 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, FREEMAIL_REPLY=1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 2IwZcmUjE1pZ for ; Sat, 23 Jan 2016 09:31:59 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9440F1B39F6 for ; Sat, 23 Jan 2016 09:31:59 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-11v.sys.comcast.net with comcast id 9VXy1s00554zqzk01VXy1s; Sat, 23 Jan 2016 17:31:58 +0000 Received: from [IPv6:2601:148:c000:1bb4:8579:2304:499a:677a] ([IPv6:2601:148:c000:1bb4:8579:2304:499a:677a]) by resomta-po-11v.sys.comcast.net with comcast id 9VXy1s0013ltbWu01VXyHh; Sat, 23 Jan 2016 17:31:58 +0000 To: pkix@ietf.org References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> From: Michael StJohns Message-ID: <56A3B913.3030506@comcast.net> Date: Sat, 23 Jan 2016 12:32:03 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453570318; bh=SGmNBHAoRa9JFBY4B8tuO4T/GZZSxYRSewSMGy/PPgc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=dU7k6eUjBmyzHH3HVaSsr6sem8PSHIyDxCCScliXGByXydjwQEKGUc9Ocl2kXDo0B sWlTj8bJ6PuzcGi1/goVOPKWHlOBzQv+bkuZCxj012dwm4w8hWZIfgPf+uVScJ75TV WGMSFAQwArCSGGX4iyUapvsGOQbT7eyCjlMkdnrjjRmZ3EV74NJc1FCoDmy9gngX9W UHDXWBRah5OUc8pWGNX6X7wjVYEG78sgNurOIozg+YHMnTsGCZExM1Dbe6lzVdtGhU saZa+xYjSVVctE3KWJiyZqJfhNbIZ7mmM6MdsaKAPlxcW+JQ1hEQnu6dg6ML13f7T4 ZD/txrSUR3t3A== Archived-At: Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 17:32:01 -0000 On 1/23/2016 7:44 AM, Peter Bowen wrote: > In 8.2.2.4, replace the first sentence with: > > The presence of this extension in an end-entity certificate indicates > one or more purposes for which the certified public key may be used, > in addition to, or in place of the basic purposes indicated in the key > usage extension field. The presence of this extension in a certificate > issued by one CA to another CA constrains the key purposes in > subsequent certificates in a certification path. > > If there is support for this addition, then additions will also be > needed in section 10 to include key purposes in the input, output, and > processing. > > Thanks, > Peter As a general concept, backwards compatibility is a good idea. As is having end systems all get the same results when presented with the same data. I don't think the above approach accomplishes this. Instead of overloading the current meaning of ExtendedKeyUsage, I would strongly recommend creating another extension, new OID with similar syntax, but the new semantics. This also gives you the opportunity to turn on the "critical" bit (maybe "bits" if you have some extended usages that you care about always and others that you don't). Alternately (and possibly the best choice), place the OIDs in the CertificatePolicy extension as constraints on the key usage bits. You can use the same EKU oids, but their presence in the certificate policy then becomes a constraint on subordinate certificates and you can describe exactly how that works. (See my post script for a couple of ways of doing this). In your above comment I would avoid the language "in addition to, or in place of" and use one or the other. If you leave the language in, then you need additional language which describes how to determine which rules in the situation where the ExtendedKeyUsage meanings are disjoint with the KeyUsage meanings. (E.g. "If there is an ExtendedKeyUsage purpose that would normally imply a required KeyUsage bit (for example a "SignSpecialValidationCACertificate" implies that the "keyCertSign" bit should be on), but that bit is not set, then the relying party shall consider the certificate signing of all but certificates with a profile consistent with the extended key usage OID invalid). If it takes a human (as opposed to a computer) to understand - consistently - what's meant by what's included in the certificate, then we're not doing it right. Figuring out whether the relying party needs to do an "OR" ("or in place of") or an "AND" ("in addition to") between KeyUsage bits and ExtendedKeyUsage OIDs meanings (or some combination thereof) is already painful. Mike ps - Possibility 1 (not exactly how Policies are supposed to work, but): Grab a new oid and call it id-ce-extended-keyusage-policy. Stick the ExtendedKeyUsage values as "PolicyQualifierInfo.policyQualifierId"s. Have the PolicyQualifierInfo.qualifier be an ENUM of { allowed, required, prohibited }. Define a specific algorithm for determining acceptance. Possibility 2: Each EKU OID becomes a new policy. Add a policyQualifierId of id-qt-acceptance-enum with a qualifier as above {allowed, required, prohibited}. Each EKU OID has one policy qualifier info of this type. This is probably cleaner as it requires each subordinate certificate to have a specific EKU expression for each EKU policy in the parent. > > On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen wrote: >> Hi Peter, >> >> I would like to explore whether there is support for such an addition to X.509. Could I have your comments please? >> >> Regards, >> >> Erik >> >> -----Oprindelig meddelelse----- >> Fra: Peter Bowen [mailto:pzbowen@gmail.com] >> Sendt: 23 January 2016 02:50 >> Til: Erik Andersen >> Cc: Stephen Farrell ; Directory list ; PKIX ; WG15@iectc57.org >> Emne: Re: [pkix] Next edition of X.509 >> >> Erik, >> >> While I'm sure this is a contentious proposal, I would proposal that >> X.509 add language allowing usage of Extended Key Usage for constraints, joining certificate policies, name constraints, basic constraints, etc. Many widely deployed certificate path validation libraries already implement this even though it is unclear at best whether such is compliant with X.509 (10/2012). >> >> Thanks, >> Peter >> >> On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen wrote: >>> Hi Stephen, >>> >>> I will collect any comment on any list. The goal is to get the best technical specification. >>> >>> Regards, >>> >>> Erik >>> >>> -----Oprindelig meddelelse----- >>> Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>> Sendt: 07 December 2015 11:45 >>> Til: Erik Andersen ; Directory list >>> ; PKIX >>> Cc: WG15@iectc57.org >>> Emne: Re: [pkix] Next edition of X.509 >>> >>> >>> Thank you Erik! Do I understand correctly that comments from this list that you get before February are useful and that sending comments to the pkix list works well enough for you? >>> >>> If so, great, and I'd ask folks who care about RFC5280 or other PKIX >>> RFCs to please review this to check for any glitches that might affect >>> interop should new code be written based on the ISO doc. I'm sure >>> other comments are also welcome, >>> >>> Cheers, >>> S. >>> >>> On 07/12/15 10:33, Erik Andersen wrote: >>>> In preparation for the next edition of X.509 (the 2016 edition), I >>>> have forwarded to the ISO/IEC JTC1/SC6 two documents for three months ballots: >>>> >>>> >>>> >>>> These two documents may be found as: >>>> >>>> >>>> >>>> 1. http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf, >>>> which is the 3rd PDAM text for an amendment to X.509. >>>> >>>> 2. http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, which a >>>> second draft technical corrigendum. This technical corrigendum is >>>> based on a set of defects reports, which include the justification >>>> for the changes. The Defect reports may be found on >>>> http://www.x500standard.com/index.php?n=Ig.DefectReports. >>>> >>>> >>>> >>>> An early corrigendum has been approved within ISO and ITU-T and may >>>> be found >>>> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. >>>> >>>> >>>> >>>> These three documents together with the seventh edition will provide >>>> the input to the next edition of X.509. The different >>>> X.recommendations, including X.509, may be found at >>>> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely available in the PDF version. >>>> >>>> >>>> >>>> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot >>>> comments on the two documents out for ballot. Others, which may have >>>> comments on the these document, may post them on the lists and after >>>> consolidation and consensus, they may be issued as ITU-T comments. >>>> >>>> >>>> >>>> It is important to check whether any of the suggested changes affects >>>> running codes. If that is a case, it is a mistake. >>>> >>>> >>>> >>>> The intension behind the changes has been: >>>> >>>> 1. A better separation between public-key certificates and attribute >>>> certificates. >>>> >>>> 2. Use of a consistent terminology. >>>> >>>> 3. Use of a consistent editing style in accordance with the ITU-T >>>> editing guidelines.. >>>> >>>> 4. A new PKI component called trust broker assists a relying party >>>> validating a public-key certificate is included. >>>> >>>> 5. IEC TC57 WG15 has identified a requirement for a feature first >>>> called whitelist but now the term is authorization and validation >>>> list is used. A proposal for such a feature is included in the amendment. >>>> >>>> The main goal has been to position X.509 for new challenges, such >>>> smart grid security and security for Internet of Things with battery >>>> driven devices, very short messages (can we put a 257 octets >>>> signature on a few octets message?) , short reaction time >>>> requirements, many millions of entities, etc. This is all very different from Web-based systems. >>>> >>>> Kind regards, >>>> >>>> Erik >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Sat Jan 23 09:40:17 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12931B2C7D for ; Sat, 23 Jan 2016 09:40:16 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 Kb8s9KOHLobc for ; Sat, 23 Jan 2016 09:40:14 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 1D71C1B2A0D for ; Sat, 23 Jan 2016 09:40:14 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id e65so59284257pfe.0 for ; Sat, 23 Jan 2016 09:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1p+57zQkaSBCyyOAnDtrAONpEZEJ6JHvnbQ/JyfyWYs=; b=1Ipa6+zsmLy/ACFnllvTt2NtoU5oqMEF1xheMHD/+O/+2cMl/tc8KWMMRL5o+uiZLU 5zi6PQy+jlAQ/+4JkxAASsTPEtcxONibzCeDCxMnzUH7ZSEbZRgQu4K5JZJrxEqnWj02 ahwvbuoROX8aqHbt1LLAyhqeWhXWLUAinzetmrDhUYjcYC3qQjKeWSojc1MlaW3Hc/M/ F1vxts5pC7ipjNuQP0mKPFsDFnkttWrkGEltil8ckLnvyeJ0aLVV07qB1ZTZt5fenIxK BB0JJ1DGPoOyoZI0HHV1cYDUvnYiYz2l2DCxdB4FfNFT5KTyztMU/TtMaiW5NQxBoGHN 08Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1p+57zQkaSBCyyOAnDtrAONpEZEJ6JHvnbQ/JyfyWYs=; b=Voxh+S12vRPna5htwF9mDLWT8o8AFv9gNMrA1uish5FifRmsZlP4e3rU9lc0SuD+xF oHz4D0yLHi3qFjXIKQ2Crs+LLoVSY0r18whbMzNTy+xN+9pUAQAOnlprm417wOFKLbBr WIZOHL1eqMTm+3Rj70Lc5O49DwJogKgypKC7uCETU7N04tDwpPkFk7qkUar6t2Qh5bS0 S9UhxemneV41ADYJ9yoh3b7xw0v1D+0xpStZ69R9Epvos3gUQooaS+4ZIYVEq7PDHwIp ODxbW7xCO1oASH0olT2GoAsM+LLaZgMUNXyk8RsoX4pxsVTo+P8Xs4ah/RPj6F5HQZD/ LsHA== X-Gm-Message-State: AG10YOTQkqT0VKFy6ZuHqh5iPwVPLagfrN4dE2quMjNv6K0OZMTe7Y19KH3mRpkOYaBKTSueHfM/k257fx2uYQ== MIME-Version: 1.0 X-Received: by 10.98.68.152 with SMTP id m24mr13435368pfi.78.1453570813734; Sat, 23 Jan 2016 09:40:13 -0800 (PST) Received: by 10.66.142.193 with HTTP; Sat, 23 Jan 2016 09:40:13 -0800 (PST) In-Reply-To: <56A3B913.3030506@comcast.net> References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> <56A3B913.3030506@comcast.net> Date: Sat, 23 Jan 2016 09:40:13 -0800 Message-ID: From: Peter Bowen To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 17:40:17 -0000 On Sat, Jan 23, 2016 at 9:32 AM, Michael StJohns wrote: > On 1/23/2016 7:44 AM, Peter Bowen wrote: >> >> In 8.2.2.4, replace the first sentence with: >> >> The presence of this extension in an end-entity certificate indicates >> one or more purposes for which the certified public key may be used, >> in addition to, or in place of the basic purposes indicated in the key >> usage extension field. The presence of this extension in a certificate >> issued by one CA to another CA constrains the key purposes in >> subsequent certificates in a certification path. >> >> If there is support for this addition, then additions will also be >> needed in section 10 to include key purposes in the input, output, and >> processing. >> >> Thanks, >> Peter > > > As a general concept, backwards compatibility is a good idea. As is having > end systems all get the same results when presented with the same data. I > don't think the above approach accomplishes this. I probably should have pointed out that I'm not trying to dream up something new here. Microsoft, OpenSSL, and Mozilla all have implemented this and are compatible with each other's certificate path processing libraries, at least in this respect. As I understand it, this use of the EKU extension has been widely deployed for more than a decade. However it is not clear that anyone has ever proposed it to be included as part of the X.509 standard. The lack of standardization or recognition in X.509 and PKIX has led to many disagreements over whether it is valid. My hope is that this revision of X.509 might be able to at least clarify that it is not invalid to use EKU in the manner that it is currently used by these systems. > Instead of overloading the current meaning of ExtendedKeyUsage, I would > strongly recommend creating another extension, new OID with similar syntax, > but the new semantics. This also gives you the opportunity to turn on the > "critical" bit (maybe "bits" if you have some extended usages that you care > about always and others that you don't). > > Alternately (and possibly the best choice), place the OIDs in the > CertificatePolicy extension as constraints on the key usage bits. You can > use the same EKU oids, but their presence in the certificate policy then > becomes a constraint on subordinate certificates and you can describe > exactly how that works. (See my post script for a couple of ways of doing > this). > > In your above comment I would avoid the language "in addition to, or in > place of" and use one or the other. If you leave the language in, then you > need additional language which describes how to determine which rules in the > situation where the ExtendedKeyUsage meanings are disjoint with the KeyUsage > meanings. (E.g. "If there is an ExtendedKeyUsage purpose that would > normally imply a required KeyUsage bit (for example a > "SignSpecialValidationCACertificate" implies that the "keyCertSign" bit > should be on), but that bit is not set, then the relying party shall > consider the certificate signing of all but certificates with a profile > consistent with the extended key usage OID invalid). > > If it takes a human (as opposed to a computer) to understand - consistently > - what's meant by what's included in the certificate, then we're not doing > it right. Figuring out whether the relying party needs to do an "OR" ("or > in place of") or an "AND" ("in addition to") between KeyUsage bits and > ExtendedKeyUsage OIDs meanings (or some combination thereof) is already > painful. > > > Mike > > > ps - > Possibility 1 (not exactly how Policies are supposed to work, but): Grab a > new oid and call it id-ce-extended-keyusage-policy. Stick the > ExtendedKeyUsage values as "PolicyQualifierInfo.policyQualifierId"s. Have > the PolicyQualifierInfo.qualifier be an ENUM of { allowed, required, > prohibited }. Define a specific algorithm for determining acceptance. > > Possibility 2: Each EKU OID becomes a new policy. Add a policyQualifierId > of id-qt-acceptance-enum with a qualifier as above {allowed, required, > prohibited}. Each EKU OID has one policy qualifier info of this type. This > is probably cleaner as it requires each subordinate certificate to have a > specific EKU expression for each EKU policy in the parent. > > > > > > >> >> On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen wrote: >>> >>> Hi Peter, >>> >>> I would like to explore whether there is support for such an addition to >>> X.509. Could I have your comments please? >>> >>> Regards, >>> >>> Erik >>> >>> -----Oprindelig meddelelse----- >>> Fra: Peter Bowen [mailto:pzbowen@gmail.com] >>> Sendt: 23 January 2016 02:50 >>> Til: Erik Andersen >>> Cc: Stephen Farrell ; Directory list >>> ; PKIX ; WG15@iectc57.org >>> Emne: Re: [pkix] Next edition of X.509 >>> >>> Erik, >>> >>> While I'm sure this is a contentious proposal, I would proposal that >>> X.509 add language allowing usage of Extended Key Usage for constraints, >>> joining certificate policies, name constraints, basic constraints, etc. >>> Many widely deployed certificate path validation libraries already implement >>> this even though it is unclear at best whether such is compliant with X.509 >>> (10/2012). >>> >>> Thanks, >>> Peter >>> >>> On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen wrote: >>>> >>>> Hi Stephen, >>>> >>>> I will collect any comment on any list. The goal is to get the best >>>> technical specification. >>>> >>>> Regards, >>>> >>>> Erik >>>> >>>> -----Oprindelig meddelelse----- >>>> Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>>> Sendt: 07 December 2015 11:45 >>>> Til: Erik Andersen ; Directory list >>>> ; PKIX >>>> Cc: WG15@iectc57.org >>>> Emne: Re: [pkix] Next edition of X.509 >>>> >>>> >>>> Thank you Erik! Do I understand correctly that comments from this list >>>> that you get before February are useful and that sending comments to the >>>> pkix list works well enough for you? >>>> >>>> If so, great, and I'd ask folks who care about RFC5280 or other PKIX >>>> RFCs to please review this to check for any glitches that might affect >>>> interop should new code be written based on the ISO doc. I'm sure >>>> other comments are also welcome, >>>> >>>> Cheers, >>>> S. >>>> >>>> On 07/12/15 10:33, Erik Andersen wrote: >>>>> >>>>> In preparation for the next edition of X.509 (the 2016 edition), I >>>>> have forwarded to the ISO/IEC JTC1/SC6 two documents for three months >>>>> ballots: >>>>> >>>>> >>>>> >>>>> These two documents may be found as: >>>>> >>>>> >>>>> >>>>> 1. >>>>> http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf, >>>>> which is the 3rd PDAM text for an amendment to X.509. >>>>> >>>>> 2. http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, >>>>> which a >>>>> second draft technical corrigendum. This technical corrigendum is >>>>> based on a set of defects reports, which include the justification >>>>> for the changes. The Defect reports may be found on >>>>> http://www.x500standard.com/index.php?n=Ig.DefectReports. >>>>> >>>>> >>>>> >>>>> An early corrigendum has been approved within ISO and ITU-T and may >>>>> be found >>>>> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. >>>>> >>>>> >>>>> >>>>> These three documents together with the seventh edition will provide >>>>> the input to the next edition of X.509. The different >>>>> X.recommendations, including X.509, may be found at >>>>> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely >>>>> available in the PDF version. >>>>> >>>>> >>>>> >>>>> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot >>>>> comments on the two documents out for ballot. Others, which may have >>>>> comments on the these document, may post them on the lists and after >>>>> consolidation and consensus, they may be issued as ITU-T comments. >>>>> >>>>> >>>>> >>>>> It is important to check whether any of the suggested changes affects >>>>> running codes. If that is a case, it is a mistake. >>>>> >>>>> >>>>> >>>>> The intension behind the changes has been: >>>>> >>>>> 1. A better separation between public-key certificates and >>>>> attribute >>>>> certificates. >>>>> >>>>> 2. Use of a consistent terminology. >>>>> >>>>> 3. Use of a consistent editing style in accordance with the ITU-T >>>>> editing guidelines.. >>>>> >>>>> 4. A new PKI component called trust broker assists a relying >>>>> party >>>>> validating a public-key certificate is included. >>>>> >>>>> 5. IEC TC57 WG15 has identified a requirement for a feature first >>>>> called whitelist but now the term is authorization and validation >>>>> list is used. A proposal for such a feature is included in the >>>>> amendment. >>>>> >>>>> The main goal has been to position X.509 for new challenges, such >>>>> smart grid security and security for Internet of Things with battery >>>>> driven devices, very short messages (can we put a 257 octets >>>>> signature on a few octets message?) , short reaction time >>>>> requirements, many millions of entities, etc. This is all very >>>>> different from Web-based systems. >>>>> >>>>> Kind regards, >>>>> >>>>> Erik >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> pkix mailing list >>>>> pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From nobody Sat Jan 23 15:35:08 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D37B1B2B44 for ; Sat, 23 Jan 2016 15:35:07 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 U0Hf8ZYXXa9D for ; Sat, 23 Jan 2016 15:35:04 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 387601B2B3F for ; Sat, 23 Jan 2016 15:35:04 -0800 (PST) Received: by mail-pa0-x22f.google.com with SMTP id yy13so60524719pab.3 for ; Sat, 23 Jan 2016 15:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=zXdOfQwr7nsX3iwEyYWMKgBvVhiDPfXO8zAqK3uA8wc=; b=x2QSEhmzS7lsRrwaHc2H4f7EmAnEI6dIjobrRYUwfOL4Z6/O/xUdX6wrgUa7WJnE/C c1q8Bs+YUeV4Wcj3WIDeY4KBmZv8kByQEGuOK9v8hrKXGTTKFOOZSl/wkcsGovGrjZcM lA9/2cOk0vApREKvxSGTKj8K9WubFUEdm/MbD4/jmHRC4pCFIfLdIrkr+dre8z7SalwF HdUN1Tqb+99WdR29l2iS8WjqHm+Zu2cJJNQFdlDHRhRRd9kREuIrcLYZ0ukJfZrqkUYp f6u9HzVvUBx1tZ1gpcxBK/4KbsNyx2AUMOxdpJSm2feWA+8K/s800wDwee7Q6pc/LIUl 4nvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=zXdOfQwr7nsX3iwEyYWMKgBvVhiDPfXO8zAqK3uA8wc=; b=BU8HTWjXVyItCiCxhZemeC/eXY1hmbZm8aYDgX/odOXogG3Vt4o05U/IEHN2tsrbJp l5h355pDP3xINfh5dBhzwY077wwk/CjeatUO95T8OjNakDyyAB1ITOTXRuHm6pC+tq5O Iih4BKbXYYzX24/bBDW0Dq4oKK7o/h+Mxdj1X6F6aBSLR/Coe/2SffB0e2Gpec8eN5YN rDk1pdDorfb8d1v5LqS1HmEuVowef+7o/t9d7x7G+KoHHLaZHVk/trmMpXVceNPlsTOk vJD2nF+H9Gh2G29bWyZbRZyiXGCUr+HVfNrUHQVOR6L1CyUwhvZ9FQ3lObvgqpBibXGu 4TEg== X-Gm-Message-State: AG10YOSk8gwcYrVfm3EMTT+YAMX8uLjDIzm8uzatPZDExx1eEmz84RWvc3I2n8mniUkHSQ== X-Received: by 10.66.55.39 with SMTP id o7mr14941028pap.13.1453592103843; Sat, 23 Jan 2016 15:35:03 -0800 (PST) Received: from SantoshBrain ([27.5.106.227]) by smtp.gmail.com with ESMTPSA id v75sm18586783pfa.60.2016.01.23.15.35.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jan 2016 15:35:03 -0800 (PST) From: "Santosh Chokhani" To: "'Peter Bowen'" , "'Michael StJohns'" References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> <56A3B913.3030506@comcast.net> In-Reply-To: Date: Sat, 23 Jan 2016 18:34:59 -0500 Message-ID: <052101d15636$aecdca40$0c695ec0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIVSzUXZpx0TCzS4mpo4m9SkbHUeQJEdeqNAqiykAAB5gd5AgKSQWGxAf+4FlUCfrtvPwFTuCGCnggXvtA= Content-Language: en-us Archived-At: Cc: pkix@ietf.org Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 23:35:07 -0000 >From security viewpoint I am sympathetic to what Peter says. If we roll back the clock constraining the path for EKU is a superior approach and COTS use it. But, rather putting this onus on X.509, should this not be done in RFC 5280 prior to or in conjunction with X.509 revisions? -----Original Message----- From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Peter Bowen Sent: Saturday, January 23, 2016 12:40 PM To: Michael StJohns Cc: Subject: Re: [pkix] Next edition of X.509 On Sat, Jan 23, 2016 at 9:32 AM, Michael StJohns wrote: > On 1/23/2016 7:44 AM, Peter Bowen wrote: >> >> In 8.2.2.4, replace the first sentence with: >> >> The presence of this extension in an end-entity certificate indicates >> one or more purposes for which the certified public key may be used, >> in addition to, or in place of the basic purposes indicated in the >> key usage extension field. The presence of this extension in a >> certificate issued by one CA to another CA constrains the key >> purposes in subsequent certificates in a certification path. >> >> If there is support for this addition, then additions will also be >> needed in section 10 to include key purposes in the input, output, >> and processing. >> >> Thanks, >> Peter > > > As a general concept, backwards compatibility is a good idea. As is having > end systems all get the same results when presented with the same data. I > don't think the above approach accomplishes this. I probably should have pointed out that I'm not trying to dream up something new here. Microsoft, OpenSSL, and Mozilla all have implemented this and are compatible with each other's certificate path processing libraries, at least in this respect. As I understand it, this use of the EKU extension has been widely deployed for more than a decade. However it is not clear that anyone has ever proposed it to be included as part of the X.509 standard. The lack of standardization or recognition in X.509 and PKIX has led to many disagreements over whether it is valid. My hope is that this revision of X.509 might be able to at least clarify that it is not invalid to use EKU in the manner that it is currently used by these systems. > Instead of overloading the current meaning of ExtendedKeyUsage, I > would strongly recommend creating another extension, new OID with > similar syntax, but the new semantics. This also gives you the > opportunity to turn on the "critical" bit (maybe "bits" if you have > some extended usages that you care about always and others that you don't). > > Alternately (and possibly the best choice), place the OIDs in the > CertificatePolicy extension as constraints on the key usage bits. You > can use the same EKU oids, but their presence in the certificate > policy then becomes a constraint on subordinate certificates and you > can describe exactly how that works. (See my post script for a couple > of ways of doing this). > > In your above comment I would avoid the language "in addition to, or in > place of" and use one or the other. If you leave the language in, then you > need additional language which describes how to determine which rules > in the situation where the ExtendedKeyUsage meanings are disjoint with > the KeyUsage meanings. (E.g. "If there is an ExtendedKeyUsage purpose > that would normally imply a required KeyUsage bit (for example a > "SignSpecialValidationCACertificate" implies that the "keyCertSign" > bit should be on), but that bit is not set, then the relying party > shall consider the certificate signing of all but certificates with a > profile consistent with the extended key usage OID invalid). > > If it takes a human (as opposed to a computer) to understand - > consistently > - what's meant by what's included in the certificate, then we're not > doing it right. Figuring out whether the relying party needs to do an > "OR" ("or in place of") or an "AND" ("in addition to") between > KeyUsage bits and ExtendedKeyUsage OIDs meanings (or some combination > thereof) is already painful. > > > Mike > > > ps - > Possibility 1 (not exactly how Policies are supposed to work, but): Grab a > new oid and call it id-ce-extended-keyusage-policy. Stick the > ExtendedKeyUsage values as "PolicyQualifierInfo.policyQualifierId"s. > Have the PolicyQualifierInfo.qualifier be an ENUM of { allowed, > required, prohibited }. Define a specific algorithm for determining acceptance. > > Possibility 2: Each EKU OID becomes a new policy. Add a > policyQualifierId of id-qt-acceptance-enum with a qualifier as above > {allowed, required, prohibited}. Each EKU OID has one policy > qualifier info of this type. This is probably cleaner as it requires > each subordinate certificate to have a specific EKU expression for each EKU policy in the parent. > > > > > > >> >> On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen wrote: >>> >>> Hi Peter, >>> >>> I would like to explore whether there is support for such an >>> addition to X.509. Could I have your comments please? >>> >>> Regards, >>> >>> Erik >>> >>> -----Oprindelig meddelelse----- >>> Fra: Peter Bowen [mailto:pzbowen@gmail.com] >>> Sendt: 23 January 2016 02:50 >>> Til: Erik Andersen >>> Cc: Stephen Farrell ; Directory list >>> ; PKIX ; WG15@iectc57.org >>> Emne: Re: [pkix] Next edition of X.509 >>> >>> Erik, >>> >>> While I'm sure this is a contentious proposal, I would proposal that >>> X.509 add language allowing usage of Extended Key Usage for >>> constraints, joining certificate policies, name constraints, basic constraints, etc. >>> Many widely deployed certificate path validation libraries already >>> implement this even though it is unclear at best whether such is >>> compliant with X.509 (10/2012). >>> >>> Thanks, >>> Peter >>> >>> On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen wrote: >>>> >>>> Hi Stephen, >>>> >>>> I will collect any comment on any list. The goal is to get the best >>>> technical specification. >>>> >>>> Regards, >>>> >>>> Erik >>>> >>>> -----Oprindelig meddelelse----- >>>> Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>>> Sendt: 07 December 2015 11:45 >>>> Til: Erik Andersen ; Directory list >>>> ; PKIX >>>> Cc: WG15@iectc57.org >>>> Emne: Re: [pkix] Next edition of X.509 >>>> >>>> >>>> Thank you Erik! Do I understand correctly that comments from this >>>> list that you get before February are useful and that sending >>>> comments to the pkix list works well enough for you? >>>> >>>> If so, great, and I'd ask folks who care about RFC5280 or other >>>> PKIX RFCs to please review this to check for any glitches that >>>> might affect interop should new code be written based on the ISO >>>> doc. I'm sure other comments are also welcome, >>>> >>>> Cheers, >>>> S. >>>> >>>> On 07/12/15 10:33, Erik Andersen wrote: >>>>> >>>>> In preparation for the next edition of X.509 (the 2016 edition), I >>>>> have forwarded to the ISO/IEC JTC1/SC6 two documents for three >>>>> months >>>>> ballots: >>>>> >>>>> >>>>> >>>>> These two documents may be found as: >>>>> >>>>> >>>>> >>>>> 1. >>>>> http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf, >>>>> which is the 3rd PDAM text for an amendment to X.509. >>>>> >>>>> 2. http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, >>>>> which a >>>>> second draft technical corrigendum. This technical corrigendum is >>>>> based on a set of defects reports, which include the justification >>>>> for the changes. The Defect reports may be found on >>>>> http://www.x500standard.com/index.php?n=Ig.DefectReports. >>>>> >>>>> >>>>> >>>>> An early corrigendum has been approved within ISO and ITU-T and >>>>> may be found >>>>> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. >>>>> >>>>> >>>>> >>>>> These three documents together with the seventh edition will >>>>> provide the input to the next edition of X.509. The different >>>>> X.recommendations, including X.509, may be found at >>>>> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely >>>>> available in the PDF version. >>>>> >>>>> >>>>> >>>>> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot >>>>> comments on the two documents out for ballot. Others, which may >>>>> have comments on the these document, may post them on the lists >>>>> and after consolidation and consensus, they may be issued as ITU-T comments. >>>>> >>>>> >>>>> >>>>> It is important to check whether any of the suggested changes >>>>> affects running codes. If that is a case, it is a mistake. >>>>> >>>>> >>>>> >>>>> The intension behind the changes has been: >>>>> >>>>> 1. A better separation between public-key certificates and >>>>> attribute >>>>> certificates. >>>>> >>>>> 2. Use of a consistent terminology. >>>>> >>>>> 3. Use of a consistent editing style in accordance with the ITU-T >>>>> editing guidelines.. >>>>> >>>>> 4. A new PKI component called trust broker assists a relying >>>>> party >>>>> validating a public-key certificate is included. >>>>> >>>>> 5. IEC TC57 WG15 has identified a requirement for a feature first >>>>> called whitelist but now the term is authorization and validation >>>>> list is used. A proposal for such a feature is included in the >>>>> amendment. >>>>> >>>>> The main goal has been to position X.509 for new challenges, such >>>>> smart grid security and security for Internet of Things with >>>>> battery driven devices, very short messages (can we put a 257 >>>>> octets signature on a few octets message?) , short reaction time >>>>> requirements, many millions of entities, etc. This is all very >>>>> different from Web-based systems. >>>>> >>>>> Kind regards, >>>>> >>>>> Erik >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> pkix mailing list >>>>> pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From nobody Sat Jan 23 15:43:06 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78431B2B7E for ; Sat, 23 Jan 2016 15:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 6P6-B5O7m_tx for ; Sat, 23 Jan 2016 15:43:02 -0800 (PST) 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 EEB4E1B2B7A for ; Sat, 23 Jan 2016 15:43:01 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id s5so42333988qkd.0 for ; Sat, 23 Jan 2016 15:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f3sqc3H0idlGMQ4+R8Yco0XinWvvGCLT24wkuTb/Yw8=; b=Zp6a6/JPXw6+7j6PRtoqXjyFHFkziKb54NDvCPOItKn2NA4qB/quDbgJ/5rs+u9ce3 9fcUkTU3QotvhwL7+rDSTLTcTx8qXso+mNw8GBMEIqfJhcUxCrlsEOQCc0lY1W0WP5hg V52E50SUx6WiWxRNm1FV39UpBnMkWltQdInSEaByHAXze/S4ziAKj/lQiYwIs+CUFWER LjWGdF9tMWVHg6xJh/uV9fpnlqBoRR0J3+/72C2I+dlofeQwt/NXLLy7Nxa8bEHn2VsV xzKz/FfwjghxAw0E1X8Ag+PSzATfIcJEGGlFx1JA0e5bwJlcC/yXCkwQSp7qp2625zcM QLNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f3sqc3H0idlGMQ4+R8Yco0XinWvvGCLT24wkuTb/Yw8=; b=N6r3haGi0lN8Gn2rO7xILU3tK1oqCGFXMfpUh8Gcx8Pqe78JJLzxP3y7H7Nn0yGUtf 1WVCldoIoI4O5DgmeMDR6TCx1V4s0jvhMWj3gpKN8K2A4Vs9s6NgZr3Eq5fM+nDT0Kv3 2d+AqRQcFmpUOZpc+CULXkihUHwzsY8wBhqTLKG988+Xz+MUQvPoeEIY/5IOjRZQi7+1 PXCaxlUH1wRia5AmT159IrXoHVtNtZd1oksg/UvriICSFy7tA3VOTkr8wYjKU8OW/+4B LKx1++7U/mjRT/1HZvb03/H+jM5cTKlserLOcwrbU8+zjs/tqHRtukN66q+5cNXL2lf/ 2o5g== X-Gm-Message-State: AG10YOTWkst7ZE261p/pusY3uGKXJy4EKE7l9AMniqmtN8WWY+fOHEA4GhFR91bBde4pLtDYQ5oBOOFpfzEIjw== MIME-Version: 1.0 X-Received: by 10.55.23.144 with SMTP id 16mr3826386qkx.64.1453592581123; Sat, 23 Jan 2016 15:43:01 -0800 (PST) Received: by 10.140.38.99 with HTTP; Sat, 23 Jan 2016 15:43:01 -0800 (PST) In-Reply-To: References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> Date: Sun, 24 Jan 2016 00:43:01 +0100 Message-ID: From: Erwann Abalea To: Peter Bowen Content-Type: multipart/alternative; boundary=001a1147b93e7231f2052a08e57d Archived-At: Cc: Directory list , PKIX Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 23:43:05 -0000 --001a1147b93e7231f2052a08e57d Content-Type: text/plain; charset=UTF-8 It doesn't work with designated OCSP responder certificates, unless you introduce an exception for this particular extended key usage. 2016-01-23 13:44 GMT+01:00 Peter Bowen : > In 8.2.2.4, replace the first sentence with: > > The presence of this extension in an end-entity certificate indicates > one or more purposes for which the certified public key may be used, > in addition to, or in place of the basic purposes indicated in the key > usage extension field. The presence of this extension in a certificate > issued by one CA to another CA constrains the key purposes in > subsequent certificates in a certification path. > > If there is support for this addition, then additions will also be > needed in section 10 to include key purposes in the input, output, and > processing. > > Thanks, > Peter > > On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen wrote: > > Hi Peter, > > > > I would like to explore whether there is support for such an addition to > X.509. Could I have your comments please? > > > > Regards, > > > > Erik > > > > -----Oprindelig meddelelse----- > > Fra: Peter Bowen [mailto:pzbowen@gmail.com] > > Sendt: 23 January 2016 02:50 > > Til: Erik Andersen > > Cc: Stephen Farrell ; Directory list < > x500standard@freelists.org>; PKIX ; WG15@iectc57.org > > Emne: Re: [pkix] Next edition of X.509 > > > > Erik, > > > > While I'm sure this is a contentious proposal, I would proposal that > > X.509 add language allowing usage of Extended Key Usage for constraints, > joining certificate policies, name constraints, basic constraints, etc. > Many widely deployed certificate path validation libraries already > implement this even though it is unclear at best whether such is compliant > with X.509 (10/2012). > > > > Thanks, > > Peter > > > > On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen wrote: > >> Hi Stephen, > >> > >> I will collect any comment on any list. The goal is to get the best > technical specification. > >> > >> Regards, > >> > >> Erik > >> > >> -----Oprindelig meddelelse----- > >> Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > >> Sendt: 07 December 2015 11:45 > >> Til: Erik Andersen ; Directory list > >> ; PKIX > >> Cc: WG15@iectc57.org > >> Emne: Re: [pkix] Next edition of X.509 > >> > >> > >> Thank you Erik! Do I understand correctly that comments from this list > that you get before February are useful and that sending comments to the > pkix list works well enough for you? > >> > >> If so, great, and I'd ask folks who care about RFC5280 or other PKIX > >> RFCs to please review this to check for any glitches that might affect > >> interop should new code be written based on the ISO doc. I'm sure > >> other comments are also welcome, > >> > >> Cheers, > >> S. > >> > >> On 07/12/15 10:33, Erik Andersen wrote: > >>> In preparation for the next edition of X.509 (the 2016 edition), I > >>> have forwarded to the ISO/IEC JTC1/SC6 two documents for three months > ballots: > >>> > >>> > >>> > >>> These two documents may be found as: > >>> > >>> > >>> > >>> 1. > http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf, > >>> which is the 3rd PDAM text for an amendment to X.509. > >>> > >>> 2. http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, > which a > >>> second draft technical corrigendum. This technical corrigendum is > >>> based on a set of defects reports, which include the justification > >>> for the changes. The Defect reports may be found on > >>> http://www.x500standard.com/index.php?n=Ig.DefectReports. > >>> > >>> > >>> > >>> An early corrigendum has been approved within ISO and ITU-T and may > >>> be found > >>> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. > >>> > >>> > >>> > >>> These three documents together with the seventh edition will provide > >>> the input to the next edition of X.509. The different > >>> X.recommendations, including X.509, may be found at > >>> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely > available in the PDF version. > >>> > >>> > >>> > >>> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot > >>> comments on the two documents out for ballot. Others, which may have > >>> comments on the these document, may post them on the lists and after > >>> consolidation and consensus, they may be issued as ITU-T comments. > >>> > >>> > >>> > >>> It is important to check whether any of the suggested changes affects > >>> running codes. If that is a case, it is a mistake. > >>> > >>> > >>> > >>> The intension behind the changes has been: > >>> > >>> 1. A better separation between public-key certificates and > attribute > >>> certificates. > >>> > >>> 2. Use of a consistent terminology. > >>> > >>> 3. Use of a consistent editing style in accordance with the ITU-T > >>> editing guidelines.. > >>> > >>> 4. A new PKI component called trust broker assists a relying > party > >>> validating a public-key certificate is included. > >>> > >>> 5. IEC TC57 WG15 has identified a requirement for a feature first > >>> called whitelist but now the term is authorization and validation > >>> list is used. A proposal for such a feature is included in the > amendment. > >>> > >>> The main goal has been to position X.509 for new challenges, such > >>> smart grid security and security for Internet of Things with battery > >>> driven devices, very short messages (can we put a 257 octets > >>> signature on a few octets message?) , short reaction time > >>> requirements, many millions of entities, etc. This is all very > different from Web-based systems. > >>> > >>> Kind regards, > >>> > >>> Erik > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> pkix mailing list > >>> pkix@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pkix > >>> > >> > >> _______________________________________________ > >> pkix mailing list > >> pkix@ietf.org > >> https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Erwann. --001a1147b93e7231f2052a08e57d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It doesn't work with designated OCSP responder certifi= cates, unless you introduce an exception for this particular extended key u= sage.

2016-01-= 23 13:44 GMT+01:00 Peter Bowen <pzbowen@gmail.com>:
In 8.2.2.4, replace the first sentence with:

The presence of this extension in an end-entity certificate indicates
one or more purposes for which the certified public key may be used,
in addition to, or in place of the basic purposes indicated in the key
usage extension field. The presence of this extension in a certificate
issued by one CA to another CA constrains the key purposes in
subsequent certificates in a certification path.

If there is support for this addition, then additions will also be
needed in section 10 to include key purposes in the input, output, and
processing.

Thanks,
Peter

On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen <era@x500.eu> wrote:
> Hi Peter,
>
> I would like to explore whether there is support for such an addition = to X.509. Could I have your comments please?
>
> Regards,
>
> Erik
>
> -----Oprindelig meddelelse-----
> Fra: Peter Bowen [mailto:pzbowen@= gmail.com]
> Sendt: 23 January 2016 02:50
> Til: Erik Andersen <era@x500.eu&= gt;
> Cc: Stephen Farrell <s= tephen.farrell@cs.tcd.ie>; Directory list <x500standard@freelists.org>; PKIX <pkix@ietf.org>; WG15@iectc57.org
> Emne: Re: [pkix] Next edition of X.509
>
> Erik,
>
> While I'm sure this is a contentious proposal, I would proposal th= at
> X.509 add language allowing usage of Extended Key Usage for constraint= s, joining certificate policies, name constraints, basic constraints, etc.= =C2=A0 Many widely deployed certificate path validation libraries already i= mplement this even though it is unclear at best whether such is compliant w= ith X.509 (10/2012).
>
> Thanks,
> Peter
>
> On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen <era@x500.eu> wrote:
>> Hi Stephen,
>>
>> I will collect any comment on any list. The goal is to get the bes= t technical specification.
>>
>> Regards,
>>
>> Erik
>>
>> -----Oprindelig meddelelse-----
>> Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>> Sendt: 07 December 2015 11:45
>> Til: Erik Andersen <era@x500.eu<= /a>>; Directory list
>> <x500standard@fre= elists.org>; PKIX <pkix@ietf.org= >
>> Cc: WG15@iectc57.org
>> Emne: Re: [pkix] Next edition of X.509
>>
>>
>> Thank you Erik! Do I understand correctly that comments from this = list that you get before February are useful and that sending comments to t= he pkix list works well enough for you?
>>
>> If so, great, and I'd ask folks who care about RFC5280 or othe= r PKIX
>> RFCs to please review this to check for any glitches that might af= fect
>> interop should new code be written based on the ISO doc. I'm s= ure
>> other comments are also welcome,
>>
>> Cheers,
>> S.
>>
>> On 07/12/15 10:33, Erik Andersen wrote:
>>> In preparation for the next edition of X.509 (the 2016 edition= ), I
>>> have forwarded to the ISO/IEC JTC1/SC6 two documents for three= months ballots:
>>>
>>>
>>>
>>> These two documents may be found as:
>>>
>>>
>>>
>>> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf,
>>> which is the 3rd PDAM text for an amendment to X.509.
>>>
>>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttp://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, which a
>>> second draft technical corrigendum. This technical corrigendum= is
>>> based on a set of defects reports, which include the justifica= tion
>>> for the changes. The Defect reports may be found on
>>> http://www.x500standard.com/i= ndex.php?n=3DIg.DefectReports.
>>>
>>>
>>>
>>> An early corrigendum has been approved within ISO and ITU-T an= d may
>>> be found
>>> as: http://www.x500standard.co= m/uploads/dtc/X509-Ed7-Cor1.pdf.
>>>
>>>
>>>
>>> These three documents together with the seventh edition will p= rovide
>>> the input to the next edition of X.509. The different
>>> X.recommendations, including X.509, may be found at
>>> http://www.itu.int/rec/T-REC-X/e. This edition of X= .509 is freely available in the PDF version.
>>>
>>>
>>>
>>> Those involved in=C2=A0 ISO/IEC JTC1/SC6 can, of course, submi= t ballot
>>> comments on the two documents out for ballot. Others, which ma= y have
>>> comments on the these document, may post them on the lists and= after
>>> consolidation and consensus, they may be issued as ITU-T comme= nts.
>>>
>>>
>>>
>>> It is important to check whether any of the suggested changes = affects
>>> running codes. If that is a case, it is a mistake.
>>>
>>>
>>>
>>> The intension behind the changes has been:
>>>
>>> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0A better separation between publi= c-key certificates and attribute
>>> certificates.
>>>
>>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0Use of a consistent terminology.<= br> >>>
>>> 3.=C2=A0 =C2=A0 =C2=A0 =C2=A0Use of a consistent editing style= in accordance with the ITU-T
>>> editing guidelines..
>>>
>>> 4.=C2=A0 =C2=A0 =C2=A0 =C2=A0A new PKI component called trust = broker assists a relying party
>>> validating a public-key certificate is included.
>>>
>>> 5.=C2=A0 =C2=A0 =C2=A0 =C2=A0IEC TC57 WG15 has identified a re= quirement for a feature first
>>> called whitelist but now the term is authorization and validat= ion
>>> list is used. A proposal for such a feature is included in the= amendment.
>>>
>>> The main goal has been to position X.509 for new challenges, s= uch
>>> smart grid security and security for Internet of Things with b= attery
>>> driven devices, very short messages (can we put a 257 octets >>> signature on a few octets message?) , short reaction time
>>> requirements, many millions of entities, etc. This is all very= different from Web-based=C2=A0 systems.
>>>
>>> Kind regards,
>>>
>>> Erik
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> pkix mailing list
>>> pkix@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pkix
>>>
>>
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix >

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



--
=
Erwann.
--001a1147b93e7231f2052a08e57d-- From nobody Sat Jan 23 15:55:09 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C541B2BEE for ; Sat, 23 Jan 2016 15:55:07 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 06QKg8-QJ1fm for ; Sat, 23 Jan 2016 15:55:04 -0800 (PST) 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 542A71B2BEA for ; Sat, 23 Jan 2016 15:55:04 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id 65so61777868pff.2 for ; Sat, 23 Jan 2016 15:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=5AGaYFhAEaA3etjW3npaCCkSZsBtZBeXzu2IMlyM7+g=; b=hZ5tbyBour2RC2mLRVEzQ+VXMQVL16nIKwvCB/qr7aSJo16zqwHbTL5wU2EFtodqCH TDvkwmU6m7FKq6zmwAg0SDmv9ILsBDgeuZdyRRNF0qoEEnr9lXs+2OKOenaOqSPMFT1M J81R0iVB4eJ/ChIvpD/sWMp+ePyaWyqH5FvQWgrwlokTl+uT10dmy8t1N8Q0RwEnGLxZ n7b06bVKY6E5jcZ7R0F5cWsHUTuzoov02WTEyYKZIXu/j73RTdB4wAmu8qWVPozYnkQ5 5Lb1XuhYsH4oowIoMfUxhEiWdQibHZwojEkJrc6LtuIw3fshMk8puqSik3h84bVEhfU8 S4bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:thread-index:content-language; bh=5AGaYFhAEaA3etjW3npaCCkSZsBtZBeXzu2IMlyM7+g=; b=DyBYh1EAB5BaHxQEOA16yTJ0MsFiOVPpcPmq5yZgLOjz5TI2lw1KGaKbD8K2wEbJuN vzp4D4RALHTFe4ha04yEgX2QtOttQ9kjzLznq3i12yOL1P8zajpkj6Q4mBlvrfrob+9s OIiY6kjzw49BaazrISezdVAy3sX6BK8M5cjHifST8oij5XKihauIC3JOQvCY33Cuy+OR e1o1oQ617fFq5TGuMbvOx8Q4e9ajlWRP1n/wt2buDbK0O6o2Cy28Ws+l/NXMshtxKBMm 8KoyNxRe5aPsU4AJTgqF/oSyzp1BDPX9HqtCbEZFpr/M6vkJi9sQ3+KoqTQ20yrgAvnQ ndMA== X-Gm-Message-State: AG10YOShI9FtiBeYm+WlvfVE+wu0hxwtdSdTOpxmcIyw5BXncdTXTDSdPeqqp9BXAcAjog== X-Received: by 10.98.89.139 with SMTP id k11mr15458412pfj.82.1453593303979; Sat, 23 Jan 2016 15:55:03 -0800 (PST) Received: from SantoshBrain ([27.5.106.227]) by smtp.gmail.com with ESMTPSA id 73sm18652429pfp.50.2016.01.23.15.55.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jan 2016 15:55:03 -0800 (PST) From: "Santosh Chokhani" To: "'Erwann Abalea'" , "'Peter Bowen'" References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> In-Reply-To: Date: Sat, 23 Jan 2016 18:54:59 -0500 Message-ID: <052f01d15639$79fa33a0$6dee9ae0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0530_01D1560F.9125D950" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIVSzUXZpx0TCzS4mpo4m9SkbHUeQJEdeqNAqiykAAB5gd5AgKSQWGxAf+4FlUBv3gY9Z4YtUHQ Content-Language: en-us Archived-At: Cc: 'Directory list' , 'PKIX' Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 23:55:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0530_01D1560F.9125D950 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What do you mean by not working? =20 If one assumes that absence of EKU makes a certificate unconstrained, = does this not work? =20 May be you mean OCSP clients do not enforce EKU for the path. =20 From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Erwann Abalea Sent: Saturday, January 23, 2016 6:43 PM To: Peter Bowen Cc: Directory list ; PKIX Subject: Re: [pkix] Next edition of X.509 =20 It doesn't work with designated OCSP responder certificates, unless you = introduce an exception for this particular extended key usage. =20 2016-01-23 13:44 GMT+01:00 Peter Bowen >: In 8.2.2.4, replace the first sentence with: The presence of this extension in an end-entity certificate indicates one or more purposes for which the certified public key may be used, in addition to, or in place of the basic purposes indicated in the key usage extension field. The presence of this extension in a certificate issued by one CA to another CA constrains the key purposes in subsequent certificates in a certification path. If there is support for this addition, then additions will also be needed in section 10 to include key purposes in the input, output, and processing. Thanks, Peter On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen > wrote: > Hi Peter, > > I would like to explore whether there is support for such an addition = to X.509. Could I have your comments please? > > Regards, > > Erik > > -----Oprindelig meddelelse----- > Fra: Peter Bowen [mailto:pzbowen@gmail.com = ] > Sendt: 23 January 2016 02:50 > Til: Erik Andersen > > Cc: Stephen Farrell >; Directory list = >; PKIX = >; WG15@iectc57.org = =20 > Emne: Re: [pkix] Next edition of X.509 > > Erik, > > While I'm sure this is a contentious proposal, I would proposal that > X.509 add language allowing usage of Extended Key Usage for = constraints, joining certificate policies, name constraints, basic = constraints, etc. Many widely deployed certificate path validation = libraries already implement this even though it is unclear at best = whether such is compliant with X.509 (10/2012). > > Thanks, > Peter > > On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen > wrote: >> Hi Stephen, >> >> I will collect any comment on any list. The goal is to get the best = technical specification. >> >> Regards, >> >> Erik >> >> -----Oprindelig meddelelse----- >> Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie = ] >> Sendt: 07 December 2015 11:45 >> Til: Erik Andersen >; Directory = list >> >; = PKIX > >> Cc: WG15@iectc57.org =20 >> Emne: Re: [pkix] Next edition of X.509 >> >> >> Thank you Erik! Do I understand correctly that comments from this = list that you get before February are useful and that sending comments = to the pkix list works well enough for you? >> >> If so, great, and I'd ask folks who care about RFC5280 or other PKIX >> RFCs to please review this to check for any glitches that might = affect >> interop should new code be written based on the ISO doc. I'm sure >> other comments are also welcome, >> >> Cheers, >> S. >> >> On 07/12/15 10:33, Erik Andersen wrote: >>> In preparation for the next edition of X.509 (the 2016 edition), I >>> have forwarded to the ISO/IEC JTC1/SC6 two documents for three = months ballots: >>> >>> >>> >>> These two documents may be found as: >>> >>> >>> >>> 1. = http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf, >>> which is the 3rd PDAM text for an amendment to X.509. >>> >>> 2. http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, = which a >>> second draft technical corrigendum. This technical corrigendum is >>> based on a set of defects reports, which include the justification >>> for the changes. The Defect reports may be found on >>> http://www.x500standard.com/index.php?n=3DIg.DefectReports. >>> >>> >>> >>> An early corrigendum has been approved within ISO and ITU-T and may >>> be found >>> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. >>> >>> >>> >>> These three documents together with the seventh edition will provide >>> the input to the next edition of X.509. The different >>> X.recommendations, including X.509, may be found at >>> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely = available in the PDF version. >>> >>> >>> >>> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot >>> comments on the two documents out for ballot. Others, which may have >>> comments on the these document, may post them on the lists and after >>> consolidation and consensus, they may be issued as ITU-T comments. >>> >>> >>> >>> It is important to check whether any of the suggested changes = affects >>> running codes. If that is a case, it is a mistake. >>> >>> >>> >>> The intension behind the changes has been: >>> >>> 1. A better separation between public-key certificates and = attribute >>> certificates. >>> >>> 2. Use of a consistent terminology. >>> >>> 3. Use of a consistent editing style in accordance with the = ITU-T >>> editing guidelines.. >>> >>> 4. A new PKI component called trust broker assists a relying = party >>> validating a public-key certificate is included. >>> >>> 5. IEC TC57 WG15 has identified a requirement for a feature = first >>> called whitelist but now the term is authorization and validation >>> list is used. A proposal for such a feature is included in the = amendment. >>> >>> The main goal has been to position X.509 for new challenges, such >>> smart grid security and security for Internet of Things with battery >>> driven devices, very short messages (can we put a 257 octets >>> signature on a few octets message?) , short reaction time >>> requirements, many millions of entities, etc. This is all very = different from Web-based systems. >>> >>> Kind regards, >>> >>> Erik >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/pkix >>> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ pkix mailing list pkix@ietf.org =20 https://www.ietf.org/mailman/listinfo/pkix =20 --=20 Erwann. ------=_NextPart_000_0530_01D1560F.9125D950 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

What do you mean by not working?

 

If one assumes that absence of EKU makes a certificate unconstrained, = does this not work?

 

May be you mean OCSP clients do not enforce EKU for the = path.

 

From:<= /b> = pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Erwann = Abalea
Sent: Saturday, January 23, 2016 6:43 PM
To: = Peter Bowen <pzbowen@gmail.com>
Cc: Directory list = <x500standard@freelists.org>; PKIX = <pkix@ietf.org>
Subject: Re: [pkix] Next edition of = X.509

 

It = doesn't work with designated OCSP responder certificates, unless you = introduce an exception for this particular extended key = usage.

 

2016-01-23 13:44 GMT+01:00 Peter Bowen <pzbowen@gmail.com>:

In = 8.2.2.4, replace the first sentence with:

The presence of this = extension in an end-entity certificate indicates
one or more purposes = for which the certified public key may be used,
in addition to, or in = place of the basic purposes indicated in the key
usage extension = field. The presence of this extension in a certificate
issued by one = CA to another CA constrains the key purposes in
subsequent = certificates in a certification path.

If there is support for = this addition, then additions will also be
needed in section 10 to = include key purposes in the input, output, = and
processing.

Thanks,
Peter


On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen = <era@x500.eu> wrote:
> Hi = Peter,
>
> I would like to explore whether there is support = for such an addition to X.509. Could I have your comments = please?
>
> Regards,
>
> Erik
>
> = -----Oprindelig meddelelse-----
> Fra: Peter Bowen [mailto:pzbowen@gmail.com]
> Sendt: = 23 January 2016 02:50
> Til: Erik Andersen <era@x500.eu>
> Cc: Stephen = Farrell <stephen.farrell@cs.tcd.ie&g= t;; Directory list <x500standard@freelists.org= >; PKIX <pkix@ietf.org>; = WG15@iectc57.org
> Emne: = Re: [pkix] Next edition of X.509
>
> Erik,
>
> = While I'm sure this is a contentious proposal, I would proposal = that
> X.509 add language allowing usage of Extended Key Usage for = constraints, joining certificate policies, name constraints, basic = constraints, etc.  Many widely deployed certificate path validation = libraries already implement this even though it is unclear at best = whether such is compliant with X.509 (10/2012).
>
> = Thanks,
> Peter
>
> On Mon, Dec 7, 2015 at 3:38 AM, = Erik Andersen <era@x500.eu> = wrote:
>> Hi Stephen,
>>
>> I will collect = any comment on any list. The goal is to get the best technical = specification.
>>
>> Regards,
>>
>> = Erik
>>
>> -----Oprindelig meddelelse-----
>> = Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]<= br>>> Sendt: 07 December 2015 11:45
>> Til: Erik Andersen = <era@x500.eu>; Directory = list
>> <x500standard@freelists.org= >; PKIX <pkix@ietf.org>
>> Cc: WG15@iectc57.org
>> Emne: = Re: [pkix] Next edition of X.509
>>
>>
>> = Thank you Erik! Do I understand correctly that comments from this list = that you get before February are useful and that sending comments to the = pkix list works well enough for you?
>>
>> If so, = great, and I'd ask folks who care about RFC5280 or other = PKIX
>> RFCs to please review this to check for any glitches = that might affect
>> interop should new code be written based = on the ISO doc. I'm sure
>> other comments are also = welcome,
>>
>> Cheers,
>> = S.
>>
>> On 07/12/15 10:33, Erik Andersen = wrote:
>>> In preparation for the next edition of X.509 (the = 2016 edition), I
>>> have forwarded to the ISO/IEC JTC1/SC6 = two documents for three months = ballots:
>>>
>>>
>>>
>>> = These two documents may be found = as:
>>>
>>>
>>>
>>> = 1.       http://www.x500standard.com/uploads/extensions/x509-pda= m-amd2.pdf,
>>> which is the 3rd PDAM text for an = amendment to X.509.
>>>
>>> 2.    =    http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.p= df, which a
>>> second draft technical corrigendum. This = technical corrigendum is
>>> based on a set of defects = reports, which include the justification
>>> for the = changes. The Defect reports may be found on
>>> http://www.x500standard.com/index.php?n=3DIg.DefectRepo= rts.
>>>
>>>
>>>
>>> = An early corrigendum has been approved within ISO and ITU-T and = may
>>> be found
>>> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.p= df.
>>>
>>>
>>>
>>> = These three documents together with the seventh edition will = provide
>>> the input to the next edition of X.509. The = different
>>> X.recommendations, including X.509, may be = found at
>>> http://www.itu.int/rec/T-REC-X/e. This edition of = X.509 is freely available in the PDF = version.
>>>
>>>
>>>
>>> = Those involved in  ISO/IEC JTC1/SC6 can, of course, submit = ballot
>>> comments on the two documents out for ballot. = Others, which may have
>>> comments on the these document, = may post them on the lists and after
>>> consolidation and = consensus, they may be issued as ITU-T = comments.
>>>
>>>
>>>
>>>= It is important to check whether any of the suggested changes = affects
>>> running codes. If that is a case, it is a = mistake.
>>>
>>>
>>>
>>> = The intension behind the changes has = been:
>>>
>>> 1.       A = better separation between public-key certificates and = attribute
>>> certificates.
>>>
>>> = 2.       Use of a consistent = terminology.
>>>
>>> 3.      =  Use of a consistent editing style in accordance with the = ITU-T
>>> editing = guidelines..
>>>
>>> 4.      =  A new PKI component called trust broker assists a relying = party
>>> validating a public-key certificate is = included.
>>>
>>> 5.      =  IEC TC57 WG15 has identified a requirement for a feature = first
>>> called whitelist but now the term is authorization = and validation
>>> list is used. A proposal for such a = feature is included in the amendment.
>>>
>>> = The main goal has been to position X.509 for new challenges, = such
>>> smart grid security and security for Internet of = Things with battery
>>> driven devices, very short messages = (can we put a 257 octets
>>> signature on a few octets = message?) , short reaction time
>>> requirements, many = millions of entities, etc. This is all very different from = Web-based  systems.
>>>
>>> Kind = regards,
>>>
>>> = Erik
>>>
>>>
>>>
>>>
&= gt;>>
>>>
>>>
>>>
>>&g= t;
>>>
>>> = _______________________________________________
>>> pkix = mailing list
>>> pkix@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pkix
>&= gt;>
>>
>> = _______________________________________________
>> pkix mailing = list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
><= br>
_______________________________________________
pkix mailing = list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix



 

-- =

Erwann.

------=_NextPart_000_0530_01D1560F.9125D950-- From nobody Sat Jan 23 15:58:44 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E88A1B2C1A for ; Sat, 23 Jan 2016 15:58:43 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 GpXuvJ4X0rsq for ; Sat, 23 Jan 2016 15:58:39 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 EE3461B2C18 for ; Sat, 23 Jan 2016 15:58:38 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id e65so62054186pfe.0 for ; Sat, 23 Jan 2016 15:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ld4exxsvAmwAxaqeiDEFRGedtRW1TVeodhdV8YY0FpI=; b=q5KXy+2/7G/7je8Boe7vFXdLYVUyNQ/LZUUOdOysDqGY0JN1zrccWWUmxxzvlbWCEn 2GsXSUpHBa5JyT1kGkv0LhP9i1oF5e1qvjJulU+F2ivQjmvJ0stI7ExF/3eRBQqHmpy4 OyluWW0zzlagMIxw4xqm2yc4f+CHcmWowi1Pt5rrw/Sb+Kcldc7SrFnW/LIK1/Zd4x1k Q27fSclWnZqA6gNQ6hePatrM5D0bEjZXIsXisc90g6FWOay468cYBIJi5LfTS69fPp5s QlzoVmca64/CWaEYSgOQt6/cVUC/cmO5QoDNGTlWhtCr+Q6Iq9G+YHml9Nmb+S6o2R2b ciVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ld4exxsvAmwAxaqeiDEFRGedtRW1TVeodhdV8YY0FpI=; b=T8eN6fM71uSafhH/Q/20CdzRCvn9I9IwtrLQKAxE1DJ772VXdE8zlq2H+uC/XpcnU4 mHen+3iihHWUblC350IkcQ47F9MZg2ukdrAn4SXeGJIctKXFPNETTCi6BOQniBR9X9Gz GNeHu5i20mXfwBFmE6w9cxCoDk5H6s6DJVQaMG81lKsr8FYfMqxXnKtsBygVOE1XOQFJ WAdOEoByIXoncdQZbzHbsMHZw7FEY1aDrIFqnX/xV1OFPiSfcfrcx5xFegafZT87Jv/6 j64+qCnwpfoM6XLoBzyQWgPih+NwA2ISNsrjAC9JwAJNrrrDr9fkimxf3VjsZX33JtjI iIGw== X-Gm-Message-State: AG10YOSBoj4o9yBfdW97HXjf3vD2o+skv/JvK7AdKaPMk493py3UrJTf8phXCXDFn4Io4zG9Adip0Opt/zfCjw== MIME-Version: 1.0 X-Received: by 10.98.80.135 with SMTP id g7mr15149914pfj.132.1453593518646; Sat, 23 Jan 2016 15:58:38 -0800 (PST) Received: by 10.66.142.193 with HTTP; Sat, 23 Jan 2016 15:58:38 -0800 (PST) In-Reply-To: <052101d15636$aecdca40$0c695ec0$@gmail.com> References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> <56A3B913.3030506@comcast.net> <052101d15636$aecdca40$0c695ec0$@gmail.com> Date: Sat, 23 Jan 2016 15:58:38 -0800 Message-ID: From: Peter Bowen To: Santosh Chokhani Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 23:58:43 -0000 On Sat, Jan 23, 2016 at 3:34 PM, Santosh Chokhani wrote: > From security viewpoint I am sympathetic to what Peter says. If we roll > back the clock constraining the path for EKU is a superior approach and COTS > use it. > > But, rather putting this onus on X.509, should this not be done in RFC 5280 > prior to or in conjunction with X.509 revisions? RFC 5280 states that it profiles X.509. Until it is clear that using EKU in the way I described in covered by X.509, it is not possible to have a strict profile (e.g. PKIX) include it in the profile. The topic of using EKU for constraints has been raised previously on PKIX, and during that discussion it was said: "If there is such a strong belief that the extension should be interpreted in a manner similar to the way that certificatePolicies are processed, why hasn't a proposal been made to change X.509 to specify these semantics?" Since Erik was so kind as to make the offer to take comments on X.509 in preparation for a new revision, I figured I would take the opportunity to make the proposal as suggested. > -----Original Message----- > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Peter Bowen > Sent: Saturday, January 23, 2016 12:40 PM > To: Michael StJohns > Cc: > Subject: Re: [pkix] Next edition of X.509 > > On Sat, Jan 23, 2016 at 9:32 AM, Michael StJohns > wrote: >> On 1/23/2016 7:44 AM, Peter Bowen wrote: >>> >>> In 8.2.2.4, replace the first sentence with: >>> >>> The presence of this extension in an end-entity certificate indicates >>> one or more purposes for which the certified public key may be used, >>> in addition to, or in place of the basic purposes indicated in the >>> key usage extension field. The presence of this extension in a >>> certificate issued by one CA to another CA constrains the key >>> purposes in subsequent certificates in a certification path. >>> >>> If there is support for this addition, then additions will also be >>> needed in section 10 to include key purposes in the input, output, >>> and processing. >>> >>> Thanks, >>> Peter >> >> >> As a general concept, backwards compatibility is a good idea. As is > having >> end systems all get the same results when presented with the same data. > I >> don't think the above approach accomplishes this. > > I probably should have pointed out that I'm not trying to dream up something > new here. Microsoft, OpenSSL, and Mozilla all have implemented this and are > compatible with each other's certificate path processing libraries, at least > in this respect. As I understand it, this use of the EKU extension has been > widely deployed for more than a decade. However it is not clear that anyone > has ever proposed it to be included as part of the X.509 standard. > > The lack of standardization or recognition in X.509 and PKIX has led to many > disagreements over whether it is valid. My hope is that this revision of > X.509 might be able to at least clarify that it is not invalid to use EKU in > the manner that it is currently used by these systems. > >> Instead of overloading the current meaning of ExtendedKeyUsage, I >> would strongly recommend creating another extension, new OID with >> similar syntax, but the new semantics. This also gives you the >> opportunity to turn on the "critical" bit (maybe "bits" if you have >> some extended usages that you care about always and others that you > don't). >> >> Alternately (and possibly the best choice), place the OIDs in the >> CertificatePolicy extension as constraints on the key usage bits. You >> can use the same EKU oids, but their presence in the certificate >> policy then becomes a constraint on subordinate certificates and you >> can describe exactly how that works. (See my post script for a couple >> of ways of doing this). >> >> In your above comment I would avoid the language "in addition to, or in >> place of" and use one or the other. If you leave the language in, then > you >> need additional language which describes how to determine which rules >> in the situation where the ExtendedKeyUsage meanings are disjoint with >> the KeyUsage meanings. (E.g. "If there is an ExtendedKeyUsage purpose >> that would normally imply a required KeyUsage bit (for example a >> "SignSpecialValidationCACertificate" implies that the "keyCertSign" >> bit should be on), but that bit is not set, then the relying party >> shall consider the certificate signing of all but certificates with a >> profile consistent with the extended key usage OID invalid). >> >> If it takes a human (as opposed to a computer) to understand - >> consistently >> - what's meant by what's included in the certificate, then we're not >> doing it right. Figuring out whether the relying party needs to do an >> "OR" ("or in place of") or an "AND" ("in addition to") between >> KeyUsage bits and ExtendedKeyUsage OIDs meanings (or some combination >> thereof) is already painful. >> >> >> Mike >> >> >> ps - >> Possibility 1 (not exactly how Policies are supposed to work, but): Grab > a >> new oid and call it id-ce-extended-keyusage-policy. Stick the >> ExtendedKeyUsage values as "PolicyQualifierInfo.policyQualifierId"s. >> Have the PolicyQualifierInfo.qualifier be an ENUM of { allowed, >> required, prohibited }. Define a specific algorithm for determining > acceptance. >> >> Possibility 2: Each EKU OID becomes a new policy. Add a >> policyQualifierId of id-qt-acceptance-enum with a qualifier as above >> {allowed, required, prohibited}. Each EKU OID has one policy >> qualifier info of this type. This is probably cleaner as it requires >> each subordinate certificate to have a specific EKU expression for each > EKU policy in the parent. >> >> >> >> >> >> >>> >>> On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen wrote: >>>> >>>> Hi Peter, >>>> >>>> I would like to explore whether there is support for such an >>>> addition to X.509. Could I have your comments please? >>>> >>>> Regards, >>>> >>>> Erik >>>> >>>> -----Oprindelig meddelelse----- >>>> Fra: Peter Bowen [mailto:pzbowen@gmail.com] >>>> Sendt: 23 January 2016 02:50 >>>> Til: Erik Andersen >>>> Cc: Stephen Farrell ; Directory list >>>> ; PKIX ; WG15@iectc57.org >>>> Emne: Re: [pkix] Next edition of X.509 >>>> >>>> Erik, >>>> >>>> While I'm sure this is a contentious proposal, I would proposal that >>>> X.509 add language allowing usage of Extended Key Usage for >>>> constraints, joining certificate policies, name constraints, basic > constraints, etc. >>>> Many widely deployed certificate path validation libraries already >>>> implement this even though it is unclear at best whether such is >>>> compliant with X.509 (10/2012). >>>> >>>> Thanks, >>>> Peter >>>> >>>> On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen wrote: >>>>> >>>>> Hi Stephen, >>>>> >>>>> I will collect any comment on any list. The goal is to get the best >>>>> technical specification. >>>>> >>>>> Regards, >>>>> >>>>> Erik >>>>> >>>>> -----Oprindelig meddelelse----- >>>>> Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>>>> Sendt: 07 December 2015 11:45 >>>>> Til: Erik Andersen ; Directory list >>>>> ; PKIX >>>>> Cc: WG15@iectc57.org >>>>> Emne: Re: [pkix] Next edition of X.509 >>>>> >>>>> >>>>> Thank you Erik! Do I understand correctly that comments from this >>>>> list that you get before February are useful and that sending >>>>> comments to the pkix list works well enough for you? >>>>> >>>>> If so, great, and I'd ask folks who care about RFC5280 or other >>>>> PKIX RFCs to please review this to check for any glitches that >>>>> might affect interop should new code be written based on the ISO >>>>> doc. I'm sure other comments are also welcome, >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> On 07/12/15 10:33, Erik Andersen wrote: >>>>>> >>>>>> In preparation for the next edition of X.509 (the 2016 edition), I >>>>>> have forwarded to the ISO/IEC JTC1/SC6 two documents for three >>>>>> months >>>>>> ballots: >>>>>> >>>>>> >>>>>> >>>>>> These two documents may be found as: >>>>>> >>>>>> >>>>>> >>>>>> 1. >>>>>> http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf, >>>>>> which is the 3rd PDAM text for an amendment to X.509. >>>>>> >>>>>> 2. http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, >>>>>> which a >>>>>> second draft technical corrigendum. This technical corrigendum is >>>>>> based on a set of defects reports, which include the justification >>>>>> for the changes. The Defect reports may be found on >>>>>> http://www.x500standard.com/index.php?n=Ig.DefectReports. >>>>>> >>>>>> >>>>>> >>>>>> An early corrigendum has been approved within ISO and ITU-T and >>>>>> may be found >>>>>> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. >>>>>> >>>>>> >>>>>> >>>>>> These three documents together with the seventh edition will >>>>>> provide the input to the next edition of X.509. The different >>>>>> X.recommendations, including X.509, may be found at >>>>>> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely >>>>>> available in the PDF version. >>>>>> >>>>>> >>>>>> >>>>>> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot >>>>>> comments on the two documents out for ballot. Others, which may >>>>>> have comments on the these document, may post them on the lists >>>>>> and after consolidation and consensus, they may be issued as ITU-T > comments. >>>>>> >>>>>> >>>>>> >>>>>> It is important to check whether any of the suggested changes >>>>>> affects running codes. If that is a case, it is a mistake. >>>>>> >>>>>> >>>>>> >>>>>> The intension behind the changes has been: >>>>>> >>>>>> 1. A better separation between public-key certificates and >>>>>> attribute >>>>>> certificates. >>>>>> >>>>>> 2. Use of a consistent terminology. >>>>>> >>>>>> 3. Use of a consistent editing style in accordance with the > ITU-T >>>>>> editing guidelines.. >>>>>> >>>>>> 4. A new PKI component called trust broker assists a relying >>>>>> party >>>>>> validating a public-key certificate is included. >>>>>> >>>>>> 5. IEC TC57 WG15 has identified a requirement for a feature > first >>>>>> called whitelist but now the term is authorization and validation >>>>>> list is used. A proposal for such a feature is included in the >>>>>> amendment. >>>>>> >>>>>> The main goal has been to position X.509 for new challenges, such >>>>>> smart grid security and security for Internet of Things with >>>>>> battery driven devices, very short messages (can we put a 257 >>>>>> octets signature on a few octets message?) , short reaction time >>>>>> requirements, many millions of entities, etc. This is all very >>>>>> different from Web-based systems. >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Erik >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> pkix mailing list >>>>>> pkix@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>> >>>>> _______________________________________________ >>>>> pkix mailing list >>>>> pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From nobody Sat Jan 23 16:11:34 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6541ACD41 for ; Sat, 23 Jan 2016 16:11:33 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 XSkHpVVtg8Qj for ; Sat, 23 Jan 2016 16:11:30 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 1F0651ACD83 for ; Sat, 23 Jan 2016 16:11:30 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id o6so42587097qkc.2 for ; Sat, 23 Jan 2016 16:11:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/WspfIFbDZpByiPH3ACfi7z3dcRjTkVmIee+ozjXw0I=; b=Jy9s93koCfgKUQEbZjk6Zd8u4YHbn7F3bwIP4vulh3izfEzhDSm4keeLVLRDaMku12 OuaK6YnEJzwlzE1Ls/mTnOmnI0/gAZ3HNN5A6+IUvrbNDHe2gBbbZLF9JwePAKKjzncn 2DUPguBb7AhZV4JB+pTQ60sFT6U99+Z25sIL8jebl+FuvlmRZWTcW8gBGLTTaoNSKkmK 4qhceM1BO7kKcBxF4CyCgiBIzAlZw/36s56Sv+HbUxYeexr7K12UgS/1UoQmQtGarMsf mzdcJoNHru9k77MCuECDo1DwQVHVpje0tvTLt/UCVb9yPY3oRZTvvjCEnVELxPbYv8+G o5Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/WspfIFbDZpByiPH3ACfi7z3dcRjTkVmIee+ozjXw0I=; b=c1gTr+IfMUKhbYDZG0ELHYz0RXzS113+AbZ9WEtbg0m5Eog8OKLsEboXzqMZ4TWwBW a2T+Q+FG6TQSJHEBZ4gR2orilZ47h3RzXcSQVyJbjrRfgflrZWGC4oe8vsB0o7v0yD3U ey236CLPwLTkdVzAjIEB0Q2L7wqdisuTFYXvYyS0uHsIuwjNsny2Qm57AT5/ZdWlLtj9 90Z5AtcgJ9SQDHbXgU6vAvFhyEbSo6Bk2ikN6D80laCjaR3Pd9Fyf+VPpM073QKlZ2PL vnRJeYE+hOeSt5wtb2/HLxHHWkr31RsExt7rtfY2hSwoBbe1R6vj8yQmYreRGa3ifRGu XO/Q== X-Gm-Message-State: AG10YOSuE/ptvCxm8JpOMEJ3CN9qcFxvV5Pf0UdMhZw6HOdvVprkkpfMSxdHXkgEJMf6Yvn5+snnt4FlkfrdtQ== MIME-Version: 1.0 X-Received: by 10.55.25.169 with SMTP id 41mr3548119qkz.15.1453594289328; Sat, 23 Jan 2016 16:11:29 -0800 (PST) Received: by 10.140.38.99 with HTTP; Sat, 23 Jan 2016 16:11:29 -0800 (PST) In-Reply-To: <052f01d15639$79fa33a0$6dee9ae0$@gmail.com> References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> <052f01d15639$79fa33a0$6dee9ae0$@gmail.com> Date: Sun, 24 Jan 2016 01:11:29 +0100 Message-ID: From: Erwann Abalea To: Santosh Chokhani Content-Type: multipart/alternative; boundary=001a1147f95c43597e052a094b52 Archived-At: Cc: Directory list , PKIX Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 00:11:34 -0000 --001a1147f95c43597e052a094b52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you need an EKU used by an end-entity certificate to be present in the CA certificates (=3Dgranted), then you'll need the OCSPsigning EKU to be present in the issuing CA certificate. Which makes this issuing CA certificate a designated OCSP responder for its issuer. The problem will arise if you want to constrain a CA for specific key usages, i.e. when you'll want to make use of this redefinition. Le dimanche 24 janvier 2016, Santosh Chokhani a =C3=A9crit : > What do you mean by not working? > > > > If one assumes that absence of EKU makes a certificate unconstrained, doe= s > this not work? > > > > May be you mean OCSP clients do not enforce EKU for the path. > > > > *From:* pkix [mailto:pkix-bounces@ietf.org > ] *On Behalf Of *E= rwann > Abalea > *Sent:* Saturday, January 23, 2016 6:43 PM > *To:* Peter Bowen > > *Cc:* Directory list >; PKIX < > pkix@ietf.org > > *Subject:* Re: [pkix] Next edition of X.509 > > > > It doesn't work with designated OCSP responder certificates, unless you > introduce an exception for this particular extended key usage. > > > > 2016-01-23 13:44 GMT+01:00 Peter Bowen >: > > In 8.2.2.4, replace the first sentence with: > > The presence of this extension in an end-entity certificate indicates > one or more purposes for which the certified public key may be used, > in addition to, or in place of the basic purposes indicated in the key > usage extension field. The presence of this extension in a certificate > issued by one CA to another CA constrains the key purposes in > subsequent certificates in a certification path. > > If there is support for this addition, then additions will also be > needed in section 10 to include key purposes in the input, output, and > processing. > > Thanks, > Peter > > > On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen > wrote: > > Hi Peter, > > > > I would like to explore whether there is support for such an addition t= o > X.509. Could I have your comments please? > > > > Regards, > > > > Erik > > > > -----Oprindelig meddelelse----- > > Fra: Peter Bowen [mailto:pzbowen@gmail.com > ] > > Sendt: 23 January 2016 02:50 > > Til: Erik Andersen > > > Cc: Stephen Farrell >; Directory > list >; PKIX < > pkix@ietf.org >; > WG15@iectc57.org > > Emne: Re: [pkix] Next edition of X.509 > > > > Erik, > > > > While I'm sure this is a contentious proposal, I would proposal that > > X.509 add language allowing usage of Extended Key Usage for constraints= , > joining certificate policies, name constraints, basic constraints, etc. > Many widely deployed certificate path validation libraries already > implement this even though it is unclear at best whether such is complian= t > with X.509 (10/2012). > > > > Thanks, > > Peter > > > > On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen > wrote: > >> Hi Stephen, > >> > >> I will collect any comment on any list. The goal is to get the best > technical specification. > >> > >> Regards, > >> > >> Erik > >> > >> -----Oprindelig meddelelse----- > >> Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie > ] > >> Sendt: 07 December 2015 11:45 > >> Til: Erik Andersen >; Directory list > >> >; PKIX < > pkix@ietf.org > > >> Cc: WG15@iectc57.org > >> Emne: Re: [pkix] Next edition of X.509 > >> > >> > >> Thank you Erik! Do I understand correctly that comments from this list > that you get before February are useful and that sending comments to the > pkix list works well enough for you? > >> > >> If so, great, and I'd ask folks who care about RFC5280 or other PKIX > >> RFCs to please review this to check for any glitches that might affect > >> interop should new code be written based on the ISO doc. I'm sure > >> other comments are also welcome, > >> > >> Cheers, > >> S. > >> > >> On 07/12/15 10:33, Erik Andersen wrote: > >>> In preparation for the next edition of X.509 (the 2016 edition), I > >>> have forwarded to the ISO/IEC JTC1/SC6 two documents for three months > ballots: > >>> > >>> > >>> > >>> These two documents may be found as: > >>> > >>> > >>> > >>> 1. > http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf, > >>> which is the 3rd PDAM text for an amendment to X.509. > >>> > >>> 2. http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, > which a > >>> second draft technical corrigendum. This technical corrigendum is > >>> based on a set of defects reports, which include the justification > >>> for the changes. The Defect reports may be found on > >>> http://www.x500standard.com/index.php?n=3DIg.DefectReports. > >>> > >>> > >>> > >>> An early corrigendum has been approved within ISO and ITU-T and may > >>> be found > >>> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. > >>> > >>> > >>> > >>> These three documents together with the seventh edition will provide > >>> the input to the next edition of X.509. The different > >>> X.recommendations, including X.509, may be found at > >>> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely > available in the PDF version. > >>> > >>> > >>> > >>> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot > >>> comments on the two documents out for ballot. Others, which may have > >>> comments on the these document, may post them on the lists and after > >>> consolidation and consensus, they may be issued as ITU-T comments. > >>> > >>> > >>> > >>> It is important to check whether any of the suggested changes affects > >>> running codes. If that is a case, it is a mistake. > >>> > >>> > >>> > >>> The intension behind the changes has been: > >>> > >>> 1. A better separation between public-key certificates and > attribute > >>> certificates. > >>> > >>> 2. Use of a consistent terminology. > >>> > >>> 3. Use of a consistent editing style in accordance with the ITU= -T > >>> editing guidelines.. > >>> > >>> 4. A new PKI component called trust broker assists a relying > party > >>> validating a public-key certificate is included. > >>> > >>> 5. IEC TC57 WG15 has identified a requirement for a feature fir= st > >>> called whitelist but now the term is authorization and validation > >>> list is used. A proposal for such a feature is included in the > amendment. > >>> > >>> The main goal has been to position X.509 for new challenges, such > >>> smart grid security and security for Internet of Things with battery > >>> driven devices, very short messages (can we put a 257 octets > >>> signature on a few octets message?) , short reaction time > >>> requirements, many millions of entities, etc. This is all very > different from Web-based systems. > >>> > >>> Kind regards, > >>> > >>> Erik > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> pkix mailing list > >>> pkix@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pkix > >>> > >> > >> _______________________________________________ > >> pkix mailing list > >> pkix@ietf.org > >> https://www.ietf.org/mailman/listinfo/pkix > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > > > > > -- > > Erwann. > --=20 Erwann. --001a1147f95c43597e052a094b52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you need an EKU used by an end-entity certificate to be present in the C= A certificates (=3Dgranted), then you'll need the OCSPsigning EKU to be= present in the issuing CA certificate. Which makes this issuing CA certifi= cate=C2=A0a designated OCSP responder for its issuer.

Th= e problem will arise if you want to constrain a CA for specific key usages,= i.e. when you'll want to make use of this redefinition.
<= br>Le=C2=A0dimanche 24 janvier 2016, Santosh Chokhani <santosh.chokhani@gmail.com> a =C3=A9cri= t=C2=A0:

What do you m= ean by not working?

=C2=A0

If one assumes that absence of EKU makes a certificate unconstrained, does= this not work?

=C2=A0

Ma= y be you mean OCSP clients do not enforce EKU for the path.

=C2=A0<= /p>

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Erwann AbaleaSent: Saturday, January 23, 2016 6:43 PM
To: Peter Bowen = <pzbowen@gmail.com>
Cc: Directory = list <x500standard@freelists.org>; = PKIX <pkix@ietf.org>
Subject: Re: [pki= x] Next edition of X.509

= =C2=A0

It doesn't work with d= esignated OCSP responder certificates, unless you introduce an exception fo= r this particular extended key usage.

=C2=A0

2016-01-23 13:4= 4 GMT+01:00 Peter Bowen <pzbowen@gmail.com>:=

In 8.2.2.4, replace the first sentence with:

The p= resence of this extension in an end-entity certificate indicates
one or = more purposes for which the certified public key may be used,
in additio= n to, or in place of the basic purposes indicated in the key
usage exten= sion field. The presence of this extension in a certificate
issued by on= e CA to another CA constrains the key purposes in
subsequent certificate= s in a certification path.

If there is support for this addition, th= en additions will also be
needed in section 10 to include key purposes i= n the input, output, and
processing.

Thanks,
Peter


On Sat, Jan 23, 2016 at 2:19 AM,= Erik Andersen <era@x500.eu> wrote:
> Hi Pet= er,
>
> I would like to explore whether there is support for su= ch an addition to X.509. Could I have your comments please?
>
>= Regards,
>
> Erik
>
> -----Oprindelig meddelelse--= ---
> Fra: Peter Bowen [mailto:pzbowen@gmail.com= ]
> Sendt: 23 January 2016 02:50
> Til: Erik Andersen <<= a href=3D"javascript:_e(%7B%7D,'cvml','era@x500.eu');" targ= et=3D"_blank">era@x500.eu>
> Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>; Directory list <= ;x500standard@freelists.org>; PKIX <= ;pkix@ietf.org>; WG15@iectc57.o= rg
> Emne: Re: [pkix] Next edition of X.509
>
> Erik,=
>
> While I'm sure this is a contentious proposal, I would= proposal that
> X.509 add language allowing usage of Extended Key Us= age for constraints, joining certificate policies, name constraints, basic = constraints, etc.=C2=A0 Many widely deployed certificate path validation li= braries already implement this even though it is unclear at best whether su= ch is compliant with X.509 (10/2012).
>
> Thanks,
> Peter=
>
> On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen <era@x500.eu> wrote:
>> Hi Stephen,
>>
&= gt;> I will collect any comment on any list. The goal is to get the best= technical specification.
>>
>> Regards,
>>
&= gt;> Erik
>>
>> -----Oprindelig meddelelse-----
>= ;> Fra: Stephen Farrell [mailto:stephen.far= rell@cs.tcd.ie]
>> Sendt: 07 December 2015 11:45
>> T= il: Erik Andersen <era@x500.eu>; Directory list>> <x500standard@freelists.org&= gt;; PKIX <pkix@ietf.org>
>> Cc: WG15@iectc57.org
>> Emne: Re: [pkix] Next editio= n of X.509
>>
>>
>> Thank you Erik! Do I underst= and correctly that comments from this list that you get before February are= useful and that sending comments to the pkix list works well enough for yo= u?
>>
>> If so, great, and I'd ask folks who care abo= ut RFC5280 or other PKIX
>> RFCs to please review this to check fo= r any glitches that might affect
>> interop should new code be wri= tten based on the ISO doc. I'm sure
>> other comments are also= welcome,
>>
>> Cheers,
>> S.
>>
>= ;> On 07/12/15 10:33, Erik Andersen wrote:
>>> In preparatio= n for the next edition of X.509 (the 2016 edition), I
>>> have = forwarded to the ISO/IEC JTC1/SC6 two documents for three months ballots:>>>
>>>
>>>
>>> These two do= cuments may be found as:
>>>
>>>
>>>>>> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.= x500standard.com/uploads/extensions/x509-pdam-amd2.pdf,
>>>= which is the 3rd PDAM text for an amendment to X.509.
>>>
&= gt;>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.x500standa= rd.com/uploads/dtc/X509-Ed7-Cor2.pdf, which a
>>> second dr= aft technical corrigendum. This technical corrigendum is
>>> ba= sed on a set of defects reports, which include the justification
>>= ;> for the changes. The Defect reports may be found on
>>> <= a href=3D"http://www.x500standard.com/index.php?n=3DIg.DefectReports" targe= t=3D"_blank">http://www.x500standard.com/index.php?n=3DIg.DefectReports= .
>>>
>>>
>>>
>>> An early = corrigendum has been approved within ISO and ITU-T and may
>>> = be found
>>> as: http://www.x500standard.com/uploa= ds/dtc/X509-Ed7-Cor1.pdf.
>>>
>>>
>>&g= t;
>>> These three documents together with the seventh edition = will provide
>>> the input to the next edition of X.509. The di= fferent
>>> X.recommendations, including X.509, may be found at=
>>> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely = available in the PDF version.
>>>
>>>
>>&g= t;
>>> Those involved in=C2=A0 ISO/IEC JTC1/SC6 can, of course,= submit ballot
>>> comments on the two documents out for ballot= . Others, which may have
>>> comments on the these document, ma= y post them on the lists and after
>>> consolidation and consen= sus, they may be issued as ITU-T comments.
>>>
>>><= br>>>>
>>> It is important to check whether any of the= suggested changes affects
>>> running codes. If that is a case= , it is a mistake.
>>>
>>>
>>>
>&= gt;> The intension behind the changes has been:
>>>
>&= gt;> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0A better separation between public-key= certificates and attribute
>>> certificates.
>>>>>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0Use of a consistent terminology= .
>>>
>>> 3.=C2=A0 =C2=A0 =C2=A0 =C2=A0Use of a con= sistent editing style in accordance with the ITU-T
>>> editing = guidelines..
>>>
>>> 4.=C2=A0 =C2=A0 =C2=A0 =C2=A0A= new PKI component called trust broker assists a relying party
>>&= gt; validating a public-key certificate is included.
>>>
>= ;>> 5.=C2=A0 =C2=A0 =C2=A0 =C2=A0IEC TC57 WG15 has identified a requi= rement for a feature first
>>> called whitelist but now the ter= m is authorization and validation
>>> list is used. A proposal = for such a feature is included in the amendment.
>>>
>>= ;> The main goal has been to position X.509 for new challenges, such
= >>> smart grid security and security for Internet of Things with b= attery
>>> driven devices, very short messages (can we put a 25= 7 octets
>>> signature on a few octets message?) , short reacti= on time
>>> requirements, many millions of entities, etc. This = is all very different from Web-based=C2=A0 systems.
>>>
>= >> Kind regards,
>>>
>>> Erik
>>>=
>>>
>>>
>>>
>>>
>>= ;>
>>>
>>>
>>>
>>>
&g= t;>> _______________________________________________
>>> = pkix mailing list
>>> pkix@ietf.org
>= ;>> https://www.ietf.org/mailman/listinfo/pkix
>>>
&= gt;>
>> _______________________________________________
>= > pkix mailing list
>> pkix@ietf.org
&g= t;> https://www.ietf.org/mailman/listinfo/pkix
>

________= _______________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix<= /u>


=C2=A0<= u>

--

Erwann.



--
Erwann.
--001a1147f95c43597e052a094b52-- From nobody Sat Jan 23 16:24:10 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EFA1B2C5A for ; Sat, 23 Jan 2016 16:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 raJ6N_a51hRn for ; Sat, 23 Jan 2016 16:24:05 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B6B1B2C59 for ; Sat, 23 Jan 2016 16:24:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7CAFDBE50; Sun, 24 Jan 2016 00:24:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdV6_WY9jExZ; Sun, 24 Jan 2016 00:24:02 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.16.108]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CC8C3BE2C; Sun, 24 Jan 2016 00:24:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1453595042; bh=JzP9EwUNpoA8+VC/RaOQ78Y+09IOiL9R9+ieukVIVRg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ZIv6VfMdUzhpBovwxu13sQmfBw4ZGJWIdcve3dZqpzB0J+/jLZtwKKDoplpx4sill rtpfcQdrq6sDNLktTTcNvoOSd+Q0vmD9zXnZdruthQyk0h/+jl95XxtzpugTMartbM wzgVXSpAyaXme2n8D6fXKgnsp51t+OvgDDhKQbiU= To: Peter Bowen , Santosh Chokhani References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> <56A3B913.3030506@comcast.net> <052101d15636$aecdca40$0c695ec0$@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56A419A1.2040503@cs.tcd.ie> Date: Sun, 24 Jan 2016 00:24:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 00:24:06 -0000 Hiya, On 23/01/16 23:58, Peter Bowen wrote: > Until it is clear that using > EKU in the way I described in covered by X.509, it is not possible to > have a strict profile (e.g. PKIX) include it in the profile. I don't know what you mean by that, can you elaborate? My guess is that almost nobody does new implementations of X.509 code nowadays, and those that might would go to 5280 and not the latest version of X.509, but I'd be very interested if either of those assumptions is wrong. If I'm not wrong, then updates to the base X.509 spec are no longer really important, other than for the sake of tidiness. Another corollary would be that the opinions of people who have no influence over running code but who think one document or the other is more important, can safely be ignored. Again, good to know it that's incorrect. Thanks, S. From nobody Sat Jan 23 16:35:35 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7002F1B2CB4 for ; Sat, 23 Jan 2016 16:35:33 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 YCjmqk0wPrH4 for ; Sat, 23 Jan 2016 16:35:30 -0800 (PST) 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 6A1611B2CB2 for ; Sat, 23 Jan 2016 16:35:30 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id e65so62331513pfe.0 for ; Sat, 23 Jan 2016 16:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=cgtr2PRsp1OfF+lt5DB8iOPjNidUGb7GH855so9FIu0=; b=epNxs9XQBNwLAW8m099BXW47XqS2DQwm70nCuNXftn4XZ5IP/ru/Kll6+e/cSJlGtB cx1JcnSA3fDYi8Iw3JfmDhChcZD1GH9jkHPzqki+jBP8DzibKZ31mFaLjM80EvSg/JwH Y1QjynxPZCCjT0TuYl6figcXRFAW0vqQ8CKTbs3NJUZSR/iyodVhmmKFvI/wprh/L1/6 C8AR366YvUqYujeAe8xo+YJ1FhnCaa5m5OFqbhZkXLsf5s4Rp993+DADjla5uQulOnof eSTREh8TETzacgZbUfVdSfC2ZHSTyrRrP08donJSjemjs05kPGikJv1d14c8+EWRD+lY aiDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=cgtr2PRsp1OfF+lt5DB8iOPjNidUGb7GH855so9FIu0=; b=jG/4truJwChhFF7ox93aM90a/lDb7iQ0N6BIDHdYk7lgPd/3Lla2RB8oPMah6GK8Ia h7TODCRydCIHJLqkq7Na2OyRYFRTVZrEgw0vr3quGECZjjd3Q5wEt4t2eIg40ugw9etb yb0EsAOVBJNidQw3vmVu+hqJ8xiPla6Q5Kx4OTX9uYLyO1I9JB6enUJxfYjiEHk/owYt gMWWT8MAAYQi5INl0m14uc5kb+vj+/aWxSBLIVKvwWE0dQHGoXnqY25j/poW84dHP+OU S4CVjcYNMncaXuCXE3hBwunIbaAGwQJmwSrkr5ERY9sgJW/c/Up7JXA1k4zfNVAeiFri 6Oww== X-Gm-Message-State: AG10YOTEJY4oiL8257A7GKNic2n/E0Z1R2PIPLRAj/HJHVafaTOtFH6Xz9GgQWthXaibnA== X-Received: by 10.98.72.156 with SMTP id q28mr15231066pfi.161.1453595730083; Sat, 23 Jan 2016 16:35:30 -0800 (PST) Received: from SantoshBrain ([27.5.106.227]) by smtp.gmail.com with ESMTPSA id 70sm18698878pfc.69.2016.01.23.16.35.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jan 2016 16:35:28 -0800 (PST) From: "Santosh Chokhani" To: "'Peter Bowen'" References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> <56A3B913.3030506@comcast.net> <052101d15636$aecdca40$0c695ec0$@gmail.com> In-Reply-To: Date: Sat, 23 Jan 2016 19:35:25 -0500 Message-ID: <054f01d1563f$1fcf6930$5f6e3b90$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIVSzUXZpx0TCzS4mpo4m9SkbHUeQJEdeqNAqiykAAB5gd5AgKSQWGxAf+4FlUCfrtvPwFTuCGCAe/27fQBRpxP1J3udDDg Content-Language: en-us Archived-At: Cc: pkix@ietf.org Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 00:35:33 -0000 It should not be like certificate policies; it should be like name = constraints. That is, absence of extension means the certificate is = unrestricted. I believe that is how COTS (at least MSFT to my = knowledge) process it. -----Original Message----- From: Peter Bowen [mailto:pzbowen@gmail.com]=20 Sent: Saturday, January 23, 2016 6:59 PM To: Santosh Chokhani Cc: Michael StJohns ; = Subject: Re: [pkix] Next edition of X.509 On Sat, Jan 23, 2016 at 3:34 PM, Santosh Chokhani = wrote: > From security viewpoint I am sympathetic to what Peter says. If we=20 > roll back the clock constraining the path for EKU is a superior=20 > approach and COTS use it. > > But, rather putting this onus on X.509, should this not be done in RFC = > 5280 prior to or in conjunction with X.509 revisions? RFC 5280 states that it profiles X.509. Until it is clear that using = EKU in the way I described in covered by X.509, it is not possible to = have a strict profile (e.g. PKIX) include it in the profile. The topic of using EKU for constraints has been raised previously on = PKIX, and during that discussion it was said: "If there is such a strong belief that the extension should be = interpreted in a manner similar to the way that certificatePolicies are = processed, why hasn't a proposal been made to change X.509 to specify = these semantics?" Since Erik was so kind as to make the offer to take comments on X.509 in = preparation for a new revision, I figured I would take the opportunity = to make the proposal as suggested. > -----Original Message----- > From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Peter Bowen > Sent: Saturday, January 23, 2016 12:40 PM > To: Michael StJohns > Cc: > Subject: Re: [pkix] Next edition of X.509 > > On Sat, Jan 23, 2016 at 9:32 AM, Michael StJohns=20 > > wrote: >> On 1/23/2016 7:44 AM, Peter Bowen wrote: >>> >>> In 8.2.2.4, replace the first sentence with: >>> >>> The presence of this extension in an end-entity certificate=20 >>> indicates one or more purposes for which the certified public key=20 >>> may be used, in addition to, or in place of the basic purposes=20 >>> indicated in the key usage extension field. The presence of this=20 >>> extension in a certificate issued by one CA to another CA constrains = >>> the key purposes in subsequent certificates in a certification path. >>> >>> If there is support for this addition, then additions will also be=20 >>> needed in section 10 to include key purposes in the input, output,=20 >>> and processing. >>> >>> Thanks, >>> Peter >> >> >> As a general concept, backwards compatibility is a good idea. As is > having >> end systems all get the same results when presented with the same = data. > I >> don't think the above approach accomplishes this. > > I probably should have pointed out that I'm not trying to dream up=20 > something new here. Microsoft, OpenSSL, and Mozilla all have=20 > implemented this and are compatible with each other's certificate path = > processing libraries, at least in this respect. As I understand it,=20 > this use of the EKU extension has been widely deployed for more than a = > decade. However it is not clear that anyone has ever proposed it to = be included as part of the X.509 standard. > > The lack of standardization or recognition in X.509 and PKIX has led=20 > to many disagreements over whether it is valid. My hope is that this=20 > revision of > X.509 might be able to at least clarify that it is not invalid to use=20 > EKU in the manner that it is currently used by these systems. > >> Instead of overloading the current meaning of ExtendedKeyUsage, I=20 >> would strongly recommend creating another extension, new OID with=20 >> similar syntax, but the new semantics. This also gives you the=20 >> opportunity to turn on the "critical" bit (maybe "bits" if you have=20 >> some extended usages that you care about always and others that you > don't). >> >> Alternately (and possibly the best choice), place the OIDs in the=20 >> CertificatePolicy extension as constraints on the key usage bits. You = >> can use the same EKU oids, but their presence in the certificate=20 >> policy then becomes a constraint on subordinate certificates and you=20 >> can describe exactly how that works. (See my post script for a couple = >> of ways of doing this). >> >> In your above comment I would avoid the language "in addition to, or = in >> place of" and use one or the other. If you leave the language in, = then > you >> need additional language which describes how to determine which rules = >> in the situation where the ExtendedKeyUsage meanings are disjoint=20 >> with the KeyUsage meanings. (E.g. "If there is an ExtendedKeyUsage=20 >> purpose that would normally imply a required KeyUsage bit (for=20 >> example a "SignSpecialValidationCACertificate" implies that the = "keyCertSign" >> bit should be on), but that bit is not set, then the relying party=20 >> shall consider the certificate signing of all but certificates with a = >> profile consistent with the extended key usage OID invalid). >> >> If it takes a human (as opposed to a computer) to understand -=20 >> consistently >> - what's meant by what's included in the certificate, then we're not=20 >> doing it right. Figuring out whether the relying party needs to do=20 >> an "OR" ("or in place of") or an "AND" ("in addition to") between=20 >> KeyUsage bits and ExtendedKeyUsage OIDs meanings (or some combination >> thereof) is already painful. >> >> >> Mike >> >> >> ps - >> Possibility 1 (not exactly how Policies are supposed to work, but):=20 >> Grab > a >> new oid and call it id-ce-extended-keyusage-policy. Stick the >> ExtendedKeyUsage values as "PolicyQualifierInfo.policyQualifierId"s. >> Have the PolicyQualifierInfo.qualifier be an ENUM of { allowed,=20 >> required, prohibited }. Define a specific algorithm for determining > acceptance. >> >> Possibility 2: Each EKU OID becomes a new policy. Add a=20 >> policyQualifierId of id-qt-acceptance-enum with a qualifier as above=20 >> {allowed, required, prohibited}. Each EKU OID has one policy=20 >> qualifier info of this type. This is probably cleaner as it requires = >> each subordinate certificate to have a specific EKU expression for=20 >> each > EKU policy in the parent. >> >> >> >> >> >> >>> >>> On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen wrote: >>>> >>>> Hi Peter, >>>> >>>> I would like to explore whether there is support for such an=20 >>>> addition to X.509. Could I have your comments please? >>>> >>>> Regards, >>>> >>>> Erik >>>> >>>> -----Oprindelig meddelelse----- >>>> Fra: Peter Bowen [mailto:pzbowen@gmail.com] >>>> Sendt: 23 January 2016 02:50 >>>> Til: Erik Andersen >>>> Cc: Stephen Farrell ; Directory list=20 >>>> ; PKIX ;=20 >>>> WG15@iectc57.org >>>> Emne: Re: [pkix] Next edition of X.509 >>>> >>>> Erik, >>>> >>>> While I'm sure this is a contentious proposal, I would proposal=20 >>>> that >>>> X.509 add language allowing usage of Extended Key Usage for=20 >>>> constraints, joining certificate policies, name constraints, basic > constraints, etc. >>>> Many widely deployed certificate path validation libraries already=20 >>>> implement this even though it is unclear at best whether such is=20 >>>> compliant with X.509 (10/2012). >>>> >>>> Thanks, >>>> Peter >>>> >>>> On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen wrote: >>>>> >>>>> Hi Stephen, >>>>> >>>>> I will collect any comment on any list. The goal is to get the=20 >>>>> best technical specification. >>>>> >>>>> Regards, >>>>> >>>>> Erik >>>>> >>>>> -----Oprindelig meddelelse----- >>>>> Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>>>> Sendt: 07 December 2015 11:45 >>>>> Til: Erik Andersen ; Directory list=20 >>>>> ; PKIX >>>>> Cc: WG15@iectc57.org >>>>> Emne: Re: [pkix] Next edition of X.509 >>>>> >>>>> >>>>> Thank you Erik! Do I understand correctly that comments from this=20 >>>>> list that you get before February are useful and that sending=20 >>>>> comments to the pkix list works well enough for you? >>>>> >>>>> If so, great, and I'd ask folks who care about RFC5280 or other=20 >>>>> PKIX RFCs to please review this to check for any glitches that=20 >>>>> might affect interop should new code be written based on the ISO=20 >>>>> doc. I'm sure other comments are also welcome, >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> On 07/12/15 10:33, Erik Andersen wrote: >>>>>> >>>>>> In preparation for the next edition of X.509 (the 2016 edition),=20 >>>>>> I have forwarded to the ISO/IEC JTC1/SC6 two documents for three=20 >>>>>> months >>>>>> ballots: >>>>>> >>>>>> >>>>>> >>>>>> These two documents may be found as: >>>>>> >>>>>> >>>>>> >>>>>> 1. >>>>>> http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf >>>>>> , which is the 3rd PDAM text for an amendment to X.509. >>>>>> >>>>>> 2. = http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, >>>>>> which a >>>>>> second draft technical corrigendum. This technical corrigendum is = >>>>>> based on a set of defects reports, which include the=20 >>>>>> justification for the changes. The Defect reports may be found on = >>>>>> http://www.x500standard.com/index.php?n=3DIg.DefectReports. >>>>>> >>>>>> >>>>>> >>>>>> An early corrigendum has been approved within ISO and ITU-T and=20 >>>>>> may be found >>>>>> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. >>>>>> >>>>>> >>>>>> >>>>>> These three documents together with the seventh edition will=20 >>>>>> provide the input to the next edition of X.509. The different=20 >>>>>> X.recommendations, including X.509, may be found at=20 >>>>>> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely = >>>>>> available in the PDF version. >>>>>> >>>>>> >>>>>> >>>>>> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot = >>>>>> comments on the two documents out for ballot. Others, which may=20 >>>>>> have comments on the these document, may post them on the lists=20 >>>>>> and after consolidation and consensus, they may be issued as=20 >>>>>> ITU-T > comments. >>>>>> >>>>>> >>>>>> >>>>>> It is important to check whether any of the suggested changes=20 >>>>>> affects running codes. If that is a case, it is a mistake. >>>>>> >>>>>> >>>>>> >>>>>> The intension behind the changes has been: >>>>>> >>>>>> 1. A better separation between public-key certificates and >>>>>> attribute >>>>>> certificates. >>>>>> >>>>>> 2. Use of a consistent terminology. >>>>>> >>>>>> 3. Use of a consistent editing style in accordance with the > ITU-T >>>>>> editing guidelines.. >>>>>> >>>>>> 4. A new PKI component called trust broker assists a = relying >>>>>> party >>>>>> validating a public-key certificate is included. >>>>>> >>>>>> 5. IEC TC57 WG15 has identified a requirement for a feature > first >>>>>> called whitelist but now the term is authorization and validation = >>>>>> list is used. A proposal for such a feature is included in the=20 >>>>>> amendment. >>>>>> >>>>>> The main goal has been to position X.509 for new challenges, such = >>>>>> smart grid security and security for Internet of Things with=20 >>>>>> battery driven devices, very short messages (can we put a 257=20 >>>>>> octets signature on a few octets message?) , short reaction time=20 >>>>>> requirements, many millions of entities, etc. This is all very=20 >>>>>> different from Web-based systems. >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Erik >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> pkix mailing list >>>>>> pkix@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>>> >>>>> _______________________________________________ >>>>> pkix mailing list >>>>> pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From nobody Sat Jan 23 16:43:22 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572F71B2CD2 for ; Sat, 23 Jan 2016 16:43:21 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 h7QhL9SXCADT for ; Sat, 23 Jan 2016 16:43:20 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 157831B2CD1 for ; Sat, 23 Jan 2016 16:43:20 -0800 (PST) Received: by mail-pa0-x232.google.com with SMTP id yy13so61017495pab.3 for ; Sat, 23 Jan 2016 16:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FVypNRkJtKvUbf7qaYstjQHrvlfQidld8HiH2EewNYQ=; b=ZYeVv+AhOrkw4QFeI9MV3OkijyVKVURjSMUc9ppnkgnZUrRykY+TTwgjBsEtUuHO7M V41agvTf0BkNwkpQRqQ4nTQ80E+jcbV1v6UCyLXbWDiK1+gHVTpEW5c08hcxINkQ5hjd ELmEKmLvKvVWAgkjOqKYW3JkkJJfL9y0RrBic3yacXXNS+OzAfBnoY/2LodPnaTlFHxf p6NIZ7AKbwBowPA3U0yqbAB4WIP2HEW4YVNIHFsEe2JEFfAHpvSJVbSDcAqqLPQ71CqU aCSuV8FfigmNozFZISu/DE2uOImtPHFbfyGr6fQkVn2WN/iVUM/bapFmzSsC8YY1Fy4J vJvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FVypNRkJtKvUbf7qaYstjQHrvlfQidld8HiH2EewNYQ=; b=E/kaWF59CWLSaeEgtpNwcCV4Styf6W7S3g4aIq4qbTzUCgL4sHpQcZd0PcIY3o2Svs aYJSfRUaO/Q+0kt642oNY7SEytME3jYugbnLnd4GAiF9O1X7hJJC+8+Nnle+N6tvzePf jMr9ecE/eyEmx7KzXy7tiURtgyziLMS9tc61ozupeq448z+1aT8OBYqSdc/QvfI74Mw6 maJ8PldqEejGTNL5G6xAOYPdRHdrwkzOeYG/CJ2/i7UqhTgsBLOwzkMcK8wv8UVzurfC XY8qLLugOBg2b+V6HZB9oE5ghdfSjIiLIQQ/cvPumLR5O6Yk3I4j072R0XUs1MD7S6cr S4vg== X-Gm-Message-State: AG10YOSHQCcD6vzk/G9T3lhYQEsKrTqIoEaru6VhviwFW3RzM2ArRiROCfdeJ4hPAYj/FmlueK+jDi652ECQKg== MIME-Version: 1.0 X-Received: by 10.67.14.136 with SMTP id fg8mr14490711pad.105.1453596199730; Sat, 23 Jan 2016 16:43:19 -0800 (PST) Received: by 10.66.142.193 with HTTP; Sat, 23 Jan 2016 16:43:19 -0800 (PST) In-Reply-To: <56A419A1.2040503@cs.tcd.ie> References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> <56A3B913.3030506@comcast.net> <052101d15636$aecdca40$0c695ec0$@gmail.com> <56A419A1.2040503@cs.tcd.ie> Date: Sat, 23 Jan 2016 16:43:19 -0800 Message-ID: From: Peter Bowen To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 00:43:21 -0000 On Sat, Jan 23, 2016 at 4:24 PM, Stephen Farrell wrote: > On 23/01/16 23:58, Peter Bowen wrote: >> Until it is clear that using >> EKU in the way I described in covered by X.509, it is not possible to >> have a strict profile (e.g. PKIX) include it in the profile. > > I don't know what you mean by that, can you elaborate? > > My guess is that almost nobody does new implementations of X.509 > code nowadays, and those that might would go to 5280 and not the > latest version of X.509, but I'd be very interested if either of > those assumptions is wrong. > > If I'm not wrong, then updates to the base X.509 spec are no > longer really important, other than for the sake of tidiness. > Another corollary would be that the opinions of people who > have no influence over running code but who think one document > or the other is more important, can safely be ignored. Again, > good to know it that's incorrect. 5280 clearly states that "This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet." I'm assuming (possibly incorrectly) that a profile is a subset. It add restrictions but anything that is compliant to the profile is also compliant to the more general spec. During discussions about PKI interoperability (especially getting existing PKIs cross-signed by other PKIs or added to trust anchor lists) it has come up repeatedly that some PKI implementers see the use of EKU in a CA-certificates as a constraint as not allowed under X.509 and therefore not allowed in RFC 5280. If I have this wrong, and you think that it is a viable path to define the use of EKU in CA-certificates as a constraint in the PKIX profile with no changes to X.509, I would be very happy. Thanks, Peter From nobody Sat Jan 23 16:51:38 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B981E1B2CF1 for ; Sat, 23 Jan 2016 16:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 A_fQhAA_ELv5 for ; Sat, 23 Jan 2016 16:51:36 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0751B2CED for ; Sat, 23 Jan 2016 16:51:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DAEA5BE50; Sun, 24 Jan 2016 00:51:34 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SC37_LHi5Pr5; Sun, 24 Jan 2016 00:51:33 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.16.108]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CEDB8BE29; Sun, 24 Jan 2016 00:51:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1453596693; bh=MbkrqOlNKFtyo2hCg4gmGjtLXjQCk6wWlYuaxWB4F44=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=HzpTSpTLqW5FweBWWAf8ca3fGgM5iaeWG7ilkxNS/+ZuZmqHVch1ROoW6eX+7Ld/V LDwXyFuvD5GUWGzDLNCkppkHn30GiPcIIJmHscMabmXyKnocdPnb2N3V1piHgAZSHd TTY66SQqv71UsKCEZ44LN5yca3gLoUgbzyPdePEo= To: Peter Bowen References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> <56A3B913.3030506@comcast.net> <052101d15636$aecdca40$0c695ec0$@gmail.com> <56A419A1.2040503@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <56A42014.5060301@cs.tcd.ie> Date: Sun, 24 Jan 2016 00:51:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 00:51:37 -0000 Hiya, On 24/01/16 00:43, Peter Bowen wrote: > On Sat, Jan 23, 2016 at 4:24 PM, Stephen Farrell > wrote: >> On 23/01/16 23:58, Peter Bowen wrote: >>> Until it is clear that using >>> EKU in the way I described in covered by X.509, it is not possible to >>> have a strict profile (e.g. PKIX) include it in the profile. >> >> I don't know what you mean by that, can you elaborate? >> >> My guess is that almost nobody does new implementations of X.509 >> code nowadays, and those that might would go to 5280 and not the >> latest version of X.509, but I'd be very interested if either of >> those assumptions is wrong. >> >> If I'm not wrong, then updates to the base X.509 spec are no >> longer really important, other than for the sake of tidiness. >> Another corollary would be that the opinions of people who >> have no influence over running code but who think one document >> or the other is more important, can safely be ignored. Again, >> good to know it that's incorrect. > > 5280 clearly states that "This memo profiles the X.509 v3 certificate > and X.509 v2 certificate revocation list (CRL) for use in the > Internet." Right, the history though is that PKIX and CCITT (now ITU-T) collaborated very well twenty years ago on that and it was then a good idea to ensure a lack of divergence. I think the world has changed sufficiently since then, but again that's back to the assumptions from my previous posting. Keep in mind that RFC2459 begat RFC3280 which begat RFC5280 so there's a good bit of history, and we mostly wanted to minimise the code/text changes throughout that evolution. > I'm assuming (possibly incorrectly) that a profile is a > subset. It add restrictions but anything that is compliant to the > profile is also compliant to the more general spec. > > During discussions about PKI interoperability (especially getting > existing PKIs cross-signed by other PKIs or added to trust anchor > lists) it has come up repeatedly that some PKI implementers see the > use of EKU in a CA-certificates as a constraint as not allowed under > X.509 and therefore not allowed in RFC 5280. > > If I have this wrong, and you think that it is a viable path to define > the use of EKU in CA-certificates as a constraint in the PKIX profile > with no changes to X.509, I would be very happy. There are many cases where things initially proposed in an I-D ended up being back-ported to the ITU-T X.509 document. If you have a thing you think needs doing and find that publishing an I-D seems like a reasonable approach, then I'd say just go for it and we'll see if it gets support from implementers. If OTOH you care more about whether text gets into an ITU-T spec, then that might not be the route for you. Cheers, S. > > Thanks, > Peter > From nobody Sun Jan 24 01:53:39 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0AA1B2BCF for ; Sun, 24 Jan 2016 01:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DK=1.009, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 m2DqmjXk5rO8 for ; Sun, 24 Jan 2016 01:53:33 -0800 (PST) Received: from mail04.dandomain.dk (mail04.dandomain.dk [194.150.112.204]) (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 BA3AB1B2BC9 for ; Sun, 24 Jan 2016 01:53:32 -0800 (PST) Received: from Morten ([62.44.135.85]) by mail04.dandomain.dk (DanDomain Mailserver) with ASMTP id 4201601241053285110; Sun, 24 Jan 2016 10:53:28 +0100 From: "Erik Andersen" To: , "Directory list" References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> <56A3B913.3030506@comcast.net> <052101d15636$aecdca40$0c695ec0$@gmail.com> <56A419A1.2040503@cs.tcd.ie> <56A42014.5060301@cs.tcd.ie> In-Reply-To: <56A42014.5060301@cs.tcd.ie> Date: Sun, 24 Jan 2016 10:53:31 +0100 Message-ID: <000001d1568d$15684ef0$4038ecd0$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIVSzUXZpx0TCzS4mpo4m9SkbHUeQJEdeqNAqiykAAB5gd5AgKSQWGxAf+4FlUCfrtvPwFTuCGCAe/27fQBRpxP1AJo+GJCAfu63acBvR9xt5298ifA Content-Language: en-gb Archived-At: Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 09:53:35 -0000 OK - let me explain what the intention is for the current work on X.509. 1. X.509 has been developed over a long period. It has been edited, at = times simultaneously, by different people. There has been a shift in = terminology during that time (e.g. the term certificate using system has been used = as a synonym for relying party). Streamlining terminology and style is a = pure (major) editorial task not intended to change the technical content. 2. When attribute certificates were introduced, an attempt was made to generalize a lot of the text to cover both types of certificates. This = was not done consistently and has made the text difficult to read. X.509 has = a section 2 with the header "Public-key certificate framework", but it has = a lot of stuff about attribute certificate before it has been introduced = in Section 3. The goal has been to separate the discussion on PKI and PMI. = This give a little redundancy, but not that much. People only interested in public-key certificates can read section 2 without being bothered with a = lot on attribute certificate talk. Again, no technical change is intended. 3. The IT world is changing quite rapidly. I sometimes have the feeling = that many PKI experts assumes that the work has more or less been done, = except possibly for cryptographic algorithms. We have smart grid and IoT = being developed quite rapidly. These are new environments with new challenges = for PKI (and possibly for PMI). Revocation is this environment can be a = major challenge. Resource constrained (battery driven) devices have to be supported, etc. All this requires X.509 adaptations. These adaptations = has to made without affecting the current use of PKI. It is certainly not = the intention to cause problems for running code. Personally, I am quite involved in smart grid security within IEC TC 57 WG15 on behalf of the Danish Energy Sector to progress that work and to understand the special requirements.. So the tasks are: 1) Streamline X.509; 2) adapt it to new environments. Collaboration with PKIX is very important, but we cannot let PKIX = slow-down our effort to adapt to new environments. The task here is quite urgent. Major national infrastructure are at risk. Regards, Erik -----Oprindelig meddelelse----- Fra: pkix [mailto:pkix-bounces@ietf.org] P=E5 vegne af Stephen Farrell Sendt: 24 January 2016 01:52 Til: Peter Bowen Cc: Emne: Re: [pkix] Next edition of X.509 Hiya, On 24/01/16 00:43, Peter Bowen wrote: > On Sat, Jan 23, 2016 at 4:24 PM, Stephen Farrell=20 > wrote: >> On 23/01/16 23:58, Peter Bowen wrote: >>> Until it is clear that using >>> EKU in the way I described in covered by X.509, it is not possible=20 >>> to have a strict profile (e.g. PKIX) include it in the profile. >> >> I don't know what you mean by that, can you elaborate? >> >> My guess is that almost nobody does new implementations of X.509 code = >> nowadays, and those that might would go to 5280 and not the latest=20 >> version of X.509, but I'd be very interested if either of those=20 >> assumptions is wrong. >> >> If I'm not wrong, then updates to the base X.509 spec are no longer=20 >> really important, other than for the sake of tidiness. >> Another corollary would be that the opinions of people who have no=20 >> influence over running code but who think one document or the other=20 >> is more important, can safely be ignored. Again, good to know it=20 >> that's incorrect. >=20 > 5280 clearly states that "This memo profiles the X.509 v3 certificate=20 > and X.509 v2 certificate revocation list (CRL) for use in the=20 > Internet." Right, the history though is that PKIX and CCITT (now ITU-T) = collaborated very well twenty years ago on that and it was then a good idea to ensure = a lack of divergence. I think the world has changed sufficiently since = then, but again that's back to the assumptions from my previous posting. Keep in mind that RFC2459 begat RFC3280 which begat RFC5280 so there's a good bit of history, and we mostly wanted to minimise the code/text = changes throughout that evolution. > I'm assuming (possibly incorrectly) that a profile is a subset. It=20 > add restrictions but anything that is compliant to the profile is also = > compliant to the more general spec. >=20 > During discussions about PKI interoperability (especially getting=20 > existing PKIs cross-signed by other PKIs or added to trust anchor > lists) it has come up repeatedly that some PKI implementers see the=20 > use of EKU in a CA-certificates as a constraint as not allowed under > X.509 and therefore not allowed in RFC 5280. >=20 > If I have this wrong, and you think that it is a viable path to define = > the use of EKU in CA-certificates as a constraint in the PKIX profile=20 > with no changes to X.509, I would be very happy. There are many cases where things initially proposed in an I-D ended up being back-ported to the ITU-T X.509 document. If you have a thing you = think needs doing and find that publishing an I-D seems like a reasonable approach, then I'd say just go for it and we'll see if it gets support = from implementers. If OTOH you care more about whether text gets into an = ITU-T spec, then that might not be the route for you. Cheers, S. >=20 > Thanks, > Peter >=20 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From nobody Mon Jan 25 14:25:36 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F031A1AA2 for ; Mon, 25 Jan 2016 14:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 4accN0RXPQ5q for ; Mon, 25 Jan 2016 14:25:33 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::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 CE8B51A1A9B for ; Mon, 25 Jan 2016 14:25:32 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id v14so179122392ykd.3 for ; Mon, 25 Jan 2016 14:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WDyc/gsxYJNTXkf89V9R7LV3Pvy7a2xz0MRkwdK3bJs=; b=m16+ISMqUVJrV5eFVIJndOh59n7tafcQJ+kKDSfQdtpSTQnUjYwm+MH64TaxA/p2t+ Hb4CMmKeIImaUaxoAyXTl/vhRTCC05Lkw8ElYjSEeMLgrmbw8Poir7cd4349qvEzxKwP sr0rrtZa2QUIJKbpRu6YhEUJPWPwhyAqL2D5Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=WDyc/gsxYJNTXkf89V9R7LV3Pvy7a2xz0MRkwdK3bJs=; b=c1ai3GEKkCCG6XLstSC690qVWDDtKQ0QsEPXxyOd1FAjErD7VWZNgdxKwt3dmuvPzZ 5Zc8Nwe81TNNc3XRXC2xv6Y9JXOp22VbI9Nx9yr2e5Tx1mg0OCLHrQkHlzeeliUMH+Q+ yAordMmMe5mdhwtKGrQ7KryZqShBjLeY1Bm0ivGupb0LuO2uLb9C+8ilX1VFdsA63VxI pNrVYPMAwUfZGdXKeGteDsCg+f+OTVjcYR1qAVYBnbOcwCswXShiXc169Emv1Tvxw/jN tKL48n8tbr/guTRMtlr0yK71ny7wWTeLOJcd7Ww1ggc7gEk7MRsGljpmIBfMUoPFaxlj IaWA== X-Gm-Message-State: AG10YORN5RLIcKuQYSU7Z8bykhQrheGPldK5jzMcFk1bM4LYmysuxAjswVuczD2HQhwJ0w== X-Received: by 10.129.148.2 with SMTP id l2mr9449722ywg.298.1453760732195; Mon, 25 Jan 2016 14:25:32 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id l128sm15742201ywd.5.2016.01.25.14.25.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 14:25:31 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Turner In-Reply-To: Date: Mon, 25 Jan 2016 17:25:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Bowen X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [pkix] Strings in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 22:25:34 -0000 My two cents =E2=80=A6 On Jan 18, 2016, at 22:10, Peter Bowen wrote: >=20 > In writing certlint (https://github.com/awslabs/certlint), I ran > across several items related to strings in certificates that are > slightly unclear. I=E2=80=99m hoping that someone might be able to = help > clarify a few things: >=20 >=20 > 1) TeletexString, BMPString, and UniversalString types of = DirectoryStrings >=20 > RFC 5280 says CAs should not use TeletexString, BMPString, and > UniversalString types for DirectoryStrings. As early as 1999 (RFC > 2459) these were flagged as deprecated. >=20 > Is there anything that has moved these to SHALL NOT/MUST NOT or are we > still at SHOULD NOT? I=E2=80=99d love to hear that CAs haven=E2=80=99t generated these string = types for the last decade =E2=80=A6. > 2) VisibleString and BMPString types of DisplayText >=20 > RFC 5280 says: > Conforming CAs SHOULD use the > UTF8String encoding for explicitText, but MAY use IA5String. > Conforming CAs MUST NOT encode explicitText as VisibleString or > BMPString. >=20 > However the organization field of noticeref also uses DisplayText. Do > the same rules apply? I remember something about this =E2=80=A6 ah yeah @ IETF 74: https://ietf.org/proceedings/74/slides/pkix-3.pdf I think it was just meant to apply to explicitText because that=E2=80=99s = what was seen in the wild given the following statement in s4.2.1.4: "Conforming CAs SHOULD NOT use the noticeRef option.=E2=80=9D > 3) Unicode normalization >=20 > A number of fields in certificates can take unicode strings. Is there > any specification as to how (or if) they should be normalized? I thought there were references in s7 of RFC 5280 (and some tweaks in s5 = of RFC 6818). There=E2=80=99s also some additional information in RFC = 6125. In a perfect world, the output of precis = (https://datatracker.ietf.org/wg/precis/documents/) would be adopted the = world over. I=E2=80=99m not going to hold my breath though. spt= From nobody Mon Jan 25 17:46:30 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F721ACD5F for ; Mon, 25 Jan 2016 17:46:28 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 hihqFLgIj-7l for ; Mon, 25 Jan 2016 17:46:27 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 3E35E1A700E for ; Mon, 25 Jan 2016 17:46:27 -0800 (PST) Received: by mail-pa0-x232.google.com with SMTP id cy9so89866655pac.0 for ; Mon, 25 Jan 2016 17:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=v+4OfF6Wk/wIUHJ/hJuCksMw0OSNHvqHAfvG44VJHx4=; b=oVy7uyDDHWWDks+8VtEpI0dYZtM3oW8RzQG9aXimOFk0DqtLQTCBx3nN0JX1aeW60P IKAGckXaVXa9us5q0i32/kPMvj8cAPX+Ia7LqpndeZzS2zN5Zmk0I2nLOWULb7Ks3JBJ LQZvGRcOaxbrpjgfB8mEZ/PR2ZI0dgmqlJ6OqXiEE4yRPOOhlq3CB3Seo1Q6KtYmouzE HIfHl343MbG0FKA6SoyFEg0badcSxAS9nUoE52mHIqXF/ufmDl+eD7atRmNCYKn83unI dUyBOODD65VB9UGxlOORghIN61jnT5R4o6By1lB+loyCo6OrHWmbfxIjN1QBxOx0rn1e ArTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v+4OfF6Wk/wIUHJ/hJuCksMw0OSNHvqHAfvG44VJHx4=; b=WfPfyHHRZ9I725nxkRaHd4jRtF8Obt+VDgm+4y1b3NZrqe+YlJhDTJZJuE6hpc6Ccm c7A2p4rhD6uO1obVDWJPXHSJAdsA0Lq50gAmihHkhkykOkY4HWRZcS07KPn7c1FqUGhF HufTcIzhGTdDK1P5gWvAn7YsY/0JzNap06COVWMHJQ7J5GLI0i7iMmxnKl8kGEC38FCU zwHdHiM9aBxdn8CnP7euqmxUGxEIXeOuNUOVxUzF4E8kkTJygJT109F0RcvQn0RVw0yE kgDgQNr5IqzHn+Hen89D7mKXa9hnWfIDyU8XUBMBzu2wbGFBjptHG1i1uqiWDTp8ZikD f56w== X-Gm-Message-State: AG10YORZKxZh3U0iyzDGpStw4S2AkYEmFrW20OM7mCQrsnu5gKU+0+iS2lGhrZLrNB/ulmR66UUws8rM/Di3mw== MIME-Version: 1.0 X-Received: by 10.66.122.97 with SMTP id lr1mr29884120pab.68.1453772786778; Mon, 25 Jan 2016 17:46:26 -0800 (PST) Received: by 10.66.142.193 with HTTP; Mon, 25 Jan 2016 17:46:26 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Jan 2016 17:46:26 -0800 Message-ID: From: Peter Bowen To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [pkix] Strings in certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 01:46:29 -0000 Sean, Thanks for providing your thoughts. On Mon, Jan 25, 2016 at 2:25 PM, Sean Turner wrote: > My two cents =E2=80=A6 > > On Jan 18, 2016, at 22:10, Peter Bowen wrote: >> >> In writing certlint (https://github.com/awslabs/certlint), I ran >> across several items related to strings in certificates that are >> slightly unclear. I=E2=80=99m hoping that someone might be able to help >> clarify a few things: >> >> >> 1) TeletexString, BMPString, and UniversalString types of DirectoryStrin= gs >> >> RFC 5280 says CAs should not use TeletexString, BMPString, and >> UniversalString types for DirectoryStrings. As early as 1999 (RFC >> 2459) these were flagged as deprecated. >> >> Is there anything that has moved these to SHALL NOT/MUST NOT or are we >> still at SHOULD NOT? > > I=E2=80=99d love to hear that CAs haven=E2=80=99t generated these string = types for the last decade =E2=80=A6. You won't hear that from me. I've seen hundreds (if not thousands) of certificates issued in the last week that use these string types. >> 2) VisibleString and BMPString types of DisplayText >> >> RFC 5280 says: >> Conforming CAs SHOULD use the >> UTF8String encoding for explicitText, but MAY use IA5String. >> Conforming CAs MUST NOT encode explicitText as VisibleString or >> BMPString. >> >> However the organization field of noticeref also uses DisplayText. Do >> the same rules apply? > > I remember something about this =E2=80=A6 ah yeah @ IETF 74: > https://ietf.org/proceedings/74/slides/pkix-3.pdf > > I think it was just meant to apply to explicitText because that=E2=80=99s= what was seen in the wild given the following statement in s4.2.1.4: > "Conforming CAs SHOULD NOT use the noticeRef option.=E2=80=9D Yes, I was pointed to RFC 6818 which changed this rule. >> 3) Unicode normalization >> >> A number of fields in certificates can take unicode strings. Is there >> any specification as to how (or if) they should be normalized? > > I thought there were references in s7 of RFC 5280 (and some tweaks in s5 = of RFC 6818). There=E2=80=99s also some additional information in RFC 6125= . In a perfect world, the output of precis (https://datatracker.ietf.org/w= g/precis/documents/) would be adopted the world over. I=E2=80=99m not goin= g to hold my breath though. I don't see anything there that specifies a specific normalization form for storage, except for the one thing about explicitText. I'll assuming anything (including mixed) is good. Thanks, Peter From nobody Wed Jan 27 02:33:59 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920871A03A1 for ; Wed, 27 Jan 2016 02:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.308 X-Spam-Level: X-Spam-Status: No, score=0.308 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DK=1.009, RCVD_IN_DNSWL_LOW=-0.7] autolearn=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 z8bd58vNrxKz for ; Wed, 27 Jan 2016 02:33:56 -0800 (PST) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) (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 BB85F1A037F for ; Wed, 27 Jan 2016 02:33:55 -0800 (PST) Received: from Morten ([62.44.135.33]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201601271133508165; Wed, 27 Jan 2016 11:33:50 +0100 From: "Erik Andersen" To: "'Peter Bowen'" References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> In-Reply-To: Date: Wed, 27 Jan 2016 11:33:53 +0100 Message-ID: <001001d158ee$38831330$a9893990$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIVSzUXZpx0TCzS4mpo4m9SkbHUeQJEdeqNAqiykAAB5gd5AgKSQWGxAf+4FlWeLBiX4A== Content-Language: en-gb Archived-At: Cc: 'Directory list' , 'PKIX' Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 10:33:58 -0000 Hi Peter, Back to the subject. The second sentence in your proposal seems to imply that when a CA = certificate has a certain extended key usage, then this extended key = usage also applies for subsequent public-key certificates on = certification path. Is that a right interpretation. As to your first mail, it was my impression you were asking for the = definition of new OIDs with associated semantics to cover restriction. = Is that the case? The Chinese member body of SC6 is interested in a better algorithm for = certificate validation to be added to X.509. I wonder whether your = suggestion fits into that effort. Regards, Erik -----Oprindelig meddelelse----- Fra: Peter Bowen [mailto:pzbowen@gmail.com]=20 Sendt: 23 January 2016 13:44 Til: Erik Andersen Cc: Directory list ; PKIX Emne: Re: [pkix] Next edition of X.509 In 8.2.2.4, replace the first sentence with: The presence of this extension in an end-entity certificate indicates = one or more purposes for which the certified public key may be used, in = addition to, or in place of the basic purposes indicated in the key = usage extension field. The presence of this extension in a certificate = issued by one CA to another CA constrains the key purposes in subsequent = certificates in a certification path. If there is support for this addition, then additions will also be = needed in section 10 to include key purposes in the input, output, and = processing. Thanks, Peter On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen wrote: > Hi Peter, > > I would like to explore whether there is support for such an addition = to X.509. Could I have your comments please? > > Regards, > > Erik > > -----Oprindelig meddelelse----- > Fra: Peter Bowen [mailto:pzbowen@gmail.com] > Sendt: 23 January 2016 02:50 > Til: Erik Andersen > Cc: Stephen Farrell ; Directory list=20 > ; PKIX ; WG15@iectc57.org > Emne: Re: [pkix] Next edition of X.509 > > Erik, > > While I'm sure this is a contentious proposal, I would proposal that > X.509 add language allowing usage of Extended Key Usage for = constraints, joining certificate policies, name constraints, basic = constraints, etc. Many widely deployed certificate path validation = libraries already implement this even though it is unclear at best = whether such is compliant with X.509 (10/2012). > > Thanks, > Peter > > On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen wrote: >> Hi Stephen, >> >> I will collect any comment on any list. The goal is to get the best = technical specification. >> >> Regards, >> >> Erik >> >> -----Oprindelig meddelelse----- >> Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sendt: 07 December 2015 11:45 >> Til: Erik Andersen ; Directory list=20 >> ; PKIX >> Cc: WG15@iectc57.org >> Emne: Re: [pkix] Next edition of X.509 >> >> >> Thank you Erik! Do I understand correctly that comments from this = list that you get before February are useful and that sending comments = to the pkix list works well enough for you? >> >> If so, great, and I'd ask folks who care about RFC5280 or other PKIX=20 >> RFCs to please review this to check for any glitches that might=20 >> affect interop should new code be written based on the ISO doc. I'm=20 >> sure other comments are also welcome, >> >> Cheers, >> S. >> >> On 07/12/15 10:33, Erik Andersen wrote: >>> In preparation for the next edition of X.509 (the 2016 edition), I=20 >>> have forwarded to the ISO/IEC JTC1/SC6 two documents for three = months ballots: >>> >>> >>> >>> These two documents may be found as: >>> >>> >>> >>> 1. = http://www.x500standard.com/uploads/extensions/x509-pdam-amd2.pdf, >>> which is the 3rd PDAM text for an amendment to X.509. >>> >>> 2. http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, = which a >>> second draft technical corrigendum. This technical corrigendum is=20 >>> based on a set of defects reports, which include the justification=20 >>> for the changes. The Defect reports may be found on=20 >>> http://www.x500standard.com/index.php?n=3DIg.DefectReports. >>> >>> >>> >>> An early corrigendum has been approved within ISO and ITU-T and may=20 >>> be found >>> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. >>> >>> >>> >>> These three documents together with the seventh edition will provide = >>> the input to the next edition of X.509. The different=20 >>> X.recommendations, including X.509, may be found at=20 >>> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely = available in the PDF version. >>> >>> >>> >>> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot=20 >>> comments on the two documents out for ballot. Others, which may have = >>> comments on the these document, may post them on the lists and after = >>> consolidation and consensus, they may be issued as ITU-T comments. >>> >>> >>> >>> It is important to check whether any of the suggested changes=20 >>> affects running codes. If that is a case, it is a mistake. >>> >>> >>> >>> The intension behind the changes has been: >>> >>> 1. A better separation between public-key certificates and = attribute >>> certificates. >>> >>> 2. Use of a consistent terminology. >>> >>> 3. Use of a consistent editing style in accordance with the = ITU-T >>> editing guidelines.. >>> >>> 4. A new PKI component called trust broker assists a relying = party >>> validating a public-key certificate is included. >>> >>> 5. IEC TC57 WG15 has identified a requirement for a feature = first >>> called whitelist but now the term is authorization and validation=20 >>> list is used. A proposal for such a feature is included in the = amendment. >>> >>> The main goal has been to position X.509 for new challenges, such=20 >>> smart grid security and security for Internet of Things with battery = >>> driven devices, very short messages (can we put a 257 octets=20 >>> signature on a few octets message?) , short reaction time=20 >>> requirements, many millions of entities, etc. This is all very = different from Web-based systems. >>> >>> Kind regards, >>> >>> Erik >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > From nobody Wed Jan 27 04:05:29 2016 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B5F1A878B for ; Wed, 27 Jan 2016 04:05:28 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 sn0nCeElRzkP for ; Wed, 27 Jan 2016 04:05:22 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 A97921A8757 for ; Wed, 27 Jan 2016 04:05:22 -0800 (PST) Received: by mail-pa0-x22e.google.com with SMTP id uo6so4021702pac.1 for ; Wed, 27 Jan 2016 04:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8MNiJRU6PzQGyaLSSd2/1CDMxH/xV3kokl8YyfGfn5I=; b=HmMg4ldtwMLbGSwf8zERTL0Ox8x4Cu4/aryyJUUQKM+7CMjeoim7sJMNddIrpUAURo PYQ6YksKYAqcJwiI947LczP7ZMNFD+KDSWU/PPZRDNy4hapzfHb+pJFemrgQHtI5ezP8 aPTaNXiDhUL86i4xKRmysyJXnph1G9VNjTJrvLQJQkFU/ryMbbzJNixsnuFj2OvU2u+J NoJOoqunZVqs6gE6l4rNpfWR5UTnh7pI44WPx/hGeehQXn9HD0gid0xb2lEXL2BGSOii XYllC1LRO+qRy4hWsJ7d9HfWLPD2d8d+dXcI/ZwILrH98x1N65g6J8EC2gblYH310lJ3 /U7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8MNiJRU6PzQGyaLSSd2/1CDMxH/xV3kokl8YyfGfn5I=; b=Sf9e2QM1krgSFQTRoXhQ5IWodEqA1YP/F3OJmnZj2p4vCJs9WQRUORcJlhHqqF+mvN pG83RH5/MUesmXVRclhd+T3csy5oEqZwPw0Y0TvPHx1oIekI2MbLBtgmaYWGX9XtgesM IHfA6UPP93nSAWrfo8OaSTBjcFtoeCSNIF7dbteCrv+1soJ6E7Q1nBc/aujG4Sz+vS/J pX13ncGt/43Gjlqn9PLJNBjaERpuBtWW43TtwwSOCGwlWGzQIUaYd36Vp7ompq9mMluA 4iLFV9KBIi5FAOL4z41aB8SYzbBggT2zE91fZEAkYGdPAmktw4IvHKftPZMRQIptdkon UDtg== X-Gm-Message-State: AG10YOSE9rEitTh4uOgEKT1kY5o4Bm3XvETPojGU9coyVhGsvTHtgLyeIccLQYDYeS57guqTSrhNP3P+eGBV1g== MIME-Version: 1.0 X-Received: by 10.66.100.163 with SMTP id ez3mr42063877pab.5.1453896322009; Wed, 27 Jan 2016 04:05:22 -0800 (PST) Received: by 10.66.142.193 with HTTP; Wed, 27 Jan 2016 04:05:21 -0800 (PST) In-Reply-To: <001001d158ee$38831330$a9893990$@x500.eu> References: <000001d130da$b05884d0$11098e70$@x500.eu> <5665633F.7070906@cs.tcd.ie> <000401d130e3$bdf08120$39d18360$@x500.eu> <000001d155c7$98b64530$ca22cf90$@x500.eu> <001001d158ee$38831330$a9893990$@x500.eu> Date: Wed, 27 Jan 2016 04:05:21 -0800 Message-ID: From: Peter Bowen To: Erik Andersen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Directory list , PKIX Subject: Re: [pkix] Next edition of X.509 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 12:05:28 -0000 On Wed, Jan 27, 2016 at 2:33 AM, Erik Andersen wrote: > The second sentence in your proposal seems to imply that when a CA certif= icate has a certain extended key usage, then this extended key usage also a= pplies for subsequent public-key certificates on certification path. Is tha= t a right interpretation. Yes, that is the right interpretation. To further clarify, a CA-certificate that includes an extKeyUsage extension containing the anyExtendedKeyUsage key purpose is equivalent to a CA-certificate that does not include an extKeyUsage extension. > As to your first mail, it was my impression you were asking for the defin= ition of new OIDs with associated semantics to cover restriction. Is that t= he case? No. There is no request to define new OIDs. Rather the request is to clarify (or redefine depending on your view) the meaning of the extKeyUsage extension when present in a CA-certificate. > The Chinese member body of SC6 is interested in a better algorithm for ce= rtificate validation to be added to X.509. I wonder whether your suggestion= fits into that effort. Without more details, I would assume it could. Several code libraries that implement portions of X.509 already interpret extKeyUsage as described. Thanks, Peter > -----Oprindelig meddelelse----- > Fra: Peter Bowen [mailto:pzbowen@gmail.com] > Sendt: 23 January 2016 13:44 > Til: Erik Andersen > Cc: Directory list ; PKIX > Emne: Re: [pkix] Next edition of X.509 > > In 8.2.2.4, replace the first sentence with: > > The presence of this extension in an end-entity certificate indicates one= or more purposes for which the certified public key may be used, in additi= on to, or in place of the basic purposes indicated in the key usage extensi= on field. The presence of this extension in a certificate issued by one CA = to another CA constrains the key purposes in subsequent certificates in a c= ertification path. > > If there is support for this addition, then additions will also be needed= in section 10 to include key purposes in the input, output, and processing= . > > Thanks, > Peter > > On Sat, Jan 23, 2016 at 2:19 AM, Erik Andersen wrote: >> Hi Peter, >> >> I would like to explore whether there is support for such an addition to= X.509. Could I have your comments please? >> >> Regards, >> >> Erik >> >> -----Oprindelig meddelelse----- >> Fra: Peter Bowen [mailto:pzbowen@gmail.com] >> Sendt: 23 January 2016 02:50 >> Til: Erik Andersen >> Cc: Stephen Farrell ; Directory list >> ; PKIX ; WG15@iectc57.org >> Emne: Re: [pkix] Next edition of X.509 >> >> Erik, >> >> While I'm sure this is a contentious proposal, I would proposal that >> X.509 add language allowing usage of Extended Key Usage for constraints,= joining certificate policies, name constraints, basic constraints, etc. M= any widely deployed certificate path validation libraries already implement= this even though it is unclear at best whether such is compliant with X.50= 9 (10/2012). >> >> Thanks, >> Peter >> >> On Mon, Dec 7, 2015 at 3:38 AM, Erik Andersen wrote: >>> Hi Stephen, >>> >>> I will collect any comment on any list. The goal is to get the best tec= hnical specification. >>> >>> Regards, >>> >>> Erik >>> >>> -----Oprindelig meddelelse----- >>> Fra: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>> Sendt: 07 December 2015 11:45 >>> Til: Erik Andersen ; Directory list >>> ; PKIX >>> Cc: WG15@iectc57.org >>> Emne: Re: [pkix] Next edition of X.509 >>> >>> >>> Thank you Erik! Do I understand correctly that comments from this list = that you get before February are useful and that sending comments to the pk= ix list works well enough for you? >>> >>> If so, great, and I'd ask folks who care about RFC5280 or other PKIX >>> RFCs to please review this to check for any glitches that might >>> affect interop should new code be written based on the ISO doc. I'm >>> sure other comments are also welcome, >>> >>> Cheers, >>> S. >>> >>> On 07/12/15 10:33, Erik Andersen wrote: >>>> In preparation for the next edition of X.509 (the 2016 edition), I >>>> have forwarded to the ISO/IEC JTC1/SC6 two documents for three months = ballots: >>>> >>>> >>>> >>>> These two documents may be found as: >>>> >>>> >>>> >>>> 1. http://www.x500standard.com/uploads/extensions/x509-pdam-amd2= .pdf, >>>> which is the 3rd PDAM text for an amendment to X.509. >>>> >>>> 2. http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor2.pdf, wh= ich a >>>> second draft technical corrigendum. This technical corrigendum is >>>> based on a set of defects reports, which include the justification >>>> for the changes. The Defect reports may be found on >>>> http://www.x500standard.com/index.php?n=3DIg.DefectReports. >>>> >>>> >>>> >>>> An early corrigendum has been approved within ISO and ITU-T and may >>>> be found >>>> as: http://www.x500standard.com/uploads/dtc/X509-Ed7-Cor1.pdf. >>>> >>>> >>>> >>>> These three documents together with the seventh edition will provide >>>> the input to the next edition of X.509. The different >>>> X.recommendations, including X.509, may be found at >>>> http://www.itu.int/rec/T-REC-X/e. This edition of X.509 is freely avai= lable in the PDF version. >>>> >>>> >>>> >>>> Those involved in ISO/IEC JTC1/SC6 can, of course, submit ballot >>>> comments on the two documents out for ballot. Others, which may have >>>> comments on the these document, may post them on the lists and after >>>> consolidation and consensus, they may be issued as ITU-T comments. >>>> >>>> >>>> >>>> It is important to check whether any of the suggested changes >>>> affects running codes. If that is a case, it is a mistake. >>>> >>>> >>>> >>>> The intension behind the changes has been: >>>> >>>> 1. A better separation between public-key certificates and attri= bute >>>> certificates. >>>> >>>> 2. Use of a consistent terminology. >>>> >>>> 3. Use of a consistent editing style in accordance with the ITU-= T >>>> editing guidelines.. >>>> >>>> 4. A new PKI component called trust broker assists a relying par= ty >>>> validating a public-key certificate is included. >>>> >>>> 5. IEC TC57 WG15 has identified a requirement for a feature firs= t >>>> called whitelist but now the term is authorization and validation >>>> list is used. A proposal for such a feature is included in the amendme= nt. >>>> >>>> The main goal has been to position X.509 for new challenges, such >>>> smart grid security and security for Internet of Things with battery >>>> driven devices, very short messages (can we put a 257 octets >>>> signature on a few octets message?) , short reaction time >>>> requirements, many millions of entities, etc. This is all very differe= nt from Web-based systems. >>>> >>>> Kind regards, >>>> >>>> Erik >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >