From rob.stradling@comodo.com Mon Apr 2 02:23:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E5E21F8946 for ; Mon, 2 Apr 2012 02:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxogCzLSeN+9 for ; Mon, 2 Apr 2012 02:23:52 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 73B7C21F893E for ; Mon, 2 Apr 2012 02:23:51 -0700 (PDT) Received: (qmail 12196 invoked from network); 2 Apr 2012 09:23:49 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 2 Apr 2012 09:23:49 -0000 Received: (qmail 17253 invoked by uid 1000); 2 Apr 2012 09:23:49 -0000 Received: from nigel.brad.office.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 (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 02 Apr 2012 10:23:49 +0100 Message-ID: <4F797025.6000402@comodo.com> Date: Mon, 02 Apr 2012 10:23:49 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: "pkix@ietf.org" References: <4F74C077.4050103@comodo.com> In-Reply-To: <4F74C077.4050103@comodo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kathleen Wilson Subject: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 09:23:53 -0000 On 29/03/12 21:05, Rob Stradling wrote: > RFC5280 says: > "4.2.1.10. Name Constraints > ...Conforming CAs MUST mark this extension as critical" > > Can anyone explain the reason for this requirement? Everyone, thanks for your comments. There is certainly no consensus to change RFC5280 so that it doesn't advocate that Name Constraints be critical. However, I wonder if we could arrive at a compromise... PROPOSAL: Change the "MUST" to "SHOULD". RFC2119 says: '3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.' Now, I would say that the desire to avoid breaking all Apple devices is a "valid reason"! And I think "SHOULD" would still send the appropriate message to implementers that they need to think very carefully about these things. Comments? Votes? Thanks. > Mozilla are currently considering requiring CAs in their Root Program to > include the Name Constraints extension in "external" subordinate CA > certificates (i.e. where the holder of the sub-CA private key is a > different organization to the Root CA). > Setting the critical flag would cause any software that doesn't > recognize the Name Constraints extension to barf. I'm told that Apple's > iOS and OSX platforms are among those that don't recognize the Name > Constraints extension, so specifying critical Name Constraints is a > non-starter. Therefore, Mozilla's current plan is to recommend that Name > Constraints be non-critical. > > Should RFC5280 be updated to specify that Name Constraints need not be > critical? > > Thanks. > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From paul.hoffman@vpnc.org Mon Apr 2 05:32:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D2E21F866A for ; Mon, 2 Apr 2012 05:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IieytWaHBEJ5 for ; Mon, 2 Apr 2012 05:32:03 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F1B7021F8669 for ; Mon, 2 Apr 2012 05:32:02 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q32CW1Y3059207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 2 Apr 2012 05:32:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: <4F797025.6000402@comodo.com> Date: Mon, 2 Apr 2012 05:32:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> To: PKIX X-Mailer: Apple Mail (2.1257) Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 12:32:03 -0000 On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote: > On 29/03/12 21:05, Rob Stradling wrote: > > RFC5280 says: > > "4.2.1.10. Name Constraints > > ...Conforming CAs MUST mark this extension as critical" > > > > Can anyone explain the reason for this requirement? >=20 > Everyone, thanks for your comments. There is certainly no consensus = to change RFC5280 so that it doesn't advocate that Name Constraints be = critical. >=20 > However, I wonder if we could arrive at a compromise... >=20 >=20 > PROPOSAL: Change the "MUST" to "SHOULD". >=20 >=20 > RFC2119 says: > '3. SHOULD This word, or the adjective "RECOMMENDED", mean that = there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course.' >=20 > Now, I would say that the desire to avoid breaking all Apple devices = is a "valid reason"! And I think "SHOULD" would still send the = appropriate message to implementers that they need to think very = carefully about these things. >=20 > Comments? Votes? Fully disagree. A number of people gave security reasons for the current = wording. Watering down the security of the protocol because a vendor = made a bad decision and no one is doing conformance testing (which would = have trivially picked this up) is not a good response. --Paul Hoffman From eabalea@gmail.com Mon Apr 2 06:06:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE97E21F8454 for ; Mon, 2 Apr 2012 06:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Oe2zqwCdLdH for ; Mon, 2 Apr 2012 06:06:03 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 138DF21F8450 for ; Mon, 2 Apr 2012 06:06:02 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1247035ghb.31 for ; Mon, 02 Apr 2012 06:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bs1ZHioxdivcJkjtqVLR5UZvUWx34Ip2M/Pz/CytFF8=; b=CLKG72+H6dxBvFLaHllQsMq5sbIXjYp3f5xCxAnJTkkjBWOX4QokhPnIL448/V41Gv zgvOrcO3hw+oxaRbpf98YCzJMT3frvqeQ56brLaVP6vzCP+9RFweDV0mQreMicSlKJc6 Fu3ra/zDHjg9L2I6am1GYHV9ctWXljchYX0D1GkXRL801+603SkQkiaEMnmqrKdK3Tlz eFJuHA1/FqHyQOlCYV9Wqz7XCHyIZICUfDRnemBZe3qPqxhxXdbIb3xO7NyRxnraJJgH idy+jN51VvDzstcVpcWPv2HWxCCV/2nN/jqZr8OuahVM70PRNKFgD22DLaKiCHlcVtAP b1SA== MIME-Version: 1.0 Received: by 10.236.170.41 with SMTP id o29mr6791393yhl.83.1333371962626; Mon, 02 Apr 2012 06:06:02 -0700 (PDT) Received: by 10.236.176.233 with HTTP; Mon, 2 Apr 2012 06:06:02 -0700 (PDT) In-Reply-To: <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> Date: Mon, 2 Apr 2012 15:06:02 +0200 Message-ID: From: Erwann Abalea To: Paul Hoffman Content-Type: multipart/alternative; boundary=20cf303b38e32f947604bcb1da46 Cc: PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 13:06:03 -0000 --20cf303b38e32f947604bcb1da46 Content-Type: text/plain; charset=UTF-8 I agree with Paul (and thus disagree with Rob). This is a constraint. If this constraint is set by the CA, the CA wants it to be enforced (else, why would it set this constraint?). Not so long ago, Apple had to correct a pretty bad behaviour with X.509 certificates, not enforcing basicConstraints:CA=False set to critical. Nobody then thought of changing a MUST into a SHOULD to allow this behaviour. Apple choosed the only realistic solution, update its code. This is the same situation here. If Apple can't correctly handle a constraint imposed by the CA, or can't reject a certificate because of a critical-but-unknown extension, that's their problem, and they're putting their users at risk. That said, I'm an Apple user, and in the Mozilla context I'm following, Rob's proposition was not a bad one at first thought. Only at first. 2012/4/2 Paul Hoffman > On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote: > > > On 29/03/12 21:05, Rob Stradling wrote: > > > RFC5280 says: > > > "4.2.1.10. Name Constraints > > > ...Conforming CAs MUST mark this extension as critical" > > > > > > Can anyone explain the reason for this requirement? > > > > Everyone, thanks for your comments. There is certainly no consensus to > change RFC5280 so that it doesn't advocate that Name Constraints be > critical. > > > > However, I wonder if we could arrive at a compromise... > > > > > > PROPOSAL: Change the "MUST" to "SHOULD". > > > > > > RFC2119 says: > > '3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course.' > > > > Now, I would say that the desire to avoid breaking all Apple devices is > a "valid reason"! And I think "SHOULD" would still send the appropriate > message to implementers that they need to think very carefully about these > things. > > > > Comments? Votes? > > Fully disagree. A number of people gave security reasons for the current > wording. Watering down the security of the protocol because a vendor made a > bad decision and no one is doing conformance testing (which would have > trivially picked this up) is not a good response. > -- Erwann. --20cf303b38e32f947604bcb1da46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Paul (and thus disagree with Rob).

This is a constraint= . If this constraint is set by the CA, the CA wants it to be enforced (else= , why would it set this constraint?).

Not so long ago, Apple had to = correct a pretty bad behaviour with X.509 certificates, not enforcing basic= Constraints:CA=3DFalse set to critical. Nobody then thought of changing a M= UST into a SHOULD to allow this behaviour. Apple choosed the only realistic= solution, update its code.
This is the same situation here. If Apple can't correctly handle a cons= traint imposed by the CA, or can't reject a certificate because of a cr= itical-but-unknown extension, that's their problem, and they're put= ting their users at risk.

That said, I'm an Apple user, and in the Mozilla context I'm fo= llowing, Rob's proposition was not a bad one at first thought. Only at = first.

2012/4/2 Paul Hoffman <paul.hoffman@vpnc.org>
On Apr 2, 2012, at 2:23 AM= , Rob Stradling wrote:

> On 29/03/12 21:05, Rob Stradling wrote:
> > RFC5280 says:
> > "4.2.1.10. Name Constraints
> > ...Conforming CAs MUST mark this extension as critical"
> >
> > Can anyone explain the reason for this requirement?
>
> Everyone, thanks for your comments. =C2=A0There is certainly no consen= sus to change RFC5280 so that it doesn't advocate that Name Constraints= be critical.
>
> However, I wonder if we could arrive at a compromise...
>
>
> PROPOSAL: Change the "MUST" to "SHOULD".
>
>
> RFC2119 says:
> '3. SHOULD =C2=A0 This word, or the adjective "RECOMMENDED&qu= ot;, mean that there
> =C2=A0 may exist valid reasons in particular circumstances to ignore a=
> =C2=A0 particular item, but the full implications must be understood a= nd
> =C2=A0 carefully weighed before choosing a different course.'
>
> Now, I would say that the desire to avoid breaking all Apple devices i= s a "valid reason"! =C2=A0And I think "SHOULD" would st= ill send the appropriate message to implementers that they need to think ve= ry carefully about these things.
>
> Comments? =C2=A0Votes?

Fully disagree. A number of people gave security reasons for the curr= ent wording. Watering down the security of the protocol because a vendor ma= de a bad decision and no one is doing conformance testing (which would have= trivially picked this up) is not a good response.


-- <= br>Erwann.
--20cf303b38e32f947604bcb1da46-- From rob.stradling@comodo.com Mon Apr 2 06:25:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB1B21F8503 for ; Mon, 2 Apr 2012 06:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+LQs2XR0ssQ for ; Mon, 2 Apr 2012 06:25:02 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id DA55A21F8501 for ; Mon, 2 Apr 2012 06:25:01 -0700 (PDT) Received: (qmail 3172 invoked from network); 2 Apr 2012 13:25:00 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 2 Apr 2012 13:25:00 -0000 Received: (qmail 12620 invoked by uid 1000); 2 Apr 2012 13:25:00 -0000 Received: from nigel.brad.office.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 (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 02 Apr 2012 14:25:00 +0100 Message-ID: <4F79A8AB.4060402@comodo.com> Date: Mon, 02 Apr 2012 14:24:59 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: Erwann Abalea , Paul Hoffman References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: PKIX , Kathleen Wilson Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 13:25:03 -0000 Paul, Erwann, Aside from maybe petitioning Apple to fix their code, what would you advise Mozilla to do? a) Require critical Name Constraints for "external" Sub-CAs ASAP, thereby causing currently deployed Apple products to reject all certs issued by these Sub-CAs. b) Require Name Constraints, but specify that the critical flag need not be set and mention that this requirement breaks RFC5280. c) Not require Name Constraints. Instead, require all "external" Sub-CAs to undergo a "full" audit. d) Other. On 02/04/12 14:06, Erwann Abalea wrote: > I agree with Paul (and thus disagree with Rob). > > This is a constraint. If this constraint is set by the CA, the CA wants > it to be enforced (else, why would it set this constraint?). > > Not so long ago, Apple had to correct a pretty bad behaviour with X.509 > certificates, not enforcing basicConstraints:CA=False set to critical. > Nobody then thought of changing a MUST into a SHOULD to allow this > behaviour. Apple choosed the only realistic solution, update its code. > This is the same situation here. If Apple can't correctly handle a > constraint imposed by the CA, or can't reject a certificate because of a > critical-but-unknown extension, that's their problem, and they're > putting their users at risk. > > That said, I'm an Apple user, and in the Mozilla context I'm following, > Rob's proposition was not a bad one at first thought. Only at first. > > 2012/4/2 Paul Hoffman > > > On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote: > > > On 29/03/12 21:05, Rob Stradling wrote: > > > RFC5280 says: > > > "4.2.1.10. Name Constraints > > > ...Conforming CAs MUST mark this extension as critical" > > > > > > Can anyone explain the reason for this requirement? > > > > Everyone, thanks for your comments. There is certainly no > consensus to change RFC5280 so that it doesn't advocate that Name > Constraints be critical. > > > > However, I wonder if we could arrive at a compromise... > > > > > > PROPOSAL: Change the "MUST" to "SHOULD". > > > > > > RFC2119 says: > > '3. SHOULD This word, or the adjective "RECOMMENDED", mean that > there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course.' > > > > Now, I would say that the desire to avoid breaking all Apple > devices is a "valid reason"! And I think "SHOULD" would still send > the appropriate message to implementers that they need to think very > carefully about these things. > > > > Comments? Votes? > > Fully disagree. A number of people gave security reasons for the > current wording. Watering down the security of the protocol because > a vendor made a bad decision and no one is doing conformance testing > (which would have trivially picked this up) is not a good response. > > > > -- > Erwann. > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From ietf@augustcellars.com Mon Apr 2 06:47:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F49121F8559 for ; Mon, 2 Apr 2012 06:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fWQYmJZMrwB for ; Mon, 2 Apr 2012 06:47:55 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 89E4121F849D for ; Mon, 2 Apr 2012 06:47:55 -0700 (PDT) Received: from Tobias (unknown [81.253.40.88]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 9040C38F23; Mon, 2 Apr 2012 06:47:53 -0700 (PDT) From: "Jim Schaad" To: "'Rob Stradling'" , "'Erwann Abalea'" , "'Paul Hoffman'" References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> <4F79A8AB.4060402@comodo.com> In-Reply-To: <4F79A8AB.4060402@comodo.com> Date: Mon, 2 Apr 2012 15:46:59 +0200 Message-ID: <047701cd10d7$16721240$435636c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQLEnBOTxyZKOpqdpKcAqK9wvIYe6AJ3iq3yAjdENcICiQcFUAHvizD6lE863XA= Cc: 'PKIX' , 'Kathleen Wilson' Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 13:47:56 -0000 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Rob Stradling > Sent: Monday, April 02, 2012 3:25 PM > To: Erwann Abalea; Paul Hoffman > Cc: PKIX; Kathleen Wilson > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > Constraints from MUST to SHOULD > > Paul, Erwann, > > Aside from maybe petitioning Apple to fix their code, what would you advise > Mozilla to do? > > a) Require critical Name Constraints for "external" Sub-CAs ASAP, thereby > causing currently deployed Apple products to reject all certs issued by these > Sub-CAs. > b) Require Name Constraints, but specify that the critical flag need not be set > and mention that this requirement breaks RFC5280. > c) Not require Name Constraints. Instead, require all "external" > Sub-CAs to undergo a "full" audit. For what it is worth this is basically what you suggested by making it non critical Jim > d) Other. > > On 02/04/12 14:06, Erwann Abalea wrote: > > I agree with Paul (and thus disagree with Rob). > > > > This is a constraint. If this constraint is set by the CA, the CA > > wants it to be enforced (else, why would it set this constraint?). > > > > Not so long ago, Apple had to correct a pretty bad behaviour with > > X.509 certificates, not enforcing basicConstraints:CA=False set to critical. > > Nobody then thought of changing a MUST into a SHOULD to allow this > > behaviour. Apple choosed the only realistic solution, update its code. > > This is the same situation here. If Apple can't correctly handle a > > constraint imposed by the CA, or can't reject a certificate because of > > a critical-but-unknown extension, that's their problem, and they're > > putting their users at risk. > > > > That said, I'm an Apple user, and in the Mozilla context I'm > > following, Rob's proposition was not a bad one at first thought. Only at first. > > > > 2012/4/2 Paul Hoffman > > > > > > On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote: > > > > > On 29/03/12 21:05, Rob Stradling wrote: > > > > RFC5280 says: > > > > "4.2.1.10. Name Constraints > > > > ...Conforming CAs MUST mark this extension as critical" > > > > > > > > Can anyone explain the reason for this requirement? > > > > > > Everyone, thanks for your comments. There is certainly no > > consensus to change RFC5280 so that it doesn't advocate that Name > > Constraints be critical. > > > > > > However, I wonder if we could arrive at a compromise... > > > > > > > > > PROPOSAL: Change the "MUST" to "SHOULD". > > > > > > > > > RFC2119 says: > > > '3. SHOULD This word, or the adjective "RECOMMENDED", mean that > > there > > > may exist valid reasons in particular circumstances to ignore a > > > particular item, but the full implications must be understood and > > > carefully weighed before choosing a different course.' > > > > > > Now, I would say that the desire to avoid breaking all Apple > > devices is a "valid reason"! And I think "SHOULD" would still send > > the appropriate message to implementers that they need to think very > > carefully about these things. > > > > > > Comments? Votes? > > > > Fully disagree. A number of people gave security reasons for the > > current wording. Watering down the security of the protocol because > > a vendor made a bad decision and no one is doing conformance testing > > (which would have trivially picked this up) is not a good response. > > > > > > > > -- > > Erwann. > > > > > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > COMODO CA Limited, Registered in England No. 04058690 Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. If > you have received this email in error please notify the sender by replying to > the e-mail containing this attachment. Replies to this email may be > monitored by COMODO for operational or business reasons. Whilst every > endeavour is taken to ensure that e-mails are free from viruses, no liability > can be accepted and the recipient is requested to use their own virus > checking software. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Mon Apr 2 06:51:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82AF21F84F0 for ; Mon, 2 Apr 2012 06:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DC_IMAGE_SPAM_HTML=0.001, DC_PNG_UNO_LARGO=0.558, EXTRA_MPART_TYPE=1, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E38yYE4zRqzh for ; Mon, 2 Apr 2012 06:51:36 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D14AA21F84EF for ; Mon, 2 Apr 2012 06:51:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A684821B116B; Mon, 2 Apr 2012 09:51:34 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 916D621B1162; Mon, 2 Apr 2012 09:51:34 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.233]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Mon, 2 Apr 2012 09:51:34 -0400 From: "Miller, Timothy J." To: Erwann Abalea Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD Thread-Index: AQHNENFdCwPvcioO5kmMwQq0xX8GqZaH0NIA Date: Mon, 2 Apr 2012 13:51:33 +0000 Message-ID: <814C42F2-56CC-4BF9-9C60-08A39A1AEF64@mitre.org> References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.31.42.203] Content-Type: multipart/related; boundary="_004_814C42F256CC4BF99C6008A39A1AEF64mitreorg_"; type="multipart/alternative" MIME-Version: 1.0 Cc: PKIX , Paul Hoffman Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 13:51:36 -0000 --_004_814C42F256CC4BF99C6008A39A1AEF64mitreorg_ Content-Type: multipart/alternative; boundary="_000_814C42F256CC4BF99C6008A39A1AEF64mitreorg_" --_000_814C42F256CC4BF99C6008A39A1AEF64mitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 2, 2012, at 8:06 AM, Erwann Abalea wrote: This is the same situation here. If Apple can't correctly handle a constrai= nt imposed by the CA, or can't reject a certificate because of a critical-b= ut-unknown extension, that's their problem, and they're putting their users= at risk. Heh. See attached screenshot. So it's not Apple who can't get it right, it's the iOS team. :) (The extension in question is the MS Application Policies OID [1.3.6.1.4.1.= 311.21.10].) It's CryptoAPI that ignores critical extensions: http://technet.microsoft.com/en-us/library/cc700843.aspx "The CryptoAPI engine does not enforce critical extensions in certificates,= only Certificate Revocation Lists (CRLs). The CryptoAPI engine and program= ming model places the burden of parsing critical extensions on to the calli= ng application. Therefore, an application must understand and enforce a cri= tical extension when evaluating a certificate. The CryptoAPI revocation pro= vider, however, does evaluate critical extensions in CRLs and therefore wou= ld reject a CRL with a critical extension that is not known or understood." I understand MS's reasoning behind this design, but I've never liked it. T= oo many applications get it wrong. -- T [cid:EB8DCFBA-3AA0-4530-9505-0587310FB748] --_000_814C42F256CC4BF99C6008A39A1AEF64mitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable On Apr 2, 2012, at 8:06 AM, Erwann Abalea wrote:

This is the same situation here. If Apple can't c= orrectly handle a constraint imposed by the CA, or can't reject a certifica= te because of a critical-but-unknown extension, that's their problem, and t= hey're putting their users at risk.

Heh.  See attached screenshot.  

So it's not Apple who can't get it right, it's the iOS team.  :)<= /div>

(The extension in question is the MS Application Policies OID [1.3.6.1= .4.1.311.21.10].)

It's CryptoAPI that ignores critical extensions:

"The CryptoAPI engine does not enforce critical extensions in cer= tificates, only Certificate Revocation Lists (CRLs). The CryptoAPI eng= ine and programming model places the burden of parsing critical extensions = on to the calling application. Therefore, an application must understand and enforce a critical extension when evalu= ating a certificate. The CryptoAPI revocation provider, however, does = evaluate critical extensions in CRLs and therefore would reject a CRL = with a critical extension that is not known or understood."

I understand MS's reasoning behind this design, but I've never liked i= t.  Too many applications get it wrong.

-- T

--_000_814C42F256CC4BF99C6008A39A1AEF64mitreorg_-- --_004_814C42F256CC4BF99C6008A39A1AEF64mitreorg_ Content-Type: image/png; name="PastedGraphic-2.png" Content-Description: PastedGraphic-2.png Content-Disposition: inline; filename="PastedGraphic-2.png"; size=46466; creation-date="Mon, 02 Apr 2012 13:51:33 GMT"; modification-date="Mon, 02 Apr 2012 13:51:33 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAq8AAAGPCAYAAAByJTk2AAAX7mlDQ1BJQ0MgUHJvZmlsZQAAWIWV WQVYFVHTPrt7i0t3lzRId3cjIA2CcumOS7ciooSAKK2SFiIYSCiNCiIqKiAKKIiomISiIvEviH7f /8XzP/95nnP2vbNz5syZmZ09cxcAjkZSWFgQTAdAcEgk2cZYj8/J2YUPPwFggABmIADESJ4RYbrW 1hbgv7blUQBtXp9Ibsr673z/sdF7eUd4AgBZo9jDK8IzGMWNACAtnmHkSACwm/IEYyLDNnEeipnI qIIortnEvr9xyyb2+I0Ht3jsbPRRPAUAgYpEIvsCQP0RpfNFe/qicmioAMAxhHj5h6CsfCjW8vQj eQHA4Y7y7AwODt3E2SgW9fgnOb7/S6bHX5kkku9f/HsvW41g4B8RFkSK+3+a4/9uwUFRf9bgQTtV RKCtOXplQe0W60kytEUxG4pz/LxNLbbpZ8Mi9Wy26W3+kaZ2mzZC8bBflIn9Nn4XFWivi2IuFK8G hppv8qN2gtlCPCytUMyAYkHPCH2X3zJhpXg/O8dtHgsvbwNDFKNRBDuRQ23+8PtFRNv+ocfH++lb /uEPIJlt+psGxZkk8tZeUB3gYu8g4811d6C4LizS2m57rQchQZbbe4Ff+5CNbLbxinfE1n631or0 szP5LR+hi0QD4LdMhMvH38j0tw6IjB/Z5A9dJyxoK6bRuYgdOcpm0w6CKPbxDrHflolkepEMzH/b BDkJjAAJkIE38AAhYA3wAQugDwy2Rz6UHoKOniAUBKGdzEf75w72DfYR9hV2BDuFffaXW/8PH/AH Xuj1D93zn+i2IB58QqV6g4g/q2E4MFoYdYwFOuqgXQ6jglH9c+/Bx+aPf7X6rasvOldym6K3rX30 P2u/zz+V/C9zPP7O+HedjMDrLanbHDIXZeZkVv/M/8eOcYY4A5wJzggnhhxBriF9SDdyF2lDmgEf 0om0IINI+yb+l1VI21Yhb+3XHF3RG0Rt/Qr5jxpF/eXYptKI0ygCmy3+QPSe/98VHLa09v83KVFo 90AlBaD3zP/u8Y+lhVHrKmL0MJqonVEbY1gwHEASo4BaXBejjfpAEaXq/+us7VES+GzZMnprL4Hg DYqDI71jIzcDXT80LI7s7+sXyaeLZkvvnXymIZ5SO/nkZGTlwGbu/f1oL9ls5VSI5eE/aCQ0dlWY ASCu/IMWWgtAwwqaeg7+gyb0HADWBQDOXfaMIkf/pmE2BywgAlo0+tnRzCEARFE95YASUAc6wBCY AStgB5zBXtS6fiAY1TgGJIIDIB1kgTxQAEpBOagG58ElcBU0gzbQDe6Ae2AIjIBxMAVmwQcwD5bB LwiC8BA1xAixQ7yQECQByUEqkBZkCFlANpAz5A75QiFQFJQIHYSyoHyoFKqELkBXoFaoG7oLPYKe QdPQHLQIrcAITAUzwdywMCwNq8C6sDlsB7vBvnA4HA+nwTlwMVwF18FNcDd8Dx6Bp+AP8DcEIJQI C8KPSCIqiD5ihbggPggZSUYykUKkCqlHbqCx+ASZQj4iPzE4DCOGDyOJetIEY4/xxIRjkjHZmFLM eUwT5hbmCWYaM49Zx1JjubASWDWsKdYJ64uNwaZjC7Fnsdext9HneRa7jMPhWHAiOGU02p1xAbgE XDbuFK4B14V7hJvBfcPj8ex4Cbwm3gpPwkfi0/El+Dp8J/4xfhb/g0BJ4CXIEYwILoQQQiqhkFBL 6CA8Jrwl/KKgoxCiUKOwovCiiKPIpaihuEHxkGKW4heRnihC1CTaEQOIB4jFxHribeIEcYmSknIH pSrlbkp/yv2UxZSXKfsppyl/UjFQiVPpU7lSRVHlUJ2j6qJ6RrVETU0tTK1D7UIdSZ1DfYG6l/oF 9Q8aRhopGlMaL5oUmjKaJprHNJ9pKWiFaHVp99LG0xbSXqN9SPuRjoJOmE6fjkSXTFdG10r3lO4b PSO9LL0VfTB9Nn0t/V36dwx4BmEGQwYvhjSGaoZehhlGhFGAUZ/Rk/EgYw3jbcZZJhyTCJMpUwBT FtMlpgdM88wMzArMDsyxzGXM7cxTLAiLMIspSxBLLstVllGWFVZuVl1Wb9YM1nrWx6zf2TjZdNi8 2TLZGthG2FbY+dgN2QPZj7E3s09yYDjEOXZzxHCc5rjN8ZGTiVOd05Mzk/Mq53MumEucy4Yrgaua a5DrGzcPtzF3GHcJdy/3Rx4WHh2eAJ4TPB08c7yMvFq8/rwneDt53/Mx8+nyBfEV893im+fn4jfh j+Kv5H/A/2uHyA77Hak7GnZMChAFVAR8BE4I9AjMC/IK7hJMFLwo+FyIQkhFyE+oSKhP6LuwiLCj 8GHhZuF3ImwipiLxIhdFJkSpRbVFw0WrRIfFcGIqYoFip8SGxGFxRXE/8TLxhxKwhJKEv8QpiUc7 sTtVd4bsrNr5VJJKUlcyWvKi5LQUi5SFVKpUs9RnaUFpF+lj0n3S6zKKMkEyNTLjsgyyZrKpsjdk F+XE5TzlyuSG5anljeRT5FvkFxQkFLwVTiuMKTIq7lI8rNijuKakrERWqleaUxZUdlc+qfxUhUnF WiVbpV8Vq6qnmqLapvpTTUktUu2q2hd1SfVA9Vr1dxoiGt4aNRozmjs0SZqVmlNafFruWhVaU9r8 2iTtKu1XOgI6Xjpndd7qiukG6NbpftaT0SPrXdf7rq+mn6TfZYAYGBtkGjwwZDC0Nyw1fGG0w8jX 6KLRvLGicYJxlwnWxNzkmMlTU25TT9MLpvNmymZJZrfMqcxtzUvNX1mIW5AtbuyCd5ntOr5rwlLI MsSy2QpYmVodt5q0FrEOt765G7fbenfZ7jc2sjaJNn22jLb7bGttl+307HLtxu1F7aPsexxoHVwd Ljh8dzRwzHeccpJ2SnK658zh7O/c4oJ3cXA56/Jtj+Gegj2zroqu6a6jbiJusW5393LsDdrbvo92 H2nfNXesu6N7rfsqyYpURfrmYepx0mPeU9+zyPODl47XCa85b03vfO+3Ppo++T7vfDV9j/vO+Wn7 Ffp99Nf3L/VfCDAJKA/4HmgVeC5wI8gxqCGYEOwe3BrCEBIYciuUJzQ29FGYRFh62FS4WnhB+DzZ nHw2Aopwi2iJZEIPuYNRolGHoqajtaLLon/EOMRci6WPDYkdjBOPy4h7G28UfyYBk+CZ0JPIn3gg cTpJN6kyGUr2SO5JEUhJS5ndb7z//AHigcAD91NlUvNTvx50PHgjjTttf9rMIeNDF9Np0snpTw+r Hy4/gjnif+RBhnxGScZ6plfmQJZMVmHWarZn9sBR2aPFRzdyfHIe5Crlns7D5YXkjR7TPnY+nz4/ Pn/m+K7jTSf4TmSe+Fqwr+BuoUJheRGxKKpoqtiiuKVEsCSvZLXUr3SkTK+s4STXyYyT3095nXp8 Wud0fTl3eVb5SoV/xVilcWVTlXBVYTWuOrr6TY1DTd8ZlTMXznKczTq7di7k3NR5m/O3LihfuFDL VZt7Eb4YdXGuzrVu6JLBpZZ6yfrKBpaGrMvgctTl91fcr4xeNb/ac03lWn2jUOPJ64zXM5ugprim +Wa/5qkW55ZHrWatPTfUb1y/KXXzXBt/W1k7c3tuB7EjrWOjM77zW1dY18du3+6Znn09471OvcO3 dt96cNv8dv8dozu9fbp9nf2a/W131e62DqgMNN9Tutc0qDh4/b7i/esPlB40PVR+2DKkOnTjkcaj jsfaj7ufGDy5M2w6fG/EcuTRqP3o2FPXp1NjXmPvngU9W3ge/fzX+P4J7ETmJN1k4QuuF1UvxV42 TClNtU8bTA++sn01PuM58+F1xOvV2bQ31G8K3/K+vfBO7l3bnNHc0Ps972c/hH349TH9E/2nk59F Pzd+0fkyOO80P7tAXthYzF5iXzr3VeFrzzfrby+Wg5d/fc/8wf7j/E+Vn30rjitvf8Ws4leL18TW bqybr09sBG9shJHIpK2jAIJ22McHgMVzaN3iDADjEHqmoPldG203BD18wOjVAcqAwxFDjD5WGieI pyVwUrAT+Si1qOyoo2lKaF/RKzAkM44yy7Kks75lt+C4zsXJncsL+KL4FwWCBL8Kp4jSiZVJiO9s ltKTfizrI7ekkKbEoVyrqqo2qOGoOaXto/NBL1h/3jDY6I3JPtMn5sYWjZb8VjnWizYatkl2bfY/ HOWdgpyrXEZdCW4qe3325bu3k+Y8Gbxkva18An0P+hX7XwxoCxwIGgt+HbIQuhqOJzNGcEVyRjFF E6NXY97HDse1xJckRCdaJQkn/Up+mFKzP/bAnlStgzvS8GmfD42mdx2uO1KakZmZnEXODjjqkeOY q5bHnvfz2Hh++/HyEwcL/AutipSL+UqIJV9LX5YNnuw9deP0pfLyiuzK6CrXap2aHWfgM6/Odp2r OJ9ywavW7qJpnc4llXrZBrHL/FfYrlJdXb/2sfHp9c6mmub0lsBW6xvKN/naKNq+tk93DHV2dzV2 n+853Vtw6+jt/XdIfRr9bP3Ld4cHrt8rGky47/7A5KHsEOcj3KOlxy+fdA6XjySOOj6VHkPGHj8r fu48zjx+byJ2UmBy4EXUS9GXr6cqpt1ecb4amyl8bTtLN3v/TcZbg7cb71rnSO/h92Uf1D/MfCz8 tOsz/nPnl4h5vvnuBeuF0UWzxZalnUtnv/J/Lf/G/61uWXd5+nvZj8CfriuJv56u1WxsbPnfEJZF MMgcphtbgIvEuxOcKGyJZpRmVLupPWmyabvpfjDIMPoxVTO/ZZVli2fv5WTlCuTu5OVGY2BSwFDw urCASK7oinigxISkhVSrjKRsqTyNQorivPI+lT41afUSjXUtL+3bugJ6yfpjhtJG6cZjpuJmseb1 FpOWlFYq1h67M2zqbR/afXGgdpRwMnJ2d4nbk+da49a0986+EfcZ0hePn17AG+dD6UvjR+fPEMAU yBTEEEwbQgyFQ3+EfQgfJ/dFXIksikqI3hOjGssSuxg3FH85IS8xNMkqWTaFMWV5//iB7tRzB3PT Yg95pJsdFkNz43RGZ+bJrIRs56OqOew5v3In8zqPVeUfOh54wrnApFCxiL+YWLxYMlbaVlZ+MvWU x2n9csEKbMVc5WhVf/WNmoYzNWdLzx07f/hCQm3oRfc660ua9WINDA2rl99ceXS1A81XldcLm3Kb s1qyWo/eyL9Z0lbVXttR1HmwK7TbrWdXr/YtxduSd8T6xPol7yoMaN0zG7S9b/XA6KHGkOwj4cec T2iGoeGlkdejI09vj11/dub5sfGoCftJxRfML769HJ66Np3/KnzG+rX0LO3s5zcP3za8y5kLfm/2 QfjD+scnn2o+k79ozmPm+xcyFk2WcEudX92+zn+L/ra+fOK73PfJH6d/klecfzmu+q1lr3du+18A ugw7I/TIVcweLBHbiiPjFQkYQj9FHtGL0ohKllqAhouWgY6Gno2Bl1GeaRczmeU062N2iEOT04cr n7ub5xMfB7/ejkCBfMEWoZciQJRfTFt8jwR550HJAqnz0q0yA7Ljcp/k1xQplTiVRVWUVQ3VrNR3 a1hr7tIy0dbWkdPl16PS+6r/zOCGYYlRrLG9iYwp0XTSrME81cJhl6QlzvKVVaf16d3JNu62enYC 9hj71w69juVOic5OLvJ7qPe8de1yK94bus/Inct9nnTbo8TT30vZG+c94lPjG+mn78/oPxPQGJge 5BQsFrwa0h+aFWYSjgnvIidGKEUsRNZGeUZzRj+OyYzViV2Oq4snJbAmPEw8kqSXtJZ8MyVuv+r+ lQNtqckHddOQtN5D+9NV05cOXzrilyGUMZNZneWVLZY9f7Q151CuTR5f3qdjN9AYsjrBeuJFQXWh b5FY0fvi2hL/UtHSt2UXTmadCj1tU65QwVyxVDlUVVt9oMbujPCZ5bO3zuWd97ngULv7okWd0SXt eqUG8ctcV4hXlq++uNbbeOb6oabQ5tiWnNaaG203h9s+dxA6Bbq0ul16YnqP37p8e/DOh372u2YD KegbbPGB/MPYod7HzE+Ch++Oij/NGVt+7j3+cTL7pfLU51fNr4vfnHjX+H7tU/q85VLI8tdf7Jv+ //0f2WbDKQGQ3wuA/TIAtgcAyLoDgMgqWmcSAbCmBsBOFcDTxgA+EQ+gSuO/7w8IHXFo1UkHWNEa WQwooLWmBXBBK8xYcAQUgXOgFQyASTAPYdGKURqtE12hCCgbqoE6oDFoCaaBxWFj2As+AJfD7fAE vIpwI1qIO3IQOYfcQ+YxzBgNtHbLwlzDTGBxWFmsGzYD24SdxTHjDHExuFrcJJ4Bb4xPxjfhvxDE Cd6EKsIUBS+FO0UVxSxRjBhCbKEkULpQ1lMhVHuoGqlpqYOo79HspMml+Uq7h/YWnTRdGT0FfTz9 AoM/w2tGD8YZJl+mT8wxaMWSzyrA2sRmwTbDnsjBwdHDGcLFyzXCnc/jwMvPu8Q3yF+7I0cgStBd SEuYRwQSmRUdELssXiSRvNMbzYIK0lwyWJllOSBPpcChKKakrmypQlKNUTuqfkajU3Nc66cOte4O PS39fQYZhq1GiyaypjFm3RZ0u0iW162R3To2SbY37VYc1B33O/W7sOwJcL2zV3xfIYnS47AX5J3k 89Mv2n8pMDzoU4h/6Gw4iTwZ6RL1NMYrjit+JDE32Ww/cqD9YPQhqfQ3R05lOmTTHh3IrTiWeJxU sLvIqsS9LPvUSIVm1cCZ6PP0tfF1bxrsrtxp1GhqbdW42dfh0vWtd6VPZkBkcP7h+cd+I6ZjCRNO 0xyz8XMdn84sMCz9WA77kbZi/OvRGv265AbLVv6A0NMGHlABRsAFhIEs0ATmqPcDQALIBqdAA+gB o+ADBEFsqO+NIXcoHiqALkOD0ByMh4VgQ9TzafAZ+A78Dq3spRE7JB6pQGv4Lxg2jB4mGFOMuY1Z xPJhrbAp2MvYV2gtbo47gGvGzePF8J74cvwEgZOwh3CK8JJCkMKf4jLFT6I+MYc4RalEmUP5Dq2P K6khak/qfhppmmJaDG047TSdLV0fvSZ9M4M8w1VGecZmJk2mPmZb5hmWKFYiaxWbJttz9jgOLtTf gVxsXHe5U3hUeX7ydvBl8LvskBGgEvgkOCR0TbhEJFU0WMxF3FRCdae4JI8UgzRBBsisyVHKcylI KeoruShHquSq1qndU/+oSaelpO2qE6tbotehP2fIbmRlnGUyaEZv7mpxYddPKwvr47tHbNns9thX OLxxknKOdxlw5XWL3/vcXZdU78nndcKHwjfZbyHAI/BxsHZIbRhDeBz5ZaRhVG0MY2xdvFHCq6Sk FLb9l1ONDo4d8k1fPJKQCWcdPkqZU5lneWzjeGNBUJFY8fvShpNxp40q2Co/Vd85U30u60LuxcJL VQ1Xr9y+Nnn9RwvrDZU2t45DXfU947ep+4zuHr438kB26PQTrpG6MetxeLJ3qvS16juFD/c/ry70 fNVcTv5RsJK9Gryuue1/LKAETOizLwW0gBXwBHEgF5wFHeApWIRoIHHIBPKBDqHP+y3oNYyFRWEz OAwugjtRjzMi2kgwchK5j2xg5DF+mArMMywTdjc2D/sEx4pzw9XgPuNV8en4YYIQIZYwSCFAkUAx QpQjniD+pCRRDlKpU9VTC1FX0vDTnKWVoW2ns6SboU9k4GHoZfRnomNqYSaxULI0s3qxMbH1sSdx KHMsc7ZypXCb8LDwvOVt5yvij9zhIKAhKCTEKkwjQhDFieHEiRJ0O9klhaTkpQ1lnGQPyXUrIIpm SkXKc6r6alUaeM0IrRmdPbrD+pYGd430jTtN1cxaLFR2tVkZWL+wSbUTs3/imOQs7PLAlbyXaV8j ydbjm9dpn11+GP/ewOxgt1CVcPYIOHI++lVsZrxcwlTS8ZRdB+hSJ9KupRccOZAZkx2dsy8Pe6zu uFMBobC9OK5U8yTx1HR5T+Wl6uozVecOXxCrvVcXUs/Q0HzF7Rqmsa7JvgW0Xrzp3E7RcbMrtEeo 9/Ztjzvr/cUDsvf67js/eDcU+Wj1Scrw+mji0+/PQp+/mXCdfPTScKruFTxj9jp3dugt5TuDuYj3 FR+6P774tPB5Yx7Mry98WnyxdPNr0beAZbnlle+NP3x/cvzsXtm3svarbFVgtW5Nca19XW79zAbb Rvam/yN85OW2Xh8QlR4A2BcbG0vCAODzAVg7trHxq2pjY60aLTYmAOgK+v3dZetdQwfAycVN1H/y 8v5//f7xPzkts4tFMQ5eAAAACXBIWXMAAAsTAAALEwEAmpwYAAAgAElEQVR4nOy9eZwUxf3//+ye mb13YRdYLpflFlQWFCNeqLteeMRFg9GomKBGjPErkEOCHyUJJBL9JB+RJAaIBqJoouKxJFF+KqxH VDxAWRSR+z52Ya+BnZmdnu7fHzM1W9PbMzt7cNfz8ZjHdFdVV1fVu6vmVe+u7tEsy0KhUCgUCoVC oTge0I92ARQKhUKhUCgUimRR4lWhUCgUCoVCcdygxKtCoVAoFAqF4rhBiVeFQqFQKBQKxXGDEq8K hUKhUCgUiuMGJV4VCoVCoVAoFMcNSrwqFAqFQqFQKI4b3Ee7AMcbmqZpR7sMCoVCoVAoThws9dL9 VqGdbO2lxKdCoVAoFIoTiZNN/J6Q4lUJVIVCoVAoFIoTU9ge9+L1CApVJYgVCoVCoVAcTo6IKDve Be1xJ147UKwqMapQKBQKheJ4pkNE3PEmZo8L8doOwXq4BaoSwAqFQqFQKNrC4RZgbcr/eBCyx6x4 bYNgba+QVEJUoVAoFArFsUx7RVurjj9WhewxJ15bKVqPtMDt6HwUCoVCoVCc3HSUEGttPkmnP9ZE 7DEhXg+DYG2LuFSCVKFQKBQKxbFMW0RbMsccV0L2qIrXDhath0vUtuc4hUKhUCgUitbQVmHWESL1 uBCxR028Jilc2ytYkxWdidIp4apQKBQKheJIkkicJSvc2itUWzzP0RKwR1y8doBobY/QdIpXSwwU CoVCoVAcLTpqKUB7xGi7xPKRFrFHVLy2U7i2Ntwp7nAuLeio4xUKhUKhUJxYHIm3BNjTtEWQtja8 KcERFJRHTLwmIVw7SrRqSaRpKa6jjlcoFAqFQqGIR3uXByR7fEeJ1YRlOlIC9rCL13aI1nhxicLa 4p11ildLCRQKhUKhUHQ0HbFEoK3LA6wE8a1dhnBURexhFa8d7G1trWhtr2c22TzacrxCoVAoFIoT m/Y+WNUakdqaPDpKxB41AXvYxGsHCtfWiNaWRGxbz6lesaVQKBQKhaI1dNQrr5L1vLYkZuPl05q0 LaWLjTxMItN9ODJtgfZ4W5MVrcl6ZNuzPlYJU4VCoVAoFPFIRickI+7kfCxp3y5W7ZrGLk7tx9nL J+enOew7lTde+GHlsHheE3hd2+v5TCZdsp7atnppE51foVAoFAqFIhla+0BWSx7SljypyXp0O8Lz 2xR4GIRmh4vXFpYLtMa7at9vyWPa0nGJztOWcsULUygUCoVCoWiJtt6uTyRo7QI0GYGajABubbli IzpYbHaoeO1g4Zqs6Ex0TDL5xUsXL22849qTRqFQKBQKxYlDR/9Va7Ie2ERC1B7XGhGcKE1LYeGI DhScR0K8tiUsGW9rvPRt8cq2pkzx4hUKhUKhUCiSpbVe1XjxyQrP1orYZARs0mHHpHhtxTrXjlgm 4ORhTVb8tlfQthSnBK1CoVAoFAqZtjyt3xahmoz4dDqmo5cRHNb1rx0iXjtYuLbG2xovzH6804Nc 7VkTq7ywCoVCoVAoWktr17m2ZU1rsh7WeGHxynHMCNjD+aqs1oq5ZIWrkyBNJGKTCbfn63RconK3 JU6hUCgUCsWJi5NI0xzi7FohGc+nPR8hLoXOsaRve7iF8znteWq27Xh1iod8fIdyJN/z2pYHr+xx dm9ra72xySwjSNYDq5YNKBQKhUKhSIZklg0kIxoTiVmnOFmw2kWs03GtEbB2cXrYxKqddi8bSPIh rbYI13ie1kSe13hC1gNkRT4pcfJNppwtbdtRQlahUCgUipOT1q5nTbQt7zstDQgADYAXCBIrWLEd Fy+feOthncqVTDnj7bd76UC7xOthFq6JPKrJeGPFfiqQN23atBFXX331Zb17974kMzOzj2VZaJqG qL/YtiwLXddxahc5vdgHEHnJiHQiTtM0TNNE1/Xot3ycfdvpvPbzOG3b62VHhIvz2+tvP6dTG8nn EvWJd36nfOzllfMU6US+9no6ldd+rFM7inB72yv7K/vb21jZX9lf2V/Z386xbH+/379t586d773+ +utv/fa3v60A9hMWsxBfsCYjYJ3incLtccnsY8W7UJPgSIvXZD2s9m/7xx6eaD/3wQcfHDV+/PhJ 2dnZZ7lcrminkOoRc7Hpuh7dtiOnA5pdhKZp4nK5CIVC0bztnT3eACN3HrFv72DiIw88dkRHsZsn 0aCWqMPb2yfRwBEvb3unF+WzD24tDZjx8nUqv/0YYRtlf+dj7HVW9lf2V/aPRdlf2V/+PtbsX1dX 9/miRYtmP/LIIx8DNSQnWp32nQRrS9+Jtp32seJdNElwuMVrPCEb71tst0a4thRX8NZbb/2/IUOG jIfmMxxxMcSb5dn3If4FK19kpmnG5C/nF+8itZ9HPpe9TPHCRJ7y7M6OvcPLZXbquE6DSbwO5TRo 2ttcrpd95i6QBzdxnH02Ltfb3n7yQOFkc3lb2V/ZX9lf2d/eJsr+TXHK/seP/devX/9sSUnJH4Ed xBejiYRqonCk/UTf9nROcVhOF2iStFm8avarLRKcYL8l4er0HU+c6g5p5Dh5v//69ev/kZaWViAK IjqBvUPKcfYO63Rxy8c6XaBOHUOE2/OzX8z2jip3cDlfe+eQ87cPZDKibpZlxXQ8e73sA4vcYTVN i+lc9nYQedtnui21ndNtFbmu9kFW13VCoVBMWeTObK+bsr+yv7K/sr+yv7K/nFaOO57tHwgEdgwe PPh7wGZiRaVp25cFabw4u4Btzbd922m/zQK2I982kIxwte8nCrcLVKdwJxErp9cB3eVyFTQ2NkYN LV9AouPaLwa5A8kXtujQ8mAg0osOIa9rgfgzKU3TMAwjWoZQKBRzIYp9e4eQzyvSyOcSZTAMI1o2 OW/59onckeQOJw+E4hjLsnC7my4ZkUb+yG0n6ifydxok5YFCHjhEe8oDpGmauN3uaFlCoRAulyta T9lWcv72WbCyv7K/sr+yv7K/sv+JaH+Xy1VARPsQFqXR0xMrRjWaRKsubdu1mxxu2eIShdu3nfbb TJvEqya3YBLJbdvxPLZ2j6t9W29hO67AlWct9lmVPAOr3bObDeXvsO2LVVRu3owJ9Ojfn4IRIzi1 uIROPXrGFFq+qKIVkTpBTdUuNny+lJ0bPmT/ts0A5PXpT5/B5zNwxJV07toregGK/OwXvPgOhUJU Ve9jxVfv89WWL9iyeztYIQp79+OMvkWcP+wSunftGZNeHrjcbnfMACN3eCBmli7KYR+YxIAnd2i5 vnIbyOUQeQWDwei2GHhkRJns9Zc/oj7iWPnc9s5vHxBbsr98XnsbijZrjf3tg6nc7nJYsvaXz2Xv gvZ6HXf2D9WzZuUGsgcOp08nN5ZRx9erN5I1cDiFnT0nqP1D7FxXgTdzAEMLck5u+6P6v7K/sn9H 2Z8mXSS0kBCxQjwKT6weZ1ucwEqwLWMPT1qkapqmWXJDJUmblg04iNdkva66Q7iTWHXyoLYkXON9 BmzYsGG5XE+5o4qZ1o7VX7Dy2UXsW/kJhV3yKOzeE8uCbfv2sO1ANT1Gns1Z48dTMHxEzAXndCHq us7ODav4Yvlfqf9yGX17ZtC3YAAAW3dsZeseLzlnXMqIkh9SMHhkswFAdAp5/+tNFSz570t8vutz 8vrm0asgH8sy2bV9HzXbajmz4CzGXvhdhvQfFr2I5fqJfOQOIncwOZ3cEcRsV9RL5BPvdpHYl7ct y4rOmJ1uB9kHGHlQsF+f8mJ4MbuX98Wxcn72AcbJ/k79wD7wyO3Ukv3lHwXx42Evp2jHZOwv20mu gziffWA7OvZv4N2n5lC+06L4jilcVJAq2b+Bt/70J97en8/EX9xJ/zQf7/75UdYM/j73Xd4f89CX /PAHv6b4l09zy2lZaP6vuev7v+KS6X/lltOy22d/cyfPzHyazamppEXCUgF/JK2/Fop/PIX+65/l z98MYvq9F5NxROzfwOKbJ7C49Fe8cMvQdtt/+zt/5ad/fjNalhFX/4h7b7+YTlI+G95+iof++hYA /S+ZyIP3Xkp2JN/GvR/xyP2PszZSnx6nXcGd99zCiJ6ZDvYP8sHf/483G8/j53deRKamQaiapQvm 89KbqzioaVhZffnu3T/m+rN7q/5/UvT/5u2mxv+jY/+BAweWAJtwXgIgf4SoTbRt/+CwLZA9vVac 7Wb7bRGvh+NPCuIJV6fttgpX8bEvIXBK5zIMI6YjyC5/0zSp37eXlQueoeGLz/jFlZeRd/UYuHh0 uHnffZ8Dr7/Bk0uX8YWlkT45j9xevWMuxFAohMfjic4K6w7soaJ8PinfLOfH936b7NE34cm+EtA5 v34ptR/8kxfn/4sKzSI953/Izu2Oy+VyvPgty6KyZh+vfvAPKmq+ZPyPx1I6+Bp6ZIwEYJfvE15Z t4R/LHgd64MQ38/Oo1vn/HCjaM3X1ohbJSJOnp3KnUCEWVZ4xizKJtKFQqFoOnkmbJ/92jt7MBiM uVicOqp9oJBtJ/LXNI3GxsZoW4nbZLJd5Vtjiewv19mOPLCIbVHnePaX8xXtL5fNMIyonUWbJrK/ KIfTD5Sot91zcnTsb1G79gvW7Ya6d7/ivJuGNdlq56c89f5qYCC+oEHQFaL2i3VU5DaG89dT6eVy kZESuf2Gh566Tmaa3n77Wyn0GFhAo5VCKlD1+X/4ZE9vLrvmTFIsi8YcjS5pBmZwK1vfy6XxbqPp ZdAdZv8AG99/g03ZZ3PF8O4RO5tkFOgUpLuj9WqP/Q1/I2PueJhrR3Vn5/vP8djzc3m8S28evKIQ TdPYv2Ih059exnn3zOIHhdv40f/M5yfudObecU647P5DpBTfxqzvjCaj8hN+9duFzHqiG/NnXkOm zf57P3iGP76xGqvn6QSCQdJcLvBt55W3N3PdL2Zx0Snw+h//h5dnT6XT/y7k0l6a6v8nfP9X4/8x ZH8XscsEhDdVFqZ2b6kupZO37Th5Y508rvG2O4RWi1dNnmq04rA423JYW4WrU3hMHuICsqymxely 59ha/i6BFR8z/rQB5PUrhG++gS8j/gePiy79+zJ+QF+e/3AF20aMIOem74q2iLmYxYW3efVS3OuX c/01eXQ6bQRa3XbMA38OH+NOofPQM7n+mg949Y3lbPvyHIZdND5mpmyaZvSCtiyLVes+YPWBCs67 bhinFQ5ko7mJNbVfA5DuTmFE39PYdt02PlqymqFfvsvVF4wDcLw1I8/Y5Bm03NF0XY/e4hFp5c4j D1Cis4oOZB/47LNscR5RN8Mw8Hg8MZ1VlCN6cUiDmdiXy2cvozi3aEd5YHSyvzxginTyue1tI8+6 newv2lYg0sjllbfFuePZ3z5YymWVb6PZ2/vI298kLcuFywWVSz9j53fOoLcrnPeGT8ojZcnEbYaA DG5+6U3G+6s54A1PLht0HSL5Y1r4XC4sMxS1Z5vtr3en9J5JuCwLTdfZ/NpGVi4+jx/dMy4sUjUI eOsIXf8n3rwlSNXeGkIdbn+Dr//6Ii9dfyqXF+U3lV1z0UD4lq4ZDGK63dBG+w8YO5Vh+Gnwhzjl 5h9y8QufscejR9rNy3uvvoPr3Ad46NqhNDSewd8eWM8P/7CYL2/6FqdnaHj6XcvvHtDx+wIYvccy /Za3eeDTNAiFCMn23/8Jj/2lPFyHLA2PsH/K6fx1yYtkmA00NJrc/T//w+t3/o7V3+ymuEeB6v8n fP9X4/8xZH9ZBwmBKRrWvlTAvi42WQEbYybaIVQ1rfVLBzrC8xpPzGpxvuV4J8Hq5JVNJFztItbu jdXFhSE6lTwbtSyL+s8/Y7gWoufBOvjkM8jrAhnp4VwafFB9gJ6H6iiyTPas/AzruzdGLxSRpzzL q9/1X4afAp0y09E2r0TL7oqekgmAGWwA7wE6ZaYz/BRYu/N9TPPWmIYRF6DokF/v+YqcITlk5KSy uvIrctI6k+LxANAYDFDnqyc9J41OQ7P5Zt/XjJE6rP32hii3GNTsa58gdjYqdxL7TNo+WxXtKuLk POT2EgOgQMzsnQYUOV+5bUS4nI/owHL5RcdOZH85X3nw0zQtZkCW2yGR/eV2E3mItpZn1fGw21/+ sZDrIZfR3uZHx/4WaDrhoP/y2abv0GtQFpa1l/++sjWS1h+xSx2vTv0pn59xF5Mu7Y9mmGi6jmVF 2tcMC00Q10oDq16ez1+WfgVAwaU/5Gc3n0N6KASNm/nL1Kfo8u1L2PvPxXzJGB5/ahw5wv4EqK7y RQf+uoYGdC1I1YEDpEr23/7vX/L4l4P57aQS0q1DvDfnt3w95HqKapeycNkOoBt3zJhK9/WLmbVo BQDn3vwAd146KGz/g1t55al5vPHVfgAyTx/DlLu/Q99MnU1vPMnLuo5e9gT/r+wgp970ED+6rAeW ppMV3MVHrz7LX/+1EchkzD2/4Dsj3bz6yG/4ou/t/M9NZ+HWNCDEZ8/PYHHN5fzqR+fhsdn/UHUl DeIHvn4PtbpOhjt8m1Xz7eHTKp3Rt/fhwIE6dJeLlMKR6PoHbNjh5dQB6WDUsK9B/GB72bljL/r+ Qzb7H+Rfjz7J/t7XMPGcb/jrciviKQdT0wjW7aPaDLen30pnoK4TDDYXS6r/n4j9X43/x4r9CWsf F85eVlmQtiRgZfEre1xjiixtO6V3qnC7PbEdvWygNUI2ngdWfCfjWU1m2yVc8/YZV7TjbtjMUIKk 7tgGhgHeWsjMCZ/9UD3U1JK6bw9DLYNdmzdFbwGIGaA8W7IsC6NhM70KITXNj5sDELIg6AfAZXjB qoY0P70KoWLv5pjbMUCzzlLt20XPEV0IZVg06A1gmqQEwzc2G0ONNOg+rHSTnoXdOLB3d7Qs8u0I UXf7bR95Ib9oD3l2J5fL3jFFWZ1mrGLfaTA1TTP61KpcDtF+8vnkgUa0h/gWeYjzik4uBmcxmLRk f3lAlQdAkaf9No48MDnZXyDfUpPbWK6j/OMQz/72NhEDtjzIyW0iyn/k7W8Q8On0Kvk2ee/+m9c/ WMs1/UfSsPlTPtR7cff9F/DUnP8SCgYxUzQC1dXsDITt4MZCj3haQ6EQiDpHPBobX/s/5r8V5N7/ /QvDgl8y46G/8NceBfy/i7pjoRPwVbP8xVe4eMJkpvfrQZppEoxjfwsdl0vDCAZxS/bH3INvZx90 y8I0NUxfNatf+xurT72WX878Hsv+8AcW/uoBYAiTZ06nquw3/OPFMi46fwoDUvew6Ge/4wNrBD// 398wwLOJp375Bx6ZcogZT95O34vGcvara9l4/jh+ckV/UnK7YZpBPJk6la8/xdP5F/Pzmd9l/cLf 8a/5bzP6L99nxIhO/OeVV6i4fBhFnXSo/YLnyncxctJwPKEQoWb2D7J77VfsqNzF8sX/Ydfpt/CX ywswDwZo2LOe/S4XxWkujFAIQiFI7cJAXWfj7gNY/XtjGAYHd6xj/Z4DbP1sCe+s68XPHr+OFCNA KGL/TUvn8u8DnXhw4Z3kvjUVXdcImiYewAoFkB9pWfvaQra5XEwYkR8dM1X/P5H7vxr/jxX707Rs QF4qIDyuRL5127aTgBXf8YSo0/KBwyZYZQ7HmldIvEzA7mWN93FK6yRQE4WB5HmF2JmLuKjSUlx0 ys2FtHTI6wRZOZCRCboOLj38ret0bvCRluKOXqjyrQB5TUtKmht3Xg56bh/o1AXSssEd8eQaGqRq 6LqJuy5ISq272cxS7oyWZZGa7iEvK4uc9Axy0tLJ0NNId4UfhvGbLlwhDctlkpsdJJTWGO2s8iwS mgYAGfnpR7EYXpxXvrUjv1JEdBbxmhJ5BiqQBwERJ75Fp5f3xXnt/04SCoWiA5s8kMnlEIOEPHDJ EwJ5EHSyv1iHJQ9gov11XY/W0ePxxLx+Jp79xYAoyhwMBqODiihjMBiMllP2XtjtL8ot/wCIbVEG cYzL5YoZTI+K/XWdjN7DuPbbK/nmP/9lxy0jqP/wdVyn38uZ+QfC9tA1gkEDXXeRpYm6hj2tWqTe hEw0lwvLNKBxC/9Zthv9tFsopI56PY/eLherP1/DwQu6kolGQNc5/77HuXdUHgHD4NDBBow49rc0 DV2LtUW4gXR0LQUrktYIuNDPmsDCX1yK4Q2Qfm1/Pn6hO4899xO6Nngxx43jhS8+AAu861ayQtf5 zq/vZ3hXg0ZtBD996BbGT/snH6y7muuH9eW0Xi72dh9IYWEBoUADgZBFo+bCNeC7zH9sLCkHA3S9 8HRe376BGl+QYZd8D1fZHMpXbuP0i/uw8b3/jwZ9JFcNz8BoCDrY32DPxlV8uv0Ae3QdV+0uvtlQ y4BuHnC50XUdf2MACN+1sYI+0HXqvL5of2ioWs+HFTuoWx9A131s+WYLfYfm43K5COxazh+WbObK qfMZ4tvH5oAfl27hNgzMmP4fYv2y+fxl2W4uue9xLu2iUeMPqf5/MvT/CGr8P7r2p/myAWguYu1e V7tQTeRtjRZZinfywNq3O4z2itdEIjXZ+HheWSfvK1J4dFmAlMbJS6v7fD7cbnf0IhUXnVjwnTFk MLXbdtIlLwfyu0C3HpDbGTQNauugsgrSqqitqyetR6/ohScuavmicrlcpOUOocbayymZ3SAzDzJy IaVzuJSNteDxQKiRWr2A9LzeMZ5cWWiLWXN+pz5Y3kNkutLo7EmnsyeXbD38BLbX9HKgsZagYaAf 1OmZ3QcgZsAReYsyinoD0cFBngHKt5RE5xAdUTw1KTq6QLxH1+PxEAwGYwYPeWCSZ79iYJHfwSsG W7fbHW0Xv98fHcBEHUR55QFQHqhE/cW549lftI08MIq6iXYJBoN4PB78fn900BQDmdOgIrbldpdv jYn6iTBhDyf7y/WU6ySHyV4Ve9oja/8gmqbj8+n0u2AM2uvP8MlHH1H5icZlU08l5CtH1zWMQAAD A1PT0NAIBAJoochdkJARHuwhvGzAsvD7TIKahvbNP5j+UMSTo+tku9xYhoG/MYhf1+ne2WTfgZqY 69/J/iFTQ9Mg2NgYHigi9g9ZGroe8Y6Ewtdk94GnUL1jD7rHQ12gAb3HKWh7tlHn8uCrB13X0ION uLIz0bRserjqqPaCZR2kPpCFruukprrwH6rBhwahemprayPtGETz63QfPRj/jj0c1DRqG3xoWgau Rh/16UP4wVCdv7+2itpz3Sxftpse199B5/oGfJaT/VO4+Ps/4+oUN5p3Lb+bOJM/zc1l5oMlpOrp aJpGSqqO3+8P2z8Qnmz0K8iL9oWeo7/PzDEpaG4/7/7xfuY99Ve6//oXDMk4xJtPlaHrOssW/pqv TD97a2rQtTJ++uAG7p16O30zNDweg3ef+g2vfaXx/V/+hcv7mOyr9av+f1L0fzX+Hyv2p/myAdnr Gm/ZgBCidq+rwGn5QGvXvnaYqG2VeNWcpm4OyVqIs4tVbGEtiVn7mlakcKf1ry4g+rJk0QlkwZha dCa7ausZcEohdMmFPgXQNT8sXvdXgjsN0jPYFdxG+vARzS4aMRCIjp6Rfw57D77GQI+HzAw3pOVC apdwyVwAXnweD3t8kJF/TsyMT3REcVG73W4G5A5h3YEVZIZSyNGy6OLuTJY7DwCP4cIwGgkYPkJV jQzIOzPaSQ3DiLmNJMJEvYGYWaDYlwcJeYCC2DVU9kEEiHbEGE+XNFOUB0nxLeclJgDyk6Ripi4m DKJ9xEAi3/aR6yDyTWR/2X5i4JZn08IuYoAV6RPZX74FJD8JKpdZeArEMWJgsttfHtRE3vLMXGyL 8svHH3n7a1iaC5cRJJAzjMtyXJS//DK4RnFb3xC+jeByaRDJV9NdaJbwmIDmcoEZilxHwiNhonk8 ZLhc5FwwmXk/OrvJgxRqYOfOqrAn1eUi1NCAYaS3aH/QcEVEqibb39Jw6U0/PJbmQmuoJ0QORmMj Gjq6L0QQHQwD07JwuTQs06TRdwiXy8fuA4307xm+hgxfVaRdTUxTR9Nd+A3Z/iHQdTTfQXxGdiSt jssFaBqNBw8yovQ6Fm34N0/N+Yq9ejb3XtKLhqA3jv2D7N+zkwOahubpwZmn6qypDce5eg5iqMvF qq/3MOr8nuHr68AGdrlcnJuXFs2noXovO2vDw+YZoy9F/+jf7NlziEF90zn/jvsYaqZAYwDd7WHX h0/zymf9ue2uK+mdGfaaf/HSH/jXuhx+8uTjnMZe9lQHVf8/afq/Gv+PFfvTtGwAmq9zhVgPrLyE wP4+WPnbaVlAS2IWW7q4aFrrHtrqqGUDyXpV7XHxlgvEW78qxzsJV6flAzo0GVZ85Auq67nnsn/3 TlYFgpzV8xTokg85Ec8rGlgaq6r3UzugL3nnnEMwGIxe6OLCEheby+Uiv++F7P1qPau3bGN4p66k pYbQraZ1Kf6gxerNB6jnNLoXnBdzi8e+nsU0TYb0Hk7lph3s/eoAPc7shtvtiQ42LsOD7tfZ+9UB ugRP4fR+Z0U7puhkoqOIj5gNR40RGejkDifOLd/SEIOIyFvUR55xAs0GQ9EppY4VLZt9gBFlFB3a vi/yBKLiXgwk8q0tES9m2YnsL+pqH2BFW8meCvttGrv9xWAjBhYRJw/68mAkBt949pcHNpfLRSAQ iHo/RLtC7PsPZU/EkbW/AbqOjwDBgzrnXlHIu2U7yLz8YrLqglSbkfYTPyyajq5FfizFj4AlvV1A 19FMC9PVl3HXFvLo63N4PG8CVwzviXmomu17DYaeUYhuRG4PSnUHH+8vfJLy4Ch+eudFpEq2D6Gj 65G2iLF/+GGzUCiEi/D5ZfuHjyMqeqHpxyej3yiG6W+z9OU3KRh/Cd2sfbz9z6Xo+jDO6ZOJ4fOR lqvjKy9n88hSememkeIyI23Q5P0x0dB1CAQbsVI0zD6jOF9/nRVVdehF32eAUU3AchPybeH5PzxN 40V3MeHCPrhcsP3Lr6F7AV1zPNRvfI/XN+noAzujNzbSaHSh9Mp8/rD0VSqG3EVRehVvLHoTPfta vtVTI3jQoHZTBftSetOnezaafx+vPfc6uj6YopL86ngAACAASURBVIEZmI0mXfqdTg/MyLgIOdu6 oH/Tn7OHnkKgzsvBPR/w/Kf16PmX4vvyLd47aIABXQYMoXumrvr/Cd//w6jx/+jbn1iN5LTOFZoE rNi2ayz7coKWlg8IWuOdbTPtEa/JeGETHZPIwxrP6yoLUnnbLlxj9n0+X4wLXu5EoVCI1Mwsulx+ JXs//IB3Nm+ip9tFV3cKaLC/cj97NmygITuLvPMvwp3TiWAwGDOrlTuMaZq4UzrRddA4Krf9mw8/ /oYefero2r0XAPv37Wbv9r0c8p9Kt8HX4EnLjYphuWOLvAKBABmp2Yzqdylf7HyPNR+tw9srQH6+ D4B9lfvYvGsrqcEuDOt3IZmpOdGOI6/lEfmK2yEC++xZzE4bGxtJTU2N3toQHVBsi7YTecjtK3cq 0SHtnVYMlvIMVJShsbER0zSjt6DkGbgs6sWgK8++5YFHDGqiTPHsLwa4qMdNysPuERdtm8j+cllF /UVdRRuL+oo0iewv9gOBQPQYeT2UqIf8o2Wa5lGwvwmaTtfMFEzTT7fR9/GLQVV06tkNb31DuDPq 6ZhmiMbGIGg6uhkK29i0yHC5SHF7wvYPhkjXdVyECAZq6XrtA9ynzefJN/5OxdLID16fy3lgSG/c kbRuXfYs6bgaDtLo1zDs/d9Kx5VpYQSDmJL9NXcuemQ5AQSxNB3NNKK2gAz0DDBDIRoNAytkoevp GI0BGhpy+NGsycz97Rz+9n8rwufKGMmPZ/2AHF8VPsvN8G+X8tqcf/PM4+sY+b0pXDUgJXwOK2xn TdPQ3WnoOnhc4XPWV7opHjeIT17ZxJVXDuVgw0FwWYRMnUONOprpjnhyAmx980XeqpF+Ewou41f3 j8aqrKSRWnreMI1xe37Jq3+cxSuWBYzkF49fS2j/nvCDVge/5IWy16I21bR8vveziXQPHOSQpVG7 vzJGANUZGnqGQeX+GtJcLkJEvFbV5fztaaJ96Jxbp3BFv0zV/0/4/q/G/2PF/sRqJHm5gIhDCtNt 207eV1m7xXs4qy2itM1CtlX/sKXJ0ytnISpvJxKiTh/7Lf+WBKtG7BN1djFLJH7wu++++w9o8r56 PJ5opxGLqdPT00kNNnJo3ToObtpEw759AGR0707WgAFkDhlCwJPCoUOHojMlaJqJic4oPLKpqal4 9Ebq932K98AX+A5uAiA9awDZXUaQnX82IdLw+XyibaMXNzQNCKID5uTkYBBgc9WX7KjZSG19JWDR OSufPl0HU5g3lBQ9nUOHDkXLJfKRO61YqyPSiPqbpklKSkqzGaPoIKKDOw0m9oHLfmvJab2TiJe3 481S5YEhepFpTbdw5NmrfLyIE16ARPYXecrnEQO9PDsXA09L9hfpRJ2ELYVNYrtSy/YX70KUZ9pi YBQ2ldeFHR37u+k1oB8pB/ewdd9BNE862Rkp+OtraLR0XFndKcxPo2rbVuoNNz379yXDX8WWvV40 dw6Fhd3wV25nd10AXDn065ePv3I7lYdCgJtO3XuQ5wpSHzDwpGWRrjewY0cVATLp3797NG3Y/m56 9OtLJl52bKvCkOyfe8pAuqY2sH3rPnyS/bO696VHlp8tG/dg4Ca/bx+yGg+wda8XTdPIyO9DfpqP 7Vv3EdI03Fnd6dsjg8ptW6nxG3gy8+jVoxOhQz6ClotOOR4O7N5FrT9yOzKzKwXZGvUB0Bv3s6/O oke/QtL9VWzd6yUUCpHdsx89sqByy1YO4cIwAmz49x947esLefi3xQTqwuv0XCmd6dOnK9bBveyo 8mEY0GtgIZq3jkMBA82TRbccjb07d3MwKOzvoXf/QozqShpwk5efRfXmzRwyw/bP6dmfXFcDhw76 MXCT060T/sqdVNYFHO2f07M/+ek+dmyrJGhZuLN60K9ndvSaEdfHocot7PU2f++n6v8nWv9X4/+x Yv/i4uLvAesh+spqU/qIpQJmJN6yxdm35fTYwuJ9iLNPom2rFYK0o8WrXag6hdmFqvh2EqxOYS5p 28kDaw87dfny5YvERSVuacgXnXDDZ2Zmkp2dTUZGRsxi7UAgQG1tLcFgMHoBiYtNXPjygC2+09LS yMzMJCMjg5SUlOj5GhoaqK+vj3pc5VsYfr8/5kJNSUmJ3h5JS0sjJycnLIw9HjQt/LCLz+fD6/U2 PYhB06xY3NoQHU/s22e8hhF+WbRY+iB3UrEvvxhadCz7oCYGFVEfuUPKHVPMjMU/k8gDXUpKSrQO onMC0XPIM3vRyeV9cS77jLgl+4sBVp75yoOR/ARtMvYX7SrKLNrc7qFI1v4CeYYtvCuyR+yEtr8n hTSPm5DRiBGyjkH767g97rAHN2g0t7/bg1uzMIIGehL2d9Wv5Q9/e5NTb/o5NxZY+BPaXyclNQ23 SyNkBPAHDEf7p6Sno4UMgoFGLJv9QyakpnrCryxrDGIea/ZX/f/k7v/K/knZv6Sk5DbgG5xFaTyh GiK+aE0kZKG5oIXmItYehn37sIhXm3CF1otXWYwm8r7KwhNo5ml1EqvxhKsOnPrmm28+Iy5asUZG XGwpKSnNFoF7PJ5oJxdPJDY0NEQvKnkWZX9S037xezwe3G53s/fvyUsZ7J1ani3LF7oon+h8okOI 2wniYhYDQ0pKSswMT6ydEWnlGbiYNdpny/bbJvKMV9xaktdPiXzk2bA9TtRTDACWZZGamhqNk9tE HiCBqOAXXgKRJxAd+ET55Q6drP1FPYGYATYQCLTJ/vLAJPZF27XF/uIcphn7rkRxTSj7n1j2NwJe 9leZnFp0CgfrGpT9TzL7q/6v7N8W+48ZM+Z2YsVrPAFrj7d7YnE4viWvqziu1eI1UuekROnh/Ict OS6ex1bsO32guSC1C1P7cgHHbbnjiTUy4kIKBAIxnQFin+KTZ6DyOh0xi7MvOhedQlxswWAwOmMU 37qux9y+EZ1NDChut7vZzFF0OHlAEBe9eBJSngXLnUCe/ZmmGS2zuCUSCoWiYWKmK89kRdnEDFDk a1kWfr8/OiCKcsplFG0vRLtoRzGIyIOSuIUjJg2ic4vyyaJdzIQDgUB0wBKdWnzLM9jW2F/UW3yL tmmL/cW+sG1H2V8+p7zuS9n/xLJ/Wm4BI/p6qNm7j0BQ2f9ks7/q/8r+bbE/TTrIovmaVmhar+q0 /jXRg1yyfpNFpibti23NloY46dtEWz2vrfG6yttO3td4SweSWefqihMnH3dq+fLyBfLtEFn8iQtG XPRiJiYWi4vZjV0gigtLvt0gtkU6w2i+XkUcJ5cj0r4xHUQgr9mRb9XIHUPYUO5Y8uxPnvFB7OtS RCcXgl3M6JzKKRbyi3aSZ5bQ9JSpPAiKzmhZTe8XlF9XIg8aYkASyLPLYDBIampqtKOKPO0eBrs3 QZxf2V/ZX9lf2V/ZX9n/ZLD/ZZdfNoEmz6vsSbV7VuX9ROtfk137KsKQwpy25e+YbStJUXq4/mHL TiLvrIi3C97WLDGwC+MY0fvS4pfCGWtNi8Ll9pE7ugiP1epNyLM4sS8fL+J0PfYfR+QZoOi8Io3Y tp9bzCZFnNy55XPJszv5fJYVux7I3gais8i3h+x1FS9TFmUQndfecUQ5RJxcH7nTiXzt5QWalUHY Q7SXfXAT55dtJbeL3Hb2uiv7K/sLlP2V/eXzyTawo+yv7H882J/YpZdCOApNJDyrlrSfyOkoPpZt Ox7t9qomw5ESr+Dseo63hCBemN1z25K3VgP0cePGUVxc3GEVUSgUCoVCoTicVFdXt/qY1atX8+ST T8o6SF4GAE3CUghYWUOFcBao8cIsWidsOwy95SRJ0dIyAqe0Lan8ZD/gLGKxbSsUCoVCoVCc6Djp IPtSzbbqrWQdkfHiW7oTnxTtFXbJLAdIJt7ucXVqHKf1ss2WCDikV+JVoVAoFArFyYJd/9g1UiI9 JdJDctosHu2NT0hHC7tEhYmnxBOp+XgN7LRkwB5nF7MKhUKhUCgUJzpOOigZ7ZSskG3pO16ZOoy2 iNe2FCDZCsZT9YmWFrRkCOV5VSgUCoVCcbIQTwsl0krYtkkQTpw0JEiXiFYfc6Qf2LLvJ2q8luLs +07ucbXmVaFQKBQKxcmEXfuINw7YH9KCWB1lEV+DOR0n8kYKO64e2LITT4G3xrUcrwGTcXU7CV+F QqFQKBSKE532aiYnR2GiczmlaY8ntkU6UrwmsxTAni6RR9Upb3sa+6Jkp3e/Ks+rQqFQKBSKkwXH 14ZKcXI4tE5/OaWzb7e0xKDdtEfYORUiXmWSOdYel2gmkMxHvW1AoVAoFArFyUZLbxVozQfp24lk 41rSjK3iaAq7RIo/UVhL+06LkhUKhUKhUChOBuJpodboKVoRdsRpUbxqEVqRZzyXs9N+sssJ7PEt zSacXsirUCgUCoVCcaKT7Ouw7BqpJe2VzHYy+3FJVnN2hLBLplAtrYFwajAcwuPNFJJxeysUCoVC oVCc6LRlWUCipQKJdJrTeZMpX7s4nF7JltY3tOSRTdZtLe/H874qFAqFQqFQnAy05HW1p4P4mqs1 us2pHIeFjhKviVR4S2HxRGiiuNZ+FAqFQqFQKE4GOkIvOXll7XHx9uOFJQpvFR35JwUtFTSe2o93 fEue2MMqXt94+13++c4mwGjL4ccxbm6+ZABXXXZxG4832LZqJduDAJ341qghpDWLaySl0wBGDekF Rg1rKtYT9PSgaFghbvwsnTODV7f0YMqs+xmSZt9vb/38rPt4NXVx4xvB04uRZxWya00Fe4MeBhcN I/cI/p3HpqVzeOzVLZx102QmlhR2QI4GNVWV1Nf7MNw59C7shlMzGt4qtlXW407Pp7BXdrN4f00V ++rrMQw3eb0LyW2DLfzeGqqr6/HhIb93L7KP5N+kKBQKxclBW3WSk0i1/wmB03ksW3r7cfHyazNH +6cjmaUF8RrLnr5DxeuX3+xg6/ArSM3RsUJmW7I47tBcOoF6ky+/eYerLmtrLj7KJpzLpIrwXtmu INf1ilxm3pVMGHku5QBFT1C9+n7cFX+laORU4FGqrQfIJci212Yxv7yUO2bcD2n2/XZW0ruam849 l4qEiR6l2vohLxSNZCrwXr3F6OZa7rDRsG058+eXUXz6+PaLV/8axqcXsSgmsJSXKhYwblhuNGTd kpkMLZ0e3S+eVkbZI9chqr1m3liK7imLyWXyghX87w9GNRtEvGue58KiW6mglJX1r3FWNoCfxRPT uXG+nLKIGS8tYtq4YUd9IFIoFIoTiGREqj2t0/HyvtM5jsi/aTnR2mUD7XX3xmuAZEVsa7yxifJu EcsysRobMBt9mI0+fL6GE/oj6mk1NmBZ7RPrOf2atv/2r6+j29vKy8LCFaBfKm4gveAqyl56ibJl V0WFUmpO+NsTZ78lvDVVVFXVAFC1aR3rNlU1RWaP4r/VlVRWVlJdX82yR0sBKJ6xjOr6aiorK6ms /hG5ZHPVsjKee2kZA9KTPHGrMVg6czyaNpzn18ke/nBL5KQmW+MEuHO46okFLFtZwcaNFTw34zag jBsfLsMbSVL1/mNh4Vo0mfc2fs1zk4spn1VK6cz3o9lkDPouz72xgq83bmRF2aMUAbMn3M17Vbbz 7V5OadGtDpODIJwyjblly6j4uoJlz82giAqm31jE67tPtrsbCoVCcVhpiz5KZnmA03GJ0raGVh1/ uP8etjXxiQRqorCWDNOmBjVNE8uysCwLLIshnVM5LS+V03JPsE9eKkM6p0KkrpZlYZrt9DRLXsqy J19jNwBeyl+a1RRRH/kOVrGirIz/fLAFX9InqGH5vAcp0TQ0TaNk/Ew+3u2PxHlZ8J188vPzmPLg ePIHDmXowAXUyMXL7Ua3bt3Izc6lW6eIUMzvHN7v1o1uudmAwa7Pynnjrc+oj2irdYtnUlIynuc/ /piFU0rQNI3hJVNYvqmKVc8/yPDhJZQML2HO0k3Rcxk165j34HiGi7KOncKSVWHFt+75n3PV9EVA BbfeNJKxDy6OCkoAKtew+LGJkfOMZ/GaGsDL4gfHM3bsWOYs3x1N6t+0hPHDS2LCAHAXcsv9P6Dk rGEMGDCMG675VqT9hQF2M/e+qQA8sWAGowcM4ZZZv6cUKJ9+H0sjwnJAyS3cMmYUQwYMYNTVl9El cnRjUBKe/jVM6X0p5RQ52CybcQ8/wsTrShg2ZBglt9zDuEiydTu8DukVCoVC0Ubao5OSDZPjWipL h3Ok7tbFK3yi8Hhu7JaErD28zQ1nWRZmyMID/OWSAjyuE/OVscGQyTVLNhIMRcR6e/ECpZOZzHJm l03nzXXT+EGXD5iwCG6bfDcVs+dHPXO+vRuYtWgRFF/I7x5OJnM/S6bkUTobiifPpexbdTx861TO XQS7rIfpBeREPLWzZy1ixty55GePoEXnacAeEGTbh7NZVFbKfb8H0iB4YCXl5WWUn7sIikspLYKy 8tlcOnA2UMRtpbCorILyqS8zfswD5PrXMCEvfMu+dNoCHj2jkqm3TqW0bDZPrKhkXMFwioFyoPjc cVx1Vv+YcpZNv5WyolJuKy5iUfkibpx0IfXLJ3LGGRmUzVpEWX0J40vuJxc//36slEUVpdz3rV7N qmZUrePtj9azd+sKHp80CyjlpSfGh+cY3r2srAAo5syCyKwjrYCSYigrr2D9Xi9jeuWCUcX7b3/E vuqtvPXUJMqByQvmc5lYEsJu5lxdxGyKea/yZfb9JI8bFzUrSpSaj//B9Mh5z+ufGz+hQqFQKFpL oqUCrRGnIqw161ePyHKCw63GkhWOidK1Rsja49qn+K3wx7LAZ4S9kZbkoYx7mJTmWP9AuG6W1VTf DiF7ODffcQ0Ar725kjVvPQdMZsIN58XeUpbujCc1k/Ku5m+zAYq4644buOLb32FcMcB03tnkj0m6 YGU1D0+cyMRbRrVpqWxqsyKGxV3xtDJ8y1/jnwvmhoOLplFRv5pnFy+gFKDiQ9Z7YdO//xRea1r8 BAse+QFjbnmARXPDyxQmTXuF7NE3c3t4l5vu+zkTx50V2wa3zaVy9WssePLeaJABDLnqNooByifx xiZg95vcOB9Kn5jOKIe1ucaBVVxVWsqESbMibd+dvIymykV8z2RGGyktOgFoymQvi64q5cZbJzE/ svajZzQTL4unXMWkcpi78mVGd3NzIOJMDTqsCKhZ8zyXnDsJgAUrX2B0t+ZpFAqFQtEuEglYe7zT cYnyTfb8h422ite2FioZ93KihmtpxtCSsVqFFbKwzPCnWUE0DcMwWLVqFR988AEff/wxn332GZs3 b47Gt+6PyY4uop5WqIPUqxcGjy6lGCibdC5Fty6iaMYNnNncMdgq/JWbCD82VMGtRfmk5wxkekRM 7a8LSilvo+i0w+PRu+l7xaQBwYiqLb33ewzLBnxNKyY8QN2BfeGdQb2i4X3Pvyqaj0FTeQPB5osm Si88n26AT6qWGyD3PCZPDt9zf+rlJSx+ejZQzE/Hn+VY3rQht0QmKz6+LpsBzOfSgfezxg8EiSxV qKfWL5Sml8otkU1x7rRhzItMeKq3vsfdwNTSIv7v4xrwruXJ2WFZfM/IPDQth/CzXWWcm1fCx9Kq gHVLZpJXdCsVRZN5b5ePH5yllKtCoVB0MImWC7RmSUAy8fZztrWsraK9nte2nDRZj2iyjZVIpLZ7 2YCTeNU0jXXr1vHMM89QV1dHWloaKSkppKamUlNTw3//+1927NiBaZpREXusC9moeO2IZQMA9QHS c0dyV2lT0L1jv0V2sNn9+VaRlj8AkeVzG30xXuT7z5Ldjl4kbYi/ZjebNm1i2+72r68M2N2JgciJ bM9XZaRGyrPhQHQ9b+WaVdF4N02rFVI9DgsbAsHmYZEji+8Ie2PLp5Zy4/Ryih/9NaMjWr1m2yY2 bdpEld/u9kxjyHU3chsAXhqCQHYB54fduHy2OVJK/w4+jNzSP8Phln5u4WguDmfChx9vgfQe3PXE ozwxdy5PPDGXuXNnhD3DwN0z7qJHpF1WLZwYfjDstrlUr36c0b3a/d4zhUKhUDSnpfWprdVXHZEu XlnaxNF8Q01r1HxLSwFammW0iah4penBLU3T2LZtGxUVFdx8881kZGQ0O+7gwYO89957rFmzhp49 e9K1a1eys7Pp1KlTu8ShrutRoaZpWocITQ25nnSceAWCuLnkjslQNhuYzJhhaRhrmuIN2nABZg/n truhbD7cesMPaZw5gQFZB/n87XJ63T6DcUOcD1v77G2MnFQefUXXkVhlOaT0PopZRHn5PUyfV8gd I6p57Nbwu6KmPTCGbDxkR/TtG//4O4MaLuOiUQOSyjt72LeZUXRPdN3oQxNGR2K8PHvdQCZVwKMr qnlgeDUL57/PgAvPpU+nIB88/1jktVnd6eQB6MaEXz/K1PKpTL17Fue9cjs7/jSNMqBoxq8p6Qbg Z+mcOVSfcTGjBnRl/6cv81RkPWvJqH7gzuWW+x+QSmeQ+sZ0ystKuW/aLRS6Ae8qfjYh8p6sRW8w o+sqGhqgYR+U/u73jBtyBN9FplAoFCc2rb0b3VrdJKc7Kq/LOlZer9haoRnPIB3r3jSt8Mdmm927 d3PFFVeQkZERfTJf13UCgQBlZWXU19dz0UUXUVBQQHV1NQ0NDbhcLjp37txmcajrOocOHaKqqoqM jAy6devg263Cu+ywRKJNRNZM9rriQSpW3Axd+1MIeMVK0t6psRdfTqotA7uYEftpjJtXyUun/IQb py9iQmnTU0HP3T4j7vGenN7hjaIc54vefvq45ZCTpsY5NnJM7ijKNi7jZz+8lNn3XMXscAF4tOwF HhgTfn/r5VMWULxoAmWz7qFsVvhdt9FcIq/K8ngiJ4hZh9qLG6fczfQJ8yma9lBEZEaS9QMqiIjT Op6ZNKHpFWUARXdT9sLvo3/40G30A3z9UoChN07nooHhN0KUTnuJBQ8LQRxk7/KpTJgUkwnTnlvA vaOcpgE+UrqH2yHoizSHB3pH48uYPbsp9bem/94hD4VCoVB0IE56qa2666i931WgtSSmtNj73Xbl Lr51Wxrxsf+vrssWrsf5uCIfeV98u6V9t5TW/hHpT1++fPnDxcXiRmZy/G7OQl5LHYk704Ubi7Jx g+mU6obIkoHs7Gx69+4d9YJu2rSJJ554gosvvpjrrrsOj8eDaZpUVlayadMmRowYQWZmZsLXUInl BfJyA9M00XWdyspK1q5dS48ePejcuTM9evRI6pVWsrfWMV7TqAsYlC5ej4GGcSjE2MBKfnH/D1rV XkcDw+/F6zNwu9NJz047ZmZiTnhrajCA9Oxc0poV1E9NjQ93ejbZzSPjUMWcsflMKiuibNfKpj+C cMDwe/F6/fiCQfCkk98t17GtDG8NlV4feLLp1c0u2g28NTV4fUHAQ3Z+N/XvWAqFQnEYqa6ubvUx q1evpqSkZCbwFRACzMi308eQ4g1betN2rBnnY0nfIZoe/ZbD7V5AIV6sON9YLYjTjv756fB1pzSf IXS8hzUOlmlihTQsqc1N02Tw4MFs3LiRyspKsrKy2LFjB9OnT+fHP/4x5513HsFgkO3bt1NbW0th YSFFRUV4vV4yMzMTnk/TNHw+H6mpqRiGQSAQICsrK+rRHTp0KDU1NQwcODApD66u6/j9fjRNw+NJ /MJ7K2RioWG19x2vRxB3Wnab/qL0aJCdm2ihQhq5razImoU/YVIZMHkmVycQriDaKbvFpRLu7Fx6 ZcdL5SY7txtxoxUKhUJxPNLRGkscaxcpHeqxPRyvymppXWpHnyeZp+nahGU2PcgkN7mmaQwePBiP x0N1dTUPP/wwF110EYMGDWLv3r2sXbuWmpoaunXrhtfrJS0tLSpcdV1H0zR0XW+2vWTJEp5//nl0 XefFF1/kxRdfBODZZ5+lW7duLFu2jJ07d+J2u6PHyWUS+YiP1+tlxowZVFZWxoQ3e3jMkh7YOn60 60mMn2CPG3nppTIqHrz6mPY4KxQKheKocdh1ksP54pWhQzmcv3tHSsS2pQxJYZpW+CM9sCXfgs/N zaW8vJyUlBTuuOMOPB4PPp8Pt9tNly5dSElJYcuWLZimSXZ2Ntu3b8eyLHr06IHf7+fQoUN07dqV rVu3ous6CxYs4Kc//SmBQICCggKGDx/ORx99xLvvvsukSZPo3bs3Q4cOBWDXrl243W66du2Ky+WK rocNhUL4/X5OPfVU5s+fTyAQID8/H4Dt27ej6zqdO3cmIyMjWo/wv2pZ4XsAHbXmVXEYSeOsMdfh /GIshUKhUJzkHLE71NL5nDyth2197NH8yyinxk3mjQJHjPCygfCnWWEiT/u/8847XHPNNaSnp9PY 2IjP56Nnz564XC4A/H4/Xq+XBQsWsGXLFt59913Wrl1LVVUVzz33HAsXLmTt2rUsWbKE0aNHc8EF F/DEE0+wdetWOnXqxLPPPsvEiRN59dVX2bdvH1lZWTzzzDNUVFSwdu1aDMPgo48+4pVXXiEnJ4dH HnmEPXv2UFlZySeffMLkyZNpaGjg73//O5s3b6a8vJwtW7bEeG2BaD2Pp2UDCoVCoVAoOoyW3kTg FH5UOBb+77Q1gjVRug5vREt4Xk3nf6YKhUIYhhH1hvr9fubOncuePXvQdR2fz0dlZSUzZ86kpqYG j8dDYWEhhYWFfPjhh2zYsIHLL7+cU089lc8//5x7772XFStWsG7dOm666Sb+9a9/kZ2dHV27euWV V/LnP/+ZPXv24PF42LhxI+Xl5SxYsIDrr7+ezz//nC5dunDppZfyu9/9jptuuomuXbvy8MMPR8/f u3dv+vTpQygUiqlPtJ7K86pQKBQKxYlIazRUa4TsEed4WC4Xr5GcGrFD13NYVuRftrTmgs40Tdxu N6eeeiqGEX4ZfHp6OhdddBE5OTlYlsWqVavYtWsXaWlp3HXXXaSlpVFfX4/f72fp0qX88Ic/xOVy MW/ePMaPH08gEGD+/PlMnDgRr9fL888/FYg6oQAAIABJREFUz5QpU/jnP//JxIkTqays5J133uGP f/wjnTp1YujQofzsZz/jN7/5DT6fj7///e/8+te/5tNPP+XgwYPccMMNvPLKK1iWFT3/gQMHmnld IbLmNfJXuAqFQqFQKI5rEumhljTSURenLXEseF4PN202ghUysQwTy7AcF22Ypsn111/Pnj17aGho IDU1lUsuuYRAIMAXX3zBKaecwvDhw7niiitISUlh7969ZGVl8fTTT1NSUkJxcTHp6enk5ORw9tln s2vXLgYMGMDZZ5/NCy+8wNChQ+natSuFhYV0794dwzC44IILSEtLo7a2FsMwuPjii8nLy+Obb75h 0KBB5ObmsmHDBm666Sa8Xi/du3fnhhtuQNf1qJC2v7LLgnAdDeclEgqFQqFQKI4bjnnx2V6OB8/r UcMKRZ7A1yL/QkXs+1JDoRAFBQWkpaXxzTffkJmZGX0/66BBg8jKyiIUCtG5c2d2795N9+7dsSyL Cy64gHPOOYdQKEReXh533nknjY2NDBo0iNtvv52NGzfy1Vdf8dBDD9G9e3euvfZagsEgffr04fbb b+fAgQN06dKF7t27c/3111NfX8+ZZ57JKaecQigU4tprr6WqqgqXy8WoUaPYt28f+/bto2vXrmRk ZBAKhcL1s6S6mWbE03y0WluhUCgUCoWiZZR4TYB4dVRU4Dm87D8YDNKlSxfy8vKiceJVVMFgEE3T 6NGjRzTONE1KSkowDINQKISmaRQUFES3+/Tpw7PPPst3v/tdevXqRTAYpF+/fpimSTAYpFOnTuTk hP9qKRQK0bVr12jeffr0if7BQVZWFqZpRt9uIK/TjamjJf09rMXx/aosYzdLFn3I8JvHUWh7bWrV qiW8e2g440YXHp2yHSEMfw011Qakp5Gdne3whwiKZDlcbWn4vZCWrQZfhUKhaCMnw7KBtiO/bSDB YtBQKBQViuGHn8zobXnLsqLxIqyxsTEm3rKs6DrUTz/9lP79+3PJJZfQ2NiIZVkYhhFNL+dlz1uk C4VCMQ9k2c/fDMtqqmd73zbgX8VYTWPeGm/78mkLvh2UTriRvcHmUTveLuXGd/Z20Im8LByvoWlj +bhGDt/GzOEa2th5eAHvmnlo2lhW1a5hbMQj3+wzfA471iyMCRs+/jHW1ITXUXttcZqmMWdVjUOZ alj62Hg86Xnk984nPy+HdM9RskMrWfWYhjbz4w7Lz95mw8fPZFWV0aFt6V/3PJqmMXN5VdLl2r18 HiXDNTzppaw89s2iUCgUxyxKvCbAMq3w0oFQ87cNtOYT9sPGj6+qqor+jWxWVhbnnXcegUCgXeds 9UfUswPeNlAPBIJGu/NpNekZFBPnb4DTiilKTfwvY63CC1DGP5dtagpaVcb0CsINEKWeoGsoz1ZX U11dT/3WZRRTxBtbq6mvrqb6nbvpTAAiYbsqyui3aCqTXvw6cnxTXH11NdXV1dxdZP+bK4PlMy/h qqm7eKmiEsuyCPrq2bjyPc7v0oF17hD8LByrUTJvTTRk0G1fU3H74A48R1ObVW5cxrmLpjNy7kd0 XFsavPPMowBMn/MfktWhQU8hDzy6oENqqFAoFCczSrwmwBIezlZ4IzUtdqW0S9c45A8SNOLnIbyu PXv2ZPDgwQSDDq7Dw0xb6toyXpY+Nj7q5Yp6rrzreGz88Ej4eFZ5w2mfH1/SlMa/honDJ0biYPf7 8xgeyWfiwiYvnX/3+0wcHg4vGXcb5eTgJNc8AIF1LJwSOe/YsDeu6uM5aCUz2Sa0tn8NE4ePZelu gzXzxlIyZ1XCGs5+8j+EfXcG5fOehuIih3O7yc7NJTc3m+zunYEu5OblRsLE+oZ+9O6eS69hV1AC HKhrkHLoR+/eIn1u89vX/gp+M72CaW8sYtywbkD4L2EHnDWaYb3SAD8fL3wwaoeSKQvZ5g8fuu75 KUycs5h5E8Ne4Br/OqaUTGTxkqb2fvD5VYjm2f3xQkqE57JkCu/vDmfkX/c8Y8fPYfG8iWhaCR97 /SyXbF8ycR67Ddi0eBITyqD8niI0bSJr/FD54Tz+VL5TVKaFsi5h8cyxERs+xrq4yrEL+d1z6Tag hOsnA+t3EOiQtgS8K3lsVgXTHp0MZRMo35bcRK1w9BjGXDYy3vRKoVAoFEmixGscNMAMmdFPS55L l64RMk28DUEaAkYkDA7U+1m5sZKDvkZ029pZ8encuTNdu3YlNTU1vE4WcLu0pDymbl1Di5Nvaz5y XTvsMcXd5Vw1dRFv7Api+aq5oW96OPiDeUxddA1bgxa+6v9jUDiY/RXl1EU9tkE2VGwgCLB7Cb0v uoeZW31Y9StpmHAuCzf5gd3M6H0RG+58D1/Qx5N3jAPqcZT+qb2pmH4rOy5YQGXl1zxaP52RP3mN 3NMupLh8Oi+sDEvQbf/+E/MrShjVy02Pi3/KQ8UFjlUL1MOM5+ZSVD6JZdsA/0oent+PsofuhAOB NjRWGWtWr2H5whlMAqZcNTgm7rGfz2TmzAeZOW85ftuR/g0VlFPMuAt6Oea8e+k0zp2wgmVb6wn6 tjJ29QT6TlqCAQS9W5g/6Ua2Xb6CyncmkBtsYEv5fG6cXcmCXZV8/cajzLp1JK9t8sPupfQ+dwJj lm0kaNXz3tgtXNR7GtuAYNBL2aJJzNx2OVsrX2Z4NnQ77z52+Sys6hUw/x4Wf+1lwNgHmVEERdPe oLL+9wxNg7rdy1lRGUyyrKWUdbqfysoKJpdN5aW1Trf9AQ5QW+1l2/sLmTob7i69gNQOaEuAdf/6 E+VFc5n+wHRmAA+/sDJu2mYYR35iqlAoFCca6pmBBFgmaCErocS3LIu0FDfb9tWzYU8deVmpeNwu OmWk0K1TOv/5ZAvnDu1Bp8xUQnFuyctrUXVNw9dosKPKy8BenROeN8XtYsPuWjplptIlOw2zPS9p NS0wwTI78A0beYO5G7jqqgksePQBbh4zLBzc91vArVw3IZ1HH7iHSHBcNn1YDsB/5s1gBQdYBAze 78NI/4xZFLFiwmjS3DDk6rEUU+6cSWAXRY+u4OFx4T9VnfDAZKZetRvvs+N4aBpcOmsZD7x2Kc/c OJ/Jb+wiF2DIaErilClwAPKHjWFqKTy5dA3fKvwbFZPvZ3SvDVDRFvEKj959GxUVFUwu28oPhsXe zh52wQWcndcImYXNOm2QROcz+OzV2RQ9uoKSwmwgm7ufeIJJRS+x8Ynrwip82jIeGTcqnNwP9RSx ouxhzsoGet3GNKayuc7Htq9e5f9n7/7jorrvRP+/DszAoDmjQEADsWBQK0kZUkhWk1RbiM3VphWS YtJEzIbNrrDZ3Ij7I15sY78X21hsv9+I39xcsd9E26C7W2kb7GZxcyNktc3qNtB1aJRGjRADNaAQ 56gzOIc53z/OAMMwM4DaRJL38/E4j5k5Pz+fz/mcM+/5zOecA1X8VX4GFmDR6g3krcnlNyc38Q36 gUreeK6IpME03zWPw/+6m7r2D7ADeHWwJDArERJnJpOkqv45E8ef1vIGXnk6H/Aw3wHnw/aKcHJv qh3Io2pPM08XpeFtvdqyBOjipytrKdj2FF4P3FOVx4Z1L9P29ALm2zzs3biGPR/AFP/cly7dzLd/ /CzzbRFXKoQQYgIkeI3E5zP7vRL+bgOx1mhaTnTTcqKHoi9lMP2GWDDgrWNn2P9fp5kSa+HW9GTc 7uA2ntBibFZe+JWTRDWW29IS8VwO/ZdkdJRCz3k3P6prYeOf3wUKV9RfdfhuAz7zTgPXMni1zafG 3ckD//QS65Y5KKlowPvcUmzzH8XdmcU/vbSZZY5kKurbeW55grnIUJX0cm5oRZeAYh545BGSvV6K ip5i5lwVvfsCkIh1HN06vQC2KSM/+y1+YhfMeZGa3cfYwGqOLQnf6haonxk89HQFK+8tZjlOth37 X6j8flzLjlbAPx95lUub88kt+A6rXK+YwaN/2rLCfLLCHK1q+u3kUUbdb7vIyQ9Ou86FS4AtsJBi AQ0vZjk4pgf/SAos0+GS0s0VjTppXB6cxTGNoRhNa2GVPRetchcbH13CmTUMtXKGDw/HkdabkofS FTnMzOOQq5EF6vAYM5lXU5agtdSxCeDF1djLnDgcDqCJn775XZ5bmswdjz7F7MAeH1hJlbOsEEJc U9JtIAJjjG4DCma3gL2H3uOb92Qw7YZYLnq8/O5kD5ZohXc6znFbWgK/PPAHFMUMdONiLUPdAizR ClaLuQuioxTibBaOHO/maMc5VuZ9HkUxiIuJBiDGEkWsNZroKIUYSxQxsRZe/BcnS+/4HDMTpqDr A9ek28C1fEiB3tdB24cqSx9/ltptBbDpXTSgr6OND9UsHn/2RbblwWttw3cBaHS2o3s62PqthTj9 /Vcz7r4fqOXdjxLJyckhx5GOagVbahYFNFHzi1Z0vY/GF58N3+c11o7zpVdp69OBPt7ctQXK5xEP WDKWsS2vibKVG8irLmW+P9jQutpo6wp/OY7HC/GLiyjAiZMKvjHfEvJf4fH9UezivAY5z9RSSS25 q3YGXAh0ip5uDY+moWkanuDfM2o25eWw6d5i6lq6zHG6h5OH93G4A+4pWI1zTQ2t/r7F//JCGRQX kxmmNdBOE6+93oYO9LU2sQlwzFRJu6cAWMOvWs2/6tv+pYYmilk4x2Zm0jm8Du34r6kFysoeJct+ kaNDBWElMRWazl8MsWXbhNMaSejfNFdTlh/xb8+vwVF1COPIEQzD4MiRIzSUw6bNv6IPCykZWWRl BQ7zUQeDVx10t5nvyx4PfALXNAohxKeBBK8RBN5tINQjtizRUbx9/EM+f3M8Pefd7Gr8A6e7NfBf tOW+PEDTkQ9o73bR/qHG4bYz7Hz9GK5Ll2l7v4+j7/fSfNy8ovnUGRf/2XaG//UrJ3/zjSzeeb+X 15vf5x/fPM5lfYD/OHaGht928H63xu9O9PCzpj9wwe3lgXvm4Om/yn50g4/BvUZ3G7ADsVYL+odN ZKbbURQFR1k91fuLiAc+aPo+6XYFRbFT1lTM88XZgMr9z1ZQX+LAGpfOqfwqHPjjnZTltO+vZs3i VPNCHaudHUfdYMti455Ktq90YLUm8L131EjJApp5OMGKoiSw0lnJsU1L/ePjefA7lYCDZ4qGL7g6 XptJ5ktHQ67J7D/pBUsOPzjQwH7nWlIG0zvimq3QwXSoUjPnS6GivR5HfQl/Xzd4JwPzL/A4ux27 3c7XXgy+iMzG8ue72VNpZ0XuYBnFMWfhOk7rkFb0A+orjuPwl/mK4xU4txZhAayxYUrq5YexKgoJ jhIq6k+wNMWCJa2IY3sqWelIQFEUMlccZ49zqxnsW0fmW3UUUJUHy5IVlCXbmV3sYN3CElo8Nu4u qYINi4cu1gtMw0TSGibpQ+UZuuCvoizPNbOxFqqKc0cs8ZXSXdBUxv6OyP+utL5UiDVhMU00sTg5 DqVo57jvVCCEEGKYEvw3+KgZBu+47/8Y5jUq4HPgEBXic1TQ+1BDdMBr8HtLwGdLwPjgYXCe2xob G7+dlzexa3yrtu7kpfabIdrAGgX7n1lA/FTriH6rsdZo9hw8TuasBHyGQdvpj/hCWjw3Tp/C5p81 M39WPN0fubktPZFTZ85zc+INnPzjeR7Jm8dPXj/GF2bfSNvpXrJvuZF3Oz8iJjqKc1o/NyVMYdrU GE6fvUDytCks+sJNbPrnZv5s3gze7fyIe2+/mZ+80cZ/X+4gK/1GoqMDdpES5X9MloISFQPGAIZP N2+DEEJ0lELfRS/3bj6M1wcMKDyR/gHrnn58QuUVno6mubHGBd3kXfegub3EqSNv1q57NNzEoYa6 I7x/mVHr8mj0ea3Eq5Ga53R0LFjw0NfnRY0fud2WmnxyG/4S96uPMpm7J+paH30eHYvFRnz8yGBe 92i4vVbUSOXkaSE/7u/5kbsRh1fDbVUZNXuYfRciNWiaG1VV/e/14W17PHiwYAtz5/9xpfVPLFJZ CiHEn1pvb++Elzly5Aj5+fnfB94BBgCf/zXUoAfMoweM94V474swGEHvjYBxRtCAfzwBn4NfMcYI TqXlNQLDZ2Do4e/z6tUHuPVzCbR/qKHaYsjPTiXGGs0vfnOCZXemMeAzyEpP5N0P+vizeTM4+Psu li+czaGjZ0i98Qb+8EEfGTdN4/ft57hjTjLvvN/Hki/ezIHWLj6XpPLB2Ysszkrhl2+9R/YtNzIn ZRr2qTFc6teZkzKN1BunovvMBygMPZBA9xIVFUtUVByn33uVj3qPmUEsUURF24AwdzEY8Of1GrS8 jmQJ/XQii/nUotGj1dCBa8Ayoybb1DECVzMd5mJmIDJiFZ5W/r6siaoNyyZ14ApgUeNJSkoKGWxZ bOo4gkEv5ziH1wsWNUTgaq4o5L4LMaM/cB18H7Aymy1s4Dr+tP5pRSpLIYQQnxy5lCAMA/D5DFB8 +MI8HlYfMPj8zdPpOe/m/R4N+xQrl/UBluWmcctMO4k32Jh2QwxpySpxsRZW3ft5ElUb9qkx5N+e yumeC8SrsdyaloDNGs1f/rdbSbTHsvbB25kaa6H4K/OYGmth9gw7995+MwDTpsQwNc7KrKSp2KfE EGuNwmeAokThuXSWd3//fW66+VtEWaZw2fMGfzz/O6Yn3M6li3/kxLGXSZ/zEPb4OfgGLpv59F+w ZT6BCzCiQvWQ+HSzZVLvcn/iwdJ1wbaAw65fY5F4TQghxHVKgtcIDJ8PFB9GpAvwDUhNnIoaF4Ma ZyXGGo0CaB4vt6Un4PMZRN2o4DMMohSVAZ+PJbffzIBh8IX0RP94szVUUcz5bkqYOvRZH/Dx9T9L Qx8wMDC4NS3BH0DfYN7dyucDorBY4zjf9x43Jivo3v14L7m59fZH+LDrbdqcm7FaezEGjuK+9FUS Z8QwoMcwoF9isJV+6G4Dn7nIFcxWQTkUBtlUiVyFEEJcv+QbOywDBgwMJfKtsrwDA9xot2GJjkJR wKsPDE8bem8GpQOG2dnXawygoOBTBgNXHwM+g8FVDzCSxzuAJUohWlFGrF9Rorh8+RJtRzYTFxeP 97KL+Y4/wz59HgMDFzEMmJGSQ2zs74m/cRmnjts433cM34CXfk83M2++h7i4+IDHw4JiBHZLEUII IYS4vkjwGpZitkbiixi8GgbEWqKG5gHz2qgoRSFKURjwGZy/2M8FtxfN7eWCx0vPeQ/RUaCgMO2G GG6Kn0Ki3cYNNiuGgRnIMhzMWqIV/vBBHx9dvMwXM24kyn/xlWH4iImJ57LnQ26ZZycmdjZT1RS8 l/vMRBiXQYFp8XMZGLjIzelf5P33DmD4jvBh53tMT8zCNhS8+szrvPx5F0IIIYS4HknwGoExGESG 6fM6NJ//VQGioxU+uniZs+fduNxeTndrXPDofP7m6SSoNmbPUPnC5xJQoqBX6+eDsxf4r/fO4rk8 QFxMNMnxU7gpfgrTpsaa93O1RGEY8H7PBdpO9+FITyDKEoVhKERFWfC4NaaotxATMxX7NH/gGmS4 /VdhdsaX0LT3OdczlfgbMzEG3P6HFBhmtwFpdRVCCCHEdUyC10jMq5nMqHSMmE4BBgyD/3jnDJbo KDJnxZOaeANpSTfQ7x3g/KXLtH/oolfrR1FAjTNbXGfPUMm+JRFd99F93kP3R27e6egFFKwWBa/u Y/oNscyeobJgXjJWfzDr8w3wXtuPcV/6HTNuSsYWl0a/5+yYCdUHFBRFISbmI95pfp5Zs78KUalD j4dF+WwHr1pPDx4sqPHxo+9q8Keid7G39i2yv1VE2qf9mrE/dV51Dx5s12zfaX09eHRQk5JG3YlC 13ro1iwkp8SHPJHqHg1s47krQ2ievj40XcemJoW+68M46VoffTrYLOoV9+2OVA5/UrqHnr5eIM68 08jHdlAGJKGnhdr/4+Vbjy4InXePRo/mwTKuu55caSKuzXHT07KXf7+YTdGitGuXNiE+AXKrrLAm 9oQqRYELbi//+W430VEK06fGYIlWmDY1lpnxU8i8OZ4lt99MwcJ07r39ZmbPVOm76OHX7/yR1w53 8O+//yPvd2tERynMnqkye+YNTJ8ay412G7fOmk7GTDtTYi34fOb2oqNjURSVadN8zLx5Lpe9Gl5d w6tfiDx4NVAUbvn8PGJtBzn17k8Y7OY63LJ8FQGsp4VVihkgDw75W4NvBD9+LZsVlI2Hrzw94+U5 yeZCBXtyMsnJCcRZ82n5uO4g7z5NQckKzlzlsyZG8e+LVTtbA0b2sTW/kIOf1N3x/0R51bsaWZuf jWKNY2vzyH8fWmtWjaiP2ZvHUZ/0NtYqCvaEZJKTk4lTCtl7crjQOvZtxGpPJjU1AWv+ZjoCnpbV 1VhDfraCNa6A5jDl3Lqz1HxIQ5jnGrRuzScuIYHk5GTscQob93WMmeRQ62ytW4/VnkByQgJ2u5XN LaP/mQmkte5EURRqWrVxlcPI7Y8s51Ub6+jRh8t/6+HAbevsW5899KCKUNr2bUWxxpGcnGoek3FW Cmuu/Fxypdyn36Bk5b/jDjHt5L7NKHF2kpOTSbDHXdW5boxEXJPj5vQbBax480zQWI2dhSPP2cND Poc1ja2KwsbDkeuOEB8nCV7DUADD5+86MI57nw74DNQ4K0/cl0nmrHgu6+Y9eA3DYMBn4B3w0e8d QAFUm5WMmXa+/IUUChbOZskXbyYrPYGUxKnYYqKJUhRusFm57XPx5M5NIi7WgnfAhy+gy4LP52XO bas5/9FMzn74ewa8F/H2u8Y16JfP4/roNO5L6Xze8QyKYuDzDQx1HbjaHq8aUNlwArerl97eXupX O8ZcJpy5xcdwPjbvKlM0tq63XmJdfTkn3AaG18Wx5mpmx0VYQG+jUFGoaY38VKVxiZtCHhN7iMZE 1JY4qDt5DdJ5LVit5JGHdXyPHRs33TuVvGeqKIfRT9bq74TVe2jv7qS9vZ2Gv8oexxrtPHjAicsw MIxedhTXU/DCb8xJPY2kL9vALqfLnGZfR/qmg0NLeq1pPFO1I+yatdadOEq2A1rYZwenP1JLr9v8 MXmoKo8N6/ZFfBpXqHVqrTU4VrxG/QkXhmHg7u2kZG6EO0loLTzpKAGg3zsYjUcoh2D9GlDJCZeL Ewe2UbthBdv+o8dME7Dm5YPDT8TVmtm2yTk0LVhX40Yyl62hYo8Tt2FgeN10n2jm7+6eFaEUIria 49VqA2whWtC7eGnZOsrrT2AYBq7OY1TfPxvwsLNQIb+mddQSV+wanSOmTMvDERt8gKh86xXzXO1y tVPlgMr9g+fvn5OrqhQdc/LYPLkLibh+SPAagXkRk38wfONqgZ1qsxBrjQo73WcYDPh86P5g9rI+ gM0azczpccyeoZI5azq3zLQzY3ocUQpc9g4MtbYODzAwcJlTf9hBTGwXlugY+j3nudyvjW/waFy6 eA6fL4ooJcYM0geMobxeLReQnJ6GTY0nPj4e1Wbh8NZVKIVbh1qoWneXkl1ahwdo272W0q117Fyb bf7aL9xIS485Y/dbNbzQ9AEAnrbdFK7aSl1Nqb9FADxdBynN9reole6kx5+Gtr2byfa3Hgy31mjU 5CtsDdHU4+49B5zlbK8OFpX5OVnEW0Dv2Meq7OFWiJqDXYCHur/JpB4oc8SRXbobzdNKaXbpUCuS p20n+avMx3+Ole78omKahh4P66Fx83ALVn5pDV06HN5aSP7GxqEvf0/bbrLzN9M1xr4YzOmKB7eG nFfvOsz6/OH87TzYAfSwtTCbrYd7huZrqVnFqpoW0DuoKfXvp+y1HPbvJzOPNezbvX542skWNvrX XbhxH4FhQ9vrNUP7Z/3ulqF8dR0cHl+68/BgZlmbX0pd3VYURQnZemhLW8DypV9hfojfSV7AkXEL aUkppKWlkRI/jv9dLSksWpSF+XUdz8Iv5cGRDjSg7bWt4NjGg1kqEM+3frANNmynzZ/BtEVLWbok N3SoobWwylFC1Z5dFOAKF7uiJqUwmEwr52C2OhSTt9YUjmzhC7lOnaYXynBU7WB5hpWevj4s8Skk +bsNaK01KPk1AaGjxs6CXDqr9lCVx/C+ilAOo7nAkUyyqpKx6BtUAO+ePjc8efvLDDaKdzT9E/X+ EhpdBhq/+t4GqGjguaIs8696i42kjBwWZSUBYeoJGrtLC9m6bx8bC4frnRbqeEWjrrSQzXV1lCoK 2ZtbwhzrEehuzgFn/3gWHVBT5pOVEc/JujWU1ENTmQNFKaXVAx37hs9HSnYpB7vMGm+e+/ZSt7HQ f+7bTNvgOWSC5whC5Ak8HKwp9W83nyfLmkgMUf2HztVqAtOA2OnJQ+MseHirZjNNH7iHy3jv3qHz xtrdh2ndu9GfnkL2DbXMB2xbyWZnwPlEiKslwWtExlC/1/F2HxgY8IUINsdYxh/MevUBLnsH8OoD 6P6W1tBdFKK44Hqf90/+mNjYi+gDXjweF/392rgGt+c8U6ZOIzbmv2h9+x/wXr4EKAz1H7hKduDF 7/8DGzduZP36Gk56YMGT/xcV9WtI37CPrrbdOFZup+q7hdgAr3aK7WtWcPqeHXR3H6PKtYHcv30V HTjf1cihbvPrzevVqK9dw8aOr9Le/XOy1Q4qUhczZeMJDKOXtR+W8Fe724AOagrWsbC+HcNw8+MH 5/pTFseXv9NA3qzRTaoZX3+GyrxaFqZaKd261/9lALo1ldW1nWYLWDWUPfUrNGx8fX0DDqCi4Rhv /uhBVLwcdx4f+iL2XnLRVOsKk+4uKlMXc/yJA7i9bl78iyIICGSS7nqKTreB0XsItpdRd0zj1i8t o2nDWv6jD0Dn9e+vhKVfJmWMfeGimEPH9pPnXMeTNS1AYN472JC6kENL9+MyvLQfKKRkcTp7O+L5 Un4iaypeM4MYvY3ny2r50t2z2fcP6ZRN2YjXMHCuPcXCv/oZnqE8lrHu379AZ+8xKhO3sHBOLtO+ c4LO5h3Ub1jHEW2wfjSxcks3OzrjF9OHAAAgAElEQVS7OdZQxaaVubx60gNde0ldXMbGdjeGq5lL JQvZedID3kucatrOio1naG7v5K9vjQ+TWy/9IcZaY+041+WiKNms33kwYgtmSF2NPFzWRMUz30AF vC4XOBKHt3qpH+jkfGAUpocKSzV2rsrFVd3MM0U5uCB8C7TnJFvXlrIqXyF3XSLNrww/tnjml/+O 7+TNGmOdbv74If58x5GckIBVKeVglxmWxs28m4bvfHmoNrTWrKLkXDX/+kwhyecg5OUQQeUwmh2c 5+n19HFw5w/ZBBTcMwdvP+RV7aDCUc/L+zsAjX8u2EJVQznFuELk/TgNTVBddE/osglXTwDtw3rW LFvGtKdP0OncRf2GdRzVQh2vcO7Detat2MiXm0/w5l/fGuZYj8CSwTMNldSWLcSaXcreFjPYzShc T6UDHBUNdLt+RKYNrKl3UdvpwjC6qU7cznd/dQwYPPcVUD/tabq7nZTXr2PP0T5g4ucIQuSpq7GS xWUfsr/ThfvNapaOo/HWPIYC+sHgpauxlm5/a7z2YT1rCp5l3o86OdFQyZaVC3G8PI0T3e3sKK5n 3c+PmrtpXwWLyxI54TVwOddSsvBvadODtybElZELtiIJaOmMdLeBj9vAgBd7/FxuX/gTOk6+TH// f3GDPXHcaVOA3rMuzvdOJ+VzXyYq2mLeFsww/Pd5vXqOO+/hK19I4OLlqSRYAEsGz/Ue4GjCYlI3 QeX+Tpam+KtfvwtH1SGeLcoBoOSZctYt60J7BSAxYK39QCVvPFdEEqB37GcLkPfaC6w/FMfReqjP PQ+kc89qWFGwnJt3PE9Zcb5/eQvz85eGTrAtg2cbXdxf97/JXVHA9jWrae6tIScliy+4D7O7po6T p8zk6IA6I5nZwMzkVPMijeB/I0cEJUHp7jrIJhwcKlmEzQLzv1ZIHk2DCSHrrnkc/tfd1LV/gB3A q6PmfINKytje0MGib7xPQS00dC8Yx57oxDonn9r6clILctm7tBO73Zyid/zWTMdf56MC6qIStjnW sOc3J3jlkWdgzTLe7HucBb/7KbVUsTWzl0qzwNmw/hDuo/VQfzduwDKYx5pHSQLuX+qgbukOns7P AM8l8gL2owsHh+qfJUcFUoqpYB3vnXdz8ndmGbxWU8khzlELzDvrhlSzNX//G8+RkzSOLAfJeqIO 95/r9B5/nWLHYp6MOcErj2aMa1mtrQ575gpW73Ly3NKAnwpTYiZ88mypWUVJfQEHqmfR1fofnKOJ tqNdOHJSRq/LlkpB6VMs6PoqN7KCkg11/Pr5IlQgaf4i8sdcpz+8LNhG96ulJNHH7lUJLH7pLzCe XYAlKYul/pX0tdTgKKun+sD/jdZ1jNNO+KDtOJojh8Hru8KWwwgqsI70uHWQt5o9zZ0UpVlowQXT HDyyrgDHi0187+4E1lFB5z2zeTLUaryECmmHnHwrTD3JsMApKG/o5On8FPCcH6p3tuDjFS+cgor9 b/DoYKVSQx/rkfZzxtJncXfez9Z1JRTkprJ6RzM1j89lViIkzkwmyf/Aj5Ssu3Af/ldq6to5BdDv D0P7XVDewCtP5wMe5jvgvBX0rrcnfI4AS1CedA7/ahOOqkPkp6hAFssfzmPX+QgZGo9TUHHgDR7P SQLtPhw0sf2fnibDBpfuzAOPFfDw9i+3AHm8tGE9nHsNcHLe/QphfvkIMSESvEbi8w/X4W1PfQNe 1PhbiI1NQ+v7P1hjYvCN8y9/JcpHd9dZHAt2Mz1+lnk17+DdBq4BF7As7+ssygr6f0r3Dn0pJU8f bgH0AtimjPwcjmPaUAuU7v8VX/jwKvKmg7eoiB/MnAvYKKpx43zgn9i87l6SSypo9z5H2pi1XSWn 6BmM3i+zKmEhrxxej/XMd3CUaOw6sJH7bzrDhsZ+86AJ+QUb8Bep1wOB1yYHptt9AUgM3eqmtbDK notWuYuNjy7hzJrBuDiFR3cVM6eqhmUfHIWCXXxlnIGc1w0pyyvZUbyFgpJ1FJxTqQB0/fLodCSC dtkLSV9hRwFs+9le3m3YxOr6duJxcwkoKHyAx/KSueQt4i9+MBMVzItZAvJotSUGBPTBezRwm4HT LgHFPPDIIyR7vRQVPcXMoT6aeUwdx7/9sYz+HYHFgs1iISVrOdXVeTj+vzd48dGMMb9Dtbbd2DNX ssPZy+NZw629VrsdDv1xKLCxTokF7EyJ2I9X4702yMtz8d3lSzgHOIGVuf+TLHcNwYcK2Eibn0Xa /CxyU7ZhzXyRo5VFLFDHu84fmf/iF96NWU3iybm3AJ4/TN+zCwhsu/6wrQNHXh6vfvdBXjpnroOV udyV5eLxLDVsOYzWCY5qeo88TfBc5/qtZD1UBiuXsWQZFGw7RorqDR2kqrMpdMCaut/ydE5+iBnC 1RM3/cBNySH2bIjjtR+YPn244Ft3rgp9rI/BlpLDM68cYcmXCsktqWP94xVB/wD0sbMwgRIqOfCD Fdx0xsERz1CycNyUPJTIweWu7BwRnCedC2chcfaUECu5cv3A9Kn+krFazZ8HXsA28mi+DFDwMEWP 3Q2XinjkqSmkR7qOQIgJkG4DEZj9XMff3/XjHBQlmvO973Lq3Rdwu89z/qMP8Xgu4HZrEQeP5wIX Xefo93TwwXs/xzAG/C3Lw3m9Wnagu+dDdI8HTdPQPDrQwfrke0nd5cS5ZzVlud+k0d8Fyhprx/nS q7T16UAfb+7aAuXzRn0B4sX/zWqyZdxJBdD4+4tk5uSQk+NghmoFvY+2tl6ylj7Oj2u3Aa9xxg2g 09XWRpc2+r+rnrYW2roCewBCQryPt56vhfIyHl2UifeP5t9hOkDcNOYC5y9qw2nDybH2PjxdjazK XQd5saHTnZpFAU3U/KIVXe+j8cVnh/qzacd/TS1QVvYoWfaLHB1aN2R84ykKnJtYua6e6g3LzEBR 72JvzVbqWsbq/ary+NZDFDTVUu/UsAK2jAWsponnf2FeWKK1/YqyJnhokfkD4P6/q6K+rIA19cU8 dV8aWObwQDnUN3Zgz8whJyeH9BlqyDxG+gFip4nXXm9DB/pam9gEOGaqZNx9P1DLux8lkpOTQ44j HXXcF3bpoHvoB/ovugn829Pj8X+16100vNQES283A9dIZaefZEPmSqiop2CuhZ6eHnr6zPXMv68M nGW8ftIDaPzi+TKoeHo4ANVBd18E4LLH40+KStHzr9LY2EjjkSMcaa4ljzyaQwau0NfVMxSQOFta CAyOta42f12NtE6VpeWrca552d8Xt49Dr9aT92Qe8YCuddHa1oUOzH/0OY40NtLYeIQjRw6zzQFV zW4ez1IjlkNosaEDPo8X4r/CtjxwOqHswfnmuJDiKdhYDpvuZX1di78cdPpOHmbf4Y5x1JMQ/00H H6+j5tXCH+vhkqn3cPhwG+bpZHA907FjJTEVms5f9Of9A16th/KyJ1g0384fjzo5F/kn+hWfI0bm ycbnv5RH05qXae3zoJ1s5H+E6fN67dm4+4FyqG/gon0uOTk5ZKbPGHUtpRBXSoLXScowfFitcXzh js0kp/4PLrimc8HVQ7/nIv3uC3iChn73RfrdF9E+6uWjj6YRG5dvPhXMd+07IanAhnvTscbFYbfb sX/tJX65Pp1Nq/fw40ezyCqqpr78HPcmbwy4iKiZhxOsKEoCK52VHNtk/r1vjQ1YsRUYcUFOGhva 9zNjzWKsioKiWPnmjqOgf8D3M1NRFIU4RxnF1S+QqwK4qc3M5KWjo3uynfn3SjJT7ebFBQkLcVXs 4akFs1laVQlblqEoVl5om43DuYaSmlawpFFcVcCGxakohTvR1LmUlzsocSQQl7qVu6tXh0+3LYuN eyrZvtKB1ZrA994ZbilSHQVU5cGyZAVlyXZmFztYt7DEvP2RuoCnKx1AJUU5/tBeP8OWsjVsfOP0 2DsmfgEv7q8MGJHBj47toXOlA0VRsGeupGKPk0czzG+3pLuWUw7kVT3lD7AsLN3Uzja1jFSrebGG /Zu7zVbXoDxaIeKXZPPLD2NVFBIcJVTUnzC7kKQsp31/NWsWm/tOsdrZcdS8QZF9jKxprS+hWJNZ 48TcJ4q/zND4ydfi/OtLZd3sKo799YKxy8593vx7d1MBCf5bISV/8ydmH8iUpZyor6BgThyKYmfl 8UpObBhuIWx9qRBrwmKaaGJxchxK0c7RfSd1r5mrkDGMRn1xMnH+C3JyV25n24EXh4Lc47WZZL50 dPRiQetMW/4j9pQ3khmnoCgJlFBN7RNZZvaO1+LIrA3Rp9Nc2Gb1jl0Oo9ghMXbU2OGAxcZDLx6g fr+TJUmhpg9LW/5DnHsq2bQi118OVhLmLOTfTusR60lsYoiVwejjddS8avhjfdR5x08/zaaFmdit Zvpyy1zscf4V8di4u6QKNiw2bwXmnUtZZQFblqWiKMtom12Mc91Calq1kec3zH8OzKK6snNEcP6z Hq2mMm8LjoQ47HO+hzqOPq+j9+DI9YYqY2vQK0DK0k0cqJ7B4lTz+LPaSzga6n5jQlwBZax+koqi BP5proR5jQr4HDhEhfgcFfQ+1BAd8Br83hLw2RIwPngYnOe2xsbGb+flTew2I1Vbd/D/HlLx+Qaw RkPTpsXE3xDDwDhum/XxUYiKthITa+dAw6NoH9UTFRXHlKkJKFHR5r2+UECJwnv5IgY6l90KjoU7 SU1bwsCAB59+gY8uesmrOIB3AKKiovnvCzXWPV3yseWiZWs+JVRz5OlM+vrcqPETvbG7jqa5wRqH GnATc4+m4Q0aF3EtHg1N80DQzcZ1j4YbFdUGuqahx6lDN8H3eDxgGb4pvkfTIGB6RB6NPq81xI3N zfyoqup/r6OqNqCPmvwEGv7yGK8+On9o7n1rFf7tG908n38FHUIDtmcdb7rxly1Wf7omuDVdx2Kx 4NH68FrjR9+AX/egub0TSs8YiaVHM/dTUvzIv5Svpux0rY8+D8QnhX5IwdXR0fr68Ohgi0/iCp8t AAw+eMNGUtIk7Gyoa2ZLr8X/4JAR0yZeT4KP11Gbi3Csh1kCrU/zP8AhKH0eDx4sQw9W8GgaqCo2 QNM04tRxnOcmfI4In0ar+jE+eCVw6x4Nt5fx5VeM0NvbO+Fljhw5Qn5+/veBdzAfsOnzv4Ya9IB5 9IDxvhDvfREGI+i9ETDOCBpguJOiEeYVY4zgVOpSJMbg3Qaurwu2hhn4Bry4L54FYKp6H/E35tLZ /hPgLN7LYLFEoSg+Yqd+EavlBrSP/hNFAa/3AgO6m+goxcyTP598EvnznMPZfwmwEB9/JV+wFv9J fCSb/4ti3GuxqcTbRq/HYlOH+kdagk7ANtvILdhCpCMsm0rouzYF5scy9FQkT9vPKGtycKh+OHBF P0nHTbsov/tKA9fg7Y3PRMt2xNYsFv864kOvw2K7oqA4LJtKUoj9erVlZ1Hj+dPFgxbU+KRrcm2L mnRt1vOJsKjhg+4rqCfBx+voVYY/1sMsgRofH7p8bbYR9Tvw3DDu422C54hIafykWGzqVT0hTohQ JHid5Ab7qd6x6HkslilEW6ZwprORS5qH2+/awgfv7eH99/6Zr9y1jhkpX+JsdzNxU27EN3D5k076 kJy/PYxLl6o4FtucP8fleoIR33uWDEqfGd+V8yKIlJ0QQkxKEjFENNzKHWuNwmaNQr+uug2YFH9P DIPLRCvg+OLfYJsyg6Sb7iYl5XaSk28nJeV2DC5w001Z+Hw6hjEARGGJUoi1RhGi1f7jY7Fd1d+i nxkWGxNsIBVCCCE+dSRkGAfDgOYTfdjjrAxcV90GQjAMoi1/huHx8YeeEyhRFqKnFPOf7/aGDEuj FQWX2/uJ9BYQQgghhJgoCV7HoAADPoPH/5+3r7P+rhOhEKlFVVEUpsRGo1yPN7QVQgghhAggwWsk ShQoZteBKbbPwl3FzDsTCCGEEEJcryR4DcM74MMwBvD5vHwi/UA/EQpRipl3IYQQQojrkQSvYfy3 RbczfYqTy5evn6vyPw4xMTEsyL39k06GEEIIIURIEryGcecdudx5R+4nnYzJq7nZHLZvNz+vXg25 ueYwITrU/QzufBDSJsHNArWT8L9fgpPA+g2TI80fm+t4X+pdUPsWfKuIsDewbW2BuTnhp3+Wjaf8 PinXc9qutbY2mD9/7PmEmOSkg6O49pqb6bvjDvpKS+lrbjaH0lL67rjDDGhH0KBQASXUkA+aG1as hDOhniuomfMd7vs4chVay2ZQNg9/3jAHdgFfzYFzb5rpC/0szc+gSPvyE+Y+DSUrwj/H/uRucDz/ 6fq5H1x3r8ZY5Xe16fEcvvJj6Vqk7WNxDc5nrz8Jmw9fuyQJcZ36NJ2KxfXAH7jG19QA0FdaCjD8 +Y47iH/77YAWWBVe6TUfTGdxwZfS4fkTcGeCOU7FfK64NS7ExlQ45oQZH+PNT9t2Quar4H7VbMWZ WwzOwW9FDzQCOzZAjs383OyEUEmf6HYmi52F8NNCaHw89PSw+/ITFjcFCPMIab0D5qyEZten64w5 ou5epUjlN16B6dHbwJoJTjdk2cB2KzQfu7JjyWq9+rQFGquOX7FrcD578sdgnQPLXJAlN4UWn17S 8iqurcCW1dWria+pMQPX1atDzwOgxkN8PKgJ5ufpycPjBn3w5nAL7cZ9/pEeqNkMH/hb8vZuHm61 rWkJnT69C9YXjp7vYM3wuJ2DLRcalBZCXZ05/ge/gMwSoB7iFNjZCt1vwgu/MWffuQacQMkCyM6G 7K9B5atmEA5weHdAq/IqsxWpYx9kB7Q0H+wyv7iDtxM2jePIn94Bq7IDxh0cmb99+0aXracN8tdC Y0Ca954cLved64fHr90JHszWyZJ6aCoBJRtaQzSTJQLv/ctwntfXDZfPePLXthNW7Rz+vLMUavzl 07Z3eL2FAfN0HRweXxpmfFExYA+9zeafAlWQo5pltip/OG+eVsguNfdlpDLztEF+KdRtNce39Jn7 pdS/X7LXQo8efh8CdB2G/MC60jGcxsbBssuGwnwo3e0vk92wqgbqNvqnF8JJf9oD6+7uteay2dmQ nw/ZAXkMt1/GW354YPfG4XUU7mTUsbW5JSA9HvibTHNRR5yZF08n/H3NcF3pOgyFAXW6VYtQzyPx QE3pcNkd7jFHb10FhVuHt7e7FErrQtfxcPsxUtmHrKtB57Nw+ztSPbNkQP1qePbfxpF3ISYxwzAi Dpg3CR0covxDtH+w+IcY/xCL2U4UB0wBbsBsO7MD04B4zK+vG4FkYCaQAtwMfA5IB24B5gKfB24F soBsIAe4E7gLuAdYDOQDXwWWAvcDy4EHgCLgIeAR4HuNjY2G+Jjk5hq9YPSCYdTUDI+vqRken5sb ZmGXYTgwjObekeMKMAwwjP0nDMO5yzBwGIYreP52c576dsMw3IbR7Qqxfq9hlGMYlBtGe69huLrN +TrrzWXb3Ybhajbfn3AHbNthGM0nDMPlNoz9lebnY92G4fYaRnO1YVBtrt59wly24Zhh9PYaxokG wyDPTOvgNnYcMgy32zA6Ow3DaxhGp9MwnJ3m8tV5huHYZr4P3k7YNI4jf95OwzjgNGc5VG0YFBiG e4yyHdwGxYZxotsw9qw2DKrMdTSUm/lqdxmGu90w8jCM1fVmuVc6DINKw+juNfMXvH8LMLff3G4Y xxrMbew5Mc78GSPLe7DMqpqH817eYI7vHqxDg/XihGEYveb2dx0zDKPTHF99wDC8bsOorxzeV8Gq Hf5t+PMQWEfdzcPLRSqzwWmOCsNo7zT3aTmGUV5vTt9RYBgFu8Lvw8F8VO035zlQ7S+vgLqxv90w vL2GUZVnGA5/GTm3mdMKqg2ju9MwVmMYlYdGl6Wr1zA6uw3D5Z+HPMPojlTvJlB+DeXmvIfaDcPt Moz2biPksRWYnvaG4WPJ5R5ZzoNlsXqHOa270zBc3vD1fMSyodJWYdZV5w5z33kNw/D6j+WKBsM4 tst83+k1RtfxcPsxUtmHq6shzmeh9nekemYYhuGsHvlZTFrnzp2b8NDY2GgA3/PHPw/546EH/PHR /f546av++GmxP566yx9f5fjjrSx//PV5fzx2iz8++5w/Xkvxx2/J/ngu0R/fTfPHe6o//pvijwdt /vhwMFYcjB0HY8nB2HIo3jTGiE0/TX+CiU+rU0BDJ+SngOc85nESbAasBgqWw47noTh/9Cx6B2wB 9pRDmr9VVwXqmsz3NZXAOfP9WTdkWMxt738DcpLM8UnJ5vbTk8zD0Rqwfluy+bd4cirEqxCXPDzt rdeA1fD4AvNzSor/NQvch6GmztzWYNaCt/NWuDQG9CkIlz9U+IIbdtZA9ylzvBdzveHKdjBfna+Y p6lLtw1uBH65BaoOQZpqrru6Ghx7oHo5JM8GRzIkBbSaBzoFHHrF34qZBuXAe2eBceQvMF2jWODO 1bByGSTsgLJvmaM7fmu+vvYCHIqDeiD3PHS9CzigZJF5Cv1a4XAaRglV30IIW2YB0954DpIA/aS5 r/Jeg/WH4Gg91N8dfh92/JuZ3r/21+tFJeBYA785ATGvAVWQn2ZOW/4wrOv3b7AfqIBXnzY/3pYH HuvINIH5T4cK1K2F7cCxekiyhD824t5mfOXnMevL6j2wwJ++NH8LdvCxFZieGf5jJzkVVJvZsj/o pH+fri8G1QKq/1giJXQ9D1tn/GkjDzash3OvAU5wvwJqBvQegITFsAnY3wkp/u/bwDoebj9GLPsw dTVQx28Ju78f9M8Tqp4BeD3APtCe8R//Qnz6SLcBcW35uwcMdRXYvt0c/F0IAueZkOSxzsI2qHFD w1p4/l6wrh/+y2+Ivz9dTPD4S0AxPPIIFJWa/VRvDdje9MAAqn/EqkIbtWG/KaNH7VwFczbBrXmQ txDOBQYdgdsZI42BMwfnr7UGEubADbfCknsA18jpYcs2L8SXn24mxRYYEcQydCVNvyt4gdGmhIom xpM/P0fs8HvPueH3j9aAswHefR6S46BDH94VD6+CoiKzy8oTt4L7ApAYIbAJELiNIYO/+4MrQqgy C5g2VJX8yxU+AI8UwYZmOFZM2H2oXx6d3kTgshduCKpX3v6Rnx0zwyVopIObYcUWONQN8wczEWa/ TKT8gBAHnWl6mA7d4+mKG7ztsep5OAUPw2OPQOkOcAb0q9UDEjE9oLPtiDoebj/6hSv7UHU1UKT9 DUSsZ1YbsFQCV/GpJsGruLYCb4W1fbt5l4HS0uFbZgXPM27hAsLByX3Q1gtLH4fabcBrEHxRu2WO 2dL3bA30eUDXoEeDu+8HauGjRMjJAUd60BdjwLan3AicA49/3Hivd7n7fmAL1Pn7Z/Z0mdt/vhbK y2BRJvzxaPjtjJnGCPlrbgAqoGgReEMFYmOU7Qg2KFgNa2r88aoGL5RBcbEZmKXMBef58IsnAq++ br7XWs1WK8es8eUPzPJ2/hr6dGjcCuuc/oBQN28TlLUUflxrzntGg4w7zfe/v2iuN8cBqhVSs4Am +EWrWXdefJawfTbvuh92/XrkOGc7eDrgWwvDLxfJ4L5q7IDMHDNtM9Tw+zBjwXB6Adp+ZTZ0LpoL c+8E1sHuRji422yhy4sNKK8waQisu607YfE62OWEBUng8Td1htsv4y4/GzxQDtufhdYeQIeunoDp AXUvMD1x08zXiyH6TQ/u0xf8/cm1HtD0cdTzMGmrbwD7XDN/6TP80zog+V6zPPashtxvwmCyA+t4 uP04mJ+QZR+mro7IY4T9PZbOU1Bw8zjyL8TkJcGruLZyc4l/++3hoNVv8PPIOw2MU6R/bQen6R9A Zqp58YKjDKpfCNHyYIFNJ2D2JkiIA6sd/vE4pCyH/dWw2L+81Q5H3aG3nfEVKHBCstW8UMiK2VVg LIPbWOEwt5H8JLhVqKqELctAsULbbHCuMdcbvJ1IaRwrf3llwCZzuRfawNEEBTvHLttgg/ks+gFU HAe7AoodjlfA1iJz2t0PA+uGL6IJpfllc7rdARX1sDRlnPkDbr0PHLWQYIXvnYHywUS54X9kmsvG OaC4GnLjgTRo3w9rFvsvbrHCjqNgy4I9lbDSAdYEeCdCM9Wdj5n7pc0DqPBsBZQ4IC4d8qvGV2aj WGBTO6hlYPVfdPPN3YTdh2TAsT1mehUFMlfCHqfZrSLjUdi/Daruhe/+FnZVDLfgR6qfgdOaXjVf B9cfFxe53k2k/JZugiqH+Ve7YoXiX5jjg+teYHosaVBVYG438OI7wNynDbBphVl29mQ47o5czyOl rXoGpMb562SJ+aN3fbrZ1eHRLCiqhvJzkLzRXGZEHXeH2Y9EKPtwdTWwTCLs71CGttMBy7ZAxbLI +RZiklMMI/KjTxVFUQI/hnmNCvgcfIFXqAu+At+HGqIZeWFY8EViUQHvo8MMg/Pc1tjY+O28vLxx FYi4Rq7ZQwomSNPMWzHZxujOHWo+3QNuL8SpY98SSfOYffEmanAbasCXvUcDVLMFUdNGbj94O+NN Y3D+dI/5pazazNY8fRxlNBaPBl5riHLwmH0UbSHKR9fBYgm/7Ljyp0Of2+xXPO406eY9g4P3edj5 g7TWgKMNjOeHl+MalCGY+4oQaQhZl/35CC6fwHqyNR9efeza3sop3H4Zb/lNdN6hZTxgsYWpCyHK 4krruUczW0rV8f7XHqKOh9uPEbc51vxh9nc4NfnQ8R14LkSffzHp9Pb2TniZI0eOkJ+f/33gHWAA 8PlfQw16wDx6wHhfiPe+CIMR9N4IGGcEDfjHE/A5+BVjjOBUglchhBiPlsNw64Lr7767+knz3p5D 8swLruZLp8fPnNZWyMr6pFMhrhEJXsOTuw0IIcR45Cz4pFMQmiUD3C7o9bcepqbImf2zSgJX8Rkh pzghhJjsbCqkSEurEOKzQS7YEkIIIYQQk4YEr0IIIYQQYtKQ4FUIIYQQQkwaErwKIYQQQohJQ4JX IYQQQggxaUjwKoQQQgghJilh7iIAAB0KSURBVA0JXkMY68ENYXlaKFQUlDBD/taWa5tQIYQQQojP GAleg+i6zosvvsjx48cnvrBtLhv272f//gPsr9+G+UyvYvbsP8D+hgY23Tf72iXU08oqRUHJr8Fz 7dYqhBBCCHFdk+A1BJfLRV1dHT//+c85f/78BJZUycnPJz9/Eflfu5tUgIJ7+Xr+IvKXLmXB/Hja dq9FyV/L7rqtKIrC1pY+c1z2Wlo1AI26tflkl+5GA/B0sHP9quEW3FU70YDWn2ymFqCpjDillFaJ YIUQQgjxGSDBawTvvvsu27Zt49ChQ+i6PrGFda//TT/egNFe7Sw0bWHlileprN7GFxPj8GqnwHmK S/55zp1qwnlcQwe63qyhZFMtBdUH6O1t58DqXKxA+peX4QBwlNPQ/Azp19vz1oUQQggh/gTk8bBj 8Pl8NDU1ceTIEb72ta8xa9asq1yjBjiob3+d5Wlm8bf6p1j9r7H+VwugJqcBUL/mu1R6/pLSkoew Abb0LByAc3Y2X8nJQGJXIYQQQnwWSMvrOPX29vLTn/6UEydOXIO1zebmhODfDS5/9Kpx+tTwWDWn FNeJ/VSV29mybiWZybns69LB6zW7FQS17AohhBBCfJpJ8DpOCQkJPPbYY8yZM2diC7pgrA4H3n6A Jt74l33UlKaywQnYzWldLfv47aX5/O3zr7Cn3AE46TjnhrgpzAA41cbRjp4xtyGEEEII8WkgwesY oqKiyMvL44knnriyLgOpsUF9M9RRs8zOewgHsG7FMhoydlBZMDzN1fZL7nWkYlXsrNjipKBiDw9l qWCZw19UrwbnFhamL6FZm3jShBBCCCEmG2Wse5oqiqIEfgzzGhXwOXCICvE5Kuh9qCE64DX4vSXg syVgfPAwOM9tjY2N387LyxtXgei6zg9/+EMA5s2bx5IlS5g2bdq4lr0qukaf20q8GqL3qu5Bc3vB GodqswRN0nBjRbVJr1chhBDi06K3t3fCyxw5coT8/PzvA+8AA4DP/xpq0APm0QPG+0K890UYjKD3 RsA4I2jAP56Az8GvGGMEp3LBVgh2u5377ruPuXPnfnwbtajEj26U9U+zoYYKagGLTQ3RliuEEEII 8ekkwWsQi8XCk08+ycgGZyGEEEIIcT2QPq8hSOAqhBBCCHF9kuBVCCGEEEJMGhK8CiGEEEKISUOC VyGEEEIIMWlI8CqEEEIIISYNCV6FEEIIIcSkIcGrEEIIIYSYNCR4FUIIIYQQk4YEr5OWh46TJ+no 8QDQdXgvNTV76fB8wskSQgghhPgTkuA1hDEeqRuZp4VVioIyYshn486DaNcuiaAdIX3OHNK3HQHg zOEtlJVt4Yz3Wm5ECCGEEOL6IsFrEF3XefHFFzl+/PhVrqmYPQcO0LBnG8WOJjaULMa+di96pEU8 rWbgm1/DmA2ocfNwHjqA87F5AFhj7YAd61WmWgghhBDieibBawgul4u6ujp+/vOfc/78+StbScG9 fH3RIpYWlfLKr52sBtjyLG906aC1sbU0398qm83WfScBaP3JZmoBmsqIU0pp9UDHvo0jWnA3720z 169/yD9WPMU//ubDEBv3cLBmPflDy62iVboTCCGEEOJTQILXCN599122bdvGoUOH0PWIbaYh9DP0 D76ayQMVDsDJu2dOU7MqkzXbU9nf3sn+qtmsWfYgjT2Q/uVlOAAc5TQ0P0O6DfSYTPY7O3H1HqMy r4l1BTWc1AEucbTJyaGzl0ZvuutNFpdtoqlgG+2ubpwHniLxiktBCCGEEOL6IcHrGHw+H01NTbz0 0kucPn36CtdiITXNYb69dIKGeoBa3qiv4zcnXYCTt9/rQ03PMoPX2dl8JScDFci4+8tY//Artvyw huZzAKc46x5jc2oyBQD1ZXxnww56km4hxXaFSRdCCCGEuI5I8DpOvb29/PSnP+XEiRPjXCI2oP/p Sf6xrBbI44tpg22gecybN4/s+5+hoaGB5beo4PX6L+ryt9rqJ1kbl8ziFQ3MWvIgD92fBzB2v1Y1 h1ddx9hVVY5zyzruzUxm/b6O8WdWCCGEEOI6JcHrOCUkJPDYY48xZ86c8S1Qf4S3WlppOVjH2vw5 bALyqv4ni2bNIj8P4BwuUlm0aAFzU+PxokPcFGYAnGrjaEcPuvssRwBHRTH3ZU3n5KEmwMVHWuQu DHpXC3t/6+UbzzzPP+8pB+Boh+uK8y6EEEIIcb2Q4HUMUVFR5OXl8cQTTzBr1qwJLLmFe3Md5C5e wZZzBVTXO3n9mUVAEk/XO6kqhjXLHCQkJDDHsZC3znjBMoe/qF4Nzi0sTF9CM/P4y3IHzk0rSE1e g3thMdDE2tpmAFTAHju4PXVoy7q7jYJ7HdgVhcwVW6Cgko0PZV2bAhFCCCGE+AQpY93TVFEUJfBj mNeogM+BQ1SIz1FB70MN0QGvwe8tAZ8tAeODh8F5bmtsbPx2Xl7euApE13V++MMfAjBv3jyWLFnC tGnTxrXsRHk0DS8Qp6pYAtPg0XBjRbXZhuZDVbEBWp+GVVWxWUKtMZCOR3PjxYqqSodXIYQQYjLp 7e2d8DJHjhwhPz//+8A7wADg87+GGvSAefSA8b4Q730RBiPovREwzgga8I8n4HPwK8YYwemYIdBn kd1u57777mPu3Ll/0u3Y/AFpMItNDWhHNecbpMaroxcIyRJ2/UIIIYQQk5UEr0EsFgtPPvkkIxuc hRBCCCHE9UD6vIYggasQQgghxPVJglchhBBCCDFpSPAqhBBCCCEmDQlehRBCCCHEpCHBqxBCCCGE mDQkeBVCCCGEEJOGBK9CCCGEEGLSkOBVCCGEEEJMGhK8CiGEEEKISUOCVyGEEEIIMWlI8CqEEEII ISYNCV6FEEIIIcSkIcGrEEIIIYSYNCR4FUIIIYQQk4YEr0IIIYQQYtKQ4FUIIYQQQkwaErwKIYQQ QohJQ4JXIYQQQggxaUjwKoQQQgghJg0JXoUQQgghxKQhwasQQgghhJg0JHgVQgghhBCThgSvQggh hBBi0pDgVQghhBBCTBoSvAohhBBCiElDglchhBBCCDFpSPAqhBBCCCEmDQlehRBCCCHEpCHBqxBC CCGEmDQkeBVCCCGEEJOGBK9CCCHE/9/e/eQ4klx3AH7VM0vDgAzDR/BC9g3mArpza6kbaGQYhgAB WhqCZmBY8EZT5UVPTke/ehEZSSZZFc3vAwhmRkT+Y42gXz9GJoFlCK8AACxDeAUAYBnCKwAAyxBe AQBYhvAKAMAyhFcAAJYhvAIAsAzhFQCAZQivAAAsQ3gFAGAZwisAAMsQXgEAWIbwCgDAMoRXAACW IbwCALAM4RUAgGUIrwAALEN4BQBgGcIrAADLEF4BAFiG8AoAwDKEVwAAliG8AgCwDOEVAIBlCK8A ACxDeAUAYBnCKwAAyxBeAQBYhvAKAMAyhFcAAJYhvAIAsAzhFQCAZQivAAAsQ3gFAGAZwisAAMsQ XgEAWIbwCgDAMoRXAACWIbwCALAM4RUAgGUIrwAALEN4BQBgGcIrAADLEF4BAFiG8AoAwDKEVwAA liG8AgCwDOEVAIBlCK8AACxDeAUAYBnCKwAAyxBeAQBYhvAKAMAyhFcAAJYhvAIAsAzhFQCAZQiv AAAsQ3gFAGAZwisAAMsQXgEAWIbwCgDAMoRXAACWIbwCALAM4RUAgGUIrwAALEN4BQBgGcIrAADL EF4BAFiG8AoAwDKEVwAAliG8AgCwDOEVAIBlCK8AACxDeAUAYBnCKwAAyxBeAQBYhvAKAMAyhFcA AJYhvAIAsAzhFQCAZQivAAAsQ3gFAGAZwisAAMsQXgEAWIbwCgDAMoRXAACWIbwCALAM4RUAgGUI rwAALEN4BQBgGcIrAADLEF4BAFiG8AoAwDKEVwAAliG8AgCwDOEVAIBlCK8AACxDeAUAYBnCKwAA yxBeAQBYhvAKAMAyhFcAAJYhvAIAsAzhFQCAZQivAAAsQ3gFAGAZjxBeX976BAAA7uSrzz0rhNfe H+GleVVtuQ8A4BGM8tBeRnr32ek9hNfRh5jbRuPe/YcNAPBGjmSo0bg3z1tvGV57H9ZskAUA4BxH Auubhthbhtf3EELfxb8QAADu5N7Z5+7fiN8ivN4rtFbzOcr5HT/++ONfTz42AMC7kvLOdE46yd1C 7Nnh9RYnfu0H/rff//73/3nF8QEA3r2f887fDmxydqi9SwHzrPB6y6rq0ePnP8Bffvvb3/7HH//4 xz+fe4oAAO/Dn/70pz9//PjxDxHxlxg/aWDGPauzhz29vIz38/T09NSuDt7z8lN8Csft+jep/UOx /E3x3i5/24z9tunPr3b8v3z33Xf//pvf/Obffv3rX//rr371q3+a+XAAAN6zH3744a/ff//9f338 +PEPv/vd776PiP+OiL9HxE8R8fzze/X6+8/9z53xz8X7c3wKoHn55ecxbeh9jtchOC9X7/GyE07f MrxGfA6h7SuH19z2bbOel6uwu73+ISL+OSL+Me0zB+ccqtvz7r22a2k/k7wMADyOquL53Kz3Xm0I bENiFSC3tv+JTxXX/40vA2oOo39v2vJyFVSrtva1XdNdw+u3o84JL3E8oG0nvrfdTLm6+hCq/uf4 9Af9v6gDcw6rbZCtQngVXvN7xPt4ji4AcH/PzXIV1HqvNvT9lNarAJmD5t6806P56oxxvXO5yKXh 9ZLQOrPd3hyL3vyN0YTjUX9+PaVt2mNc4nl/CADwFapyxCXZJC7c5ug+e9cwG3YvcdF211Ze98yG 3NHJVx9a7w+Q+2b6e+Of43Pl9Kp/IQAAD+fa8Jq/dp8Jq+3xZvvzOe9lshk3zU23Dq+bXojdS/pV 2+jDH/1H8RSf/kP4ptNf7XsLsMIrAHDENeH1aHAdzaXtHTcGbdFpq65tpv1UtwqvexXXqv+l6JsN rL0/1N6/UPbCa8Sn/yDceAUAHHFpeD0SXGeC7Ux7HGyrrnHvMzjN0fC6F0ov2X4mvY8+zNy/vZ46 7W01tep7itfV1tGHv/VVN2wJvQDwmEbhdVueee2F2V5/7xiRlvO46vzzuNG1XuLQ9veaNtCz9wFU H1Lvw732Xyd5jmt7jJ9i/NQBAIDWKLyeGVKPvKrzms1ZvWu7uzPD61bt7LW3/S/F+Go90vh2+cxX ntu6tbWPyor4MuACAPQcCa/5cVi3DLCjUDsKrbMhtxdsTwu8Z4XXveA6aqtCbRt4o+i7NKA+Fet5 GkHE65DankdVhY3iPS8DAI9jJrw+F217YTX/stWZwbY636Ohttc2aj/kltMG9oLrTIitlnNbuz4K q5H6PsTr4FrNed3e8zSBdts2aPdC79kEYwC4zi3/f7pV/WBBL2zmJwccCbAzYTbS/iO9j7JWdNaP BNirnRFeq5BajYnOuO3DyUGz3a764Gf+9ZDDal7O/6G00wO2831K+3tK7fnnYdv/QG8ZMO/1PzgA 4Lgqz8w80qoXQJ9jHGT3wuzsMatz7wXafL0z2eTq/LIbXrffl316epoNYjnMjtZHy9t7rmxGvK6q Vn/IKqzm5U3btld5zdeRz9nPwwIAMz8P2y7nglovkLY/CbsXYGduAqvOsRdi95Zn1ru2zLnnLZ82 kKutucLZa8vbVVXWp4nlXoiNeF15bW/eytMHcmjt3XQGADyOKuBVFc29cHltaG2X83F763Gg7e6u Ca+5oprbqv7Rtrkv/wGjaBv1V2G1nR5QLUd8rrxWTxtoq617ITYvAwCPY6862csxvRuxnieXZ6uu M6/q3HvXeOT697YdutejsiLqUJuDat4m77v6A7c/+5qfINBOAxhVXtsA21ZQe08TqMJrDrFtGwDw WEaB7dLwOlNhrcLslnFye3su1TnvVWer5V4oPa1Se+ufh82Bttfe27b36v1KVkQ9H3ZUeX1Kbe16 e575Jq1eeG0JrwDwmI6E17atDZbVNIEqmI6ePnDNc2N711Fdz0z7Ke4557UKsvl9FFpjZ32rvrb/ woh4XXnthdatra2gtjdu5aCaw2vE67AqvALAY+oFum15FF4jxpXWXoht+9oxEa+Daj6P6rz2+kbX ezOXhNdR1XRvm73K614Zugq3vekA+T+C9rmuvakCOaxWldd2uaq6mvMKAIwyzfY+qrxWYXYUWHOo 7VVYq/5Iy9V5jq7xmkrr4W3OrryOgm0vwLbvkdrar/H3QutT6otmf+361ta+55u2tr6qsjqaCxvF eADg8fSCYH7PIXIUXkdV1+omrt782V6IzcesAuze+95ncbVrw+teFXa2vw2uW3sOt9Vc1ja49h5v 1QbgaMZE1NXXdkxvnmvuj+IdACBiHFrzei9I7s11rebHRmfs0cCa1/fC6LX9Q2dVXtuQ2qus5rG9 iuvoXyPVh52D7czjsHJofYn+DVq9amtvvqvKKwAwqrxuyzMBdvbpAnk9Yhxoj76iWM7XVLVXn8NV 7n3D1kywHbVV0wO2sdVUgV5ldQurW3v1RIEPTfuHYszMtAEAgNFX7TkQ5orpKMgevYGr2k8VavO5 zwTUU4LpjHuF1xxIq/420O4l/Ta4tiE1z4GNeP0IrGiWc0jtVVRfij43bAEAPb2K4yjb5PzTC697 N2qN5rvuTR+YqbrOXPPNXBpeqzDahs+ILwNiNaWg2q5Xce0tV/NcI7VVZes2dG4Btq3GtlMIrpnr KrwCwGOqgtxM5TW/jjw6Kyb6qrGj5ercq/Ourrs3pho77YzK66iqWgXTKqTm5RxOq+e0bu0vxbi8 nMNtnhrQBth2vd12VHmNGIfYexCUAWDsbl9td447CnZHKq+j5V5Ftled7VVxe+fVC7W96+x9Fheb Dq8vLy8vT09P1wSkXPkcBduq0hrx6cP8Jl7/gVqjx161IbgXYLd97FVe83J7rGoZAHgcvWrktj6q eI4qr1VYrcJs72kEedu879555WvpVY8v8vLyMr39rZ7zup3AbEW2F1Q/FOPzHNe2ffMhIn5qts3z Wqsqa3U+o6prxOvwOgqyAMDj2KtQjkLg6PUcr/NSrpy+xOcclENrdMbnc+gF2uq9d/0z4w67xw1b VUCNoq0XZHOozX+wiM8hN895/Sm+/Po/H7f9Na6nNLaaNtBbb99bwisAPKYqsO1VLXsV0Xa5Vy2d vXmrqr7OVF2PtN3UNeF1C3yXbtMLtbkvV2JHz26Npq2dJrBVV9sq6yjE5ukMM5VX4RUA2OyF1yNB dhRaqyrqqG3vEVujc8jnO7rWPReH3Fv8SEHbFvE6CLZ9le3GqjaM5ukDW0D9Jl4H2Pa4W1vE5yps G1DzdIHefNaqetsLrea8AgCjcDcKsaMnAVSBtV2PZvk5tbfBNdJyb797N27NXFfVf5VD4XXypq1R RbYXaHOldTQPNuLLpwzkCuwWbtt9f4gvQ28vtPbmuOZAPHvD1lt6L+cBAG/l5l9hT6pCXq+SOQqs vRAbab0XbvPNXxFfBt1RRThfx15QzeP6Aw7crBVxfeW1CqBH+yP60wfacNoGzhxan9Jyr9qaQ2zb 1pvXOlNlVW0FAHp6oa8a06tuVtXRKNqqKmzVX+2nerLBKMzuXeOR/mm3umFrFFpzYO2pKrHVdIKt ypp/SWsLnfmpBDmU5rYo1qtpA+17XgYAyEYhNn/LPAqvR14zz4atwvDeMfPY0TWe6laPyuq15+pq r1Kbq6sfmjHb+raPPM91e0xWVVWdmSIQRVsOxdV7dT0CLQA8pplQt/cVfQ6Hl4TWiC8rrdt6r8pa TS3oVVJ711GNPc0tf2GrCqx7N21Vc13zDVwRXwbbaMbkQLlNG+hNARhND6jCbAzeo7MOADy2XpDd +0p+pgpa9fXmwfYCam+76tyqUD26puzqIHs4vF74S1ttcK3Cbi/ItnNdRwG2mueapw1Eam/PY2/a QHVjVsTrgJvbAACqQDdTzdxbb9t7Twao5r9GjIPr6CkDvWvrXdPQ0Zu1Im4z57UXVKvl9uv+owE2 Tz1o57a2y+3rp0573l9VXd0LqkIrADAymjqwLc9WY2cqsHvTCmJneXSM3vWMlk9xq+e8VtXV3H5t gK2qsds+8/Nc94Jq+8rnPjvHda8yCwA8jiNVytFX7jNf248Cbe/JBLGzfGlwjUH7KUH26YJq7acN X08dGK3vzR+t2vPPs1bt1U+4tuM/xOtjVPutjnNkykC13msDAL5+e+F1NKYXFntV2ueiby+IVlMI Rvutjj9qr67vi/VLpgxEnDttYFR97fWN2p/jdbjc2j8UY9qq66Z3E1cbbtu+PBXhSNX19LI4APDV OVp9HQXWPK63XIXQUUCtKq7VNYzC6U2qrhFXVF4jyuprxPir9NlQWN04tdfe68v7Hc1fHVVbZ6cL qLYCAK3ZkFeNm/nKfmYqQdW215ePG/H6HC4JshdXXSNu9yMFm1xZze0zFdisat/G5ypsDqHtcfIc 16rq2i6/FMsV4RUAaO0Ftb2v42f7e9XVI+tHKq6967rpt9G3Dq/ZpVMJ9vaxtx5RB9ncXoXZSP25 La/n8xVmAeCxzIa6UUWz154roW3bpSG26ps9r6rvpq6aNhAxNXVgb330NX5+37upqjdNoDrWKJDO hNW99r0+AODrNQpYM+F2VOXcC7R70wjyNqPwWx17FFz31q+aMhBxQniNuGmAzX2jAFv1V9vnY4wC a2+batxeOwDwmI6E1Wr8bKjc3meDbNU/CqdvHlwj7jttoDdNYFuOtF71vXT62/mreepA3kcOl/nY +b06l5bKKwCQXVJ5zX17c0z3AudMaJ3Zz15ftX4ztwyvOazOjI+YD7CR2nohtmpvj7MXZqsxvWDc uyYAgCoXHJlLOhNmZ7/qHwXbve1n3CwDnTJtIKI7dSDi2PSBdn12GkFu29vH3vSAmakBoz7VVgCg NTNtYNQ3U3md2eaSauvouLPrnxpPCp2nhdeI6bmvM21HAmwev7efmf2PzqnXDwAwa68KO9u/F2i3 5dmK7N5+RufUbTsruEbcJ7z+0j3RdiR4bstHnxZwJKTuhdOZ8CrgAsBjmQlXe2P2QmU1dna+7Oz8 1aNzXLvX9G7Da8TpAbZd3wuYe9vNPkVg9rx6bQAAe47Of63aLpkTO9rHpdMEem2fOk4Om6eH14hD 81977TMBtrc+CpnXThMYjQcAmHW0OnvpNIKtbTaQXjSftdd+dnCNuFF4jTglwFZtR0LszD6vuTlL cAUArnGoghn7FdNq7FmhdXRudwuuEff/ediIzxc484iql2K9VT1Kq13P2+dHbb102meC6cwfRMAF gMd0aXA7o/J5ZErCpdMXRu03dbPKa8Tu/NeI66qwbduRyugZN2TNhlLhFQAe02zAujQY7oXVXvuR 0Hp03587bxgwbxpeI64KsL2+oyF27xhV/yWhU1AFAEYuCV2zVdC9/rNC6+453DK4RtwhvP5yoHOr sLPtl/zIwOwYYRUAuMbFAfHg9kerp++u2tq6W3iNmAqwEeeF2KrvHk8QEGoBgNa1YeuSIHtJML54 buu9gmvEncNrxNUB9pq+Xr8pAgDAWzljKsHMfi6t8r6r4BrxBuH1lwNfH2LP6J8ZJ6gCAPd07XSC mXHX9t89tG7eLLxGTAfYX4Zf2T875sztAACOOOsRW5eMmT72WwXXiDcOr7+cxLkhdnbMGdsAANzL WVMMLt7vW4bWzbsIr60bBNlrxt96PwDAYzsriB3dz1KBtfXuwuvmYIiN8JQAAODrdo+nFnwe/E5D 4rsNr60Lguwvm556IvffPwDwdbp1ALto/+81sLaWCK+tK4Lsq12dtB8AgLdwSohbIbC2lguv2Ylh dvdQdzoOAPCY7hLKVgur2fLhtXLHQAsA8G6tHlQrX2V4HRFsAYCvydcYUEceLrxeS/gFAM70aOHz WsIrAADL+PDWJwAAALOEVwAAliG8AgCwDOEVAIBlCK8AACxDeAUAYBnCKwAAy/h/xMe1J62CiAkA AAAASUVORK5CYII= --_004_814C42F256CC4BF99C6008A39A1AEF64mitreorg_-- From eabalea@gmail.com Mon Apr 2 07:06:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C1221F84B5 for ; Mon, 2 Apr 2012 07:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElR9Vin2qbCO for ; Mon, 2 Apr 2012 07:06:31 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC3A821F84B4 for ; Mon, 2 Apr 2012 07:06:30 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1296178ghb.31 for ; Mon, 02 Apr 2012 07:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZFMlpI3X587lpF2LcW/OwdvxDuFvvsmsNcCac2YmRkw=; b=LBIdw/Ei3VB/kw6/vr0Z/9FYAW3Dqh6ANNMVVxUTuKqqV+KYuTKoSP41h6Jz0Y95/C 14xyn4KjovHQkyJoR+7fjPGy3dD+TvE9vcxkQ1uIY/Yx+1PWCe2hKusbfwF4Y5dBvmsL JJb0jXr3jhL5/zOs7pmH7yDS1nIs0VlBrljmMjiCWB0jZLLCFNHjWUIg/bN9EgxfQ+Jl 24jXTVmQ2DP2Khjj7h1OF3Bg0Hf8lSN75kMze9Lg2K3LK51+yTreVGTbSyqy7ayO1klU aW5zJbAbmxUkBPaK5qYdafw3S41CgGv3xVGfqKR0xPcuEqD1NjEk+n/4X8PepIZlmiHR 7bIg== MIME-Version: 1.0 Received: by 10.236.189.98 with SMTP id b62mr7195326yhn.9.1333375590257; Mon, 02 Apr 2012 07:06:30 -0700 (PDT) Received: by 10.236.176.233 with HTTP; Mon, 2 Apr 2012 07:06:30 -0700 (PDT) In-Reply-To: <4F79A8AB.4060402@comodo.com> References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> <4F79A8AB.4060402@comodo.com> Date: Mon, 2 Apr 2012 16:06:30 +0200 Message-ID: From: Erwann Abalea To: Rob Stradling Content-Type: multipart/alternative; boundary=20cf303f69b068d34504bcb2b25f Cc: PKIX , Paul Hoffman , Kathleen Wilson Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 14:06:32 -0000 --20cf303f69b068d34504bcb2b25f Content-Type: text/plain; charset=UTF-8 Rob, Apple may not support the nameConstraints extension, I haven't tested it but I trust you in saying so. What I haven't seen is a test of this constraint placed and set to critical, giving a wrongly rejected certificate because of the critical bit. From what I know, before the summer-2011 correction, maybe Apple didn't enforce the unknown-but-critical logic and let the certificate pass the validation. Maybe it's still the case, and that's their problem. I'd go for the a) answer. This constraint MUST be set critical since RFC2459 (dated 01/1999), and it's also recommended to be set critical since 1997 edition of X.509. With my "respect of standards and security practices" hat, that's the most logical answer. With my "CA" hat, I may have some problems. But we (as CAs) have others, laxism of CAs and editors, and bad public perception of CAs is also an important one. Answer a) can help solve it. 2012/4/2 Rob Stradling > Paul, Erwann, > > Aside from maybe petitioning Apple to fix their code, what would you > advise Mozilla to do? > > a) Require critical Name Constraints for "external" Sub-CAs ASAP, thereby > causing currently deployed Apple products to reject all certs issued by > these Sub-CAs. > b) Require Name Constraints, but specify that the critical flag need not > be set and mention that this requirement breaks RFC5280. > c) Not require Name Constraints. Instead, require all "external" Sub-CAs > to undergo a "full" audit. > d) Other. > > > On 02/04/12 14:06, Erwann Abalea wrote: > >> I agree with Paul (and thus disagree with Rob). >> >> This is a constraint. If this constraint is set by the CA, the CA wants >> it to be enforced (else, why would it set this constraint?). >> >> Not so long ago, Apple had to correct a pretty bad behaviour with X.509 >> certificates, not enforcing basicConstraints:CA=False set to critical. >> Nobody then thought of changing a MUST into a SHOULD to allow this >> behaviour. Apple choosed the only realistic solution, update its code. >> This is the same situation here. If Apple can't correctly handle a >> constraint imposed by the CA, or can't reject a certificate because of a >> critical-but-unknown extension, that's their problem, and they're >> putting their users at risk. >> >> That said, I'm an Apple user, and in the Mozilla context I'm following, >> Rob's proposition was not a bad one at first thought. Only at first. >> >> 2012/4/2 Paul Hoffman > paul.hoffman@vpnc.org>**> >> >> >> On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote: >> >> > On 29/03/12 21:05, Rob Stradling wrote: >> > > RFC5280 says: >> > > "4.2.1.10. Name Constraints >> > > ...Conforming CAs MUST mark this extension as critical" >> > > >> > > Can anyone explain the reason for this requirement? >> > >> > Everyone, thanks for your comments. There is certainly no >> consensus to change RFC5280 so that it doesn't advocate that Name >> Constraints be critical. >> > >> > However, I wonder if we could arrive at a compromise... >> > >> > >> > PROPOSAL: Change the "MUST" to "SHOULD". >> > >> > >> > RFC2119 says: >> > '3. SHOULD This word, or the adjective "RECOMMENDED", mean that >> there >> > may exist valid reasons in particular circumstances to ignore a >> > particular item, but the full implications must be understood and >> > carefully weighed before choosing a different course.' >> > >> > Now, I would say that the desire to avoid breaking all Apple >> devices is a "valid reason"! And I think "SHOULD" would still send >> the appropriate message to implementers that they need to think very >> carefully about these things. >> > >> > Comments? Votes? >> >> Fully disagree. A number of people gave security reasons for the >> current wording. Watering down the security of the protocol because >> a vendor made a bad decision and no one is doing conformance testing >> (which would have trivially picked this up) is not a good response. >> >> >> >> -- >> Erwann. >> >> >> ______________________________**_________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/**listinfo/pkix >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > COMODO CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > sender by replying to the e-mail containing this attachment. Replies to > this email may be monitored by COMODO for operational or business reasons. > Whilst every endeavour is taken to ensure that e-mails are free from > viruses, no liability can be accepted and the recipient is requested to use > their own virus checking software. > -- Erwann. --20cf303f69b068d34504bcb2b25f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rob,

Apple may not support the nameConstraints extension, I haven= 9;t tested it but I trust you in saying so.
What I haven't seen is a= test of this constraint placed and set to critical, giving a wrongly rejec= ted certificate because of the critical bit. From what I know, before the s= ummer-2011 correction, maybe Apple didn't enforce the unknown-but-criti= cal logic and let the certificate pass the validation. Maybe it's still= the case, and that's their problem.

I'd go for the a) answer. This constraint MUST be set critical sinc= e RFC2459 (dated 01/1999), and it's also recommended to be set critical= since 1997 edition of X.509.
With my "respect of standards and sec= urity practices" hat, that's the most logical answer.

With my "CA" hat, I may have some problems. But we (as CAs) h= ave others, laxism of CAs and editors, and bad public perception of CAs is = also an important one. Answer a) can help solve it.

2012/4/2 Rob Stradling <= ;rob.stradlin= g@comodo.com>
Paul, Erwann,

Aside from maybe petitioning Apple to fix their code, what would you advise= Mozilla to do?

a) Require critical Name Constraints for "external" Sub-CAs ASAP,= thereby causing currently deployed Apple products to reject all certs issu= ed by these Sub-CAs.
b) Require Name Constraints, but specify that the critical flag need not be= set and mention that this requirement breaks RFC5280.
c) Not require Name Constraints. =C2=A0Instead, require all "external&= quot; Sub-CAs to undergo a "full" audit.
d) Other.


On 02/04/12 14:06, Erwann Abalea wrote:
I agree with Paul (and thus disagree with Rob).

This is a constraint. If this constraint is set by the CA, the CA wants
it to be enforced (else, why would it set this constraint?).

Not so long ago, Apple had to correct a pretty bad behaviour with X.509
certificates, not enforcing basicConstraints:CA=3DFalse set to critical. Nobody then thought of changing a MUST into a SHOULD to allow this
behaviour. Apple choosed the only realistic solution, update its code.
This is the same situation here. If Apple can't correctly handle a
constraint imposed by the CA, or can't reject a certificate because of = a
critical-but-unknown extension, that's their problem, and they're putting their users at risk.

That said, I'm an Apple user, and in the Mozilla context I'm follow= ing,
Rob's proposition was not a bad one at first thought. Only at first.
2012/4/2 Paul Hoffman <paul.hoffman@vpnc.org <mailto:paul.hoffman@vpnc.org>>


=C2=A0 =C2=A0On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote:

=C2=A0 =C2=A0 > On 29/03/12 21:05, Rob Stradling wrote:
=C2=A0 =C2=A0 > > RFC5280 says:
=C2=A0 =C2=A0 > > "4.2.1.10. Name Constraints
=C2=A0 =C2=A0 > > ...Conforming CAs MUST mark this extension as crit= ical"
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > Can anyone explain the reason for this requirement= ?
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Everyone, thanks for your comments. =C2=A0There is cert= ainly no
=C2=A0 =C2=A0consensus to change RFC5280 so that it doesn't advocate t= hat Name
=C2=A0 =C2=A0Constraints be critical.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > However, I wonder if we could arrive at a compromise...=
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > PROPOSAL: Change the "MUST" to "SHOULD&q= uot;.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > RFC2119 says:
=C2=A0 =C2=A0 > '3. SHOULD =C2=A0 This word, or the adjective "= ;RECOMMENDED", mean that
=C2=A0 =C2=A0there
=C2=A0 =C2=A0 > =C2=A0 may exist valid reasons in particular circumstan= ces to ignore a
=C2=A0 =C2=A0 > =C2=A0 particular item, but the full implications must = be understood and
=C2=A0 =C2=A0 > =C2=A0 carefully weighed before choosing a different co= urse.'
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Now, I would say that the desire to avoid breaking all = Apple
=C2=A0 =C2=A0devices is a "valid reason"! =C2=A0And I think &quo= t;SHOULD" would still send
=C2=A0 =C2=A0the appropriate message to implementers that they need to thi= nk very
=C2=A0 =C2=A0carefully about these things.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Comments? =C2=A0Votes?

=C2=A0 =C2=A0Fully disagree. A number of people gave security reasons for = the
=C2=A0 =C2=A0current wording. Watering down the security of the protocol b= ecause
=C2=A0 =C2=A0a vendor made a bad decision and no one is doing conformance = testing
=C2=A0 =C2=A0(which would have trivially picked this up) is not a good res= ponse.



--
Erwann.


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

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
=C2=A03rd Floor, 26 Office Village, Exchange Quay,
=C2=A0Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to whom they are addressed.= =C2=A0If you have received this email in error please notify the sender by= replying to the e-mail containing this attachment. Replies to this email m= ay be monitored by COMODO for operational or business reasons. Whilst every= endeavour is taken to ensure that e-mails are free from viruses, no liabil= ity can be accepted and the recipient is requested to use their own virus c= hecking software.



--
Erwann.
--20cf303f69b068d34504bcb2b25f-- From eabalea@gmail.com Mon Apr 2 07:09:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D38521F8584 for ; Mon, 2 Apr 2012 07:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8V5xSAUZE+q for ; Mon, 2 Apr 2012 07:09:28 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8185D21F8582 for ; Mon, 2 Apr 2012 07:09:28 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1305896ggm.31 for ; Mon, 02 Apr 2012 07:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vj7x2zEaIQy1KpFMd7LEN+XX+O+sS/cVt67sTuXBNAw=; b=G3sOdDFq/BKN6ZjpcvchLov+qkqR1X/XFcTh8Gkuhi4hW4c38RC2bJVtS4IQNng4fA ks5y98dNu3TpX2hDZaDe05jeXWAgO3QJyZCKHwOXOVYPmrIKwD8O7320xJ2vcbi8KQU7 W7WyBhMwBiEAqONHUHQL0Ja2QJWbGWiH5y0SsE3Yc4hECIlG91QXncICe6C4B78PnEty 4amb+7HUTQ4LCHbROTYsf0u3fu6Fy5kYUcGeXhRNGgErp4mJqCmPdJQWS8ElTu9R94Ud sHkh6bSiXkx9kkpsEoYKzeVAMos+JkLkjPQz+W9I0Uzz81b+JiHqrVP8jMMYTS385TE3 8uEg== MIME-Version: 1.0 Received: by 10.236.144.134 with SMTP id n6mr6917962yhj.45.1333375768156; Mon, 02 Apr 2012 07:09:28 -0700 (PDT) Received: by 10.236.176.233 with HTTP; Mon, 2 Apr 2012 07:09:28 -0700 (PDT) In-Reply-To: <814C42F2-56CC-4BF9-9C60-08A39A1AEF64@mitre.org> References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> <814C42F2-56CC-4BF9-9C60-08A39A1AEF64@mitre.org> Date: Mon, 2 Apr 2012 16:09:28 +0200 Message-ID: From: Erwann Abalea To: "Miller, Timothy J." Content-Type: multipart/alternative; boundary=20cf303dd2760359c304bcb2bd33 Cc: PKIX , Paul Hoffman Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 14:09:29 -0000 --20cf303dd2760359c304bcb2bd33 Content-Type: text/plain; charset=UTF-8 2012/4/2 Miller, Timothy J. > On Apr 2, 2012, at 8:06 AM, Erwann Abalea wrote: > > This is the same situation here. If Apple can't correctly handle a > constraint imposed by the CA, or can't reject a certificate because of a > critical-but-unknown extension, that's their problem, and they're putting > their users at risk. > > > Heh. See attached screenshot. > > So it's not Apple who can't get it right, it's the iOS team. :) > Thanks. > > (The extension in question is the MS Application Policies OID > [1.3.6.1.4.1.311.21.10].) > > It's CryptoAPI that ignores critical extensions: > > http://technet.microsoft.com/en-us/library/cc700843.aspx > > "The CryptoAPI engine does not enforce critical extensions in > certificates, only Certificate Revocation Lists (CRLs). The CryptoAPI > engine and programming model places the burden of parsing critical > extensions on to the calling application. Therefore, an application must > understand and enforce a critical extension when evaluating a certificate. > The CryptoAPI revocation provider, however, does evaluate critical > extensions in CRLs and therefore would reject a CRL with a critical > extension that is not known or understood." > > Awful. In the vast majority, application developers don't know anything about certificate validation, and should not have to care about it. -- Erwann. --20cf303dd2760359c304bcb2bd33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/4/2 Miller, Timothy J. &l= t;tmiller@mitre.org>
=
On Apr 2, 2012, at 8:06 AM, Erwann Abalea wrote:

This is the same situation here. If Apple can'= ;t correctly handle a constraint imposed by the CA, or can't reject a c= ertificate because of a critical-but-unknown extension, that's their pr= oblem, and they're putting their users at risk.

Heh. =C2=A0See attached screenshot. =C2=A0

So it's not Apple who can't get it right, it's the iOS tea= m. =C2=A0:)

Thanks.
=C2=A0
-= -
Erwann.
--20cf303dd2760359c304bcb2bd33-- From DPKemp@missi.ncsc.mil Mon Apr 2 07:13:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE4021F84F7 for ; Mon, 2 Apr 2012 07:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73lJ4R6D9DME for ; Mon, 2 Apr 2012 07:13:18 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id C45BB21F8505 for ; Mon, 2 Apr 2012 07:13:17 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q32EDG39031758 for ; Mon, 2 Apr 2012 10:13:16 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 10:13:17 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 2 Apr 2012 10:13:16 -0400 Message-ID: In-Reply-To: <4F79A8AB.4060402@comodo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD Thread-Index: Ac0Q1AkiQN1epGeqSZuPZMVy6rhB+QAATtYQ References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com><2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> <4F79A8AB.4060402@comodo.com> From: "Kemp, David P." To: "PKIX" X-OriginalArrivalTime: 02 Apr 2012 14:13:17.0001 (UTC) FILETIME=[BFC6E390:01CD10DA] Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 14:13:19 -0000 The first change would be from "maybe" petitioning Apple to "definitely" calling their attention to the problem and requesting a fix. DoD has encountered similar issues when deploying systems based on commercial products. For example our policy is to use "Suite B" cryptographic algorithms (ECC + AES) which are sometimes not supported in the products we need to use. The acquisition process includes a scheme for designating requirements as "Threshold" (required) and "Objective (desired). CJCSM 3170.01 (http://www.dtic.mil/cjcs_directives/cdata/unlimit/m317001.pdf) says: "Threshold values should be based on what is achievable through the current state of technology as a minimum. The objective values may be defined based on a goal for the end-state of the system." If we were acquiring a system using Apple products, the objective would be to comply with RFC 5280, and the threshold would be to comply with RFC 5280 "except for requirements A, B, and C". Our solution would NOT be to change technical standards such as 5280 to dilute requirements based on the capabilities of current products. As for what to do to get a system working using broken products, whether you choose option b), c), or d) is not a matter for PKIX to decide. If you think issuing non-standard certs is the most effective way to transition from current to target systems, then by all means choose b). Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rob Stradling Sent: Monday, April 02, 2012 9:25 AM To: Erwann Abalea; Paul Hoffman Cc: PKIX; Kathleen Wilson Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD Paul, Erwann, Aside from maybe petitioning Apple to fix their code, what would you advise Mozilla to do? a) Require critical Name Constraints for "external" Sub-CAs ASAP, thereby causing currently deployed Apple products to reject all certs issued by these Sub-CAs. b) Require Name Constraints, but specify that the critical flag need not be set and mention that this requirement breaks RFC5280. c) Not require Name Constraints. Instead, require all "external"=20 Sub-CAs to undergo a "full" audit. d) Other. On 02/04/12 14:06, Erwann Abalea wrote: > I agree with Paul (and thus disagree with Rob). > > This is a constraint. If this constraint is set by the CA, the CA=20 > wants it to be enforced (else, why would it set this constraint?). > > Not so long ago, Apple had to correct a pretty bad behaviour with=20 > X.509 certificates, not enforcing basicConstraints:CA=3DFalse set to critical. > Nobody then thought of changing a MUST into a SHOULD to allow this=20 > behaviour. Apple choosed the only realistic solution, update its code. > This is the same situation here. If Apple can't correctly handle a=20 > constraint imposed by the CA, or can't reject a certificate because of > a critical-but-unknown extension, that's their problem, and they're=20 > putting their users at risk. > > That said, I'm an Apple user, and in the Mozilla context I'm=20 > following, Rob's proposition was not a bad one at first thought. Only at first. > > 2012/4/2 Paul Hoffman > > > On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote: > > > On 29/03/12 21:05, Rob Stradling wrote: > > > RFC5280 says: > > > "4.2.1.10. Name Constraints > > > ...Conforming CAs MUST mark this extension as critical" > > > > > > Can anyone explain the reason for this requirement? > > > > Everyone, thanks for your comments. There is certainly no > consensus to change RFC5280 so that it doesn't advocate that Name > Constraints be critical. > > > > However, I wonder if we could arrive at a compromise... > > > > > > PROPOSAL: Change the "MUST" to "SHOULD". > > > > > > RFC2119 says: > > '3. SHOULD This word, or the adjective "RECOMMENDED", mean that > there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course.' > > > > Now, I would say that the desire to avoid breaking all Apple > devices is a "valid reason"! And I think "SHOULD" would still send > the appropriate message to implementers that they need to think very > carefully about these things. > > > > Comments? Votes? > > Fully disagree. A number of people gave security reasons for the > current wording. Watering down the security of the protocol because > a vendor made a bad decision and no one is doing conformance testing > (which would have trivially picked this up) is not a good response. > > > > -- > Erwann. > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Mon Apr 2 07:17:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8EA21F851D for ; Mon, 2 Apr 2012 07:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEFBEp9-Uwjb for ; Mon, 2 Apr 2012 07:17:13 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 361F721F84FC for ; Mon, 2 Apr 2012 07:17:13 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q32EHAfK016647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Apr 2012 16:17:10 +0200 (MEST) From: Martin Rex Message-Id: <201204021417.q32EH9cH012951@fs4113.wdf.sap.corp> To: eabalea@gmail.com (Erwann Abalea) Date: Mon, 2 Apr 2012 16:17:09 +0200 (MEST) In-Reply-To: from "Erwann Abalea" at Apr 2, 12 03:06:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 14:17:14 -0000 I've got the slight feeling that folks are significantly talking past each other. What Rob is asking for is permissing for the CA(!) to issue a name constraint non-critical in order to express its intention with respect to enforcement of that name constraint. To me, that looks like a perfectly valid request, and PKIX (rfc5280) is in violation of rfc2119 of requiring this extension to be always made critical by the CA (instead of leaving that decision to the CA to express its intention). Apple's implementation seems to be correct, in that it rejects critical name constraints because it does not implement them. I don't know whether that rejection applies to *ALL* name constraints (including directory names), or only to name constraints on SubjectAltNames of type DNSName, because not implementing subjectAltName constraints and rejecting all certs that contain such marked critical seems OK and conforming to rfc5280. Not implementing name constraints on directory names, while not exactly conforming with rfc5280 (where this is inappropriately declared a MUST), looks pretty sensible to me, because the use of hierarchical directory structures of DNames with only one single trust anchor is a fairly unrealistic usage scenario, so it makes no sense that this hardly usable feature is a MUST in the first place. -Martin From rob.stradling@comodo.com Mon Apr 2 08:14:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A55D21F85FF for ; Mon, 2 Apr 2012 08:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdiCpbp33GOf for ; Mon, 2 Apr 2012 08:14:08 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id A99A421F85EF for ; Mon, 2 Apr 2012 08:14:07 -0700 (PDT) Received: (qmail 11844 invoked from network); 2 Apr 2012 15:14:06 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 2 Apr 2012 15:14:06 -0000 Received: (qmail 10240 invoked by uid 1000); 2 Apr 2012 15:14:06 -0000 Received: from nigel.brad.office.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 (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 02 Apr 2012 16:14:06 +0100 Message-ID: <4F79C23D.90006@comodo.com> Date: Mon, 02 Apr 2012 16:14:05 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: Erwann Abalea References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> <4F79A8AB.4060402@comodo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: PKIX , Paul Hoffman , Kathleen Wilson Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:14:09 -0000 On 02/04/12 15:06, Erwann Abalea wrote: > Rob, > > Apple may not support the nameConstraints extension, I haven't tested it > but I trust you in saying so. Hi Erwann. To be honest, I haven't tested it myself. I'm relying on statements made over at mozilla.dev.security.policy. e.g. Kathleen wrote a few days ago: "For instance, Apple does not currently support name constraints in iOS and OS X, and they will not commit to a certain time frame to have this support available." > What I haven't seen is a test of this constraint placed and set to > critical, giving a wrongly rejected certificate because of the critical > bit. From what I know, before the summer-2011 correction, maybe Apple > didn't enforce the unknown-but-critical logic and let the certificate > pass the validation. Maybe it's still the case, and that's their problem. > > I'd go for the a) answer. This constraint MUST be set critical since > RFC2459 (dated 01/1999), and it's also recommended to be set critical > since 1997 edition of X.509. > With my "respect of standards and security practices" hat, that's the > most logical answer. > > With my "CA" hat, I may have some problems. But we (as CAs) have others, > laxism of CAs and editors, and bad public perception of CAs is also an > important one. Answer a) can help solve it. > > 2012/4/2 Rob Stradling > > > Paul, Erwann, > > Aside from maybe petitioning Apple to fix their code, what would you > advise Mozilla to do? > > a) Require critical Name Constraints for "external" Sub-CAs ASAP, > thereby causing currently deployed Apple products to reject all > certs issued by these Sub-CAs. > b) Require Name Constraints, but specify that the critical flag need > not be set and mention that this requirement breaks RFC5280. > c) Not require Name Constraints. Instead, require all "external" > Sub-CAs to undergo a "full" audit. > d) Other. > > > On 02/04/12 14:06, Erwann Abalea wrote: > > I agree with Paul (and thus disagree with Rob). > > This is a constraint. If this constraint is set by the CA, the > CA wants > it to be enforced (else, why would it set this constraint?). > > Not so long ago, Apple had to correct a pretty bad behaviour > with X.509 > certificates, not enforcing basicConstraints:CA=False set to > critical. > Nobody then thought of changing a MUST into a SHOULD to allow this > behaviour. Apple choosed the only realistic solution, update its > code. > This is the same situation here. If Apple can't correctly handle a > constraint imposed by the CA, or can't reject a certificate > because of a > critical-but-unknown extension, that's their problem, and they're > putting their users at risk. > > That said, I'm an Apple user, and in the Mozilla context I'm > following, > Rob's proposition was not a bad one at first thought. Only at first. > > 2012/4/2 Paul Hoffman >__> > > > On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote: > > > On 29/03/12 21:05, Rob Stradling wrote: > > > RFC5280 says: > > > "4.2.1.10. Name Constraints > > > ...Conforming CAs MUST mark this extension as critical" > > > > > > Can anyone explain the reason for this requirement? > > > > Everyone, thanks for your comments. There is certainly no > consensus to change RFC5280 so that it doesn't advocate that > Name > Constraints be critical. > > > > However, I wonder if we could arrive at a compromise... > > > > > > PROPOSAL: Change the "MUST" to "SHOULD". > > > > > > RFC2119 says: > > '3. SHOULD This word, or the adjective "RECOMMENDED", mean that > there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be > understood and > > carefully weighed before choosing a different course.' > > > > Now, I would say that the desire to avoid breaking all Apple > devices is a "valid reason"! And I think "SHOULD" would > still send > the appropriate message to implementers that they need to > think very > carefully about these things. > > > > Comments? Votes? > > Fully disagree. A number of people gave security reasons for the > current wording. Watering down the security of the protocol > because > a vendor made a bad decision and no one is doing conformance > testing > (which would have trivially picked this up) is not a good > response. > > > > -- > Erwann. > > > _________________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/__listinfo/pkix > > > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > COMODO CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the sender by replying to the e-mail containing this > attachment. Replies to this email may be monitored by COMODO for > operational or business reasons. Whilst every endeavour is taken to > ensure that e-mails are free from viruses, no liability can be > accepted and the recipient is requested to use their own virus > checking software. > > > > > -- > Erwann. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From eabalea@gmail.com Mon Apr 2 08:51:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5A421F85E7 for ; Mon, 2 Apr 2012 08:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxMlwGF9hvsX for ; Mon, 2 Apr 2012 08:51:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 271D321F86BE for ; Mon, 2 Apr 2012 08:51:11 -0700 (PDT) Received: by yenm5 with SMTP id m5so1416386yen.31 for ; Mon, 02 Apr 2012 08:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=erDc/TSPi5/p19Rj3yphJ7n44/lA4Fgtb1+s92hqXnA=; b=qo+NijeLuAq9vs54RZtfMfsRVDmIYLqckHLH2B9SliAj+oFnXhHYyvZY6RjIqnrzzz okMJYDWJFKV1DkDz1J/QPkqBaBXsWsVlgxjNaLh/cc8b+8Z3NJPcVQiO2Oiuun9Iz25H B9Wk+opJR53XhSlQTrZgZtby48c5JXyc4bXtGW3cAWcF51hqCwaZfS5+qVZeNeBsdAUq S9j9X4g/20fcV/gKVWhfWgBuF0PGA1knlpanBmfQn1WrLg+ZgvX0Lte4eP3imVqBiMuq Mj5hnXj42mKP2vlcOeUy6FJJD4kFs9F9wBjkiSUpLN0MfMoJD6iI9g6JCXnA7ktLLvZ3 aTzg== MIME-Version: 1.0 Received: by 10.236.103.226 with SMTP id f62mr7571896yhg.0.1333381869933; Mon, 02 Apr 2012 08:51:09 -0700 (PDT) Received: by 10.236.176.233 with HTTP; Mon, 2 Apr 2012 08:51:09 -0700 (PDT) In-Reply-To: <201204021417.q32EH9cH012951@fs4113.wdf.sap.corp> References: <201204021417.q32EH9cH012951@fs4113.wdf.sap.corp> Date: Mon, 2 Apr 2012 17:51:09 +0200 Message-ID: From: Erwann Abalea To: mrex@sap.com Content-Type: multipart/alternative; boundary=20cf303b4051b5144604bcb42847 Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:51:13 -0000 --20cf303b4051b5144604bcb42847 Content-Type: text/plain; charset=UTF-8 2012/4/2 Martin Rex > What Rob is asking for is permissing for the CA(!) to issue a name > constraint non-critical in order to express its intention with respect > to enforcement of that name constraint. Not exactly. Mozilla is looking for a way to counter the lack of constraints on externally-operated sub-CAs of their root CA program. The goal is to protect their userbase. In my opinion, Rob was asking for advice on how a non-critical nameConstraints extension would be perceived by IETF-PKIX members. > To me, that looks like a > perfectly valid request, and PKIX (rfc5280) is in violation of > rfc2119 of requiring this extension to be always made critical > by the CA (instead of leaving that decision to the CA to express > its intention). > How could PKIX be in violation of anything by requiring the extension to be critical, and why the RFC2119? Is PKIX also in violation of RFC2119 when requiring the serial number to be a positive integer not longer than 20 octets? Apple's implementation seems to be correct, in that it rejects > critical name constraints because it does not implement them. > That's not what happened before summer-2011 when Apple corrected iOS. Before that patch, a certificate containing a *critical* basicConstraints extension with the CA element set to false was still able to sign another certificate. That either means the basicConstraints wasn't correctly enforced or the unknown-but-critical rejection rule wasn't correctly enforced. I don't have any precise information about what has been corrected, so the later explanation can still hold true. -- Erwann. --20cf303b4051b5144604bcb42847 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/4/2 Martin Rex <mrex@sap.com>
What Rob is asking for is permissing for the CA(!) to issue a name
constraint non-critical in order to express its intention with respect
to enforcement of that name constraint.

Not exactly. M= ozilla is looking for a way to counter the lack of constraints on externall= y-operated sub-CAs of their root CA program. The goal is to protect their u= serbase. In my opinion, Rob was asking for advice on how a non-critical nam= eConstraints extension would be perceived by IETF-PKIX members.

=C2=A0
To me, th= at looks like a
perfectly valid request, and PKIX (rfc5280) is in violation of
rfc2119 of requiring this extension to be always made critical
by the CA (instead of leaving that decision to the CA to express
its intention).

How could PKIX be in violation of = anything by requiring the extension to be critical, and why the RFC2119? Is= PKIX also in violation of RFC2119 when requiring the serial number to be a= positive integer not longer than 20 octets?

Apple's implementation seems to be correct, in that it rejects
critical name constraints because it does not implement them.

That's not what happened before summer-2011 when Apple corr= ected iOS. Before that patch, a certificate containing a *critical* basicCo= nstraints extension with the CA element set to false was still able to sign= another certificate. That either means the basicConstraints wasn't cor= rectly enforced or the unknown-but-critical rejection rule wasn't corre= ctly enforced. I don't have any precise information about what has been= corrected, so the later explanation can still hold true.

--
Erwann.
--20cf303b4051b5144604bcb42847-- From mrex@sap.com Mon Apr 2 10:13:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6AF21F865C for ; Mon, 2 Apr 2012 10:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gcbh-LljBg9 for ; Mon, 2 Apr 2012 10:13:39 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 295ED21F8659 for ; Mon, 2 Apr 2012 10:13:39 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q32HDaQM000239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Apr 2012 19:13:36 +0200 (MEST) From: Martin Rex Message-Id: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> To: eabalea@gmail.com (Erwann Abalea) Date: Mon, 2 Apr 2012 19:13:35 +0200 (MEST) In-Reply-To: from "Erwann Abalea" at Apr 2, 12 05:51:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:13:40 -0000 Erwann Abalea wrote: > > > To me, that looks like a > > perfectly valid request, and PKIX (rfc5280) is in violation of > > rfc2119 of requiring this extension to be always made critical > > by the CA (instead of leaving that decision to the CA to express > > its intention). > > > > How could PKIX be in violation of anything by requiring the extension to be > critical, and why the RFC2119? Is PKIX also in violation of RFC2119 when > requiring the serial number to be a positive integer not longer than 20 > octets? http://tools.ietf.org/html/rfc2119#section-6 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Requiring a CA to always make name constraints critical will very probably impair/break interop with implementations that do not support that particular type of name constraints. Since the CA is the entity which defines the policy of whether RPs enforcing this name constraints is a problem or not, the MUST can *NOT* be justified with security. There for the "MUST always be critical" in rfc5280 is a clear violation of rfc2119 and therefore NULL and VOID. That is pretty simple math. The only reason that this is there is a desire for some organizations to procure specific features in COTS, rather than having to pay extra for it. Deserves to be ignored by the marketplace. The discussion of the purpose of both critical and non-critical uses of a constraints extension is much more reasonably explained here: http://tools.ietf.org/html/rfc3647#section-3.3.1 and the very same reasoning can be applied to name constraints. It must be up to the CA that puts name constraints into a subCA cert to determine whether these should be critical or not. It is invalid for rfc5280 to unconditionally require name constraints to be marked critical by CAs. -Martin From SChokhani@cygnacom.com Mon Apr 2 10:17:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF9F21F8644 for ; Mon, 2 Apr 2012 10:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9wAes8EPXAJ for ; Mon, 2 Apr 2012 10:17:24 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5C14E21F8622 for ; Mon, 2 Apr 2012 10:17:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,357,1330923600"; d="scan'208";a="4573040" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 02 Apr 2012 13:17:19 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 2 Apr 2012 13:17:19 -0400 From: Santosh Chokhani To: "mrex@sap.com" , Erwann Abalea Date: Mon, 2 Apr 2012 13:17:18 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0Q8/y52IqwdCnZSLKmF0HjuMNx9QAAERaA Message-ID: References: from "Erwann Abalea" at Apr 2, 12 05:51:09 pm <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> In-Reply-To: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:17:25 -0000 Martin, You miss the security implication of this. CA can always make it NC and the clients that do not process name constrain= ts will be exposed if the Sub CA is rogue, compromised or RAs it trusts go = rouge or are compromised. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Mar= tin Rex Sent: Monday, April 02, 2012 1:14 PM To: Erwann Abalea Cc: pkix@ietf.org; paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Erwann Abalea wrote: >=20 > > To me, that looks like a > > perfectly valid request, and PKIX (rfc5280) is in violation of > > rfc2119 of requiring this extension to be always made critical by=20 > > the CA (instead of leaving that decision to the CA to express its=20 > > intention). > > >=20 > How could PKIX be in violation of anything by requiring the extension=20 > to be critical, and why the RFC2119? Is PKIX also in violation of=20 > RFC2119 when requiring the serial number to be a positive integer not=20 > longer than 20 octets? http://tools.ietf.org/html/rfc2119#section-6 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. Requiring a CA to always make name constraints critical will very probably = impair/break interop with implementations that do not support that particul= ar type of name constraints. Since the CA is the entity which defines the policy of whether RPs enforcin= g this name constraints is a problem or not, the MUST can *NOT* be justified with security. There for the "MUST always be critical" in rfc5280 is a clear violation of rfc2119 and therefore NULL and VOID. That is pretty simple math. The only reason that this is there is a desire for some organizations to pr= ocure specific features in COTS, rather than having to pay extra for it. D= eserves to be ignored by the marketplace. The discussion of the purpose of both critical and non-critical uses of a c= onstraints extension is much more reasonably explained here: http://tools.ietf.org/html/rfc3647#section-3.3.1 and the very same reasoning can be applied to name constraints. It must be up to the CA that puts name constraints into a subCA cert to det= ermine whether these should be critical or not. It is invalid for rfc5280 = to unconditionally require name constraints to be marked critical by CAs. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From paul.hoffman@vpnc.org Mon Apr 2 10:27:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1788121F86B5 for ; Mon, 2 Apr 2012 10:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApRFAZX8lcwT for ; Mon, 2 Apr 2012 10:27:56 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC9E21F86B7 for ; Mon, 2 Apr 2012 10:27:44 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q32HRgMP069994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2012 10:27:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> Date: Mon, 2 Apr 2012 10:27:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84FF3EC6-9650-4458-89A9-372988A43A6D@vpnc.org> References: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) Cc: PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:27:57 -0000 On Apr 2, 2012, at 10:13 AM, Martin Rex wrote: > Erwann Abalea wrote: >>=20 >>> To me, that looks like a >>> perfectly valid request, and PKIX (rfc5280) is in violation of >>> rfc2119 of requiring this extension to be always made critical >>> by the CA (instead of leaving that decision to the CA to express >>> its intention). >>>=20 >>=20 >> How could PKIX be in violation of anything by requiring the extension = to be >> critical, and why the RFC2119? Is PKIX also in violation of RFC2119 = when >> requiring the serial number to be a positive integer not longer than = 20 >> octets? >=20 > http://tools.ietf.org/html/rfc2119#section-6 >=20 > 6. Guidance in the use of these Imperatives >=20 > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. >=20 >=20 > Requiring a CA to always make name constraints critical will very = probably > impair/break interop with implementations that do not support that > particular type of name constraints. True. But then you say: > Since the CA is the entity which defines the policy of whether RPs > enforcing this name constraints is a problem or not, the MUST can > *NOT* be justified with security. There for the "MUST always be = critical" > in rfc5280 is a clear violation of rfc2119 and therefore NULL and = VOID. > That is pretty simple math. No, it is absurd. You might not realize it, but there are dozens, maybe = hundreds, of RFCs that have similar requirements. Martin Rex declaring = them all "NULL and VOID" is a bit over the top. Last I checked, no one = made you an IESG member, nor the RFC Editor. > The only reason that this is there is a desire for some organizations > to procure specific features in COTS, rather than having to pay extra > for it. =20 It is more than a bit insulting for you to ascribe a single motivation = to the hundreds of people who worked on RFC 5280 and its predecessors, = as well as to everyone who has read it and didn't notice this problem. Criticality bits have caused problems for PKIX and other IETF standards. = Some people probably agree with you that there should not be a = requirement that the writer (CA) must set it; other people disagree with = you. > Deserves to be ignored by the marketplace. Feel free to ignore it, then. It is still in the standard. > The discussion of the purpose of both critical and non-critical uses = of a > constraints extension is much more reasonably explained here: >=20 > http://tools.ietf.org/html/rfc3647#section-3.3.1 >=20 > and the very same reasoning can be applied to name constraints. > It must be up to the CA that puts name constraints into a subCA cert > to determine whether these should be critical or not. It is invalid > for rfc5280 to unconditionally require name constraints to be marked > critical by CAs. So far, not many people on this list have agreed with you. Without = consensus of the WG, the document will remain the same. --Paul Hoffman From paul.hoffman@vpnc.org Mon Apr 2 10:34:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E0821F8653 for ; Mon, 2 Apr 2012 10:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeQDN-dgkgsB for ; Mon, 2 Apr 2012 10:34:56 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C6CD821F86C2 for ; Mon, 2 Apr 2012 10:34:54 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q32HYoZ4070241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2012 10:34:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 2 Apr 2012 10:34:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org> References: To: Stephen Kent X-Mailer: Apple Mail (2.1257) Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:34:57 -0000 Greetings again. I think I understand your problem with the current = draft wording, namely that it mis-uses terms that already have specific = meanings. I propose the following to replace both what you proposed and = what David has in the current draft. I believe that this does not stomp = on any current definitions but still makes it clear that such = certificates exist. Certificates with a signing key that is the same as the key in the = subjectPublicKeyInfo, but that do not include a BasicConstraints = extension that asserts the cA boolean, are commonly used to convey = public keys without an expectation that the contents of such = certificates can be validated. These certificates are sometimes used for = transmitting a PKIX trust anchor or the unvalidated public key of an end = entity; other uses are certainly possible as well. The format and use of = such certificates are outside the scope of both X.509 and this = specification. Note that these certificates cannot formally be called = "self-signed" or "self-issued" because they do not follow the definition = in the preceding paragraph. Does this work for you? If not, are there any statements in it that are = wrong, or do you want it to say more? --Paul Hoffman From eabalea@gmail.com Mon Apr 2 10:44:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6266D21F85FF for ; Mon, 2 Apr 2012 10:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRxPv270HSYg for ; Mon, 2 Apr 2012 10:44:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C2A6F21F85B4 for ; Mon, 2 Apr 2012 10:44:27 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1511908yhk.31 for ; Mon, 02 Apr 2012 10:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+6G1etr2OnCa3XZwLWAQCy0UNK+kFg792MlkLYwz2Nw=; b=unm4KKNGPfxc8gIIHlPjxoKq/cvnVCEta9ccxxkMlZP9hwR3Gj8CSnQiBzQTS+1CgZ wBfxLt1OIImb5mWLXpKovWMU8c1HThBwGVSa6ys5CUQM8V2soRgQLtA2Oacsh6Beeg7X l/ZJF3V3S6iAZlJpZIyiCd//ZHotFKx+N5zbAhmhgEF38/V5W3GVJMdAAPJSFDQNVMN+ q4ewApTuaD3KaHL4td1gYeLKntVOYy9SS1h383dR1JoQ4e5AIQ43i6NPv8bavWvbPiv8 rvJh51Z8xBin0xOjaEDjGhnFFYIFbescz4ixIieKg0/H24jjXmEew176i1fjz5MF8GlA 2zaA== MIME-Version: 1.0 Received: by 10.236.103.226 with SMTP id f62mr8005085yhg.0.1333388667431; Mon, 02 Apr 2012 10:44:27 -0700 (PDT) Received: by 10.236.176.233 with HTTP; Mon, 2 Apr 2012 10:44:27 -0700 (PDT) In-Reply-To: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> References: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> Date: Mon, 2 Apr 2012 19:44:27 +0200 Message-ID: From: Erwann Abalea To: mrex@sap.com Content-Type: multipart/alternative; boundary=20cf303b4051deab9b04bcb5bd3e Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:44:30 -0000 --20cf303b4051deab9b04bcb5bd3e Content-Type: text/plain; charset=UTF-8 2012/4/2 Martin Rex > > http://tools.ietf.org/html/rfc2119#section-6 > > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. > > > Requiring a CA to always make name constraints critical will very probably > impair/break interop with implementations that do not support that > particular type of name constraints. > That's shouldn't be taken into account. The behaviour of a compliant RP is clear, if an extension is not known and set critical, the certificate must be considered invalid. The fact that applying the rule breaks implementations written way later than the publication of RFC2459 (which states the same) doesn't say that the rule is NULL and VOID. Since the CA is the entity which defines the policy of whether RPs > enforcing this name constraints is a problem or not, the MUST can > *NOT* be justified with security. There for the "MUST always be critical" > in rfc5280 is a clear violation of rfc2119 and therefore NULL and VOID. > That is pretty simple math. > Ok, I see the argument. Let's extend it to other extensions. For example the deltaCRLIndicator extension, which also MUST be set critical. You probably know why it is dangerous for a RP to receive a CRL with such an extension non critical. Following your logic, the CA defines what is secure and what isn't, so this extension could be set non critical. Is that right? What about the X.509 which states that this extension is always set critical? Can your argumentation be applied to every extension defined in the recommendation and the PKIX profiles? The only reason that this is there is a desire for some organizations > to procure specific features in COTS, rather than having to pay extra > for it. Deserves to be ignored by the marketplace. > I need you (or someone else) to rephrase this paragraph, I don't understand it, it seems. For me, a constraint needs to be set critical, or it can be considered nonexistent (a RP is free to ignore any unknown non critical extension, therefore free to declare non critical extension as unknown). The logic behind the RFC5280 choice is security for the end-user. And this discussion has been brought here because of end-user security problems. -- Erwann. --20cf303b4051deab9b04bcb5bd3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/4/2 Martin Rex <mrex@sap.com>

http://tools.ietf.org/html/rfc2119#section-6

=C2=A0 6. Guidance in the use of these Imperatives

=C2=A0 Imperatives of the type defined in this memo must be used with care=
=C2=A0 and sparingly. =C2=A0In particular, they MUST only be used where it= is
=C2=A0 actually required for interoperation or to limit behavior which has=
=C2=A0 potential for causing harm (e.g., limiting retransmisssions) =C2=A0= For
=C2=A0 example, they must not be used to try to impose a particular method=
=C2=A0 on implementors where the method is not required for
=C2=A0 interoperability.


Requiring a CA to always make name constraints critical will very probably<= br> impair/break interop with implementations that do not support that
particular type of name constraints.

That's sh= ouldn't be taken into account. The behaviour of a compliant RP is clear= , if an extension is not known and set critical, the certificate must be co= nsidered invalid. The fact that applying the rule breaks implementations wr= itten way later than the publication of RFC2459 (which states the same) doe= sn't say that the rule is NULL and VOID.

Since the CA is the entity which defines the policy of whether RPs
enforcing this name constraints is a problem or not, the MUST can
*NOT* be justified with security. =C2=A0There for the "MUST always be = critical"
in rfc5280 is a clear violation of rfc2119 and therefore NULL and VOID.
That is pretty simple math.

Ok, I see the argument= . Let's extend it to other extensions. For example the deltaCRLIndicato= r extension, which also MUST be set critical. You probably know why it is d= angerous for a RP to receive a CRL with such an extension non critical. Fol= lowing your logic, the CA defines what is secure and what isn't, so thi= s extension could be set non critical. Is that right?
What about the X.509 which states that this extension is always set critica= l?
Can your argumentation be applied to every extension defined in the r= ecommendation and the PKIX profiles?

The only reason that this is there is a desire for some organizations
to procure specific features in COTS, rather than having to pay extra
for it. =C2=A0Deserves to be ignored by the marketplace.

I need you (or someone else) to rephrase this paragraph, I don't= understand it, it seems.
=C2=A0
For me, a constraint needs to be s= et critical, or it can be considered nonexistent (a RP is free to ignore an= y unknown non critical extension, therefore free to declare non critical ex= tension as unknown).

The logic behind the RFC5280 choice is security for the end-user. And t= his discussion has been brought here because of end-user security problems.=

--
Erwann.
--20cf303b4051deab9b04bcb5bd3e-- From dev+ietf@seantek.com Mon Apr 2 10:49:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB1B21F8637 for ; Mon, 2 Apr 2012 10:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkUXT3qbyWs4 for ; Mon, 2 Apr 2012 10:49:19 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9559C21F85F1 for ; Mon, 2 Apr 2012 10:49:19 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.89.180.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DA95622E253 for ; Mon, 2 Apr 2012 13:49:12 -0400 (EDT) Message-ID: <4F79E694.5020804@seantek.com> Date: Mon, 02 Apr 2012 10:49:08 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> In-Reply-To: <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:49:20 -0000 On 4/2/2012 5:32 AM, Paul Hoffman wrote: > On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote: > >> PROPOSAL: Change the "MUST" to "SHOULD". >> > Fully disagree. A number of people gave security reasons for the curren= t wording. Watering down the security of the protocol because a vendor ma= de a bad decision and no one is doing conformance testing (which would ha= ve trivially picked this up) is not a good response. +1 for Paul's comment. -1 for voting. Keep it "MUST". -Sean From mmyers@fastq.com Mon Apr 2 10:55:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235B221F86C9 for ; Mon, 2 Apr 2012 10:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfWJLLeF5Hvz for ; Mon, 2 Apr 2012 10:55:29 -0700 (PDT) Received: from mailout.fastq.com (postal.fastq.com [204.62.193.66]) by ietfa.amsl.com (Postfix) with ESMTP id 807CC21F85A5 for ; Mon, 2 Apr 2012 10:55:29 -0700 (PDT) Received: from [192.168.1.105] (9.63.dynamic-dsl.fastq.deru.com [140.99.65.9] (may be forged)) (authenticated bits=0) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id q32HtI8f009882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2012 10:55:26 -0700 Message-Id: <342C4A32-E427-440C-B69D-355B27584E43@fastq.com> From: Michael Myers To: Sean Leonard In-Reply-To: <4F79E694.5020804@seantek.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Apr 2012 11:01:03 -0700 References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> <4F79E694.5020804@seantek.com> X-Mailer: Apple Mail (2.936) Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:55:30 -0000 Toward WG consensus, keep it MUST. SHALL would be even better, but that's a semantic thing on my part. Mike On Apr 2, 2012, at 10:49 AM, Sean Leonard wrote: > On 4/2/2012 5:32 AM, Paul Hoffman wrote: >> On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote: >> >>> PROPOSAL: Change the "MUST" to "SHOULD". >>> >> Fully disagree. A number of people gave security reasons for the >> current wording. Watering down the security of the protocol because >> a vendor made a bad decision and no one is doing conformance >> testing (which would have trivially picked this up) is not a good >> response. > > +1 for Paul's comment. > > -1 for voting. Keep it "MUST". > > -Sean From mrex@sap.com Mon Apr 2 11:48:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D2C21F86F2 for ; Mon, 2 Apr 2012 11:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyYH7-w3WMDW for ; Mon, 2 Apr 2012 11:48:21 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B36AF21F86F1 for ; Mon, 2 Apr 2012 11:48:20 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q32ImFQg025160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Apr 2012 20:48:15 +0200 (MEST) From: Martin Rex Message-Id: <201204021848.q32ImEnH028123@fs4113.wdf.sap.corp> To: SChokhani@cygnacom.com (Santosh Chokhani) Date: Mon, 2 Apr 2012 20:48:14 +0200 (MEST) In-Reply-To: from "Santosh Chokhani" at Apr 2, 12 01:17:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 18:48:21 -0000 Santosh Chokhani wrote: > > You miss the security implication of this. > > CA can always make it NC and the clients that do not process name > constraints will be exposed if the Sub CA is rogue, compromised > or RAs it trusts go rouge or are compromised. This discussion seems to be lost some deep in the woods. RPs that implement name constraints have to process them when present independent whether they're marked critical or not, so we can safely exclude these from the discussion, they simply do not matter here. Now for the remaining RPs that do not support a particular name constraint that a higher level CA intends to impose on a subCA. When it marks that constraint critical, the certificates issued by the subCA will not be acceptable _at_all_ to RPs that do not implement the particular name constraints the CA wants to use. If the name constraints are marked non-critical, then the certificates issued by the subCA will be usable with those RPs (not implementing the name constraints) under ignorance of the name constraints. Whether the subCA "goes rogue" is irrelevant for the RPs that implement the name constraints, because they will process the name constraints even when not critical. For the RPs that do not implement the name constraints, they continue to not care about the name constraints, so whether the CA is honest or rogue (with respect to the name constraints) is irrelevant to them _as_well_. Now where is your problem letting CAs decide for themselves whether they want to make the name constraints extension critical or not, similar to leaving it up to CA to make policy constraints critical or not. -Martin From mrex@sap.com Mon Apr 2 11:51:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042FA21F8469 for ; Mon, 2 Apr 2012 11:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OHmvSIrbb2q for ; Mon, 2 Apr 2012 11:51:28 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 326FC21F8467 for ; Mon, 2 Apr 2012 11:51:27 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q32IpRgW025743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Apr 2012 20:51:27 +0200 (MEST) From: Martin Rex Message-Id: <201204021851.q32IpQWJ028237@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Mon, 2 Apr 2012 20:51:26 +0200 (MEST) In-Reply-To: <84FF3EC6-9650-4458-89A9-372988A43A6D@vpnc.org> from "Paul Hoffman" at Apr 2, 12 10:27:42 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 18:51:29 -0000 Paul Hoffman wrote: > > > Since the CA is the entity which defines the policy of whether RPs > > enforcing this name constraints is a problem or not, the MUST can > > *NOT* be justified with security. There for the "MUST always be critical" > > in rfc5280 is a clear violation of rfc2119 and therefore NULL and VOID. > > That is pretty simple math. > > No, it is absurd. You might not realize it, but there are dozens, > maybe hundreds, of RFCs that have similar requirements. Martin Rex > declaring them all "NULL and VOID" is a bit over the top. > Last I checked, no one made you an IESG member, nor the RFC Editor. rfc2119 is something like our "constitution" for standards. The requirement that CAs MUST mark name constraints extension critical is in clear conflict with rfc2116 section 6, and therefore "unconstitutional" for an IETF Standard, which makes that requirement NULL and VOID. Specifications, and in particular those that are proposed, must be assumed to contain defects. That is just one of the defects of rfc5280. -Martin From paul.hoffman@vpnc.org Mon Apr 2 12:31:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E1621F86DF for ; Mon, 2 Apr 2012 12:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWV899ZIZ5B3 for ; Mon, 2 Apr 2012 12:31:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D1F9021F86BE for ; Mon, 2 Apr 2012 12:31:15 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q32JVESY073513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2012 12:31:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <201204021851.q32IpQWJ028237@fs4113.wdf.sap.corp> Date: Mon, 2 Apr 2012 12:31:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201204021851.q32IpQWJ028237@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 19:31:17 -0000 On Apr 2, 2012, at 11:51 AM, Martin Rex wrote: > rfc2119 is something like our "constitution" for standards. No, it is not. No one has pretended that until now. It is a set of = definitions that is widely used, and is also nearly as widely abused, in = RFCs. Note the difference? Next topic, please. --Paul Hoffman From mrex@sap.com Mon Apr 2 13:21:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F1D21F8690 for ; Mon, 2 Apr 2012 13:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bNWqdpb03gV for ; Mon, 2 Apr 2012 13:21:10 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6E921F868C for ; Mon, 2 Apr 2012 13:21:10 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q32KL8GQ024493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Apr 2012 22:21:08 +0200 (MEST) From: Martin Rex Message-Id: <201204022021.q32KL7m3003456@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Mon, 2 Apr 2012 22:21:07 +0200 (MEST) In-Reply-To: from "Paul Hoffman" at Apr 2, 12 12:31:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:21:11 -0000 Paul Hoffman wrote: > > On Apr 2, 2012, at 11:51 AM, Martin Rex wrote: > > > rfc2119 is something like our "constitution" for standards. > > No, it is not. No one has pretended that until now. It is a set of > definitions that is widely used, and is also nearly as widely abused, > in RFCs. Note the difference? Most RFC (and that includes 5280) contain this disclaimer: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. rfc2119 section 6 defines which are valid used of these imperatives, and which are invalid uses. When talking about conformance, invalid uses of imperatives are simply defects of the spec and irrelevant. YMMV. -Martin From carl@redhoundsoftware.com Mon Apr 2 13:29:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7705E21F8725 for ; Mon, 2 Apr 2012 13:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfz0Jjahep48 for ; Mon, 2 Apr 2012 13:29:01 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC3321F86FA for ; Mon, 2 Apr 2012 13:29:01 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2247232qcs.31 for ; Mon, 02 Apr 2012 13:29:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=jbzH8r94wmimFhd6CsyZoL2c8LsccxtIHSNwUjv5E+0=; b=SKUJMho85gDeSnGV+IWxssqj0P2DT01OaIUQY2EUFjGjf7hA/mc0RdCUHO8inO7+Ys ZVcHbuNBpBK5616YrTuWEaY1ZZSZpe1qzrtqLMVo2L/9pBnRS97k4vdUg/nya+p90FNp RHUgqbH8bo3Ubs5R5oLJL7OUSCtIxGqaL/U48b8dJV6t2B3LVpdYbjroLZMjVUUp8geu UEfxUE0fiNVk7xfY1injpKaby77iJvslmPSqQVp0/BTyucAzbfj5SU5tNwq0ttGJn0DM hgYblsSAALpf0gV464EaLpjH5Hy1eoVASp7E2T5x6IcDPvZHkPK771bMw8rfawjyUvEQ dtdA== Received: by 10.229.106.23 with SMTP id v23mr3982075qco.5.1333398540851; Mon, 02 Apr 2012 13:29:00 -0700 (PDT) Received: from [192.168.1.4] (pool-173-79-133-63.washdc.fios.verizon.net. [173.79.133.63]) by mx.google.com with ESMTPS id j17sm36346304qaj.9.2012.04.02.13.28.59 (version=SSLv3 cipher=OTHER); Mon, 02 Apr 2012 13:29:00 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 02 Apr 2012 16:28:55 -0400 From: Carl Wallace To: , Paul Hoffman Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: <201204022021.q32KL7m3003456@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQnlYXJa22ZMz6r8KPlXuA2qclbHjxq804Q2odZ6KKr/S97AXcIhXu8WHIFD7NFaZE/n5cAd Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:29:02 -0000 On 4/2/12 4:21 PM, "Martin Rex" wrote: >Paul Hoffman wrote: >> >> On Apr 2, 2012, at 11:51 AM, Martin Rex wrote: >> >> > rfc2119 is something like our "constitution" for standards. >> >> No, it is not. No one has pretended that until now. It is a set of >> definitions that is widely used, and is also nearly as widely abused, >> in RFCs. Note the difference? > >Most RFC (and that includes 5280) contain this disclaimer: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > >rfc2119 section 6 defines which are valid used of these imperatives, >and which are invalid uses. When talking about conformance, >invalid uses of imperatives are simply defects of the spec and >irrelevant. YMMV. The short paragraph from 2119 you cited allows MUST to be used "to limit behavior which has potential for causing harm". That applies here. > >-Martin >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Mon Apr 2 16:42:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DA121F85FB for ; Mon, 2 Apr 2012 16:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmTJXZMuVLM3 for ; Mon, 2 Apr 2012 16:42:33 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 507BE21F85BD for ; Mon, 2 Apr 2012 16:42:33 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q32NgVx3012886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Apr 2012 01:42:31 +0200 (MEST) From: Martin Rex Message-Id: <201204022342.q32NgUtq014520@fs4113.wdf.sap.corp> To: carl@redhoundsoftware.com (Carl Wallace) Date: Tue, 3 Apr 2012 01:42:30 +0200 (MEST) In-Reply-To: from "Carl Wallace" at Apr 2, 12 04:28:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 23:42:34 -0000 Carl Wallace wrote: > > >Paul Hoffman wrote: > >> > >> On Apr 2, 2012, at 11:51 AM, Martin Rex wrote: > >> > >> > rfc2119 is something like our "constitution" for standards. > >> > >> No, it is not. No one has pretended that until now. It is a set of > >> definitions that is widely used, and is also nearly as widely abused, > >> in RFCs. Note the difference? > > > >Most RFC (and that includes 5280) contain this disclaimer: > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC2119]. > > > >rfc2119 section 6 defines which are valid used of these imperatives, > >and which are invalid uses. When talking about conformance, > >invalid uses of imperatives are simply defects of the spec and > >irrelevant. YMMV. > > The short paragraph from 2119 you cited allows MUST to be used "to limit > behavior which has potential for causing harm". That applies here. Nope, it clearly does NOT apply here. A CA which does not want a certificate to be accepted by RPs that do not implement a particular name constraints extension that the CA wants to add to a subCA cert can mark that name constraints as critical. The description in http://tools.ietf.org/html/rfc3647#section-3.3.1 about the semantics of critical and non-critical certificate policies makes sense, whereas the requirement that CAs must mark name constraints critical is in clear conflict with rfc2119 section 6 and can therefore be ignored by implemenations without becoming non-compliant. -Martin From mrex@sap.com Mon Apr 2 16:45:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763E321F86DC for ; Mon, 2 Apr 2012 16:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwyKrqno9FDG for ; Mon, 2 Apr 2012 16:45:20 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE1E21F86BD for ; Mon, 2 Apr 2012 16:45:20 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q32NjJbA012970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Apr 2012 01:45:19 +0200 (MEST) From: Martin Rex Message-Id: <201204022345.q32NjI9w014956@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Tue, 3 Apr 2012 01:45:18 +0200 (MEST) In-Reply-To: <201204022342.q32NgUtq014520@fs4113.wdf.sap.corp> from "Martin Rex" at Apr 3, 12 01:42:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 23:45:22 -0000 Martin Rex wrote: > > Carl Wallace wrote: > > > > >Paul Hoffman wrote: > > >> > > >> On Apr 2, 2012, at 11:51 AM, Martin Rex wrote: > > >> > > >> > rfc2119 is something like our "constitution" for standards. > > >> > > >> No, it is not. No one has pretended that until now. It is a set of > > >> definitions that is widely used, and is also nearly as widely abused, > > >> in RFCs. Note the difference? > > > > > >Most RFC (and that includes 5280) contain this disclaimer: > > > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > > document are to be interpreted as described in [RFC2119]. > > > > > >rfc2119 section 6 defines which are valid used of these imperatives, > > >and which are invalid uses. When talking about conformance, > > >invalid uses of imperatives are simply defects of the spec and > > >irrelevant. YMMV. > > > > The short paragraph from 2119 you cited allows MUST to be used "to limit > > behavior which has potential for causing harm". That applies here. > > Nope, it clearly does NOT apply here. A CA which does not want a > certificate to be accepted by RPs that do not implement a particular > name constraints extension that the CA wants to add to a subCA cert > can mark that name constraints as critical. > > The description in > > http://tools.ietf.org/html/rfc3647#section-3.3.1 > > about the semantics of critical and non-critical certificate policies > makes sense, whereas the requirement that CAs must mark name constraints > critical is in clear conflict with rfc2119 section 6 and can therefore > be ignored by implemenations without becoming non-compliant. An "Implementation" of "must mark name constraints critical" means that a CAs can issue certs with non-critical name constraints and still be conforming to rfc5280, because that particular MUST is invalid per rfc2119 section 6. -Martin From pritikin@cisco.com Mon Apr 2 16:48:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E6421F8683 for ; Mon, 2 Apr 2012 16:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWg4+NzfOTlY for ; Mon, 2 Apr 2012 16:48:15 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id DCD9221F8755 for ; Mon, 2 Apr 2012 16:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=4860; q=dns/txt; s=iport; t=1333410494; x=1334620094; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=DMsEUTDIFNVBMMZdUn+f8dabDn6OvPMnevqg4fFmTEg=; b=JxfsUAECHz/qahu9OeOfx3wzexIa4SH9M6MeBBMkjT0zPDZsX/qK14jp TXo11K9hnMOY8aPlcjKK5Pm0Ww0QFZ1ZR9zUrBIVCx9A6JgrMyYDbO329 V/a56cV0nDTNUpG1aEJLsWVOZSg2+KsbWSxJymi8u2o+puHpV07ZJGJ4D A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQGAIM6ek+rRDoG/2dsb2JhbABDgxy0cIEHggkBAQEDAQEBAQ8BJzQHBAULCxguJzAGEyKHYgQMoBaXMQSQC2MEiFiNCYVwiFeBaIMG X-IronPort-AV: E=Sophos;i="4.75,359,1330905600"; d="scan'208";a="38769819" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 02 Apr 2012 23:48:13 +0000 Received: from [10.21.0.51] ([10.21.0.51]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q32NmC15008202; Mon, 2 Apr 2012 23:48:13 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <4F719B3D.10101@telia.com> Date: Mon, 2 Apr 2012 17:48:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F718771.6060906@ieca.com> <4F719B3D.10101@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1257) Cc: pkix@ietf.org Subject: Re: [pkix] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 23:48:16 -0000 Comments inline,=20 On Mar 27, 2012, at 4:49 AM, Anders Rundgren wrote: > Continuing this thread... >=20 > =46rom the abstract I would be interested in hearing what >=20 > "simple Public Key Infrastructure clients" >=20 > actually refer to. The first paragraph of the introduction notes that: "EST is designed to = be easily implemented by clients and servers using common "off the = shelf" PKI, HTTP, and TLS components". This also relates to the use of = the "simple" messages defined in CMC.=20 >=20 > "This profile, called Enrollment over Secure Transport (EST), > describes a simple yet functional certificate management protocol" >=20 > If you combine all the options, it is not that simple anymore. > Is a client and server assumed to support all the options? > If not, how are they supposed to know which subset that can be used? > Looks like a rather configuration-dependent scheme IMHO. If you can think of any options which can be removed please indicate = them and suggest their removal. Although I feel we've done a good job = ensuring there are very few options I'd happily hear of ones that can go = away.=20 > "K1 "Algorithm agility". The protocol MUST support algorithm = agility" >=20 > The author's opinion on what that means is flawed. Although = supporting > a bunch of TLS ciphers may be interesting, algorithm agility regarding > generated keys is a parameter that most (if not all) issuers care = about. The authors opinion is irrelevant as we're discussing the actual wording = of the text.=20 I agree that K1 should also reference the type of key material being = enrolled.=20 > "5.3 Distribution of CA certificates > Before engaging in enrollment operations, clients MUST request = trust > anchor information (in the form of certificates) by sending an = HTTPS > GET message to the EST base URI with the relative path extension > '/CACerts'" >=20 > This mandatory requirement isn't particularly universal. A more > common method is that the user rather gets an option "accepting" the > root of the distributed certificate path. I think you are excessively combining the server authentication = discussion (sections 5.2 and 4.3.1.1) and the distribution of CA = certificates.=20 There is value in the "MUST" here because then the client has any = possible CA key rollover certificates which might be necessary for chain = building etc that might be encountered during the enrollment operations. = (e.g. if the client is issued a certificate using the CA's new = certificate the client has sufficient information to know what happened = and to successfully use its new certificate).=20 > In today's server-centric > world the CA of a *client certificate* often doesn't have any > meaning for the client/user at all. IF the PKI is performing key rollover on the CA certificate then this is = not true. For example when acting as a TLS client the client must build = an appropriate chain to send to the server. In the interest of limiting = options and capability exchanges the client MUST perform this operation = even if it is only useful in some re-enrollment scenarios.=20 Thanks for your feedback, - max > Anders > PS. By thinking out loud I got an idea for KeyGen2! Add an option > to the install certificate part of the protocol where the issuer may > claim that this root may be of interest to user. By doing that = KeyGen2 > doesn't have to bother users with (for example) accepting VISA's = EMV-root > since this a thing for the merchants/acquirers to care about. DS. >=20 > On 2012-03-27 11:25, Sean Turner wrote: >> Just a couple of comments the WG should consider: >>=20 >> Technical: >>=20 >> 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s=20= >> for the request and return the certificate(s) in a mime media type. = In=20 >> many instances, the "normal" query/response for a certificate is a=20 >> PKCS#10 request followed by a PKCS#7 response, where the PKCS#7 is = the=20 >> degenerate certs-only message. Does anyone see any benefit in = reusing=20 >> the PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing it=20= >> would align nicely/exactly with the simple PKI request/response from = CMC. >>=20 >> 2. in s5.6.2, just use application/pkcs8 instead of=20 >> application/pkix-privkey. >>=20 >> Not so technical: >>=20 >> 1. appendix D really ought to be in its own document or in part of=20 >> draft-nourse-scep. >>=20 >> spt >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From piyush@identicate.com Mon Apr 2 17:00:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4FB21F86E2 for ; Mon, 2 Apr 2012 17:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hzY0I0ldyPZ for ; Mon, 2 Apr 2012 17:00:29 -0700 (PDT) Received: from col0-omc3-s4.col0.hotmail.com (col0-omc3-s4.col0.hotmail.com [65.55.34.142]) by ietfa.amsl.com (Postfix) with ESMTP id ECF8521F8755 for ; Mon, 2 Apr 2012 17:00:28 -0700 (PDT) Received: from COL119-W42 ([65.55.34.136]) by col0-omc3-s4.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 17:00:28 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_b35fc61c-cb12-4468-88a5-3b7242ad5fe5_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , Date: Mon, 2 Apr 2012 17:00:27 -0700 Importance: Normal In-Reply-To: <201204022342.q32NgUtq014520@fs4113.wdf.sap.corp> References: from "Carl Wallace" at Apr 2, 12 04:28:55 pm, <201204022342.q32NgUtq014520@fs4113.wdf.sap.corp> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Apr 2012 00:00:28.0125 (UTC) FILETIME=[C729C8D0:01CD112C] Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 00:00:32 -0000 --_b35fc61c-cb12-4468-88a5-3b7242ad5fe5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > From: mrex@sap.com > To: carl@redhoundsoftware.com > Date: Tue=2C 3 Apr 2012 01:42:30 +0200 > CC: pkix@ietf.org=3B paul.hoffman@vpnc.org > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name >=20 > Carl Wallace wrote: > >=20 > > >Paul Hoffman wrote: > > >>=20 > > >> On Apr 2=2C 2012=2C at 11:51 AM=2C Martin Rex wrote: > > >>=20 > > >> > rfc2119 is something like our "constitution" for standards. > > >>=20 > > >> No=2C it is not. No one has pretended that until now. It is a set of > > >> definitions that is widely used=2C and is also nearly as widely abus= ed=2C > > >> in RFCs. Note the difference? > > > > > >Most RFC (and that includes 5280) contain this disclaimer: > > > > > > The key words "MUST"=2C "MUST NOT"=2C "REQUIRED"=2C "SHALL"=2C "SHA= LL NOT"=2C > > > "SHOULD"=2C "SHOULD NOT"=2C "RECOMMENDED"=2C "MAY"=2C and "OPTIONAL= " in this > > > document are to be interpreted as described in [RFC2119]. > > > > > >rfc2119 section 6 defines which are valid used of these imperatives=2C > > >and which are invalid uses. When talking about conformance=2C > > >invalid uses of imperatives are simply defects of the spec and > > >irrelevant. YMMV. > >=20 > > The short paragraph from 2119 you cited allows MUST to be used "to limi= t > > behavior which has potential for causing harm". That applies here. >=20 > Nope=2C it clearly does NOT apply here. A CA which does not want a > certificate to be accepted by RPs that do not implement a particular > name constraints extension that the CA wants to add to a subCA cert > can mark that name constraints as critical. > So you are saying that RPs are not subjected to any security risk by igno= ring the NC extension. That would be a very interesting claim.Just lay out = a scenario where a CA includes the NC extension and the security implicatio= ns are same for RPs who ignore it and the RPs who process it. And then ask = the question if the the CA needs to include the NC at all in such a scenari= o. > The description in >=20 > http://tools.ietf.org/html/rfc3647#section-3.3.1 >=20 > about the semantics of critical and non-critical certificate policies > makes sense=2C whereas the requirement that CAs must mark name constraint= s > critical is in clear conflict with rfc2119 section 6 and can therefore > be ignored by implemenations without becoming non-compliant. >=20 Most people in this group disagree with this interpretation. So=2C obviousl= y the conflict (if any) is not clear. >=20 > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_b35fc61c-cb12-4468-88a5-3b7242ad5fe5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B From: mrex@sap.co= m
>=3B To: carl@redhoundsoftware.com
>=3B Date: Tue=2C 3 Apr 2012= 01:42:30 +0200
>=3B CC: pkix@ietf.org=3B paul.hoffman@vpnc.org
>= =3B Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Nam= e
>=3B
>=3B Carl Wallace wrote:
>=3B >=3B
>=3B >= =3B >=3BPaul Hoffman wrote:
>=3B >=3B >=3B>=3B
>=3B >= =3B >=3B>=3B On Apr 2=2C 2012=2C at 11:51 AM=2C Martin Rex wrote:
&g= t=3B >=3B >=3B>=3B
>=3B >=3B >=3B>=3B >=3B rfc2119 is s= omething like our "constitution" for standards.
>=3B >=3B >=3B>= =3B
>=3B >=3B >=3B>=3B No=2C it is not. No one has pretended th= at until now. It is a set of
>=3B >=3B >=3B>=3B definitions that= is widely used=2C and is also nearly as widely abused=2C
>=3B >=3B = >=3B>=3B in RFCs. Note the difference?
>=3B >=3B >=3B
>= =3B >=3B >=3BMost RFC (and that includes 5280) contain this disclaimer:=
>=3B >=3B >=3B
>=3B >=3B >=3B The key words "MUST"=2C = "MUST NOT"=2C "REQUIRED"=2C "SHALL"=2C "SHALL NOT"=2C
>=3B >=3B >= =3B "SHOULD"=2C "SHOULD NOT"=2C "RECOMMENDED"=2C "MAY"=2C and "OPTIONAL" = in this
>=3B >=3B >=3B document are to be interpreted as describ= ed in [RFC2119].
>=3B >=3B >=3B
>=3B >=3B >=3Brfc2119 sec= tion 6 defines which are valid used of these imperatives=2C
>=3B >= =3B >=3Band which are invalid uses. When talking about conformance=2C>=3B >=3B >=3Binvalid uses of imperatives are simply defects of the = spec and
>=3B >=3B >=3Birrelevant. YMMV.
>=3B >=3B
>= =3B >=3B The short paragraph from 2119 you cited allows MUST to be used "= to limit
>=3B >=3B behavior which has potential for causing harm". = That applies here.
>=3B
>=3B Nope=2C it clearly does NOT apply h= ere. A CA which does not want a
>=3B certificate to be accepted by RP= s that do not implement a particular
>=3B name constraints extension t= hat the CA wants to add to a subCA cert
>=3B can mark that name constr= aints as critical.
>=3B =3B
So you are saying that RPs a= re not subjected to any security risk by ignoring the NC extension. That wo= uld be a very interesting claim.
Just lay out a scenario where a = CA includes the NC extension and the security implications are same for RPs= who ignore it and the RPs who process it. And then ask the question if the= the CA needs to include the NC at all in such a scenario.


>=3B The description in
>=3B
>=3B ht= tp://tools.ietf.org/html/rfc3647#section-3.3.1
>=3B
>=3B about t= he semantics of critical and non-critical certificate policies
>=3B ma= kes sense=2C whereas the requirement that CAs must mark name constraints>=3B critical is in clear conflict with rfc2119 section 6 and can theref= ore
>=3B be ignored by implemenations without becoming non-compliant.<= br>>=3B =3B

Most people in this group disagr= ee with this interpretation. So=2C obviously the conflict (if any) is not c= lear.

>=3B
>=3B -Martin
>=3B ___________________= ____________________________
>=3B pkix mailing list
>=3B pkix@iet= f.org
>=3B https://www.ietf.org/mailman/listinfo/pkix
=
= --_b35fc61c-cb12-4468-88a5-3b7242ad5fe5_-- From pritikin@cisco.com Mon Apr 2 17:08:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3840D21F8710 for ; Mon, 2 Apr 2012 17:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5SJW9Tw6034 for ; Mon, 2 Apr 2012 17:08:38 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 65C7C21F870F for ; Mon, 2 Apr 2012 17:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=5942; q=dns/txt; s=iport; t=1333411718; x=1334621318; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=E1LJgZpTjsUSbT1TTNfZlREQDbq2OK1/apaXqe99oMQ=; b=moA1tjtcLC2uFozVOy5xPhqQEfo+x2vY/ULwdnkT5wGJZ5yRngMnAVes 8wQGYdaDWwFppMZ5m0Ft8EV/frWnUd9TRmDAwtrBVxwKw5IwWpwDFleGG toEJp2s9E3dC0S0ThHP4poJy30I9/l1N54xSqvCaOX07N2oxc/+oP2rzH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQGAMg+ek+rRDoJ/2dsb2JhbABFgw+0cIEHggkBAQEDAQEBAQ8BJzQHBAULIy4nMAYTIodiBAybYZ8cBIsKhQFjBIhYjQmFcIhXgWiDBoE1 X-IronPort-AV: E=Sophos;i="4.75,359,1330905600"; d="scan'208";a="35656491" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 03 Apr 2012 00:08:38 +0000 Received: from [10.21.0.51] ([10.21.0.51]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3308bWu002911; Tue, 3 Apr 2012 00:08:37 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: <4F72D73E.1010705@primekey.se> Date: Mon, 2 Apr 2012 18:08:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6080E9C0-D3A3-4408-AC11-08DBBBFEF6FD@cisco.com> References: <4F718771.6060906@ieca.com> <4F719B3D.10101@telia.com> <4F72D73E.1010705@primekey.se> To: Tomas Gustavsson X-Mailer: Apple Mail (2.1257) Cc: pkix@ietf.org Subject: [pkix] Multiple CAs from one EST server Re: some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 00:08:42 -0000 (I've updated the subject on this thread) On Mar 28, 2012, at 3:17 AM, Tomas Gustavsson wrote: >=20 > You comment made me realize something Anders. >=20 > * Support for multiple CAs >=20 > Imho new protocols should support the function where the EST/CA server = contains multiple CAs. Think of one EST front end with multiple CA = backends. Most CA software today runs multiple CAs in a single instance, = and with cloud computing this only grows. >=20 > Multiple CAs can be handled with virtual hosts, but it's simpler if = there is protocol suppport. Hmm. I'd imagined either virtual hosts or differing BASEPATHs in the = URLs so that these would be three distinct EST servers offering CACerts = for different CAs: a) https://example1.org/arbitrary/base/path/CACerts b) https://example2.org/arbitrary/base/path/CACerts c) https://example2.org/DIFFERENT/base/path/CACerts In practice I expect this implies the use of Section 5.2 method 1.=20 For (a) and (b) the TLS SNI extension could be used to decide on which = server cert to use thus allowing limited use of Section 5.2 method 2 = although there is no text in the draft discussing this. Method 2 isn't = an option for (b) and (c) differentiation since there is no way to = determine the BASEPATH within the SNI extension. Should there be such = text? I tend to think this is more of a common HTTPS issue and is = supported by TLS (although not commonly?) and that nothing needs to be = discussed.=20 > Section 5.3 and 5.3.1 does not make it clear how this should work. In = fact section 5.3 is very cryptic. The URL ending is /CACerts but section = 5.3.1 says "CA trust anchor information in the form of a certificate.". Thanks for the catch. This should be plural as multiple certificates are = in the response.=20 > Can /CACerts only return a single certificate? Kind of against the = name, or can "trust anchor information" mean multiple independent = certificate chains? Section 5.3.1 paragraph 1, second sentence: "Additionally the server = MUST include any "Root CA Key Update" CMP certificates". The remainder = of this section details exactly what these certificates are -- but they = are all for the same CA. > For enrollment, ways of identifying the target CA is also desired. For = CRMF this is usually embedded in the request, but for PKCS#10 it is = not... As discussed above the URI can accurately describe which CA. Does this all work for you? Thanks, - max > Regards, > Tomas >=20 > On 03/27/2012 12:49 PM, Anders Rundgren wrote: >> Continuing this thread... >>=20 >> =46rom the abstract I would be interested in hearing what >>=20 >> "simple Public Key Infrastructure clients" >>=20 >> actually refer to. >>=20 >> "This profile, called Enrollment over Secure Transport (EST), >> describes a simple yet functional certificate management protocol" >>=20 >> If you combine all the options, it is not that simple anymore. >> Is a client and server assumed to support all the options? >> If not, how are they supposed to know which subset that can be used? >> Looks like a rather configuration-dependent scheme IMHO. >>=20 >>=20 >> "K1 "Algorithm agility". The protocol MUST support algorithm = agility" >>=20 >> The author's opinion on what that means is flawed. Although = supporting >> a bunch of TLS ciphers may be interesting, algorithm agility = regarding >> generated keys is a parameter that most (if not all) issuers care = about. >>=20 >>=20 >> "5.3 Distribution of CA certificates >> Before engaging in enrollment operations, clients MUST request = trust >> anchor information (in the form of certificates) by sending an = HTTPS >> GET message to the EST base URI with the relative path = extension >> '/CACerts'" >>=20 >> This mandatory requirement isn't particularly universal. A more >> common method is that the user rather gets an option "accepting" the >> root of the distributed certificate path. In today's server-centric >> world the CA of a *client certificate* often doesn't have any >> meaning for the client/user at all. >>=20 >> Anders >> PS. By thinking out loud I got an idea for KeyGen2! Add an option >> to the install certificate part of the protocol where the issuer may >> claim that this root may be of interest to user. By doing that = KeyGen2 >> doesn't have to bother users with (for example) accepting VISA's = EMV-root >> since this a thing for the merchants/acquirers to care about. DS. >>=20 >> On 2012-03-27 11:25, Sean Turner wrote: >>> Just a couple of comments the WG should consider: >>>=20 >>> Technical: >>>=20 >>> 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use = PKCS#10s >>> for the request and return the certificate(s) in a mime media type. = In >>> many instances, the "normal" query/response for a certificate is a >>> PKCS#10 request followed by a PKCS#7 response, where the PKCS#7 is = the >>> degenerate certs-only message. Does anyone see any benefit in = reusing >>> the PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing = it >>> would align nicely/exactly with the simple PKI request/response from = CMC. >>>=20 >>> 2. in s5.6.2, just use application/pkcs8 instead of >>> application/pkix-privkey. >>>=20 >>> Not so technical: >>>=20 >>> 1. appendix D really ought to be in its own document or in part of >>> draft-nourse-scep. >>>=20 >>> spt >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From pritikin@cisco.com Mon Apr 2 17:34:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAB021F8683 for ; Mon, 2 Apr 2012 17:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSienlZFV4lZ for ; Mon, 2 Apr 2012 17:34:50 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6F50721F85EE for ; Mon, 2 Apr 2012 17:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=3539; q=dns/txt; s=iport; t=1333413290; x=1334622890; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zR6RzQu//yd/iU4hTY9uweLdcbgkWY+aB4WXV2vEuLI=; b=Yd8FjiNFFdGqLBldmIaWc0Clh2LO1+5wVK5U1RZT9Qz1KcW2ZuUD7Lmv quhhhazxdAlLv0jij0RAnPEMcCw7ZZgQViWodIcUq17kjj930hrcaLf13 x0Sw5ssuj8hx5tYbCF0ZFuGRwMQ3oWWgbZdgSxpdlgsw2dvPbbCfr/3WI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQGANVEek+rRDoG/2dsb2JhbABDgxy0cYEHggkBAQEDAQEBAQ8BJzQLEAUULQsnMAYTERGHYgQMoByXNgSQC2MEiFiNCYVwiFeBaIMG X-IronPort-AV: E=Sophos;i="4.75,359,1330905600"; d="scan'208";a="36196312" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 03 Apr 2012 00:34:50 +0000 Received: from [10.21.0.51] ([10.21.0.51]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q330YnSH003373; Tue, 3 Apr 2012 00:34:49 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Max Pritikin X-Priority: 3 (Normal) In-Reply-To: <260966ff0f0743ba0f04d902cca68116.squirrel@www.trepanning.net> Date: Mon, 2 Apr 2012 18:34:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <17E480DA-907D-4F40-BDE5-0A10930E3695@cisco.com> References: <260966ff0f0743ba0f04d902cca68116.squirrel@www.trepanning.net> To: Dan Harkins X-Mailer: Apple Mail (2.1257) Cc: pkix@ietf.org Subject: [pkix] Using "CMC Simple PKI Response" rather than "certificate" (was: Re: some comments on draft-ietf-pkix-est-01) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 00:34:51 -0000 (I've updated the subject on this thread) My thoughts on this have not solidified yet. A couple of initial = questions, a) this requires the server to build and sign this response. Coding that = is relatively simple with off the shelf libraries but it will require = additional ASN1 and crypto operations that are effectively ignored. Is = this then an effective use of server (and client!) resources? b) Should the signature on this PKCS#7 be ignored? What if the CA has = moved on to a new key? How does it know to use an old key for this = signing?=20 c) The Simple PKI Response section 4.1 [RFC5272] includes a variety of = "MAY" statements (options!). If we move in this direction would there be = support for profiling these to a more restrictive set of options? For = each of the following statements from paragraph 2 I'm thinking: "Servers SHOULD include all intermediate certificates needed to form = complete certification paths to one or more trust anchors, not just the = newly issued certificate(s)." Change to MUST NOT.=20 Justification: this is not a trust anchor management protocol, thus this = type of flexibility isn't warranted here.=20 "The server MAY additionally return CRLs in the CRL bag." Change to MUST NOT. Justification: This is not a CRL distribution protocol, thus the best = the server can do is provide a CRL appropriate for this client's = certificate at this point in time which is of minimal use. Also not = including anything specific to the client allows the PKCS#7 to be = pre-generated for /CACerts. "Servers MAY include the self-signed certificates." (I"m assuming this means including its own self-signed certificate?) Change to MUST (and add "In addition the Root CA Key Update certificates = SHOULD be included."). Justification: The CA certs MUST be included for /CACerts so make them = always included (reducing options). This would allow clients to skip = calling /CACerts for re-enroll since they'd always receive any new CA = certs in the response. =20 "In the event clients receive a new self-signed certificate from the = server, clients SHOULD provide a mechanism to enable the user to use the = certificate as a trust anchor" Change to MUST (and make this automatic).=20 Justification: Although not doing general trust anchor management we = want to make sure CA key renewal works seamlessly.=20 Thanks for continued discussion, - max On Mar 28, 2012, at 3:04 AM, Dan Harkins wrote: >=20 > Hi, >=20 > On Tue, 27 Mar 2012 at 11:25:05 Sean Turner said: >> Just a couple of comments the WG should consider: >>=20 >> Technical: >>=20 >> 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s = for >> the request and return the certificate(s) in a mime media type. In = many >> instances, the "normal" query/response for a certificate is a PKCS#10 >> request followed by a PKCS#7 response, where the PKCS#7 is the = degenerate >> certs-only message. Does anyone see any benefit in reusing the >> PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing it = would >> align nicely/exactly with the simple PKI request/response from CMC. >=20 > Yes, I see value in reusing the PKCS#10/PKCS#7 model. EST is supposed > to implement "simple CMC" and that should use a PKCS#7 as the simple > response. >=20 > regards, >=20 > Dan. >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From tgindin@us.ibm.com Mon Apr 2 18:09:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F80021F8753 for ; Mon, 2 Apr 2012 18:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw9RWzHB2Ivi for ; Mon, 2 Apr 2012 18:09:39 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by ietfa.amsl.com (Postfix) with ESMTP id 57FBC21F8752 for ; Mon, 2 Apr 2012 18:09:39 -0700 (PDT) Received: from /spool/local by e2.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 2 Apr 2012 21:09:36 -0400 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e2.ny.us.ibm.com (192.168.1.102) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 2 Apr 2012 21:09:33 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 1A9D038C8054 for ; Mon, 2 Apr 2012 21:09:30 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3319BJI278718 for ; Mon, 2 Apr 2012 21:09:17 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3319BiN002985 for ; Mon, 2 Apr 2012 21:09:11 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3319BJM002981; Mon, 2 Apr 2012 21:09:11 -0400 In-Reply-To: <342C4A32-E427-440C-B69D-355B27584E43@fastq.com> References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> <4F79E694.5020804@seantek.com> <342C4A32-E427-440C-B69D-355B27584E43@fastq.com> To: Michael Myers MIME-Version: 1.0 X-KeepSent: 5DF180B1:2E880785-852579D4:006F924B; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Mon, 2 Apr 2012 21:09:10 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/02/2012 21:09:10, Serialize complete at 04/02/2012 21:09:10 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040301-5112-0000-0000-000006BCBB78 Cc: pkix@ietf.org, Sean Leonard Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 01:09:40 -0000 I'm obviously outvoted, but I'm in favor of MAY rather than MUST or even SHOULD. Leaving this extension as MUST be critical won't get it widely adopted any more than in the past decade, and IMHO the security difference between the CA's omitting this extension for compatibility reasons and it being non-critical is greater than that between it being non-critical and critical. Tom Gindin From: Michael Myers To: Sean Leonard , Cc: pkix@ietf.org Date: 04/02/2012 02:00 PM Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD Sent by: pkix-bounces@ietf.org Toward WG consensus, keep it MUST. SHALL would be even better, but that's a semantic thing on my part. Mike On Apr 2, 2012, at 10:49 AM, Sean Leonard wrote: > On 4/2/2012 5:32 AM, Paul Hoffman wrote: >> On Apr 2, 2012, at 2:23 AM, Rob Stradling wrote: >> >>> PROPOSAL: Change the "MUST" to "SHOULD". >>> >> Fully disagree. A number of people gave security reasons for the >> current wording. Watering down the security of the protocol because >> a vendor made a bad decision and no one is doing conformance >> testing (which would have trivially picked this up) is not a good >> response. > > +1 for Paul's comment. > > -1 for voting. Keep it "MUST". > > -Sean _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From kent@bbn.com Mon Apr 2 18:11:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A5A21F856F for ; Mon, 2 Apr 2012 18:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qfbz6WmyqSms for ; Mon, 2 Apr 2012 18:11:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BDA1D21F8535 for ; Mon, 2 Apr 2012 18:11:42 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:44232 helo=[192.168.4.14]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SEsHM-0000aG-TY; Mon, 02 Apr 2012 21:11:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201203301851.q2UIpSk7015499@fs4113.wdf.sap.corp> References: <201203301851.q2UIpSk7015499@fs4113.wdf.sap.corp> Date: Mon, 2 Apr 2012 21:11:37 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org, kwilson@mozilla.com Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 01:11:44 -0000 At 8:51 PM +0200 3/30/12, Martin Rex wrote: >Stephen Kent wrote: >> >> At 4:46 PM -0400 3/29/12, Adam Langley wrote: >> >... >> > >> >I mean that I've not encountered any path validation software that >> >requires that a name constraint, when present, to be critical. If >> >anybody knows otherwise, I'm sure Rob would be interested to hear >> >about it. >> >> Adam, I applaud your interest in using NameConstraints to improve secruity >> relative to the browser public TA trust model. > >I'm a little confused. The endpoint identification performed with the >"browser public TA trust model" is based on DNS names rather than on >distinguished directory names. I had to read the next paragraph to figure out what point you were making above. Over time, there have been three ways to provide a browser with DNS name info for comparison against a target URL: - a Netscape extension - embedding the DNS name in the CN field of a DN - Subject alt name of type DNS The first option is independent of name constraints, the final one works with name constraints. The middle option would be subject to the extension, but not in a useful way for this problem. > > The concern is that RPs might not follow 5280 (and its 2 predecessor > > cert & CRL profile RFCs) re support of this extension. > >rfc5280 and its predecessors "require" support for name constraints >*ONLY* on the directory name. Support for name constraints on >subjectAltNames (those that are typically used for server endpoint >identification performed with the "browser public TA trust model" >is _not_ required, only recommended. So rfc5280 compliance >seem not to help here at all, see last paragraph here: yes, this is a SHOULD, not a MUST. But if you look at the definition of SHOULD and consider the context in question (browsers) it seems to me that this is a context in which support ought to be present. > http://tools.ietf.org/html/rfc5280#page-40 > >Looking at *real* existing certs, like the one presented by >"https://www.google.pl" when connecting with *NO* TLS extension SNI, >contains 436 subject alt names of type DNSName, all different. as others have noted, this is not a valid example relative to this discussion. >If that cert would have to be equipped with subject alt name constraints >for each and every of those names, it would probably grow much larger >than 16 KByte and cause a number of TLS clients to abort the handshake >due to the size of the server certificate... no, for the reasons cited by others. Steve From kyanha@kyanha.net Mon Apr 2 19:45:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043B921F86A0 for ; Mon, 2 Apr 2012 19:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPIvjj6a4oIV for ; Mon, 2 Apr 2012 19:45:34 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 28C4021F869F for ; Mon, 2 Apr 2012 19:45:33 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so4960045pbb.31 for ; Mon, 02 Apr 2012 19:45:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type:x-gm-message-state; bh=UVeC6j35mEQ7GJH7DoEj4VZyXFiwMG2kZ7Lwev5JVUI=; b=UG6e493h9IAKYA3LHT9P8ECEQh7mGYRyhfjTnmUhcS0fKjQJY17SmZzxVIJ9BU4Q8b o0V+Tk8OVEvfB17jBzmUKAeLMJRZdypN6KYJDS4K4uDYij83UEaKxm5g/F9CgbNb10Sn /n/2rOZm35gMvNfH1/JPLwZXZQ9ZTzkV84y2R2EgFyVncbzgbcEPdoGcz44AEYgAp6z3 Y3nfp0w/NPHPsbXz3+00z15Nbx+tHAX7z9J2uAdQ9LX/Z1myQzdQIFsp0hXtJ7gj4eFn lMt2DZwha5jDEllPnpk87BbNqZe5w58xMd3WUBpqgK8bnjS0KElEcUQe1AoTagoBaTIb SZYw== Received: by 10.68.193.161 with SMTP id hp1mr24927143pbc.106.1333421133779; Mon, 02 Apr 2012 19:45:33 -0700 (PDT) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id o9sm15256399pbe.60.2012.04.02.19.45.31 (version=SSLv3 cipher=OTHER); Mon, 02 Apr 2012 19:45:32 -0700 (PDT) From: "Kyle Hamilton" To: "Adam Langley" Date: Mon, 2 Apr 2012 19:45:29 -0700 (Pacific Daylight Time) Message-ID: In-Reply-To: <4F74C077.4050103@comodo.com> References: <4F74C077.4050103@comodo.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.6eqh0kcig48dmbe7t87uf2 X-Gm-Message-State: ALoCoQk3mYcJmhNCAhfm/jI8T/6bFP3psyY4TsgUEexSwgexNXZ/xPyrDXwK+648aZ1Vaw8E5zoH Cc: "pkix@ietf.org" , Kathleen Wilson Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 02:45:35 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.6eqh0kcig48dmbe7t87uf2 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit On Thu, Mar 29, 2012 at 1:14 PM, Adam Langley wrote: > On Thu, Mar 29, 2012 at 4:05 PM, Rob Stradling wrote: >> Should RFC5280 be updated to specify that Name Constraints need not be >> critical? > > I'm not aware of any software that enforces this requirement and agree > that the MUST in RFC 5280 is unhelpful and support the idea that it > should be removed. I disagree. Name Constraints is integral to understanding the semantic of a CA certificate, and really has to be be critical. This is the same reason why Basic Constraints must be critical (to determine if it's even a CA certificate). I query, how is it unhelpful? How does it get in the way? How does it cause problems? It seems that the only motivation for this is the removal of language in the Basic Requirements. There is, however, a MUST in the same clause which I think should be gotten rid of: "The Name Constraints extension, which MUST only appear in CA certificates, [...]". The only time a person should need the action of the CA should be when his identity is being verified, when his identity is subpoenaed, when he's renewing, and when he needs to rekey/revoke. Why should a person be prohibited from issuing certificates to his own devices using his certified key? (I must point out, 100 CAs is not going to be enough to handle the demand of individuals when the barriers against their adoption of cryptographic security are removed. Do we want to spam them with requests for additional device keys on top of that?) I would like to allow device certificates to be issued by end entity certificates. To do this with any effective DNS-related control, Name Constraints must be in end entity certificates. I would suggest that End Entity Name Constraints be non-critical to avoid disrupting current deployment (since EE NC doesn't change any semantics if it's not understood). -Kyle H --gmsm1.9.6eqh0kcig48dmbe7t87uf2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINAjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGxjCCBa6g AwIBAgICCMUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNzE5MDFaFw0xMjA2MDUyMDMxMzFaMIHAMSAwHgYDVQQNExcyMDc2MDUtQzh5TUxvb3ll VE85NFFKeDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xIDAeBgkqhkiG9w0BCQEWEWt5YW5oYUBreWFuaGEubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5YylxEUtOSlqBT0sxqB7H0YUDx30ADzggTrSLA9n JVa0QCcIXhk04n7VUD5Augbc40rWhgmB8xl6N9pQ5qvAQZj8JmNej6LRlueN/et9MCjNN0euH0Ky zzKBSE5fxoUPYTTa6QBBurmKNR0navAKWBi8ITLRPi864zTay2oW1A1E1nt69SgJGn3PAv/LyKII WWMzu9YeJsRCd4u6vLHOsGHvr5rc7Dq4bXx8x+vyHgSuYccAnNu81lOC2Unea4TORMoULiwKOTRb pEy35H9Y7MW+SCTlaQiSLgxvYB260OuofHZgcS0wr/OnbGVAEUeBRYhfu3BaxNlZ6zY7mvs9NwID AQABo4IC+jCCAvYwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBThUNrymHVQVA3i/K/6BF4dnrmTqDAfBgNVHSMEGDAWgBSuVYNv 7DHKufcd+q9rMfPIHeOsuzAcBgNVHREEFTATgRFreWFuaGFAa3lhbmhhLm5ldDCCAUIGA1UdIASC ATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p bnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFM aW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9v Y3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDov L3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAjquLhQpUqqxo pg1hbv8zADjhTUY1Gxm1Ha/5Ntdjds7HZ54jOqD2fVwWRbqLAtq+rwHIaudvk13icftTedJlV01r +6VjmOZhSwOPPiYG/v81ABitv8bfyOkei/3BblORXOyzwuXHrbmMOgaEcCmQmqyTo1UJiNMy5Tw0 CvDt+KbSbGP2lQL8BAGyLhswuGePoReqw221KsX6sZJ4Eovk70SlNN19YiRAFYdWL+ggY5mMPn9S qXk8GGLaOyg3g2HnVr7Y4MLYfI0pheoRvoGxj8a4xofTz3u6OlGYE/3D5/uLQbw/rTz6GVVgUFPi GFSKZjzXwfEYJ3Kd1BMXCyfE6zGCAnwwggJ4AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAgjFMAkGBSsOAwIaBQCggb4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTIwNDAzMDI0NTI5WjAjBgkqhkiG9w0BCQQxFgQUueVz7Q4NZUC58RGfrWoi9wKD YiIwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIIBAFla/o+rfhCHKQxnz1rImAJwmSa5lVO2nuq7jRH3teODv4MDQcEeUCSGQerSJskh+vh8boir a+I5P9Ulp9A0NiwfhUNecrcwb6Qfvs95uEhJqsbjFUCJ9YSPuAcpXjV3NP9Df8egPevHGZzmZaBB 8Yel3xnP5I6gDTaO99EKcuPRVNr5L3GpjzotwOJx4p5V/gKsHKfsRHTsBJWbkOLwA1uNZUiB9Rxv ikib/8/0saHxA3XM9TDss+NHsfewApQ/sOO2GKw0UiT8Un1tGAdoPNAfGigUc/Q0KrpiOnMe1h2z r8VRbbKqpxCgq/+LcUaEtJZ1kuYRl+YSeTZOgwGJC10AAAAAAAA= --gmsm1.9.6eqh0kcig48dmbe7t87uf2-- From tomas@primekey.se Tue Apr 3 01:11:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063E821F854E for ; Tue, 3 Apr 2012 01:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHOuYtjOstTN for ; Tue, 3 Apr 2012 01:11:06 -0700 (PDT) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id 852FE21F851A for ; Tue, 3 Apr 2012 01:11:05 -0700 (PDT) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id E97B0E1B46 for ; Tue, 3 Apr 2012 10:11:07 +0200 (CEST) Received: from [192.168.3.193] (unknown [193.12.106.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id D0D3BE12AB for ; Tue, 3 Apr 2012 10:11:07 +0200 (CEST) Message-ID: <4F7AB091.9010706@primekey.se> Date: Tue, 03 Apr 2012 10:10:57 +0200 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: <4F718771.6060906@ieca.com> <4F719B3D.10101@telia.com> <4F72D73E.1010705@primekey.se> <6080E9C0-D3A3-4408-AC11-08DBBBFEF6FD@cisco.com> In-Reply-To: <6080E9C0-D3A3-4408-AC11-08DBBBFEF6FD@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [pkix] Multiple CAs from one EST server Re: some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 08:11:18 -0000 On 04/03/2012 02:08 AM, Max Pritikin wrote: > (I've updated the subject on this thread) > > On Mar 28, 2012, at 3:17 AM, Tomas Gustavsson wrote: > >> >> You comment made me realize something Anders. >> >> * Support for multiple CAs >> >> Imho new protocols should support the function where the EST/CA server contains multiple CAs. Think of one EST front end with multiple CA backends. Most CA software today runs multiple CAs in a single instance, and with cloud computing this only grows. >> >> Multiple CAs can be handled with virtual hosts, but it's simpler if there is protocol suppport. > > Hmm. I'd imagined either virtual hosts or differing BASEPATHs in the URLs so that these would be three distinct EST servers offering CACerts for different CAs: > > a) https://example1.org/arbitrary/base/path/CACerts > b) https://example2.org/arbitrary/base/path/CACerts > c) https://example2.org/DIFFERENT/base/path/CACerts Different baspaths is something I like! > > In practice I expect this implies the use of Section 5.2 method 1. > > For (a) and (b) the TLS SNI extension could be used to decide on which server cert to use thus allowing limited use of Section 5.2 method 2 although there is no text in the draft discussing this. Method 2 isn't an option for (b) and (c) differentiation since there is no way to determine the BASEPATH within the SNI extension. Should there be such text? I tend to think this is more of a common HTTPS issue and is supported by TLS (although not commonly?) and that nothing needs to be discussed. > >> Section 5.3 and 5.3.1 does not make it clear how this should work. In fact section 5.3 is very cryptic. The URL ending is /CACerts but section 5.3.1 says "CA trust anchor information in the form of a certificate.". > > Thanks for the catch. This should be plural as multiple certificates are in the response. > >> Can /CACerts only return a single certificate? Kind of against the name, or can "trust anchor information" mean multiple independent certificate chains? > > Section 5.3.1 paragraph 1, second sentence: "Additionally the server MUST include any "Root CA Key Update" CMP certificates". The remainder of this section details exactly what these certificates are -- but they are all for the same CA. > > >> For enrollment, ways of identifying the target CA is also desired. For CRMF this is usually embedded in the request, but for PKCS#10 it is not... > > As discussed above the URI can accurately describe which CA. > > Does this all work for you? Yes. Example descriptions of different basepaths and the clarification regarding CA certificates works fine for me. Cheers, Tomas > > Thanks, > > - max > >> Regards, >> Tomas >> >> On 03/27/2012 12:49 PM, Anders Rundgren wrote: >>> Continuing this thread... >>> >>> From the abstract I would be interested in hearing what >>> >>> "simple Public Key Infrastructure clients" >>> >>> actually refer to. >>> >>> "This profile, called Enrollment over Secure Transport (EST), >>> describes a simple yet functional certificate management protocol" >>> >>> If you combine all the options, it is not that simple anymore. >>> Is a client and server assumed to support all the options? >>> If not, how are they supposed to know which subset that can be used? >>> Looks like a rather configuration-dependent scheme IMHO. >>> >>> >>> "K1 "Algorithm agility". The protocol MUST support algorithm agility" >>> >>> The author's opinion on what that means is flawed. Although supporting >>> a bunch of TLS ciphers may be interesting, algorithm agility regarding >>> generated keys is a parameter that most (if not all) issuers care about. >>> >>> >>> "5.3 Distribution of CA certificates >>> Before engaging in enrollment operations, clients MUST request trust >>> anchor information (in the form of certificates) by sending an HTTPS >>> GET message to the EST base URI with the relative path extension >>> '/CACerts'" >>> >>> This mandatory requirement isn't particularly universal. A more >>> common method is that the user rather gets an option "accepting" the >>> root of the distributed certificate path. In today's server-centric >>> world the CA of a *client certificate* often doesn't have any >>> meaning for the client/user at all. >>> >>> Anders >>> PS. By thinking out loud I got an idea for KeyGen2! Add an option >>> to the install certificate part of the protocol where the issuer may >>> claim that this root may be of interest to user. By doing that KeyGen2 >>> doesn't have to bother users with (for example) accepting VISA's EMV-root >>> since this a thing for the merchants/acquirers to care about. DS. >>> >>> On 2012-03-27 11:25, Sean Turner wrote: >>>> Just a couple of comments the WG should consider: >>>> >>>> Technical: >>>> >>>> 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s >>>> for the request and return the certificate(s) in a mime media type. In >>>> many instances, the "normal" query/response for a certificate is a >>>> PKCS#10 request followed by a PKCS#7 response, where the PKCS#7 is the >>>> degenerate certs-only message. Does anyone see any benefit in reusing >>>> the PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing it >>>> would align nicely/exactly with the simple PKI request/response from CMC. >>>> >>>> 2. in s5.6.2, just use application/pkcs8 instead of >>>> application/pkix-privkey. >>>> >>>> Not so technical: >>>> >>>> 1. appendix D really ought to be in its own document or in part of >>>> draft-nourse-scep. >>>> >>>> spt >>>> _______________________________________________ >>>> 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 ynir@checkpoint.com Tue Apr 3 01:59:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D3F21F8633 for ; Tue, 3 Apr 2012 01:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpaDtkmk9I7H for ; Tue, 3 Apr 2012 01:59:46 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 49F8C21F85F0 for ; Tue, 3 Apr 2012 01:59:41 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q338xeqm029946 for ; Tue, 3 Apr 2012 11:59:40 +0300 X-CheckPoint: {4F7AC9B4-1-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 3 Apr 2012 11:59:40 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 3 Apr 2012 11:59:38 +0300 From: Yoav Nir To: "pkix@ietf.org" Date: Tue, 3 Apr 2012 11:59:40 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD Thread-Index: Ac0ReBksZkQ7S9vDSSmfefUojet7lQ== Message-ID: <1E6BAF89-36AF-4303-A6F2-B486551B47DC@checkpoint.com> References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> <4F79E694.5020804@seantek.com> <342C4A32-E427-440C-B69D-355B27584E43@fastq.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 08:59:47 -0000 On Apr 3, 2012, at 4:09 AM, Tom Gindin wrote: > I'm obviously outvoted, but I'm in favor of MAY rather than MUST=20 > or even SHOULD. Leaving this extension as MUST be critical won't get it= =20 > widely adopted any more than in the past decade, and IMHO the security=20 > difference between the CA's omitting this extension for compatibility=20 > reasons and it being non-critical is greater than that between it being=20 > non-critical and critical. Going back to Rob's original question, this is putting the CAs in a serious= vise. If they issue an external sub-CA certificate without name constraints or wi= th non-critical name constraints, they might be rejected by Mozilla. If they issue them with a critical name constraints, the EE certificates ma= y not work in some of the installed base. I really don't like us telling Mozilla to force the CAs to break some of th= e installed base. If Apple can be convinced to change their implementation,= all the better. Couldn't such a decision be better arrived at in the CA/Br= owser Forum? Yoav From benlaurie@gmail.com Tue Apr 3 03:03:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE92821F864E for ; Tue, 3 Apr 2012 03:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns6l-4sZ2I+1 for ; Tue, 3 Apr 2012 03:03:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 24A9021F852B for ; Tue, 3 Apr 2012 03:03:32 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2699900vbb.31 for ; Tue, 03 Apr 2012 03:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2IKpTAYkmGpzSu5lPmbT0zsKcqzn/ieaQB6dB57PklE=; b=w/QbbtcHb28CLYq5Ki0ua4XCSpkfzWSdjdi/0fLJQe8nNPQRJ50AaMIAfM45rJDJcX 7RxUz8BMZ5ao/+hmo6/hK5k51J8XrZn3niEJcj3VDWKehl7Zu71fKD4yNZkFA6xz91nQ VFvKXl/B8WuDAc731TMv4Ot0BmrIuDl+Gzris2zE1jryN8HtRX3hfKLncpi4D7v2O82x /Z4p/9W88/s87nOZAfZ3llQ4e9iV8fPiFc3YfUFRfxIJFXTmoGbilE5a2iEJiqY+f43f ZG03iCPNQgq+Dz+A+RvrXpTOGvrjOiDXnscPb4Np74XlUlSUYU2EmEMLVC8OxTlq0vga Y0fw== MIME-Version: 1.0 Received: by 10.52.89.106 with SMTP id bn10mr4693212vdb.116.1333447411677; Tue, 03 Apr 2012 03:03:31 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.52.171.14 with HTTP; Tue, 3 Apr 2012 03:03:31 -0700 (PDT) In-Reply-To: <4F797025.6000402@comodo.com> References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> Date: Tue, 3 Apr 2012 11:03:31 +0100 X-Google-Sender-Auth: 9UdOD7IwHmpBsR87X0-JHcojP18 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" , Kathleen Wilson Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 10:03:32 -0000 On Mon, Apr 2, 2012 at 10:23 AM, Rob Stradling w= rote: > On 29/03/12 21:05, Rob Stradling wrote: >> RFC5280 says: >> "4.2.1.10. Name Constraints >> ...Conforming CAs MUST mark this extension as critical" >> >> Can anyone explain the reason for this requirement? > > Everyone, thanks for your comments. =A0There is certainly no consensus to > change RFC5280 so that it doesn't advocate that Name Constraints be > critical. > > However, I wonder if we could arrive at a compromise... > > > PROPOSAL: Change the "MUST" to "SHOULD". > > > RFC2119 says: > '3. SHOULD =A0 This word, or the adjective "RECOMMENDED", mean that there > =A0 may exist valid reasons in particular circumstances to ignore a > =A0 particular item, but the full implications must be understood and > =A0 carefully weighed before choosing a different course.' > > Now, I would say that the desire to avoid breaking all Apple devices is a > "valid reason"! =A0And I think "SHOULD" would still send the appropriate > message to implementers that they need to think very carefully about thes= e > things. It doesn't break them - they correctly refuse to process the certificates := -) From SChokhani@cygnacom.com Tue Apr 3 06:44:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883B521F85A4 for ; Tue, 3 Apr 2012 06:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PO5SkJqLhZu for ; Tue, 3 Apr 2012 06:44:50 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id E0BAD21F8599 for ; Tue, 3 Apr 2012 06:44:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,362,1330923600"; d="scan'208";a="4581867" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 03 Apr 2012 09:44:42 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 3 Apr 2012 09:44:41 -0400 From: Santosh Chokhani To: "mrex@sap.com" Date: Tue, 3 Apr 2012 09:44:40 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0RASt2BmeQ2TDPRxq2yXxNM2RsmgAnpEqg Message-ID: References: from "Santosh Chokhani" at Apr 2, 12 01:17:18 pm <201204021848.q32ImEnH028123@fs4113.wdf.sap.corp> In-Reply-To: <201204021848.q32ImEnH028123@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:44:50 -0000 Martin, The answer is in your own response. The CA wants to protect those relying = parties who do not understand the semantics of the extension. If the RP is= hell-bent on accepting the certificate, it can choose to ignore critical e= xtensions as well. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Monday, April 02, 2012 2:48 PM To: Santosh Chokhani Cc: mrex@sap.com; eabalea@gmail.com; pkix@ietf.org; paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Santosh Chokhani wrote: >=20 > You miss the security implication of this. >=20 > CA can always make it NC and the clients that do not process name=20 > constraints will be exposed if the Sub CA is rogue, compromised or RAs=20 > it trusts go rouge or are compromised. This discussion seems to be lost some deep in the woods. RPs that implement name constraints have to process them when present indep= endent whether they're marked critical or not, so we can safely exclude the= se from the discussion, they simply do not matter here. Now for the remaining RPs that do not support a particular name constraint = that a higher level CA intends to impose on a subCA. When it marks that constraint critical, the certificates issued by the subC= A will not be acceptable _at_all_ to RPs that do not implement the particul= ar name constraints the CA wants to use. If the name constraints are marke= d non-critical, then the certificates issued by the subCA will be usable wi= th those RPs (not implementing the name constraints) under ignorance of the= name constraints. Whether the subCA "goes rogue" is irrelevant for the RPs that implement the= name constraints, because they will process the name constraints even when= not critical. For the RPs that do not implement the name constraints, the= y continue to not care about the name constraints, so whether the CA is hon= est or rogue (with respect to the name constraints) is irrelevant to them _= as_well_. Now where is your problem letting CAs decide for themselves whether they wa= nt to make the name constraints extension critical or not, similar to leavi= ng it up to CA to make policy constraints critical or not. -Martin From SChokhani@cygnacom.com Tue Apr 3 06:45:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E22A21F85B5 for ; Tue, 3 Apr 2012 06:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H4dYKuFOFiY for ; Tue, 3 Apr 2012 06:45:41 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 58A9321F8599 for ; Tue, 3 Apr 2012 06:45:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,362,1330923600"; d="scan'208";a="4581881" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 03 Apr 2012 09:45:38 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 3 Apr 2012 09:45:38 -0400 From: Santosh Chokhani To: Kyle Hamilton , Adam Langley Date: Tue, 3 Apr 2012 09:45:37 -0400 Thread-Topic: [pkix] Criticality of Name Constraints in 5280 Thread-Index: Ac0RQ+Jj9RV9B6vTSj+bdBwbFvnZ5AAXBXSw Message-ID: References: <4F74C077.4050103@comodo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , Kathleen Wilson Subject: Re: [pkix] Criticality of Name Constraints in 5280 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:45:43 -0000 Kyle, 5280 does not have the concept of end entity signing certificates. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Kyl= e Hamilton Sent: Monday, April 02, 2012 10:45 PM To: Adam Langley Cc: pkix@ietf.org; Kathleen Wilson Subject: Re: [pkix] Criticality of Name Constraints in 5280 On Thu, Mar 29, 2012 at 1:14 PM, Adam Langley wrote: > On Thu, Mar 29, 2012 at 4:05 PM, Rob Stradling = wrote: >> Should RFC5280 be updated to specify that Name Constraints need not=20 >> be critical? > > I'm not aware of any software that enforces this requirement and agree=20 > that the MUST in RFC 5280 is unhelpful and support the idea that it=20 > should be removed. I disagree. Name Constraints is integral to understanding the semantic of = a CA certificate, and really has to be be critical. This is the same reaso= n why Basic Constraints must be critical (to determine if it's even a CA ce= rtificate). I query, how is it unhelpful? How does it get in the way? Ho= w does it cause problems? It seems that the only motivation for this is th= e removal of language in the Basic Requirements. There is, however, a MUST in the same clause which I think should be gotten= rid of: "The Name Constraints extension, which MUST only appear in CA cert= ificates, [...]". The only time a person should need the action of the CA should be when his = identity is being verified, when his identity is subpoenaed, when he's rene= wing, and when he needs to rekey/revoke. Why should a person be prohibited= from issuing certificates to his own devices using his certified key? (I = must point out, 100 CAs is not going to be enough to handle the demand of i= ndividuals when the barriers against their adoption of cryptographic securi= ty are removed. Do we want to spam them with requests for additional devic= e keys on top of that?) I would like to allow device certificates to be issued by end entity certif= icates. To do this with any effective DNS-related control, Name Constraint= s must be in end entity certificates. I would suggest that End Entity Name= Constraints be non-critical to avoid disrupting current deployment (since = EE NC doesn't change any semantics if it's not understood). -Kyle H From anders.rundgren@telia.com Tue Apr 3 06:45:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2D521F8599 for ; Tue, 3 Apr 2012 06:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3KCq3ddZVCi for ; Tue, 3 Apr 2012 06:45:43 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 162DD21F85A4 for ; Tue, 3 Apr 2012 06:45:43 -0700 (PDT) Received: from [192.168.3.131] (193.12.106.2) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB98E008F196A; Tue, 3 Apr 2012 15:45:36 +0200 Message-ID: <4F7AFEF8.7050406@telia.com> Date: Tue, 03 Apr 2012 15:45:28 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Max Pritikin References: <4F718771.6060906@ieca.com> <4F719B3D.10101@telia.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:45:44 -0000 On 2012-04-03 01:48, Max Pritikin wrote: > > Comments inline, > > On Mar 27, 2012, at 4:49 AM, Anders Rundgren wrote: > >> Continuing this thread... >> >> From the abstract I would be interested in hearing what >> >> "simple Public Key Infrastructure clients" >> >> actually refer to. > > The first paragraph of the introduction notes that: "EST is designed to be easily implemented by clients and servers using common "off the shelf" PKI, HTTP, and TLS components". This also relates to the use of the "simple" messages defined in CMC. That's one way of expressing it. I'm a hands-on guy so I am rather thinking about how well it fits things like this: http://www.pcworld.com/businesscenter/article/252584/ibm_cio_discusses_big_blues_byod_strategy.html IMO EST doesn't address this market without adding non-standard "bootstrap" steps like Cisco's AnyConnect. I find AnyConnect pretty quirky and (undocumented...) compared to Apple's bootstrap profile scheme. It seems that you actually must be a device/OS vendor in order to implement things the way Apple do since no "mere mortals" can get under the hood or dump arbitrary junk in SYSTEM32 like we did during the Windows days. > >> >> "This profile, called Enrollment over Secure Transport (EST), >> describes a simple yet functional certificate management protocol" >> >> If you combine all the options, it is not that simple anymore. >> Is a client and server assumed to support all the options? >> If not, how are they supposed to know which subset that can be used? >> Looks like a rather configuration-dependent scheme IMHO. > > If you can think of any options which can be removed please indicate them and suggest their removal. Although I feel we've done a good job ensuring there are very few options I'd happily hear of ones that can go away. In theory "simple" respectively "full" requests could be viewed as flexibility but in reality it forces you to implement both in order to claim compliance. I guess the upgraded AnyConnect client will take care of server preferences? > >> "K1 "Algorithm agility". The protocol MUST support algorithm agility" >> >> The author's opinion on what that means is flawed. Although supporting >> a bunch of TLS ciphers may be interesting, algorithm agility regarding >> generated keys is a parameter that most (if not all) issuers care about. > > The authors opinion is irrelevant as we're discussing the actual wording of the text. > I agree that K1 should also reference the type of key material being enrolled. Isn't the bigger question then how to get it in the protocol? Quite a bunch of PKIX enrollment protocols have acquired this ability through proprietary protocol bootstrap schemes. AFAIK none of the protocols have it natively. This was BTW one of the (numerous) motivations behind KeyGen2; creating *true* interoperability. > >> "5.3 Distribution of CA certificates >> Before engaging in enrollment operations, clients MUST request trust >> anchor information (in the form of certificates) by sending an HTTPS >> GET message to the EST base URI with the relative path extension >> '/CACerts'" >> >> This mandatory requirement isn't particularly universal. A more >> common method is that the user rather gets an option "accepting" the >> root of the distributed certificate path. > > I think you are excessively combining the server authentication discussion (sections 5.2 and 4.3.1.1) and the distribution of CA certificates. That's quite possible. I just read the text "as is". > > There is value in the "MUST" here because then the client has any possible CA key rollover certificates which might be necessary for chain building etc that might be encountered during the enrollment operations. (e.g. if the client is issued a certificate using the CA's new certificate the client has sufficient information to know what happened and to successfully use its new certificate). OK. > >> In today's server-centric >> world the CA of a *client certificate* often doesn't have any >> meaning for the client/user at all. > > IF the PKI is performing key rollover on the CA certificate then this is not true. For example when acting as a TLS client the client must build an appropriate chain to send to the server. In the interest of limiting options and capability exchanges the client MUST perform this operation even if it is only useful in some re-enrollment scenarios. > > Thanks for your feedback, thanx, Anders > > - max > >> Anders >> PS. By thinking out loud I got an idea for KeyGen2! Add an option >> to the install certificate part of the protocol where the issuer may >> claim that this root may be of interest to user. By doing that KeyGen2 >> doesn't have to bother users with (for example) accepting VISA's EMV-root >> since this a thing for the merchants/acquirers to care about. DS. >> >> On 2012-03-27 11:25, Sean Turner wrote: >>> Just a couple of comments the WG should consider: >>> >>> Technical: >>> >>> 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s >>> for the request and return the certificate(s) in a mime media type. In >>> many instances, the "normal" query/response for a certificate is a >>> PKCS#10 request followed by a PKCS#7 response, where the PKCS#7 is the >>> degenerate certs-only message. Does anyone see any benefit in reusing >>> the PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing it >>> would align nicely/exactly with the simple PKI request/response from CMC. >>> >>> 2. in s5.6.2, just use application/pkcs8 instead of >>> application/pkix-privkey. >>> >>> Not so technical: >>> >>> 1. appendix D really ought to be in its own document or in part of >>> draft-nourse-scep. >>> >>> spt >>> _______________________________________________ >>> 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 bergtau@gmail.com Tue Apr 3 08:19:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8EE11E80D6 for ; Tue, 3 Apr 2012 08:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0hcoVANmHi9 for ; Tue, 3 Apr 2012 08:19:10 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9FD11E80B8 for ; Tue, 3 Apr 2012 08:19:08 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2034027yhk.31 for ; Tue, 03 Apr 2012 08:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9LdLtOVEkWH/EJ4ubEykRPUGUK3vM4hBeDrYSuL/d5s=; b=tigdgXcNYjfrUXSvp1HX8p8awKYcK6Cw5u0JwC+7LsmqtysmbgqvxNukX3NRiXhQTf +wNvdFRkberiMD/0TpRcfsXhDbqX8veHZt2sGVXPpXdiB83KKrvarvTiDNYu8stzr7mz o1JTOVd3ViuAGCiqOHimW7a5C6JGoJtqZvUIFXfre/UjW9n7rW7CSMQiQZ5kFy4Q55SQ EN9zY0H9xq/ue7C71XqKghbw1fN65Rndiqb3gKRd8/VgIQSg0JBdR9Q3IW5qnakIfWcE 3eFl3CRiNiU9xHV4Nt6vb8As8OD2p8PP2pq2XZtrRDmW7OrqyVhpm5n4PpK8TqkpqDAM X+5g== MIME-Version: 1.0 Received: by 10.50.45.228 with SMTP id q4mr10772712igm.58.1333466347373; Tue, 03 Apr 2012 08:19:07 -0700 (PDT) Received: by 10.64.81.40 with HTTP; Tue, 3 Apr 2012 08:19:07 -0700 (PDT) In-Reply-To: References: <201204021848.q32ImEnH028123@fs4113.wdf.sap.corp> Date: Tue, 3 Apr 2012 11:19:07 -0400 Message-ID: From: Michael Jenkins To: Santosh Chokhani Content-Type: multipart/alternative; boundary=14dae9340645f4859f04bcc7d3e2 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:19:11 -0000 --14dae9340645f4859f04bcc7d3e2 Content-Type: text/plain; charset=ISO-8859-1 I'm a bit confused by the way this is being talked about. If I get this wrong, I suspect Santosh will set me right :) The discussion so far has made it seem that the CA who sets name constraints is the the same one issuing the certificate the RP is going to rely on. But it's not; the CA who is going to set the name constraints is the Root CA; it sets in in the Sub CA certificate as a promise to the RP that the Sub CA will not issue outside its constraint. Making this extension critical is the only way the Root CA can ensure that if the Sub CA tries to issue a certificate outside its constraint on the sly, the client will at least raise the issue to the RP. If at that point the RP wants to accept the certificate anyway (perhaps based on other information), that's the RP's business - the Root CA's promise has been fulfilled. If the extension is not marked critical, the client is free to ignore the extension, and the Root CA has no way to bring any violation to the RP's attention. Not that a client couldn't do it, but that puts the fulfillment of the Root CA's promise in the hands of the client, not the Root CA. It seems the original problem is that Mozilla wants to require Root CAs that are put in its trust anchor list to include name constraints, but that creates a third party problem - if the Root CAs are then issuing Sub CA certificates that are going to break (non-Mozilla) clients, then Mozilla has created a problem for the Root CA that Mozilla doesn't have to suffer for. I appreciate this is a bum deal for the Root CA and one that Mozilla would like to avoid. However, the proposed solution (making name constraints non-critical) only assuages Mozilla's guilt about unintended consequences; it isn't consistent with the system problem. That is, Mozilla is saying that because their client properly processes the extension (right?) they can uphold the promise for the Root CAs in their trust anchor list. But, Root CAs - in order to solve the problem we've created for you, we're going to remove your ability to make good on your promise for certain other clients. This seems like an equally bum deal for the Root CAs. Mike Jenkins On Tue, Apr 3, 2012 at 9:44 AM, Santosh Chokhani wrote: > Martin, > > The answer is in your own response. The CA wants to protect those relying > parties who do not understand the semantics of the extension. If the RP is > hell-bent on accepting the certificate, it can choose to ignore critical > extensions as well. > > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Monday, April 02, 2012 2:48 PM > To: Santosh Chokhani > Cc: mrex@sap.com; eabalea@gmail.com; pkix@ietf.org; paul.hoffman@vpnc.org > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > > Santosh Chokhani wrote: > > > > You miss the security implication of this. > > > > CA can always make it NC and the clients that do not process name > > constraints will be exposed if the Sub CA is rogue, compromised or RAs > > it trusts go rouge or are compromised. > > This discussion seems to be lost some deep in the woods. > > RPs that implement name constraints have to process them when present > independent whether they're marked critical or not, so we can safely > exclude these from the discussion, they simply do not matter here. > > Now for the remaining RPs that do not support a particular name constraint > that a higher level CA intends to impose on a subCA. > When it marks that constraint critical, the certificates issued by the > subCA will not be acceptable _at_all_ to RPs that do not implement the > particular name constraints the CA wants to use. If the name constraints > are marked non-critical, then the certificates issued by the subCA will be > usable with those RPs (not implementing the name constraints) under > ignorance of the name constraints. > > Whether the subCA "goes rogue" is irrelevant for the RPs that implement > the name constraints, because they will process the name constraints even > when not critical. For the RPs that do not implement the name constraints, > they continue to not care about the name constraints, so whether the CA is > honest or rogue (with respect to the name constraints) is irrelevant to > them _as_well_. > > Now where is your problem letting CAs decide for themselves whether they > want to make the name constraints extension critical or not, similar to > leaving it up to CA to make policy constraints critical or not. > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --14dae9340645f4859f04bcc7d3e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm a bit confused by the way this is being talked about. If I get this= wrong, I suspect Santosh will set me right :)

The discussion so far= has made it seem that the CA who sets name constraints is the the same one= issuing the certificate the RP is going to rely on. But it's not; the = CA who is going to set the name constraints is the Root CA; it sets in in t= he Sub CA certificate as a promise to the RP that the Sub CA will not issue= outside its constraint.

Making this extension critical is the only way the Root CA can ensure t= hat if the Sub CA tries to issue a certificate outside its constraint on th= e sly, the client will at least raise the issue to the RP. If at that point= the RP wants to accept the certificate anyway (perhaps based on other info= rmation), that's the RP's business - the Root CA's promise has = been fulfilled.

If the extension is not marked critical, the client is free to ignore t= he extension, and the Root CA has no way to bring any violation to the RP&#= 39;s attention. Not that a client couldn't do it, but that puts the ful= fillment of the Root CA's promise in the hands of the client, not the R= oot CA.

It seems the original problem is that Mozilla wants to require Root CAs= that are put in its trust anchor list to include name constraints, but tha= t creates a third party problem - if the Root CAs are then issuing Sub CA c= ertificates that are going to break (non-Mozilla) clients, then Mozilla has= created a problem for the Root CA that Mozilla doesn't have to suffer = for. I appreciate this is a bum deal for the Root CA and one that Mozilla w= ould like to avoid.

However, the proposed solution (making name constraints non-critical) o= nly assuages Mozilla's guilt about unintended consequences; it isn'= t consistent with the system problem. That is, Mozilla is saying that becau= se their client properly processes the extension (right?) they can uphold t= he promise for the
Root CAs in their trust anchor list. But, Root CAs - in order to solve the = problem we've created for you, we're going to remove your ability t= o make good on your promise for certain other clients.

This seems li= ke an equally bum deal for the Root CAs.

Mike Jenkins

On Tue, Apr 3, 2012 at 9= :44 AM, Santosh Chokhani <SChokhani@cygnacom.com> wrote:
Martin,

The answer is in your own response. =A0The CA wants to protect those relyin= g parties who do not understand the semantics of the extension. =A0If the R= P is hell-bent on accepting the certificate, it can choose to ignore critic= al extensions as well.

-----Original Message-----
From: Martin Rex [mailto:mrex@sap.com]<= br> Sent: Monday, April 02, 2012 2:48 PM
To: Santosh Chokhani
Cc: mrex@sap.com; eabalea@gmail.com; pki= x@ietf.org; paul.hoffman@vpnc.= org
Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name
Santosh Chokhani wrote:
>
> You miss the security implication of this.
>
> CA can always make it NC and the clients that do not process name
> constraints will be exposed if the Sub CA is rogue, compromised or RAs=
> it trusts go rouge or are compromised.

This discussion seems to be lost some deep in the woods.

RPs that implement name constraints have to process them when present indep= endent whether they're marked critical or not, so we can safely exclude= these from the discussion, they simply do not matter here.

Now for the remaining RPs that do not support a particular name constraint = that a higher level CA intends to impose on a subCA.
When it marks that constraint critical, the certificates issued by the subC= A will not be acceptable _at_all_ to RPs that do not implement the particul= ar name constraints the CA wants to use. =A0If the name constraints are mar= ked non-critical, then the certificates issued by the subCA will be usable = with those RPs (not implementing the name constraints) under ignorance of t= he name constraints.

Whether the subCA "goes rogue" is irrelevant for the RPs that imp= lement the name constraints, because they will process the name constraints= even when not critical. =A0For the RPs that do not implement the name cons= traints, they continue to not care about the name constraints, so whether t= he CA is honest or rogue (with respect to the name constraints) is irreleva= nt to them _as_well_.

Now where is your problem letting CAs decide for themselves whether they wa= nt to make the name constraints extension critical or not, similar to leavi= ng it up to CA to make policy constraints critical or not.


-Martin
_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix

--14dae9340645f4859f04bcc7d3e2-- From DPKemp@missi.ncsc.mil Tue Apr 3 09:05:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39B11E813B for ; Tue, 3 Apr 2012 09:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQEJmJbRBwtN for ; Tue, 3 Apr 2012 09:05:55 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0030911E8139 for ; Tue, 3 Apr 2012 09:05:52 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q33G5poG052526 for ; Tue, 3 Apr 2012 12:05:51 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 12:05:51 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2012 12:05:35 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD Thread-Index: Ac0RgQ+z7lWZRjYLROKAuqmwB0KmIwALr2rw References: <4F74C077.4050103@comodo.com><4F797025.6000402@comodo.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 03 Apr 2012 16:05:51.0669 (UTC) FILETIME=[A4492E50:01CD11B3] Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:05:56 -0000 Why the smiley? - this serious! :-) The purpose of critical is to achieve this behavior. If the PKI is set = up so that CA A certifies names in *.mycompany.com and CA B certifies = *.yourcompany.com, I don't want CA B to be able to forge certificates = for my websites. Meaning I don't want the universe of Internet users to = be fooled by such forgeries, which means that it is correct for all = applications that recognize that they are unable to detect forgeries to = refuse to process the certificates. If name constraints are not useful (i.e. there is not a relationship = between a CA and the domains it is authorized to certify) then don't = include the extension in the certificate at all. If constraints are = useful (i.e. I want to ensure that my servers cannot be impersonated by = others using different CAs) then the constraints should be processed or = the user warned ("Warning: This site's certificate contains unrecognized = critical security information - Abort or Continue (not recommended)?)". Under what business scenario is it desirable for the PKI include = information to detect impersonation but mark it so that it is silently = ignored? Dave -----Original Message----- From: Ben Laurie On Mon, Apr 2, 2012 at 10:23 AM, Rob Stradling = wrote: > > Now, I would say that the desire to avoid breaking all Apple devices=20 > is a "valid reason"! =A0And I think "SHOULD" would still send the=20 > appropriate message to implementers that they need to think very=20 > carefully about these things. It doesn't break them - they correctly refuse to process the = certificates :-) From SChokhani@cygnacom.com Tue Apr 3 09:49:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FFC21F8661 for ; Tue, 3 Apr 2012 09:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QlihJX8N9Rj for ; Tue, 3 Apr 2012 09:49:50 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6C14221F865E for ; Tue, 3 Apr 2012 09:49:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="4584700" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 03 Apr 2012 12:49:36 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 3 Apr 2012 12:49:36 -0400 From: Santosh Chokhani To: "Kemp, David P." , "pkix@ietf.org" Date: Tue, 3 Apr 2012 12:49:35 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD Thread-Index: Ac0RgQ+z7lWZRjYLROKAuqmwB0KmIwALr2rwAAJ7+zA= Message-ID: References: <4F74C077.4050103@comodo.com><4F797025.6000402@comodo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 16:49:51 -0000 Amen -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Kem= p, David P. Sent: Tuesday, April 03, 2012 12:06 PM To: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Co= nstraints from MUST to SHOULD Why the smiley? - this serious! :-) The purpose of critical is to achieve this behavior. If the PKI is set up = so that CA A certifies names in *.mycompany.com and CA B certifies *.yourco= mpany.com, I don't want CA B to be able to forge certificates for my websit= es. Meaning I don't want the universe of Internet users to be fooled by su= ch forgeries, which means that it is correct for all applications that reco= gnize that they are unable to detect forgeries to refuse to process the cer= tificates. If name constraints are not useful (i.e. there is not a relationship betwee= n a CA and the domains it is authorized to certify) then don't include the = extension in the certificate at all. If constraints are useful (i.e. I wan= t to ensure that my servers cannot be impersonated by others using differen= t CAs) then the constraints should be processed or the user warned ("Warnin= g: This site's certificate contains unrecognized critical security informat= ion - Abort or Continue (not recommended)?)". Under what business scenario is it desirable for the PKI include informatio= n to detect impersonation but mark it so that it is silently ignored? Dave -----Original Message----- From: Ben Laurie On Mon, Apr 2, 2012 at 10:23 AM, Rob Stradling w= rote: > > Now, I would say that the desire to avoid breaking all Apple devices=20 > is a "valid reason"! =A0And I think "SHOULD" would still send the=20 > appropriate message to implementers that they need to think very=20 > carefully about these things. It doesn't break them - they correctly refuse to process the certificates := -) _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From ynir@checkpoint.com Tue Apr 3 12:40:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54C811E81B3 for ; Tue, 3 Apr 2012 12:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4PBrIp2c-fY for ; Tue, 3 Apr 2012 12:40:06 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE6011E8192 for ; Tue, 3 Apr 2012 12:40:04 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q33JdoAC002192; Tue, 3 Apr 2012 22:39:50 +0300 X-CheckPoint: {4F7B5FB8-1-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 3 Apr 2012 22:39:49 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 3 Apr 2012 22:39:49 +0300 From: Yoav Nir To: Michael Jenkins Date: Tue, 3 Apr 2012 22:39:53 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0R0Ydn6T7kvi/DQ+WIXng7/GmvkQ== Message-ID: <7AE2A839-10E9-41D7-ABDD-911AB94786CA@checkpoint.com> References: <201204021848.q32ImEnH028123@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 19:40:06 -0000 On Apr 3, 2012, at 6:19 PM, Michael Jenkins wrote: > I'm a bit confused by the way this is being talked about. If I get this w= rong, I suspect Santosh will set me right :) >=20 > The discussion so far has made it seem that the CA who sets name constrai= nts is the the same one issuing the certificate the RP is going to rely on.= But it's not; the CA who is going to set the name constraints is the Root = CA; it sets in in the Sub CA certificate as a promise to the RP that the Su= b CA will not issue outside its constraint.=20 >=20 > Making this extension critical is the only way the Root CA can ensure tha= t if the Sub CA tries to issue a certificate outside its constraint on the = sly, the client will at least raise the issue to the RP. If at that point t= he RP wants to accept the certificate anyway (perhaps based on other inform= ation), that's the RP's business - the Root CA's promise has been fulfilled= . True, but I think we are personifying bunches of bits here. The root CA is = not a certificate, it's a company, and companies have contracts and people.= If we take Rob to personify Comodo, Rob can avoid having sub CAs issuing t= he wrong certificates by other means, such as writing that in a contract, o= r only giving subCA certificates to trustworthy people. > If the extension is not marked critical, the client is free to ignore the= extension, Not quite. A client that understands the extension MUST process it anyway. > and the Root CA has no way to bring any violation to the RP's attention. = Not that a client couldn't do it, but that puts the fulfillment of the Root= CA's promise in the hands of the client, not the Root CA. Promise to whom? > It seems the original problem is that Mozilla wants to require Root CAs t= hat are put in its trust anchor list to include name constraints, Only for those sub-CAs that are owned by someone other than the owner of th= e root CA. > but that creates a third party problem - if the Root CAs are then issuing= Sub CA certificates that are going to break (non-Mozilla) clients, then Mo= zilla has created a problem for the Root CA that Mozilla doesn't have to su= ffer for. I appreciate this is a bum deal for the Root CA and one that Mozi= lla would like to avoid. >=20 > However, the proposed solution (making name constraints non-critical) onl= y assuages Mozilla's guilt about unintended consequences; it isn't consiste= nt with the system problem. That is, Mozilla is saying that because their c= lient properly processes the extension (right?) they can uphold the promise= for the=20 > Root CAs in their trust anchor list. But, Root CAs - in order to solve th= e problem we've created for you, we're going to remove your ability to make= good on your promise for certain other clients. >=20 > This seems like an equally bum deal for the Root CAs. It would force them to choose between not working on Firefox and not workin= g on iOS. Tough call, and only Apple can solve it. Yoav= From SChokhani@cygnacom.com Tue Apr 3 13:32:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F6C11E81FD for ; Tue, 3 Apr 2012 13:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqmqNMvpTpXq for ; Tue, 3 Apr 2012 13:32:04 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4445A11E81FC for ; Tue, 3 Apr 2012 13:32:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,364,1330923600"; d="scan'208";a="4587495" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 03 Apr 2012 16:32:01 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 3 Apr 2012 16:32:01 -0400 From: Santosh Chokhani To: Yoav Nir , Michael Jenkins Date: Tue, 3 Apr 2012 16:32:00 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0R0Ydn6T7kvi/DQ+WIXng7/GmvkQABtrOQ Message-ID: References: <201204021848.q32ImEnH028123@fs4113.wdf.sap.corp> <7AE2A839-10E9-41D7-ABDD-911AB94786CA@checkpoint.com> In-Reply-To: <7AE2A839-10E9-41D7-ABDD-911AB94786CA@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 20:32:05 -0000 See line. -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Tuesday, April 03, 2012 3:40 PM To: Michael Jenkins Cc: Santosh Chokhani; pkix@ietf.org; paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name On Apr 3, 2012, at 6:19 PM, Michael Jenkins wrote: > I'm a bit confused by the way this is being talked about. If I get=20 > this wrong, I suspect Santosh will set me right :) >=20 > The discussion so far has made it seem that the CA who sets name constrai= nts is the the same one issuing the certificate the RP is going to rely on.= But it's not; the CA who is going to set the name constraints is the Root = CA; it sets in in the Sub CA certificate as a promise to the RP that the Su= b CA will not issue outside its constraint.=20 >=20 > Making this extension critical is the only way the Root CA can ensure tha= t if the Sub CA tries to issue a certificate outside its constraint on the = sly, the client will at least raise the issue to the RP. If at that point t= he RP wants to accept the certificate anyway (perhaps based on other inform= ation), that's the RP's business - the Root CA's promise has been fulfilled= . True, but I think we are personifying bunches of bits here. The root CA is = not a certificate, it's a company, and companies have contracts and people.= If we take Rob to personify Comodo, Rob can avoid having sub CAs issuing t= he wrong certificates by other means, such as writing that in a contract, o= r only giving subCA certificates to trustworthy people. [Santosh] You can do most things by contract. The purpose of PKI is to pro= vide security and the sub CA doing something on purpose is not the only sce= nario. It, its agent could be compromised. > If the extension is not marked critical, the client is free to ignore=20 > the extension, Not quite. A client that understands the extension MUST process it anyway. [Santosh] I suspect the comment was made in the context of clients that do = not understand the extension. > and the Root CA has no way to bring any violation to the RP's attention. = Not that a client couldn't do it, but that puts the fulfillment of the Root= CA's promise in the hands of the client, not the Root CA. Promise to whom? [Santosh] To all those rely on the certificates issued by it. > It seems the original problem is that Mozilla wants to require Root=20 > CAs that are put in its trust anchor list to include name constraints, Only for those sub-CAs that are owned by someone other than the owner of th= e root CA. > but that creates a third party problem - if the Root CAs are then issuing= Sub CA certificates that are going to break (non-Mozilla) clients, then Mo= zilla has created a problem for the Root CA that Mozilla doesn't have to su= ffer for. I appreciate this is a bum deal for the Root CA and one that Mozi= lla would like to avoid. >=20 > However, the proposed solution (making name constraints non-critical)=20 > only assuages Mozilla's guilt about unintended consequences; it isn't con= sistent with the system problem. That is, Mozilla is saying that because th= eir client properly processes the extension (right?) they can uphold the pr= omise for the Root CAs in their trust anchor list. But, Root CAs - in order= to solve the problem we've created for you, we're going to remove your abi= lity to make good on your promise for certain other clients. >=20 > This seems like an equally bum deal for the Root CAs. It would force them to choose between not working on Firefox and not workin= g on iOS. Tough call, and only Apple can solve it. Yoav From david.cooper@nist.gov Tue Apr 3 13:41:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F33F11E820A for ; Tue, 3 Apr 2012 13:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.307 X-Spam-Level: X-Spam-Status: No, score=-5.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbx30CbpxEDA for ; Tue, 3 Apr 2012 13:41:04 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7CECB11E8205 for ; Tue, 3 Apr 2012 13:41:04 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q33KerhB025398 for ; Tue, 3 Apr 2012 16:40:53 -0400 Message-ID: <4F7B6055.7020900@nist.gov> Date: Tue, 03 Apr 2012 16:40:53 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 CC: "pkix@ietf.org" References: <201204021848.q32ImEnH028123@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 20:41:05 -0000 While it may be true in a hierarchical PKI that a hierarchically superior CA may procedurally impose restrictions on the certificates that may be issued by its subordinate CAs and then may include constraints extensions that reflect those restrictions, it would be incorrect to suggest that constraints extensions always work this way. As an example, the cross-certificate from the DoD Root CA to the Federal Bridge CA includes a policyConstraints extension. This is not a promise to the RP that CAs in the Federal PKI (i.e., those that can be reached through the Federal Bridge CA) will not issue outside the constraint. It is a restriction imposed by DoD on DoD relying parties to only accept a subset of those (legitimate) certificates issued within the Federal PKI that satisfy the policy constraints specified in the extension. Similarly, if DoD (hypothetically) wanted to restrict its relying parties to only accept U.S. government-issued certificates, it could place a nameConstraints extension in its cross-certificate to the Federal Bridge CA. The nameConstraints extension in the cross-certificate would not be a promise to the RP that no CA in the Federal PKI will issue outside of the constraint, nor is it an indication that any certificates issued outside the constraint are illegitimate or a "violation." The nameConstraints extension would only indicate that DoD does not want its relying parties to accept certificates that are outside of the constraint. I also disagree with your statement: > The discussion so far has made it seem that the CA who sets name > constraints is the the same one issuing the certificate the RP is > going to rely on. But it's not; The relying party relies on every certificate in the certification path, so it most definitely does rely on the certificate that includes the nameConstraints extension. On 04/03/2012 11:19 AM, Michael Jenkins wrote: > I'm a bit confused by the way this is being talked about. If I get > this wrong, I suspect Santosh will set me right :) > > The discussion so far has made it seem that the CA who sets name > constraints is the the same one issuing the certificate the RP is > going to rely on. But it's not; the CA who is going to set the name > constraints is the Root CA; it sets in in the Sub CA certificate as a > promise to the RP that the Sub CA will not issue outside its constraint. > > Making this extension critical is the only way the Root CA can ensure > that if the Sub CA tries to issue a certificate outside its constraint > on the sly, the client will at least raise the issue to the RP. If at > that point the RP wants to accept the certificate anyway (perhaps > based on other information), that's the RP's business - the Root CA's > promise has been fulfilled. > > If the extension is not marked critical, the client is free to ignore > the extension, and the Root CA has no way to bring any violation to > the RP's attention. Not that a client couldn't do it, but that puts > the fulfillment of the Root CA's promise in the hands of the client, > not the Root CA. > > It seems the original problem is that Mozilla wants to require Root > CAs that are put in its trust anchor list to include name constraints, > but that creates a third party problem - if the Root CAs are then > issuing Sub CA certificates that are going to break (non-Mozilla) > clients, then Mozilla has created a problem for the Root CA that > Mozilla doesn't have to suffer for. I appreciate this is a bum deal > for the Root CA and one that Mozilla would like to avoid. > > However, the proposed solution (making name constraints non-critical) > only assuages Mozilla's guilt about unintended consequences; it isn't > consistent with the system problem. That is, Mozilla is saying that > because their client properly processes the extension (right?) they > can uphold the promise for the > Root CAs in their trust anchor list. But, Root CAs - in order to solve > the problem we've created for you, we're going to remove your ability > to make good on your promise for certain other clients. > > This seems like an equally bum deal for the Root CAs. > > Mike Jenkins From kent@bbn.com Tue Apr 3 14:20:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B9411E80EF for ; Tue, 3 Apr 2012 14:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1JxRYg4oHrC for ; Tue, 3 Apr 2012 14:20:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8395911E80A2 for ; Tue, 3 Apr 2012 14:20:05 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:44029 helo=[192.168.4.14]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SFB8m-000MeE-DF; Tue, 03 Apr 2012 17:19:48 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1E6BAF89-36AF-4303-A6F2-B486551B47DC@checkpoint.com> References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> <4F79E694.5020804@seantek.com> <342C4A32-E427-440C-B69D-355B27584E43@fastq.com> <1E6BAF89-36AF-4303-A6F2-B486551B47DC@checkpoint.com> Date: Tue, 3 Apr 2012 16:50:30 -0400 To: Yoav Nir From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 21:20:06 -0000 A >... > >I really don't like us telling Mozilla to force the CAs to break >some of the installed base. If Apple can be convinced to change >their implementation, all the better. Couldn't such a decision be >better arrived at in the CA/Browser Forum? > >Yoav The CA/Browser forum is a good place to discuss the issue and for CAs and browser vendors to decide how to proceed. However, that forum does not have responsibility for PKIX standards. Steve From ynir@checkpoint.com Tue Apr 3 21:12:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F8F21F84F4 for ; Tue, 3 Apr 2012 21:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9f4mnqZ+Ey5 for ; Tue, 3 Apr 2012 21:12:07 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8D421F84EF for ; Tue, 3 Apr 2012 21:12:06 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q344Bwgt007950; Wed, 4 Apr 2012 07:11:58 +0300 X-CheckPoint: {4F7BD7BB-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 4 Apr 2012 07:11:58 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 4 Apr 2012 07:11:58 +0300 From: Yoav Nir To: Stephen Kent Date: Wed, 4 Apr 2012 07:12:06 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD Thread-Index: Ac0SGRQCjxb4zIuRS32ylq73SRKfTA== Message-ID: <2EEAED7F-068A-40C7-BC7C-0A8EE32E2AF8@checkpoint.com> References: <4F74C077.4050103@comodo.com> <4F797025.6000402@comodo.com> <2BF9F11C-2B64-45F8-8418-EAB70E02A67A@vpnc.org> <4F79E694.5020804@seantek.com> <342C4A32-E427-440C-B69D-355B27584E43@fastq.com> <1E6BAF89-36AF-4303-A6F2-B486551B47DC@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 04:12:08 -0000 On Apr 3, 2012, at 11:50 PM, Stephen Kent wrote: > A >> ... >>=20 >> I really don't like us telling Mozilla to force the CAs to break=20 >> some of the installed base. If Apple can be convinced to change=20 >> their implementation, all the better. Couldn't such a decision be=20 >> better arrived at in the CA/Browser Forum? >>=20 >> Yoav >=20 > The CA/Browser forum is a good place to discuss the issue and for > CAs and browser vendors to decide how to proceed. However, that forum > does not have responsibility for PKIX standards. Fully agree. And conversely, this is not the place to tell Mozilla how to r= un their CA validation program, or to tell Apple what parts of what standar= ds they have to implement. With everyone here being an individual rather th= an a representative of their company, whatever we say here is not binding o= n either Mozilla or Apple, while the CA/Browser forum seems to have had som= e success in getting such organizations to do things. As far as the PKIX standards go, I think it's really obvious that there is = a rough consensus against relaxing the MUST requirements, so I think we (th= e PKIX list) have done all we can in this matter. It's likely that ignoring= the standard and making a non-critical extension will work with all browse= rs, so I'm guessing that that is what they'll do regardless of what we say. Yoav= From rob.stradling@comodo.com Wed Apr 4 01:43:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F85921F867F for ; Wed, 4 Apr 2012 01:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5hGDYvbbYn2 for ; Wed, 4 Apr 2012 01:43:12 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 80C2821F8661 for ; Wed, 4 Apr 2012 01:43:10 -0700 (PDT) Received: (qmail 20025 invoked from network); 4 Apr 2012 08:43:09 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 4 Apr 2012 08:43:09 -0000 Received: (qmail 4393 invoked by uid 1000); 4 Apr 2012 08:43:09 -0000 Received: from nigel.brad.office.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 (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 04 Apr 2012 09:43:09 +0100 Message-ID: <4F7C099C.5020107@comodo.com> Date: Wed, 04 Apr 2012 09:43:08 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: pkix@ietf.org References: <4F74C077.4050103@comodo.com><4F797025.6000402@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kathleen Wilson Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Constraints from MUST to SHOULD X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 08:43:12 -0000 Replying to several messages at once in an effort to close this thread... On 03/04/12 17:05, Kemp, David P. wrote: > Under what business scenario is it desirable for the PKI include > information to detect impersonation but mark it so that it is > silently ignored? If CA X's certs work with Apple's software, but CA Y's certs are rejected by Apple's software, which CA is likely to generate the most sales? The (sad) fact is that Critical Name Constraints is a non-starter for the public CAs for the foreseeable future. However, non-critical Name Constraints would be better than avoiding using Name Constraints at all. On 04/04/12 05:12, Yoav Nir wrote: > As far as the PKIX standards go, I think it's really obvious that > there is a rough consensus against relaxing the MUST requirements, so > I think we (the PKIX list) have done all we can in this matter. Agreed. > It's likely that ignoring the standard and making a non-critical > extension will work with all browsers, so I'm guessing that that is > what they'll do regardless of what we say. Yep, almost certainly. On 03/04/12 21:50, Stephen Kent wrote: > The CA/Browser forum is a good place to discuss the issue and for > CAs and browser vendors to decide how to proceed. However, that forum > does not have responsibility for PKIX standards. Agreed. I'll take the discussion to the CABForum. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From dharkins@lounge.org Wed Apr 4 10:41:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344CF21F8732 for ; Wed, 4 Apr 2012 10:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.406 X-Spam-Level: X-Spam-Status: No, score=-4.406 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1BBLglrQ9GH for ; Wed, 4 Apr 2012 10:40:59 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E14B521F871E for ; Wed, 4 Apr 2012 10:40:55 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 60CDC1022404A; Wed, 4 Apr 2012 10:40:55 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 4 Apr 2012 10:40:55 -0700 (PDT) Message-ID: <7ab37b4479f2245e353fc1117171869c.squirrel@www.trepanning.net> In-Reply-To: <17E480DA-907D-4F40-BDE5-0A10930E3695@cisco.com> References: <260966ff0f0743ba0f04d902cca68116.squirrel@www.trepanning.net> <17E480DA-907D-4F40-BDE5-0A10930E3695@cisco.com> Date: Wed, 4 Apr 2012 10:40:55 -0700 (PDT) From: "Dan Harkins" To: "Max Pritikin" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: pkix@ietf.org Subject: Re: [pkix] Using "CMC Simple PKI Response" rather than "certificate" (was: Re: some comments on draft-ietf-pkix-est-01) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:41:00 -0000 Hi Max, On Mon, April 2, 2012 5:34 pm, Max Pritikin wrote: > (I've updated the subject on this thread) > > My thoughts on this have not solidified yet. A couple of initial > questions, > > a) this requires the server to build and sign this response. Coding that > is relatively simple with off the shelf libraries but it will require > additional ASN1 and crypto operations that are effectively ignored. Is > this then an effective use of server (and client!) resources? I don't think the building will be ignored. The server can deliver the client's certificate and the CA certificate in one nice package. Regarding the additional crypto operations, given the other resource use necessary to execute this protocol I think it's noise. And this is something of a one-off protocol too. > b) Should the signature on this PKCS#7 be ignored? What if the CA has > moved on to a new key? How does it know to use an old key for this > signing? Yes, I believe it's ignored. > c) The Simple PKI Response section 4.1 [RFC5272] includes a variety of > "MAY" statements (options!). If we move in this direction would there be > support for profiling these to a more restrictive set of options? For each > of the following statements from paragraph 2 I'm thinking: > > "Servers SHOULD include all intermediate certificates needed to form > complete certification paths to one or more trust anchors, not just the > newly issued certificate(s)." > Change to MUST NOT. > Justification: this is not a trust anchor management protocol, thus this > type of flexibility isn't warranted here. I agree that this isn't a "trust anchor management protocol" but for the protocol to be generally useful it would really help for the client to have all the intermediate certificates it needs to form a complete certification path. You're talking about an absolute prohibition on providing useful information. That just doesn't sound right. SHOULD sounds fine. > "The server MAY additionally return CRLs in the CRL bag." > Change to MUST NOT. > Justification: This is not a CRL distribution protocol, thus the best the > server can do is provide a CRL appropriate for this client's certificate > at this point in time which is of minimal use. Also not including anything > specific to the client allows the PKCS#7 to be pre-generated for /CACerts. MAY means "[o]ne vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product...." Seems like it would be an enhancement to provide more useful information if the market deems it necessary or a vendor believes it enhances his product. Again, you're talking about an absolute prohibition on providing useful information. You think this is of minimal use. Fine. The text that follows the ellipses above is "while another vendor may omit the same item." You may omit a CRL because you feel it is of minimal use. > "Servers MAY include the self-signed certificates." > (I"m assuming this means including its own self-signed certificate?) > Change to MUST (and add "In addition the Root CA Key Update certificates > SHOULD be included."). > Justification: The CA certs MUST be included for /CACerts so make them > always included (reducing options). This would allow clients to skip > calling /CACerts for re-enroll since they'd always receive any new CA > certs in the response. > > "In the event clients receive a new self-signed certificate from the > server, clients SHOULD provide a mechanism to enable the user to use the > certificate as a trust anchor" > Change to MUST (and make this automatic). > Justification: Although not doing general trust anchor management we want > to make sure CA key renewal works seamlessly. > > Thanks for continued discussion, And thank you! Dan. > - max > > On Mar 28, 2012, at 3:04 AM, Dan Harkins wrote: > >> >> Hi, >> >> On Tue, 27 Mar 2012 at 11:25:05 Sean Turner said: >>> Just a couple of comments the WG should consider: >>> >>> Technical: >>> >>> 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s >>> for >>> the request and return the certificate(s) in a mime media type. In many >>> instances, the "normal" query/response for a certificate is a PKCS#10 >>> request followed by a PKCS#7 response, where the PKCS#7 is the >>> degenerate >>> certs-only message. Does anyone see any benefit in reusing the >>> PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing it would >>> align nicely/exactly with the simple PKI request/response from CMC. >> >> Yes, I see value in reusing the PKCS#10/PKCS#7 model. EST is supposed >> to implement "simple CMC" and that should use a PKCS#7 as the simple >> response. >> >> regards, >> >> Dan. >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > From pritikin@cisco.com Wed Apr 4 11:08:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802C821F87DF for ; Wed, 4 Apr 2012 11:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bJ-2BR0kimW for ; Wed, 4 Apr 2012 11:08:26 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8C521F87DE for ; Wed, 4 Apr 2012 11:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=8484; q=dns/txt; s=iport; t=1333562906; x=1334772506; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7QP+WzyHS0YlxgztNtU14PTnUdosKbYG69Nf6f3mHCg=; b=YgNUMax+uZUheIApfFwFv0htGHrtY//zBafapQHenVJNdGfR3pLEJ1IF wHab8evw4BpRMOXwXTc976GMyrJhAiwwUg8YhBf6EOMfp9AjZzm/8HUp6 2JnI5fNNgHgFstUVSEh2RVynZotQSQlo0BY4YjxRKKTuiSGeY6Tk9Qrlr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUHADiNfE+rRDoH/2dsb2JhbABEgxGxYYMxgQeCCQEBAQMBAQEBDwFbBwQFCwsYLiciAQ0GExsHh2IEDJtPnmOLHYRUYwSIWI0LhXCIV4FpgwaBNw X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="38974848" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 04 Apr 2012 18:08:25 +0000 Received: from [10.21.0.49] ([10.21.0.49]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q34I8OXY022546; Wed, 4 Apr 2012 18:08:24 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Max Pritikin In-Reply-To: <4F7AFEF8.7050406@telia.com> Date: Wed, 4 Apr 2012 12:08:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2B4C275D-3278-4A0F-B231-D7384AEE9489@cisco.com> References: <4F718771.6060906@ieca.com> <4F719B3D.10101@telia.com> <4F7AFEF8.7050406@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1257) Cc: pkix@ietf.org Subject: Re: [pkix] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 18:08:27 -0000 On Apr 3, 2012, at 7:45 AM, Anders Rundgren wrote: > On 2012-04-03 01:48, Max Pritikin wrote: >>=20 >> Comments inline,=20 >>=20 >> On Mar 27, 2012, at 4:49 AM, Anders Rundgren wrote: >>=20 >>> Continuing this thread... >>>=20 >>> =46rom the abstract I would be interested in hearing what >>>=20 >>> "simple Public Key Infrastructure clients" >>>=20 >>> actually refer to. >>=20 >> The first paragraph of the introduction notes that: "EST is designed = to be easily implemented by clients and servers using common "off the = shelf" PKI, HTTP, and TLS components". This also relates to the use of = the "simple" messages defined in CMC.=20 >=20 > That's one way of expressing it. I'm a hands-on guy so I am rather > thinking about how well it fits things like this: >=20 > = http://www.pcworld.com/businesscenter/article/252584/ibm_cio_discusses_big= _blues_byod_strategy.html >=20 > IMO EST doesn't address this market without adding non-standard > "bootstrap" steps like Cisco's AnyConnect. I find AnyConnect pretty > quirky and (undocumented...) compared to Apple's bootstrap profile = scheme. >=20 > It seems that you actually must be a device/OS vendor in order to = implement > things the way Apple do since no "mere mortals" can get under the hood = or > dump arbitrary junk in SYSTEM32 like we did during the Windows days. A general purpose bootstrapping system that works for a variety of = solutions ranging from Anyconnect products to the Iphone is a great = idea. I'd happily provide input on such a working group. EST within pkix = is not the proper venue for those ideas though.=20 For extensibility we did make it clear that additional functionalities = could be support (at new URIs). Once you get a standard together for = your bootstrapping ideas above we should be able to easily integrate = with the EST extensibility.=20 >>> "This profile, called Enrollment over Secure Transport (EST), >>> describes a simple yet functional certificate management protocol" >>>=20 >>> If you combine all the options, it is not that simple anymore. >>> Is a client and server assumed to support all the options? >>> If not, how are they supposed to know which subset that can be used? >>> Looks like a rather configuration-dependent scheme IMHO. >>=20 >> If you can think of any options which can be removed please indicate = them and suggest their removal. Although I feel we've done a good job = ensuring there are very few options I'd happily hear of ones that can go = away.=20 >=20 > In theory "simple" respectively "full" requests could be viewed as = flexibility but in reality it forces you to implement both in order to = claim compliance. Multiple points in the document /fullCMC transport is indicated as = optional. Although there is not a clear specification of the error code = to respond with if it is not available. I'll add clarification. > I guess the upgraded AnyConnect client will take care of server = preferences? I don't know anything about the AnyConnect team's product plans.=20 Is there something about server preferences that you feel should be = included in the EST protocol exchange? >>> "K1 "Algorithm agility". The protocol MUST support algorithm = agility" >>>=20 >>> The author's opinion on what that means is flawed. Although = supporting >>> a bunch of TLS ciphers may be interesting, algorithm agility = regarding >>> generated keys is a parameter that most (if not all) issuers care = about. >>=20 >> The authors opinion is irrelevant as we're discussing the actual = wording of the text.=20 >> I agree that K1 should also reference the type of key material being = enrolled. >=20 > Isn't the bigger question then how to get it in the protocol? >=20 > Quite a bunch of PKIX enrollment protocols have acquired this ability > through proprietary protocol bootstrap schemes. AFAIK none of the > protocols have it natively. This was BTW one of the (numerous) > motivations behind KeyGen2; creating *true* interoperability. This would be a lot easier if you would provide constructive feedback = along the lines of suggesting improvements. As it is I'm trying to guess = from your vague statement what you really want. Generally communication = works better when both parties are straightforward and direct about what = they are looking for. If we added something like a "/enrollBootstrap" what sort of response = are you envisioning? What would its mime-type be and is there an already = existing format for the response that you have in mind? If there isn't = such a thing what would serve this role? For example would it be appropriate to have the server distribute an = example pkcs10 with some of the fields already filled out? Is that the = sort of thing you have in mind? >>> "5.3 Distribution of CA certificates >>> Before engaging in enrollment operations, clients MUST request = trust >>> anchor information (in the form of certificates) by sending an = HTTPS >>> GET message to the EST base URI with the relative path extension >>> '/CACerts'" >>>=20 >>> This mandatory requirement isn't particularly universal. A more >>> common method is that the user rather gets an option "accepting" the >>> root of the distributed certificate path. >>=20 >> I think you are excessively combining the server authentication = discussion (sections 5.2 and 4.3.1.1) and the distribution of CA = certificates.=20 >=20 > That's quite possible. I just read the text "as is". If there is "as is" text that is confusing it would help if you = reference the exact text. I'm and editor not a mind reader, Jim! Thanks, - max >> There is value in the "MUST" here because then the client has any = possible CA key rollover certificates which might be necessary for chain = building etc that might be encountered during the enrollment operations. = (e.g. if the client is issued a certificate using the CA's new = certificate the client has sufficient information to know what happened = and to successfully use its new certificate).=20 >=20 > OK. >=20 >>=20 >>> In today's server-centric >>> world the CA of a *client certificate* often doesn't have any >>> meaning for the client/user at all. >>=20 >> IF the PKI is performing key rollover on the CA certificate then this = is not true. For example when acting as a TLS client the client must = build an appropriate chain to send to the server. In the interest of = limiting options and capability exchanges the client MUST perform this = operation even if it is only useful in some re-enrollment scenarios.=20 >>=20 >> Thanks for your feedback, >=20 > thanx, > Anders >=20 >>=20 >> - max >>=20 >>> Anders >>> PS. By thinking out loud I got an idea for KeyGen2! Add an option >>> to the install certificate part of the protocol where the issuer may >>> claim that this root may be of interest to user. By doing that = KeyGen2 >>> doesn't have to bother users with (for example) accepting VISA's = EMV-root >>> since this a thing for the merchants/acquirers to care about. DS. >>>=20 >>> On 2012-03-27 11:25, Sean Turner wrote: >>>> Just a couple of comments the WG should consider: >>>>=20 >>>> Technical: >>>>=20 >>>> 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use = PKCS#10s=20 >>>> for the request and return the certificate(s) in a mime media type. = In=20 >>>> many instances, the "normal" query/response for a certificate is a=20= >>>> PKCS#10 request followed by a PKCS#7 response, where the PKCS#7 is = the=20 >>>> degenerate certs-only message. Does anyone see any benefit in = reusing=20 >>>> the PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing = it=20 >>>> would align nicely/exactly with the simple PKI request/response = from CMC. >>>>=20 >>>> 2. in s5.6.2, just use application/pkcs8 instead of=20 >>>> application/pkix-privkey. >>>>=20 >>>> Not so technical: >>>>=20 >>>> 1. appendix D really ought to be in its own document or in part of=20= >>>> draft-nourse-scep. >>>>=20 >>>> spt >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>>=20 >>>=20 >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >>=20 >>=20 >=20 From mrex@sap.com Wed Apr 4 14:17:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182B211E8110 for ; Wed, 4 Apr 2012 14:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.815 X-Spam-Level: X-Spam-Status: No, score=-9.815 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rORT5WrNTzen for ; Wed, 4 Apr 2012 14:17:02 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5D85011E8089 for ; Wed, 4 Apr 2012 14:17:01 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q34LGphr000488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Apr 2012 23:16:51 +0200 (MEST) From: Martin Rex Message-Id: <201204042116.q34LGpea018459@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Wed, 4 Apr 2012 23:16:51 +0200 (MEST) In-Reply-To: <7AE2A839-10E9-41D7-ABDD-911AB94786CA@checkpoint.com> from "Yoav Nir" at Apr 3, 12 10:39:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 21:17:03 -0000 Yoav Nir wrote: > > It would force them to choose between not working on Firefox and not > working on iOS. Tough call, and only Apple can solve it. The name constraints will _not_ appear in RootCA certs (=trust anchors), and probably _neither_ in the subCAs directly below the rootCAs, but rather in organizational subCAs signed by subCAs of RootCAs. PKI software that rejects CA certs with name constraints that are _not_ marked critical can be considered broken (because it is _not_ listed as something to check when processing a cert in a certification path in rfc5280 section 6, and rfc5280 explicitly discourages making other conformance checks on attributes from rfc5280 sections 4&5 during certificate path validation). So unless Apple's implementation aborts upon seeing _any_ name constraints (even non-critical ones), non-critical name constraints might interoperate with most of the installed base. But you will really have to test interop, and probably for several dozen independent PKI implementations (and different releases thereof) rather than just looking only at the most recent implementations shipped by the "top 5", potentially Microsoft,NSS,OpenSSL,Apple,Oracle/Java. -Martin From ynir@checkpoint.com Wed Apr 4 14:48:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7232321F8595 for ; Wed, 4 Apr 2012 14:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6IcbN76AnCm for ; Wed, 4 Apr 2012 14:48:00 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 85C3021F8582 for ; Wed, 4 Apr 2012 14:47:59 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q34Llqtw022071; Thu, 5 Apr 2012 00:47:52 +0300 X-CheckPoint: {4F7CCF2A-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 5 Apr 2012 00:47:51 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 5 Apr 2012 00:47:51 +0300 From: Yoav Nir To: "mrex@sap.com" Date: Thu, 5 Apr 2012 00:48:03 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0SrJWZ0Ugl57+OQk2Rr9yNDVYuFQ== Message-ID: References: <201204042116.q34LGpea018459@fs4113.wdf.sap.corp> In-Reply-To: <201204042116.q34LGpea018459@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 21:48:00 -0000 On Apr 5, 2012, at 12:16 AM, Martin Rex wrote: > Yoav Nir wrote: >>=20 >> It would force them to choose between not working on Firefox and not >> working on iOS. Tough call, and only Apple can solve it. >=20 > The name constraints will _not_ appear in RootCA certs (=3Dtrust anchors)= , > and probably _neither_ in the subCAs directly below the rootCAs, but rath= er > in organizational subCAs signed by subCAs of RootCAs. Yes. And if Mozilla requires that those have critical names constraints, th= en the CAs have two options: - Not comply and get removed from Mozilla's trust anchor store - breaking = compatibility with Firefox for the root CA - Comply and get the organizational subCA-signed certificates rejected by = iOS > PKI software that rejects CA certs with name constraints that > are _not_ marked critical can be considered broken (because it is > _not_ listed as something to check when processing a cert in a > certification path in rfc5280 section 6, and rfc5280 explicitly > discourages making other conformance checks on attributes from > rfc5280 sections 4&5 during certificate path validation). > So unless Apple's implementation aborts upon seeing _any_ name > constraints (even non-critical ones), non-critical name constraints > might interoperate with most of the installed base. They probably will. But a certification path that contains such a certifica= te is not compliant with RFC 5280, so it may be considered invalid (if your= policy requires all certificates on the certification path to comply with = 5280) > But you will really have to test interop, and probably for several > dozen independent PKI implementations (and different releases thereof) > rather than just looking only at the most recent implementations > shipped by the "top 5", potentially Microsoft,NSS,OpenSSL,Apple,Oracle/Ja= va. Who's "you"? If I'm implementing an RP, I should accept all certificates (and paths) tha= t comply with current standards, and also with the certificates that are "o= ut there" if broken certificates are out there in significant numbers. If I'm a CA, I should issue certificates that comply with RFC 5280, and pro= bably refrain from using features that don't work on my target RPs. If that= means that nameConstraints as in RFC 5280 are currently unusable that's a = problem, because the constraints that it provides are now seen as needed. From mrex@sap.com Wed Apr 4 15:41:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C4121F84D2 for ; Wed, 4 Apr 2012 15:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5u84z4BLX99 for ; Wed, 4 Apr 2012 15:41:35 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 961BD21F8495 for ; Wed, 4 Apr 2012 15:41:35 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q34MfPSo010534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Apr 2012 00:41:26 +0200 (MEST) From: Martin Rex Message-Id: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Thu, 5 Apr 2012 00:41:24 +0200 (MEST) In-Reply-To: from "Yoav Nir" at Apr 5, 12 00:48:03 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 22:41:37 -0000 Yoav Nir wrote: > >Martin Rex wrote: >> >> Yoav Nir wrote: >>> >>> It would force them to choose between not working on Firefox and not >>> working on iOS. Tough call, and only Apple can solve it. >> >> The name constraints will _not_ appear in RootCA certs (=trust anchors), >> and probably _neither_ in the subCAs directly below the rootCAs, but rather >> in organizational subCAs signed by subCAs of RootCAs. > > Yes. And if Mozilla requires that those have critical names constraints, then the CAs have two options: > - Not comply and get removed from Mozilla's trust anchor store - breaking compatibility with Firefox for the root CA > - Comply and get the organizational subCA-signed certificates rejected by iOS So is Mozilla going to purge the Equifax TrustAnchor because it signed a GoogleCA organizational cert without critical name constraints? .. or require them to revoke it an re-issue with name constraints for ~200 DNS Domains? I believe Microsoft is also operating an organizational CA below one of the "well-known" roots without name constraints. And those are the two that I happen to know, there are probably more of them out there. > > > PKI software that rejects CA certs with name constraints that > > are _not_ marked critical can be considered broken (because it is > > _not_ listed as something to check when processing a cert in a > > certification path in rfc5280 section 6, and rfc5280 explicitly > > discourages making other conformance checks on attributes from > > rfc5280 sections 4&5 during certificate path validation). > > So unless Apple's implementation aborts upon seeing _any_ name > > constraints (even non-critical ones), non-critical name constraints > > might interoperate with most of the installed base. > > They probably will. But a certification path that contains such a > certificate is not compliant with RFC 5280, so it may be considered > invalid (if your policy requires all certificates on the certification > path to comply with 5280) You're misreading rfc5280. A subCA cert with name constraints that is marked non-critical SHOULD be accepted by RPs per rfc-5280. What is non-compliant is the "CA issuing procedure", but that is irrelevant to certificate path validation conforming to rfc5280. > > > But you will really have to test interop, and probably for several > > dozen independent PKI implementations (and different releases thereof) > > rather than just looking only at the most recent implementations > > shipped by the "top 5", potentially Microsoft,NSS,OpenSSL,Apple,Oracle/Java. > > Who's "you"? > If I'm implementing an RP, I should accept all certificates (and paths) > that comply with current standards, and also with the certificates that > are "out there" if broken certificates are out there in significant > numbers. > If I'm a CA, I should issue certificates that comply with RFC 5280, > and probably refrain from using features that don't work on my target > RPs. If that means that nameConstraints as in RFC 5280 are currently > unusable that's a problem, because the constraints that it provides > are now seen as needed. Correct, name constraints as "envisioned" by rfc5280 are unusable, in case that you find yourself unable to ignore that invalid MUST. -Martin From ynir@checkpoint.com Wed Apr 4 16:07:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE9321F8531 for ; Wed, 4 Apr 2012 16:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANBM9Dpr4vEX for ; Wed, 4 Apr 2012 16:07:23 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1449721F8484 for ; Wed, 4 Apr 2012 16:07:22 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q34N7KJf000762; Thu, 5 Apr 2012 02:07:20 +0300 X-CheckPoint: {4F7CE1C9-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 5 Apr 2012 02:07:20 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 5 Apr 2012 02:07:19 +0300 From: Yoav Nir To: "mrex@sap.com" Date: Thu, 5 Apr 2012 02:07:19 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0St6+Y9rd4uW8WSPuws/p4fNUBug== Message-ID: <0DFEAD5C-C1DB-48FA-81FA-A523464ABA9C@checkpoint.com> References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> In-Reply-To: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 23:07:24 -0000 On Apr 5, 2012, at 1:41 AM, Martin Rex wrote: > Yoav Nir wrote: >>=20 >> Martin Rex wrote: >>>=20 >>> Yoav Nir wrote: >>>>=20 >>>> It would force them to choose between not working on Firefox and not >>>> working on iOS. Tough call, and only Apple can solve it. >>>=20 >>> The name constraints will _not_ appear in RootCA certs (=3Dtrust anchor= s), >>> and probably _neither_ in the subCAs directly below the rootCAs, but ra= ther >>> in organizational subCAs signed by subCAs of RootCAs. >>=20 >> Yes. And if Mozilla requires that those have critical names constraints,= then the CAs have two options: >> - Not comply and get removed from Mozilla's trust anchor store - breakin= g compatibility with Firefox for the root CA >> - Comply and get the organizational subCA-signed certificates rejected b= y iOS >=20 > So is Mozilla going to purge the Equifax TrustAnchor because it signed > a GoogleCA organizational cert without critical name constraints? > .. or require them to revoke it an re-issue with name constraints > for ~200 DNS Domains? I believe Microsoft is also operating an > organizational CA below one of the "well-known" roots without > name constraints. And those are the two that I happen to know, > there are probably more of them out there. That is an idea that Mozilla is thinking about. Not purge Equifax for what = they have done, but require them to use critical name constraints in the fu= ture. >>> PKI software that rejects CA certs with name constraints that >>> are _not_ marked critical can be considered broken (because it is >>> _not_ listed as something to check when processing a cert in a >>> certification path in rfc5280 section 6, and rfc5280 explicitly >>> discourages making other conformance checks on attributes from >>> rfc5280 sections 4&5 during certificate path validation). >>> So unless Apple's implementation aborts upon seeing _any_ name >>> constraints (even non-critical ones), non-critical name constraints >>> might interoperate with most of the installed base. >>=20 >> They probably will. But a certification path that contains such a >> certificate is not compliant with RFC 5280, so it may be considered >> invalid (if your policy requires all certificates on the certification >> path to comply with 5280) >=20 > You're misreading rfc5280. A subCA cert with name constraints that is > marked non-critical SHOULD be accepted by RPs per rfc-5280. The RFC is silent about non-critical nameConstraints, but I guess it doesn'= t say that it should be rejected. So requiring that the certificates be iss= ued according to the profile in RFC 5280 is not a requirement of RFC 5280, = but it may be policy.=20 >=20 > What is non-compliant is the "CA issuing procedure", but that is irreleva= nt > to certificate path validation conforming to rfc5280. >=20 >=20 >>=20 >>> But you will really have to test interop, and probably for several >>> dozen independent PKI implementations (and different releases thereof) >>> rather than just looking only at the most recent implementations >>> shipped by the "top 5", potentially Microsoft,NSS,OpenSSL,Apple,Oracle/= Java. >>=20 >> Who's "you"? >> If I'm implementing an RP, I should accept all certificates (and paths) >> that comply with current standards, and also with the certificates that >> are "out there" if broken certificates are out there in significant >> numbers. >> If I'm a CA, I should issue certificates that comply with RFC 5280, >> and probably refrain from using features that don't work on my target >> RPs. If that means that nameConstraints as in RFC 5280 are currently >> unusable that's a problem, because the constraints that it provides >> are now seen as needed. >=20 > Correct, name constraints as "envisioned" by rfc5280 are unusable, > in case that you find yourself unable to ignore that invalid MUST. Would we be having this discussion if iOS did not reject critical nameConst= raints? If all popular browsers processed them correctly, would you still = claim they were unusable? From mrex@sap.com Wed Apr 4 16:49:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC2911E811C for ; Wed, 4 Apr 2012 16:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.085 X-Spam-Level: X-Spam-Status: No, score=-10.085 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9nTfRiTAUkP for ; Wed, 4 Apr 2012 16:49:25 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0C68E11E80FE for ; Wed, 4 Apr 2012 16:49:24 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q34NnBGh015934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Apr 2012 01:49:15 +0200 (MEST) From: Martin Rex Message-Id: <201204042349.q34NnADN027181@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Thu, 5 Apr 2012 01:49:10 +0200 (MEST) In-Reply-To: <0DFEAD5C-C1DB-48FA-81FA-A523464ABA9C@checkpoint.com> from "Yoav Nir" at Apr 5, 12 02:07:19 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 23:49:25 -0000 Yoav Nir wrote: > > Would we be having this discussion if iOS did not reject critical > nameConstraints? If all popular browsers processed them correctly, > would you still claim they were unusable? Yes. Because the name constraints relevant for browsers would be those applying to subjectAltNames, and support for name constraints on subjectAltNames is purely optional. So some conforming implementations would reject certificate paths with such certs in them, some less anal implementations would ignore the constraints in-spite of being marked critical, and subCAs could still evade the constraints by issuing certs with only CN-IDs and no subjectAltNames... Whether a feature is usable is determined by the level of non-interoperability the use of that feature creates. An attitude "if it works in the most recent releases of the 5 most-used browsers" seems like a bad idea. We do have customers (running web shops) that care about continued interop with MSIE version 6, because the amount of their customers still using that browsers is non-marginal and they do not want to risk lost sales trying to force their customers to upgrade their clients. If Mozilla would adopt a policy of the kind that you're describing, it would probably turn away users of that browser, or cause them to dig in on a version of the browser where things still work. A non-marginal amount of users seems to prefer FF 3.6.x to any of the update-crazy successors already. -Martin From SChokhani@cygnacom.com Wed Apr 4 17:47:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4011E8074 for ; Wed, 4 Apr 2012 17:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqvtkDi60pPL for ; Wed, 4 Apr 2012 17:47:07 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1663811E8086 for ; Wed, 4 Apr 2012 17:47:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,371,1330923600"; d="scan'208";a="704247" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 04 Apr 2012 20:47:04 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 4 Apr 2012 20:47:04 -0400 From: Santosh Chokhani To: Yoav Nir , "mrex@sap.com" Date: Wed, 4 Apr 2012 20:47:03 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0SrJWZ0Ugl57+OQk2Rr9yNDVYuFQAGPHRQ Message-ID: References: <201204042116.q34LGpea018459@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 00:47:08 -0000 This is quite silly conversation. RP should NOT reject certificate because = the criticality flag was not per the standard. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Yoa= v Nir Sent: Wednesday, April 04, 2012 5:48 PM To: mrex@sap.com Cc: pkix@ietf.org; paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name On Apr 5, 2012, at 12:16 AM, Martin Rex wrote: > Yoav Nir wrote: >>=20 >> It would force them to choose between not working on Firefox and not=20 >> working on iOS. Tough call, and only Apple can solve it. >=20 > The name constraints will _not_ appear in RootCA certs (=3Dtrust=20 > anchors), and probably _neither_ in the subCAs directly below the=20 > rootCAs, but rather in organizational subCAs signed by subCAs of RootCAs. Yes. And if Mozilla requires that those have critical names constraints, th= en the CAs have two options: - Not comply and get removed from Mozilla's trust anchor store - breaking = compatibility with Firefox for the root CA - Comply and get the organizational subCA-signed certificates rejected by = iOS > PKI software that rejects CA certs with name constraints that are=20 > _not_ marked critical can be considered broken (because it is _not_=20 > listed as something to check when processing a cert in a certification=20 > path in rfc5280 section 6, and rfc5280 explicitly discourages making=20 > other conformance checks on attributes from > rfc5280 sections 4&5 during certificate path validation). > So unless Apple's implementation aborts upon seeing _any_ name=20 > constraints (even non-critical ones), non-critical name constraints=20 > might interoperate with most of the installed base. They probably will. But a certification path that contains such a certifica= te is not compliant with RFC 5280, so it may be considered invalid (if your= policy requires all certificates on the certification path to comply with = 5280) > But you will really have to test interop, and probably for several=20 > dozen independent PKI implementations (and different releases thereof)=20 > rather than just looking only at the most recent implementations=20 > shipped by the "top 5", potentially Microsoft,NSS,OpenSSL,Apple,Oracle/Ja= va. Who's "you"? If I'm implementing an RP, I should accept all certificates (and paths) tha= t comply with current standards, and also with the certificates that are "o= ut there" if broken certificates are out there in significant numbers. If I'm a CA, I should issue certificates that comply with RFC 5280, and pro= bably refrain from using features that don't work on my target RPs. If that= means that nameConstraints as in RFC 5280 are currently unusable that's a = problem, because the constraints that it provides are now seen as needed. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From SChokhani@cygnacom.com Wed Apr 4 17:49:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7251D11E8086 for ; Wed, 4 Apr 2012 17:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gatuGFgYBLJ0 for ; Wed, 4 Apr 2012 17:49:18 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id A264E11E8074 for ; Wed, 4 Apr 2012 17:49:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,371,1330923600"; d="scan'208";a="704253" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 04 Apr 2012 20:49:18 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Wed, 4 Apr 2012 20:49:17 -0400 From: Santosh Chokhani To: Yoav Nir , "mrex@sap.com" Date: Wed, 4 Apr 2012 20:49:17 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0St6+Y9rd4uW8WSPuws/p4fNUBugADheBw Message-ID: References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> <0DFEAD5C-C1DB-48FA-81FA-A523464ABA9C@checkpoint.com> In-Reply-To: <0DFEAD5C-C1DB-48FA-81FA-A523464ABA9C@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 00:49:19 -0000 The RFC does not require you to reject a certificate because name constrain= t was marked non critical. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Yoa= v Nir Sent: Wednesday, April 04, 2012 7:07 PM To: mrex@sap.com Cc: pkix@ietf.org; paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name On Apr 5, 2012, at 1:41 AM, Martin Rex wrote: > Yoav Nir wrote: >>=20 >> Martin Rex wrote: >>>=20 >>> Yoav Nir wrote: >>>>=20 >>>> It would force them to choose between not working on Firefox and=20 >>>> not working on iOS. Tough call, and only Apple can solve it. >>>=20 >>> The name constraints will _not_ appear in RootCA certs (=3Dtrust=20 >>> anchors), and probably _neither_ in the subCAs directly below the=20 >>> rootCAs, but rather in organizational subCAs signed by subCAs of RootCA= s. >>=20 >> Yes. And if Mozilla requires that those have critical names constraints,= then the CAs have two options: >> - Not comply and get removed from Mozilla's trust anchor store -=20 >> breaking compatibility with Firefox for the root CA >> - Comply and get the organizational subCA-signed certificates=20 >> rejected by iOS >=20 > So is Mozilla going to purge the Equifax TrustAnchor because it signed=20 > a GoogleCA organizational cert without critical name constraints? > .. or require them to revoke it an re-issue with name constraints for=20 > ~200 DNS Domains? I believe Microsoft is also operating an=20 > organizational CA below one of the "well-known" roots without name=20 > constraints. And those are the two that I happen to know, there are=20 > probably more of them out there. That is an idea that Mozilla is thinking about. Not purge Equifax for what = they have done, but require them to use critical name constraints in the fu= ture. >>> PKI software that rejects CA certs with name constraints that are=20 >>> _not_ marked critical can be considered broken (because it is _not_=20 >>> listed as something to check when processing a cert in a=20 >>> certification path in rfc5280 section 6, and rfc5280 explicitly=20 >>> discourages making other conformance checks on attributes from >>> rfc5280 sections 4&5 during certificate path validation). >>> So unless Apple's implementation aborts upon seeing _any_ name=20 >>> constraints (even non-critical ones), non-critical name constraints=20 >>> might interoperate with most of the installed base. >>=20 >> They probably will. But a certification path that contains such a=20 >> certificate is not compliant with RFC 5280, so it may be considered=20 >> invalid (if your policy requires all certificates on the=20 >> certification path to comply with 5280) >=20 > You're misreading rfc5280. A subCA cert with name constraints that is=20 > marked non-critical SHOULD be accepted by RPs per rfc-5280. The RFC is silent about non-critical nameConstraints, but I guess it doesn'= t say that it should be rejected. So requiring that the certificates be iss= ued according to the profile in RFC 5280 is not a requirement of RFC 5280, = but it may be policy.=20 >=20 > What is non-compliant is the "CA issuing procedure", but that is=20 > irrelevant to certificate path validation conforming to rfc5280. >=20 >=20 >>=20 >>> But you will really have to test interop, and probably for several=20 >>> dozen independent PKI implementations (and different releases=20 >>> thereof) rather than just looking only at the most recent=20 >>> implementations shipped by the "top 5", potentially Microsoft,NSS,OpenS= SL,Apple,Oracle/Java. >>=20 >> Who's "you"? >> If I'm implementing an RP, I should accept all certificates (and=20 >> paths) that comply with current standards, and also with the=20 >> certificates that are "out there" if broken certificates are out=20 >> there in significant numbers. >> If I'm a CA, I should issue certificates that comply with RFC 5280,=20 >> and probably refrain from using features that don't work on my target=20 >> RPs. If that means that nameConstraints as in RFC 5280 are currently=20 >> unusable that's a problem, because the constraints that it provides=20 >> are now seen as needed. >=20 > Correct, name constraints as "envisioned" by rfc5280 are unusable, in=20 > case that you find yourself unable to ignore that invalid MUST. Would we be having this discussion if iOS did not reject critical nameConst= raints? If all popular browsers processed them correctly, would you still = claim they were unusable? _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From anders.rundgren@telia.com Thu Apr 5 01:41:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C9721F8671 for ; Thu, 5 Apr 2012 01:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRJ+BPsgCu8l for ; Thu, 5 Apr 2012 01:41:53 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 075D521F856F for ; Thu, 5 Apr 2012 01:41:47 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E009A61F8; Thu, 5 Apr 2012 10:41:42 +0200 Message-ID: <4F7D5ABC.8080400@telia.com> Date: Thu, 05 Apr 2012 10:41:32 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Max Pritikin References: <4F718771.6060906@ieca.com> <4F719B3D.10101@telia.com> <4F7AFEF8.7050406@telia.com> <2B4C275D-3278-4A0F-B231-D7384AEE9489@cisco.com> In-Reply-To: <2B4C275D-3278-4A0F-B231-D7384AEE9489@cisco.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 08:41:54 -0000 On 2012-04-04 20:08, Max Pritikin wrote: > > On Apr 3, 2012, at 7:45 AM, Anders Rundgren wrote: > >> On 2012-04-03 01:48, Max Pritikin wrote: >>> >>> Comments inline, >>> >>> On Mar 27, 2012, at 4:49 AM, Anders Rundgren wrote: >>> >>>> Continuing this thread... >>>> >>>> From the abstract I would be interested in hearing what >>>> >>>> "simple Public Key Infrastructure clients" >>>> >>>> actually refer to. >>> >>> The first paragraph of the introduction notes that: "EST is designed to be easily implemented by clients and servers using common "off the shelf" PKI, HTTP, and TLS components". This also relates to the use of the "simple" messages defined in CMC. >> >> That's one way of expressing it. I'm a hands-on guy so I am rather >> thinking about how well it fits things like this: >> >> http://www.pcworld.com/businesscenter/article/252584/ibm_cio_discusses_big_blues_byod_strategy.html >> >> IMO EST doesn't address this market without adding non-standard >> "bootstrap" steps like Cisco's AnyConnect. I find AnyConnect pretty >> quirky and (undocumented...) compared to Apple's bootstrap profile scheme. >> >> It seems that you actually must be a device/OS vendor in order to implement >> things the way Apple do since no "mere mortals" can get under the hood or >> dump arbitrary junk in SYSTEM32 like we did during the Windows days. > > A general purpose bootstrapping system that works for a variety of solutions > ranging from Anyconnect products to the Iphone is a great idea. I'd happily > provide input on such a working group. EST within pkix is not the proper > venue for those ideas though. PKIX is indeed the wrong place for creating a new mainstream enrollment system since all bootstrapping systems I have seen are based on XML. Unfortunately none of "The big three" are interested in standardization efforts regarding enrollment; they rather have, or are in the process of creating such things on their own. Given the lack of interest among SDOs, I think this is the only reasonable decision. In addition, I can hardly imagine Cisco and Checkpoint cooperating on VPM BYOD enrollment so those who (like me) actually have to deploy stuff at customer sites probably gain most by one of the big three coming out as winner although it will take a while. Regards, Anders > > For extensibility we did make it clear that additional functionalities could be support (at new URIs). Once you get a standard together for your bootstrapping ideas above we should be able to easily integrate with the EST extensibility. > >>>> "This profile, called Enrollment over Secure Transport (EST), >>>> describes a simple yet functional certificate management protocol" >>>> >>>> If you combine all the options, it is not that simple anymore. >>>> Is a client and server assumed to support all the options? >>>> If not, how are they supposed to know which subset that can be used? >>>> Looks like a rather configuration-dependent scheme IMHO. >>> >>> If you can think of any options which can be removed please indicate them and suggest their removal. Although I feel we've done a good job ensuring there are very few options I'd happily hear of ones that can go away. >> >> In theory "simple" respectively "full" requests could be viewed as flexibility but in reality it forces you to implement both in order to claim compliance. > > Multiple points in the document /fullCMC transport is indicated as optional. Although there is not a clear specification of the error code to respond with if it is not available. I'll add clarification. > >> I guess the upgraded AnyConnect client will take care of server preferences? > > I don't know anything about the AnyConnect team's product plans. > > Is there something about server preferences that you feel should be included in the EST protocol exchange? > >>>> "K1 "Algorithm agility". The protocol MUST support algorithm agility" >>>> >>>> The author's opinion on what that means is flawed. Although supporting >>>> a bunch of TLS ciphers may be interesting, algorithm agility regarding >>>> generated keys is a parameter that most (if not all) issuers care about. >>> >>> The authors opinion is irrelevant as we're discussing the actual wording of the text. >>> I agree that K1 should also reference the type of key material being enrolled. >> >> Isn't the bigger question then how to get it in the protocol? >> >> Quite a bunch of PKIX enrollment protocols have acquired this ability >> through proprietary protocol bootstrap schemes. AFAIK none of the >> protocols have it natively. This was BTW one of the (numerous) >> motivations behind KeyGen2; creating *true* interoperability. > > This would be a lot easier if you would provide constructive feedback along the lines of suggesting improvements. As it is I'm trying to guess from your vague statement what you really want. Generally communication works better when both parties are straightforward and direct about what they are looking for. > > If we added something like a "/enrollBootstrap" what sort of response are you envisioning? What would its mime-type be and is there an already existing format for the response that you have in mind? If there isn't such a thing what would serve this role? > > For example would it be appropriate to have the server distribute an example pkcs10 with some of the fields already filled out? Is that the sort of thing you have in mind? > >>>> "5.3 Distribution of CA certificates >>>> Before engaging in enrollment operations, clients MUST request trust >>>> anchor information (in the form of certificates) by sending an HTTPS >>>> GET message to the EST base URI with the relative path extension >>>> '/CACerts'" >>>> >>>> This mandatory requirement isn't particularly universal. A more >>>> common method is that the user rather gets an option "accepting" the >>>> root of the distributed certificate path. >>> >>> I think you are excessively combining the server authentication discussion (sections 5.2 and 4.3.1.1) and the distribution of CA certificates. >> >> That's quite possible. I just read the text "as is". > > If there is "as is" text that is confusing it would help if you reference the exact text. I'm and editor not a mind reader, Jim! > > Thanks, > > - max > >>> There is value in the "MUST" here because then the client has any possible CA key rollover certificates which might be necessary for chain building etc that might be encountered during the enrollment operations. (e.g. if the client is issued a certificate using the CA's new certificate the client has sufficient information to know what happened and to successfully use its new certificate). >> >> OK. >> >>> >>>> In today's server-centric >>>> world the CA of a *client certificate* often doesn't have any >>>> meaning for the client/user at all. >>> >>> IF the PKI is performing key rollover on the CA certificate then this is not true. For example when acting as a TLS client the client must build an appropriate chain to send to the server. In the interest of limiting options and capability exchanges the client MUST perform this operation even if it is only useful in some re-enrollment scenarios. >>> >>> Thanks for your feedback, >> >> thanx, >> Anders >> >>> >>> - max >>> >>>> Anders >>>> PS. By thinking out loud I got an idea for KeyGen2! Add an option >>>> to the install certificate part of the protocol where the issuer may >>>> claim that this root may be of interest to user. By doing that KeyGen2 >>>> doesn't have to bother users with (for example) accepting VISA's EMV-root >>>> since this a thing for the merchants/acquirers to care about. DS. >>>> >>>> On 2012-03-27 11:25, Sean Turner wrote: >>>>> Just a couple of comments the WG should consider: >>>>> >>>>> Technical: >>>>> >>>>> 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s >>>>> for the request and return the certificate(s) in a mime media type. In >>>>> many instances, the "normal" query/response for a certificate is a >>>>> PKCS#10 request followed by a PKCS#7 response, where the PKCS#7 is the >>>>> degenerate certs-only message. Does anyone see any benefit in reusing >>>>> the PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing it >>>>> would align nicely/exactly with the simple PKI request/response from CMC. >>>>> >>>>> 2. in s5.6.2, just use application/pkcs8 instead of >>>>> application/pkix-privkey. >>>>> >>>>> Not so technical: >>>>> >>>>> 1. appendix D really ought to be in its own document or in part of >>>>> draft-nourse-scep. >>>>> >>>>> spt >>>>> _______________________________________________ >>>>> 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 tomas@primekey.se Thu Apr 5 01:56:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BB421F85E7 for ; Thu, 5 Apr 2012 01:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7+RnJn7OOiA for ; Thu, 5 Apr 2012 01:56:29 -0700 (PDT) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id 932A121F85DF for ; Thu, 5 Apr 2012 01:56:29 -0700 (PDT) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 24357E1B51 for ; Thu, 5 Apr 2012 10:56:38 +0200 (CEST) Received: from [192.168.0.3] (h234n23-aars-gr100.ias.bredband.telia.com [81.230.48.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 10AF5E0181 for ; Thu, 5 Apr 2012 10:56:38 +0200 (CEST) Message-ID: <4F7D5E3B.8010708@primekey.se> Date: Thu, 05 Apr 2012 10:56:27 +0200 From: Tomas Gustavsson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120402 Thunderbird/11.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <4F718771.6060906@ieca.com> <4F719B3D.10101@telia.com> <4F7AFEF8.7050406@telia.com> <2B4C275D-3278-4A0F-B231-D7384AEE9489@cisco.com> <4F7D5ABC.8080400@telia.com> In-Reply-To: <4F7D5ABC.8080400@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [pkix] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 08:56:30 -0000 On 04/05/2012 10:41 AM, Anders Rundgren wrote: > On 2012-04-04 20:08, Max Pritikin wrote: >> >> On Apr 3, 2012, at 7:45 AM, Anders Rundgren wrote: >> >>> On 2012-04-03 01:48, Max Pritikin wrote: >>>> >>>> Comments inline, >>>> >>>> On Mar 27, 2012, at 4:49 AM, Anders Rundgren wrote: >>>> >>>>> Continuing this thread... >>>>> >>>>> From the abstract I would be interested in hearing what >>>>> >>>>> "simple Public Key Infrastructure clients" >>>>> >>>>> actually refer to. >>>> >>>> The first paragraph of the introduction notes that: "EST is designed to be easily implemented by clients and servers using common "off the shelf" PKI, HTTP, and TLS components". This also relates to the use of the "simple" messages defined in CMC. >>> >>> That's one way of expressing it. I'm a hands-on guy so I am rather >>> thinking about how well it fits things like this: >>> >>> http://www.pcworld.com/businesscenter/article/252584/ibm_cio_discusses_big_blues_byod_strategy.html >>> >>> IMO EST doesn't address this market without adding non-standard >>> "bootstrap" steps like Cisco's AnyConnect. I find AnyConnect pretty >>> quirky and (undocumented...) compared to Apple's bootstrap profile scheme. >>> >>> It seems that you actually must be a device/OS vendor in order to implement >>> things the way Apple do since no "mere mortals" can get under the hood or >>> dump arbitrary junk in SYSTEM32 like we did during the Windows days. >> >> A general purpose bootstrapping system that works for a variety of solutions >> ranging from Anyconnect products to the Iphone is a great idea. I'd happily >> provide input on such a working group. EST within pkix is not the proper >> venue for those ideas though. > > PKIX is indeed the wrong place for creating a new mainstream enrollment system > since all bootstrapping systems I have seen are based on XML. > > Unfortunately none of "The big three" are interested in standardization efforts > regarding enrollment; they rather have, or are in the process of creating such > things on their own. Given the lack of interest among SDOs, I think this is > the only reasonable decision. > > In addition, I can hardly imagine Cisco and Checkpoint cooperating on VPM BYOD enrollment > so those who (like me) actually have to deploy stuff at customer sites probably gain > most by one of the big three coming out as winner although it will take a while. That's really painting a dark future. Those big ones have generally done a lot to make things harder for us techies, and indeed things are very hard today, much harder than it would have needed to be if they had cooperated in something like IETF. Cheers, Tomas From ynir@checkpoint.com Thu Apr 5 04:44:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200CD21F86E4 for ; Thu, 5 Apr 2012 04:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjM7SpWr-ReE for ; Thu, 5 Apr 2012 04:44:39 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F2F1D21F86D1 for ; Thu, 5 Apr 2012 04:44:38 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q35Bib5Q016398; Thu, 5 Apr 2012 14:44:37 +0300 X-CheckPoint: {4F7D933E-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 5 Apr 2012 14:44:36 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 5 Apr 2012 14:44:34 +0300 From: Yoav Nir To: Tomas Gustavsson Date: Thu, 5 Apr 2012 14:44:33 +0300 Thread-Topic: [pkix] some comments on draft-ietf-pkix-est-01 Thread-Index: Ac0TIXgHSNiPCD6jTvS+O5wEPxQzFw== Message-ID: <6AD02158-2230-4655-9BEF-4686E1C8E9BC@checkpoint.com> References: <4F718771.6060906@ieca.com> <4F719B3D.10101@telia.com> <4F7AFEF8.7050406@telia.com> <2B4C275D-3278-4A0F-B231-D7384AEE9489@cisco.com> <4F7D5ABC.8080400@telia.com> <4F7D5E3B.8010708@primekey.se> In-Reply-To: <4F7D5E3B.8010708@primekey.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "pkix@ietf.org" Subject: Re: [pkix] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 11:44:40 -0000 On Apr 5, 2012, at 11:56 AM, Tomas Gustavsson wrote: > On 04/05/2012 10:41 AM, Anders Rundgren wrote: >> On 2012-04-04 20:08, Max Pritikin wrote: >>>=20 >>> On Apr 3, 2012, at 7:45 AM, Anders Rundgren wrote: >>>=20 >>>> On 2012-04-03 01:48, Max Pritikin wrote: >>>>>=20 >>>>> Comments inline, >>>>>=20 >>>>> On Mar 27, 2012, at 4:49 AM, Anders Rundgren wrote: >>>>>=20 >>>>>> Continuing this thread... >>>>>>=20 >>>>>> From the abstract I would be interested in hearing what >>>>>>=20 >>>>>> "simple Public Key Infrastructure clients" >>>>>>=20 >>>>>> actually refer to. >>>>>=20 >>>>> The first paragraph of the introduction notes that: "EST is designed = to be easily implemented by clients and servers using common "off the shelf= " PKI, HTTP, and TLS components". This also relates to the use of the "simp= le" messages defined in CMC. >>>>=20 >>>> That's one way of expressing it. I'm a hands-on guy so I am rather >>>> thinking about how well it fits things like this: >>>>=20 >>>> http://www.pcworld.com/businesscenter/article/252584/ibm_cio_discusses= _big_blues_byod_strategy.html >>>>=20 >>>> IMO EST doesn't address this market without adding non-standard >>>> "bootstrap" steps like Cisco's AnyConnect. I find AnyConnect pretty >>>> quirky and (undocumented...) compared to Apple's bootstrap profile sch= eme. >>>>=20 >>>> It seems that you actually must be a device/OS vendor in order to impl= ement >>>> things the way Apple do since no "mere mortals" can get under the hood= or >>>> dump arbitrary junk in SYSTEM32 like we did during the Windows days. >>>=20 >>> A general purpose bootstrapping system that works for a variety of solu= tions >>> ranging from Anyconnect products to the Iphone is a great idea. I'd hap= pily >>> provide input on such a working group. EST within pkix is not the prope= r >>> venue for those ideas though. >>=20 >> PKIX is indeed the wrong place for creating a new mainstream enrollment = system >> since all bootstrapping systems I have seen are based on XML. >>=20 >> Unfortunately none of "The big three" are interested in standardization = efforts >> regarding enrollment; they rather have, or are in the process of creatin= g such >> things on their own. Given the lack of interest among SDOs, I think thi= s is >> the only reasonable decision. >>=20 >> In addition, I can hardly imagine Cisco and Checkpoint cooperating on VP= M BYOD enrollment >> so those who (like me) actually have to deploy stuff at customer sites p= robably gain >> most by one of the big three coming out as winner although it will take = a while. >=20 > That's really painting a dark future. Those big ones have generally done= =20 > a lot to make things harder for us techies, and indeed things are very=20 > hard today, much harder than it would have needed to be if they had=20 > cooperated in something like IETF. Who are these "big three" of which you speak? Yoav= From anders.rundgren@telia.com Thu Apr 5 09:12:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C321221F86AF for ; Thu, 5 Apr 2012 09:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoZug0drdy-0 for ; Thu, 5 Apr 2012 09:12:19 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id BC1FF21F864C for ; Thu, 5 Apr 2012 09:12:18 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB81D0070BEE1; Thu, 5 Apr 2012 18:12:10 +0200 Message-ID: <4F7DC44F.7070906@telia.com> Date: Thu, 05 Apr 2012 18:11:59 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Yoav Nir References: <4F718771.6060906@ieca.com> <4F719B3D.10101@telia.com> <4F7AFEF8.7050406@telia.com> <2B4C275D-3278-4A0F-B231-D7384AEE9489@cisco.com> <4F7D5ABC.8080400@telia.com> <4F7D5E3B.8010708@primekey.se> <6AD02158-2230-4655-9BEF-4686E1C8E9BC@checkpoint.com> In-Reply-To: <6AD02158-2230-4655-9BEF-4686E1C8E9BC@checkpoint.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 16:12:19 -0000 On 2012-04-05 13:44, Yoav Nir wrote: > > On Apr 5, 2012, at 11:56 AM, Tomas Gustavsson wrote: > >> On 04/05/2012 10:41 AM, Anders Rundgren wrote: >>> On 2012-04-04 20:08, Max Pritikin wrote: >>>> >>>> On Apr 3, 2012, at 7:45 AM, Anders Rundgren wrote: >>>> >>>>> On 2012-04-03 01:48, Max Pritikin wrote: >>>>>> >>>>>> Comments inline, >>>>>> >>>>>> On Mar 27, 2012, at 4:49 AM, Anders Rundgren wrote: >>>>>> >>>>>>> Continuing this thread... >>>>>>> >>>>>>> From the abstract I would be interested in hearing what >>>>>>> >>>>>>> "simple Public Key Infrastructure clients" >>>>>>> >>>>>>> actually refer to. >>>>>> >>>>>> The first paragraph of the introduction notes that: "EST is designed to be easily implemented by clients and servers using common "off the shelf" PKI, HTTP, and TLS components". This also relates to the use of the "simple" messages defined in CMC. >>>>> >>>>> That's one way of expressing it. I'm a hands-on guy so I am rather >>>>> thinking about how well it fits things like this: >>>>> >>>>> http://www.pcworld.com/businesscenter/article/252584/ibm_cio_discusses_big_blues_byod_strategy.html >>>>> >>>>> IMO EST doesn't address this market without adding non-standard >>>>> "bootstrap" steps like Cisco's AnyConnect. I find AnyConnect pretty >>>>> quirky and (undocumented...) compared to Apple's bootstrap profile scheme. >>>>> >>>>> It seems that you actually must be a device/OS vendor in order to implement >>>>> things the way Apple do since no "mere mortals" can get under the hood or >>>>> dump arbitrary junk in SYSTEM32 like we did during the Windows days. >>>> >>>> A general purpose bootstrapping system that works for a variety of solutions >>>> ranging from Anyconnect products to the Iphone is a great idea. I'd happily >>>> provide input on such a working group. EST within pkix is not the proper >>>> venue for those ideas though. >>> >>> PKIX is indeed the wrong place for creating a new mainstream enrollment system >>> since all bootstrapping systems I have seen are based on XML. >>> >>> Unfortunately none of "The big three" are interested in standardization efforts >>> regarding enrollment; they rather have, or are in the process of creating such >>> things on their own. Given the lack of interest among SDOs, I think this is >>> the only reasonable decision. >>> >>> In addition, I can hardly imagine Cisco and Checkpoint cooperating on VPM BYOD enrollment >>> so those who (like me) actually have to deploy stuff at customer sites probably gain >>> most by one of the big three coming out as winner although it will take a while. >> >> That's really painting a dark future. Those big ones have generally done >> a lot to make things harder for us techies, and indeed things are very >> hard today, much harder than it would have needed to be if they had >> cooperated in something like IETF. > > Who are these "big three" of which you speak? Yoav, It was I who mentioned "the big three". They are also known as Google, Apple and Microsoft. Together they define 99% of our mobile devices. Most of these are out of reach for third-party enrollment software. Cisco's AnyConnect to take one example isn't possible to install on a stock Android phones. Since the big three nowadays rollout entire global ecosystems with everything from devices to services, the motives for standardization are fewer than before. The SDO camp haven't noticed this "paradigm shift", which probably requires fundamentally different constellations in order to generate value. A rather peculiar thing with standardization projects is that these unlike other development activities, hardly ever are subject to interim reviews, or have to revise the charter due to changes in the market. The discussion around enrollment of PIN-protected credentials was extremely silly. Have anybody heard about a bank credential *not* using PIN-codes? Anders > > Yoav > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From kent@bbn.com Thu Apr 5 11:08:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255EF21F85F8 for ; Thu, 5 Apr 2012 11:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOPxv-qyHjC5 for ; Thu, 5 Apr 2012 11:08:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5186621F85A5 for ; Thu, 5 Apr 2012 11:08:22 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49247) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SFr6L-000FXb-HG; Thu, 05 Apr 2012 14:08:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org> References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org> Date: Thu, 5 Apr 2012 14:08:15 -0400 To: Paul Hoffman From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-878473195==_ma============" Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 18:08:23 -0000 --============_-878473195==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable At 10:34 AM -0700 4/2/12, Paul Hoffman wrote: >Greetings again. I think I understand your=20 >problem with the current draft wording, namely=20 >that it mis-uses terms that already have=20 >specific meanings. I propose the following to=20 >replace both what you proposed and what David=20 >has in the current draft. I believe that this=20 >does not stomp on any current definitions but=20 >still makes it clear that such certificates=20 >exist. > >Certificates with a signing key that is the same=20 >as the key in the subjectPublicKeyInfo, but that=20 >do not include a BasicConstraints extension that=20 >asserts the cA boolean, are commonly used to=20 >convey public keys without an expectation that=20 >the contents of such certificates can be=20 >validated. These certificates are sometimes used=20 >for transmitting a PKIX trust anchor or the=20 >unvalidated public key of an end entity; other=20 >uses are certainly possible as well. The format=20 >and use of such certificates are outside the=20 >scope of both X.509 and this specification. Note=20 >that these certificates cannot formally be=20 >called "self-signed" or "self-issued" because=20 >they do not follow the definition in the=20 >preceding paragraph. > > >Does this work for you? If not, are there any=20 >statements in it that are wrong, or do you want=20 >it to say more? > >--Paul Hoffman Certificates with a signing key that is the same=20 as the key in the subjectPublicKeyInfo, but that=20 do not include a BasicConstraints extension that=20 asserts the cA boolean, are commonly used to=20 convey public keys without an expectation that=20 the contents of such certificates can be=20 validated. I see several problems with the first sentence.=20 =46irst, it's too long :-) Second, a signing key=20 is a private key and the key in the SPKI field is=20 a public key, so they are not the same key.=20 Third, the last phrase "without and expectation=20 =8A" is confusing to me. These certificates are sometimes used for=20 transmitting a PKIX trust anchor or the=20 unvalidated public key of an end entity Let's just refer to a trust anchor, not a "PKIX trust anchor." "unvalidated" may not be the best term here, it's=20 "un-vouched for" relative to a CA. I'll try to=20 think of a better term. ; other uses are certainly possible as well. This statement seems rather vague., it that=20 intentional? I usually try to avoid such=20 open-ended statement in standards documents. Can=20 you describe the non-TA uses of interest,=20 succinctly? The format and use of such certificates are=20 outside the scope of both X.509 and this=20 specification. I don't think the format is an issue here, and=20 this phrase might encourage folks not use the=20 X.509/PKIX format, so I'd like to avoid that=20 suggestion. Note that these certificates cannot formally be=20 called "self-signed" or "self-issued" because=20 they do not follow the definition in the=20 preceding paragraph. This might be a good escape clause. I'll think about it some more. --============_-878473195==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [pkix] 5280 clarifications
At 10:34 AM -0700 4/2/12, Paul Hoffman wrote:
Greetings again. I think I understand your problem with the current draft wording, namely that it mis-uses terms that already have specific meanings. I propose the following to replace both what you proposed and what David has in the current draft. I believe that this does not stomp on any current definitions but still makes it clear that such certificates exist.
Certificates with a signing key that is the same as the key in the subjectPublicKeyInfo, but that do not include a BasicConstraints extension that asserts the cA boolean, are commonly used to convey public keys without an expectation that the contents of such certificates can be validated. These certificates are sometimes used for transmitting a PKIX trust anchor or the unvalidated public key of an end entity; other uses are certainly possible as well. The format and use of such certificates are outside the scope of both X.509 and this specification. Note that these certificates cannot formally be called "self-signed" or "self-issued" because they do not follow the definition in the preceding paragraph.


Does this work for you? If not, are there any statements in it that are wrong, or do you want it to say more?

--Paul Hoffman

Certificates with a signing key that is the same as the key in the subjectPublicKeyInfo, but that do not include a BasicConstraints extension that asserts the cA boolean, are commonly used to convey public keys without an expectation that the contents of such certificates can be validated.
I see several problems with the first sentence.  First, it's too long :-) Second, a signing  key is a private key and the key in the SPKI field is a public key, so they are not the same key. Third, the last phrase "without and expectation =8A" is confusing to me.

These certificates are sometimes used for transmitting a PKIX trust anchor or the unvalidated public key of an end entity

Let's just refer to a trust anchor, not a "PKIX trust anchor."

"unvalidated" may not be the best term here, it's "un-vouched for"  relative to a CA.  I'll try to think of a better term.

; other uses are certainly possible as well.

This statement seems rather vague., it that intentional?  I usually try to avoid such open-ended statement in standards documents. Can you describe the non-TA uses of interest, succinctly?

The format and use of such certificates are outside the scope of both X.509 and this specification.

I don't  think the format is an issue here, and this phrase might encourage folks not use the X.509/PKIX format, so I'd like to avoid that suggestion.

Note that these certificates cannot formally be called "self-signed" or "self-issued" because they do not follow the definition in the preceding paragraph.

This might be a good escape clause. I'll think about it some more.
--============_-878473195==_ma============-- From kent@bbn.com Thu Apr 5 11:08:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F8A21F85A5 for ; Thu, 5 Apr 2012 11:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPvaDcnDL6NR for ; Thu, 5 Apr 2012 11:08:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 275F721F85FF for ; Thu, 5 Apr 2012 11:08:23 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49247) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SFr6J-000FXb-J0; Thu, 05 Apr 2012 14:08:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> Date: Thu, 5 Apr 2012 13:54:50 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 18:08:23 -0000 >... > >You're misreading rfc5280. A subCA cert with name constraints that is >marked non-critical SHOULD be accepted by RPs per rfc-5280. > >What is non-compliant is the "CA issuing procedure", but that is irrelevant >to certificate path validation conforming to rfc5280. yes, 5280 does not mandate that Rps enforce constraints imposed on CAs. Howver, I am aware of at least one implementation that does enable an RP to check for 5280 CA compliance :-). > >... > >Correct, name constraints as "envisioned" by rfc5280 are unusable, >in case that you find yourself unable to ignore that invalid MUST. nonsense. name constraints can be used in any PKI where there there are clear lines of authority for issuing certs relative to a name space. The fact that the public TTP trust model, at the top, does not meet that criterion, is merely an indication of a collision between a business model and technology. Steve From paul.hoffman@vpnc.org Thu Apr 5 11:27:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14AF21F86AF for ; Thu, 5 Apr 2012 11:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sMN4iIRkyaM for ; Thu, 5 Apr 2012 11:27:08 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 25CDB21F86A5 for ; Thu, 5 Apr 2012 11:27:08 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q35IR16E000277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2012 11:27:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman In-Reply-To: Date: Thu, 5 Apr 2012 11:27:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org> To: Stephen Kent X-Mailer: Apple Mail (2.1257) Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 18:27:08 -0000 On Apr 5, 2012, at 11:08 AM, Stephen Kent wrote: > "Certificates with a signing key that is the same as the key in the = subjectPublicKeyInfo, but that do not include a BasicConstraints = extension that asserts the cA boolean, are commonly used to convey = public keys without an expectation that the contents of such = certificates can be validated." I see several problems with the first = sentence. First, it's too long :-) Second, a signing key is a private = key and the key in the SPKI field is a public key, so they are not the = same key. Third, the last phrase "without and expectation =8A" is = confusing to me. The "too long" criticism might be fairer if you proposed shorter = sentences that would still meet your requirements. I can see your pedantic disagreement about the "signing key", but the = fix for that would make the sentence longer. "without an expectation" is indeed unclear. Fixing the second and third issue: Certificates signed with a private = key whose public key is the same as the key in the subjectPublicKeyInfo, = but that do not include a BasicConstraints extension that asserts the cA = boolean, are commonly used to convey public keys when the signing part = does not have an expectation that the contents of such certificates can = be validated. > "These certificates are sometimes used for transmitting a PKIX trust = anchor or the unvalidated public key of an end entity" Let's just refer = to a trust anchor, not a "PKIX trust anchor." "unvalidated" may not be = the best term here, it's "un-vouched for" relative to a CA. I'll try = to think of a better term. Fixed: "These certificates are sometimes used for transmitting a trust = anchor or a end entity's public key that is not vouched for" > "; other uses are certainly possible as well." >=20 > This statement seems rather vague., it that intentional? I usually = try to avoid such open-ended statement in standards documents. Can you = describe the non-TA uses of interest, succinctly? Good point. Let's nuke that. > "The format and use of such certificates are outside the scope of both = X.509 and this specification." I don't think the format is an issue = here, and this phrase might encourage folks not use the X.509/PKIX = format, so I'd like to avoid that suggestion. Fixed: "The use of such certificates are outside the scope of both X.509 = and this specification" > "Note that these certificates cannot formally be called "self-signed" = or "self-issued" because they do not follow the definition in the = preceding paragraph." This might be a good escape clause. I'll think = about it some more. Please do so. In looking at this and the text above, I realize I should = be more specific that these definitions need to be made more specific = for PKIX. Current proposed wording: Certificates signed with a private key whose public key is the same as = the key in the subjectPublicKeyInfo, but that do not include a = BasicConstraints extension that asserts the cA boolean, are commonly = used to convey public keys when the signing part does not have an = expectation that the contents of such certificates can be validated. = These certificates are sometimes used for transmitting a trust anchor or = a end entity's public key that is not vouched for. The use of such = certificates are outside the scope of both X.509 and this specification. = Note that these certificates cannot formally be called "self-signed PKIX = certificates" or "self-issued PKIX certificates" because they do not = follow the definition in the preceding paragraph. --Paul Hoffman From kent@bbn.com Thu Apr 5 11:33:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFCE21F864F for ; Thu, 5 Apr 2012 11:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0whAbwIt3Mk for ; Thu, 5 Apr 2012 11:33:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 547D521F8647 for ; Thu, 5 Apr 2012 11:33:21 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49247) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SFr6K-000FXb-CH; Thu, 05 Apr 2012 14:08:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <201204042116.q34LGpea018459@fs4113.wdf.sap.corp> Date: Thu, 5 Apr 2012 13:56:46 -0400 To: Santosh Chokhani From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 18:33:21 -0000 At 8:47 PM -0400 4/4/12, Santosh Chokhani wrote: >This is quite silly conversation. RP should NOT reject certificate >because the criticality flag was not per the standard. I think the technically correct statement replaces "should not" with "need not." Steve From kent@bbn.com Thu Apr 5 11:54:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4378821F8683 for ; Thu, 5 Apr 2012 11:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAJGs9PLEcel for ; Thu, 5 Apr 2012 11:54:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id F416D21F8681 for ; Thu, 5 Apr 2012 11:54:11 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49261) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SFrog-000GvF-Vp; Thu, 05 Apr 2012 14:53:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org> <87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> Date: Thu, 5 Apr 2012 14:54:08 -0400 To: Paul Hoffman From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-878470445==_ma============" Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 18:54:15 -0000 --============_-878470445==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Paul, Thanskfor the clarifications of intent, and the challenge to re-word the text to yield shorter sentences. How about: It is common practice to use the X.509/PKIX certificate format to transmit a trust anchor or the public key of an end-entity. These certificates are delivered via channels that are deemed secure by the RPs that accept them. Typically such certificates do not include a BasicConstraints extension that asserts the cA Boolean, i.e., they are not marked as CA certificates. A certificate of this sort is validated using the public key from the subjectPublicKeyInfo field, i.e., no CA has signed the certificate. These certificates cannot formally be called "self-signed certificates" or "self-issued certificates" because they do not follow the definition in the preceding paragraph. The use of such certificates is outside the scope of both X.509 and this specification, with regard to certificate path processing. --============_-878470445==_ma============ Content-Type: text/html; charset="us-ascii" Re: [pkix] 5280 clarifications
Paul,

Thanskfor the clarifications of intent, and the challenge to re-word the text to yield shorter sentences.

How about:

It is common practice to use the X.509/PKIX certificate format to transmit a trust anchor or the public key of an end-entity. These certificates are delivered via channels that are deemed  secure by the RPs that accept them.  Typically such certificates do not include a BasicConstraints extension that asserts the cA Boolean, i.e., they are not marked as CA certificates.  A certificate of this sort is validated using the public key from the subjectPublicKeyInfo field, i.e., no CA has signed the certificate.  These certificates cannot formally be called "self-signed certificates" or "self-issued certificates" because they do not follow the definition in the preceding paragraph. The use of such certificates is outside the scope of both X.509 and this specification, with regard to certificate path processing.
--============_-878470445==_ma============-- From paul.hoffman@vpnc.org Thu Apr 5 12:12:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C17121F85D7 for ; Thu, 5 Apr 2012 12:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpoxjfMiJihV for ; Thu, 5 Apr 2012 12:12:40 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EBBFF21F85D4 for ; Thu, 5 Apr 2012 12:12:39 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q35JBFDi001821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2012 12:11:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 5 Apr 2012 12:11:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org> <87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> To: Stephen Kent X-Mailer: Apple Mail (2.1257) Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 19:12:40 -0000 On Apr 5, 2012, at 11:54 AM, Stephen Kent wrote: > Paul, >=20 > Thanskfor the clarifications of intent, and the challenge to re-word = the text to yield shorter sentences. >=20 > How about: >=20 > It is common practice to use the X.509/PKIX certificate format to = transmit a trust anchor or the public key of an end-entity. These = certificates are delivered via channels that are deemed secure by the = RPs that accept them. Typically such certificates do not include a = BasicConstraints extension that asserts the cA Boolean, i.e., they are = not marked as CA certificates. A certificate of this sort is validated = using the public key from the subjectPublicKeyInfo field, i.e., no CA = has signed the certificate. These certificates cannot formally be = called "self-signed certificates" or "self-issued certificates" because = they do not follow the definition in the preceding paragraph. The use of = such certificates is outside the scope of both X.509 and this = specification, with regard to certificate path processing. Excellent, and certainly much better than mine. --Paul Hoffman From kent@bbn.com Thu Apr 5 12:13:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BEC21F85CD for ; Thu, 5 Apr 2012 12:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TykzaSaX3RGA for ; Thu, 5 Apr 2012 12:13:05 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id F354521F85E5 for ; Thu, 5 Apr 2012 12:13:04 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49263) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SFs6y-000HQi-58; Thu, 05 Apr 2012 15:12:48 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org> <87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> Date: Thu, 5 Apr 2012 15:13:01 -0400 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 19:13:05 -0000 At 2:54 PM -0400 4/5/12, Stephen Kent wrote: >Paul, It occurs to me that we might be able to make this even more concise and tighten the scope. The current text says that these certs don contain a basic constraints extension with the CA flag set to true. Do they contain a basic constraints extension at all? Steve From david.cooper@nist.gov Thu Apr 5 12:15:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F2E21F85CD for ; Thu, 5 Apr 2012 12:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.224 X-Spam-Level: X-Spam-Status: No, score=-5.224 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHPk3rgqC0I0 for ; Thu, 5 Apr 2012 12:15:55 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id D0BBA21F85C9 for ; Thu, 5 Apr 2012 12:15:54 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q35JFhvN013892; Thu, 5 Apr 2012 15:15:45 -0400 Message-ID: <4F7DEF5E.4040605@nist.gov> Date: Thu, 05 Apr 2012 15:15:42 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: Paul Hoffman References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org> <87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> In-Reply-To: <87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "pkix@ietf.org" Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 19:15:55 -0000 On 04/05/2012 02:27 PM, Paul Hoffman wrote: 
Current proposed wording:

Certificates signed with a private key whose public key is the same as the key in the subjectPublicKeyInfo, but that do not include a BasicConstraints extension that asserts the cA boolean, are commonly used to convey public keys when the signing part does not have an expectation that the contents of such certificates can be validated. These certificates are sometimes used for transmitting a trust anchor or a end entity's public key that is not vouched for. The use of such certificates are outside the scope of both X.509 and this specification. Note that these certificates cannot formally be called "self-signed PKIX certificates" or "self-issued PKIX certificates" because they do not follow the definition in the preceding paragraph.

Paul,

I don't think adding "PKIX" in front of "self-signed" and "self-issued" will help to clarify things given the definition in X.509:

3.4.60 self-issued certificate: A public-key certificate where the issuer and the subject are the same CA. A CA might use self-issued certificates, for example, during a key rollover operation to provide trust from the old key to the new key.

3.4.61 self-signed certificate: A special case of self-issued certificates where the private key used by the CA to sign the certificate corresponds to the public key that is certified within the certificate. A CA might use a self-signed certificate, for example, to advertise their public key or other information about their operations.

NOTE – Use of self-issued certificates and self-signed certificates issued by other than CAs are outside the scope of this Recommendation | International Standard.

While the definition and the note seem contradictory, since the definition implies that self-issued and self-signed certificates are always issued by CAs, and the note implies otherwise, my guess is that the reason is that the definitions define the terms as they are used in X.509, whereas the note is mentioning a use of such certificates that is outside the scope of the standard.

I think trying to avoid the use of the term "self-signed" when referring to a certificate in which the public key that appears in the subjectPublicKeyInfo field of the certificate can be used to verify the signature on the certificate will just lead to confusion.  Besides, this entire effort is based on Sean Turner's statement that "this draft needs to also address the issue of self-signed EE certificates."  Why avoid the use of the term "self-signed" in addressing the issue of self-signed EE certificates?

Also, the proposed text seems to say that all (what I'll call) self-signed certificates "that do not include a BasicConstraints extension that asserts the cA boolean" cannot formally be called "self-signed PKIX certificates" and "are outside the scope of both X.509 and this specification."  However, it also says that "[t]hese certificates are sometimes used for transmitting a trust anchor...."  Isn't the new paragraph supposed to discuss self-signed certificates that are not intended to be used as a source of trust anchor information, regardless their contents (e.g., BasicConstraints), rather than self-signed certificates that "that do not include a BasicConstraints extension that asserts the cA boolean," regardless of their intended use?

How about a very short paragraph, like this:
In some cases, a self-signed certificate is used to convey a public key that is not intended to be used to begin certification paths.  Such certificates are commonly referred to as self-signed end-entity certificates.  The use of self-signed end-entity certificates is outside the scope of this specification.

Dave
From david.cooper@nist.gov Thu Apr 5 12:34:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B4921F86B7 for ; Thu, 5 Apr 2012 12:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.183 X-Spam-Level: X-Spam-Status: No, score=-5.183 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJcvs1YDzrSt for ; Thu, 5 Apr 2012 12:34:50 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 82C0721F86A4 for ; Thu, 5 Apr 2012 12:34:50 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q35JYdM7002479 for ; Thu, 5 Apr 2012 15:34:39 -0400 Message-ID: <4F7DF3CF.10905@nist.gov> Date: Thu, 05 Apr 2012 15:34:39 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: "pkix@ietf.org" References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org> <87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 19:34:51 -0000 On 04/05/2012 02:54 PM, Stephen Kent wrote:
Re: [pkix] 5280 clarifications
Paul,

Thanskfor the clarifications of intent, and the challenge to re-word the text to yield shorter sentences.

How about:

It is common practice to use the X.509/PKIX certificate format to transmit a trust anchor or the public key of an end-entity. These certificates are delivered via channels that are deemed  secure by the RPs that accept them.

Does "these certificates" mean all certificates used to transmit a trust anchor and all end-entity certificates?

Typically such certificates do not include a BasicConstraints extension that asserts the cA Boolean, i.e., they are not marked as CA certificates.

Doesn't this say that certificates used to transmit a trust anchor typically "are not marked as CA certificates"?

A certificate of this sort is validated using the public key from the subjectPublicKeyInfo field, i.e., no CA has signed the certificate.

Is the "no CA has signed this certificate" statement true of certificates used to transmit a trust anchor?  Also, where is there text in the preceding sentences that constrains "a certificate of this sort" to being being certificates "where the digital signature may be verified by the public key bound into the certificate" (i.e., self-signed certificates)?

These certificates cannot formally be called "self-signed certificates" or "self-issued certificates" because they do not follow the definition in the preceding paragraph.

Even if it is used to transmit a trust anchor?  Also, I don't think there is anything to be gained by trying to insist that certificates "where the digital signature may be verified by the public key bound into the certificate" cannot be called self-signed unless the issuer is a CA.  X.509 specifically mentions "self-issued certificates and self-signed certificates issued by other than CAs" (stating that they are out of scope), and I don't think others will stop calling them self-signed certificates just because this document says that can't formally be called that.

The use of such certificates is outside the scope of both X.509 and this specification, with regard to certificate path processing.

Why the phrase "with regard to certificate path processing"?  Are they within the scope of this specification with regard to something else?

From DPKemp@missi.ncsc.mil Thu Apr 5 12:47:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6565121F8674 for ; Thu, 5 Apr 2012 12:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUn5UyX+QuLa for ; Thu, 5 Apr 2012 12:47:42 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id C86F321F865D for ; Thu, 5 Apr 2012 12:47:42 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q35Jlg4Y001556 for ; Thu, 5 Apr 2012 15:47:42 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 15:47:42 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Apr 2012 15:46:43 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] 5280 clarifications Thread-Index: Ac0TXYnMURzY2JxMTmi1eeZfYtuGTAABOgVA References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org><87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> From: "Kemp, David P." To: X-OriginalArrivalTime: 05 Apr 2012 19:47:42.0045 (UTC) FILETIME=[F6B6E0D0:01CD1364] Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 19:47:43 -0000 I agree with David Cooper's objection that refusing to call such certificates "self-signed" increases confusion, not clarity. If they cannot formally be called self-signed because they do not follow the definition in the preceding paragraph(s), that is evidence that the paragraphs should be generalized. This would shorten the new text by eliminating the explanation of the conflict, because there would be no conflict requiring explanation. The first instance of each "CA" in these paragraphs can be replaced by "entity" or deleted without adversely affecting the intent of 5280. The second instance in each paragraph can remain as is, because those sentences specifically refer to CA operations: 3.4.60 self-issued certificate: A public-key certificate where the issuer and the subject are the same entity. A CA might use self-issued certificates, for example, during a key rollover operation to provide trust from the old key to the new key. =09 3.4.61 self-signed certificate: A special case of self-issued certificates where the private key used to sign the certificate corresponds to the public key that is [certified<--contained] within the certificate. A CA might use a self-signed certificate, for example, to advertise their public key or other information about their operations. Dave K -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Thursday, April 05, 2012 2:54 PM To: Paul Hoffman Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications Paul, Thanskfor the clarifications of intent, and the challenge to re-word the text to yield shorter sentences. How about: It is common practice to use the X.509/PKIX certificate format to transmit a trust anchor or the public key of an end-entity. These certificates are delivered via channels that are deemed secure by the RPs that accept them. Typically such certificates do not include a BasicConstraints extension that asserts the cA Boolean, i.e., they are not marked as CA certificates. A certificate of this sort is validated using the public key from the subjectPublicKeyInfo field, i.e., no CA has signed the certificate. These certificates cannot formally be called "self-signed certificates" or "self-issued certificates" because they do not follow the definition in the preceding paragraph. The use of such certificates is outside the scope of both X.509 and this specification, with regard to certificate path processing. From paul.hoffman@vpnc.org Thu Apr 5 12:50:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D110321F8698 for ; Thu, 5 Apr 2012 12:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Golzky9wuNvP for ; Thu, 5 Apr 2012 12:50:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 66F4521F868C for ; Thu, 5 Apr 2012 12:50:15 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q35Jo7S6002902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2012 12:50:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 5 Apr 2012 12:50:07 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4E054080-1443-42C9-9A24-38D27D501890@vpnc.org> References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org> <87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> To: Stephen Kent X-Mailer: Apple Mail (2.1257) Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 19:50:15 -0000 On Apr 5, 2012, at 12:13 PM, Stephen Kent wrote: > At 2:54 PM -0400 4/5/12, Stephen Kent wrote: >> Paul, > > > It occurs to me that we might be able to make this even more concise > and tighten the scope. The current text says that these certs don > contain a basic constraints extension with the CA flag set to true. > Do they contain a basic constraints extension at all? Good call: no. --Paul Hoffman From david.cooper@nist.gov Thu Apr 5 12:56:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D8021F86C6 for ; Thu, 5 Apr 2012 12:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7do2d8ltEY7z for ; Thu, 5 Apr 2012 12:56:13 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id C3D0521F86C2 for ; Thu, 5 Apr 2012 12:56:12 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q35Ju2WZ016699; Thu, 5 Apr 2012 15:56:03 -0400 Message-ID: <4F7DF8D2.5070109@nist.gov> Date: Thu, 05 Apr 2012 15:56:02 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: "Kemp, David P." References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org><87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "pkix@ietf.org" Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 19:56:13 -0000 David, The text that you are proposing to edit is from the definitions section of X.509. The text in RFC 5280 is: This specification covers two classes of certificates: CA certificates and end entity certificates. CA certificates may be further divided into three classes: cross-certificates, self-issued certificates, and self-signed certificates. Cross-certificates are CA certificates in which the issuer and subject are different entities. Cross-certificates describe a trust relationship between the two CAs. Self-issued certificates are CA certificates in which the issuer and subject are the same entity. Self-issued certificates are generated to support changes in policy or operations. Self- signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate. Self-signed certificates are used to convey a public key for use to begin certification paths. End entity certificates are issued to subjects that are not authorized to issue certificates. On 04/05/2012 03:46 PM, Kemp, David P. wrote: > The first instance of each "CA" in these paragraphs can be replaced by > "entity" or deleted without adversely affecting the intent of 5280. The > second instance in each paragraph can remain as is, because those > sentences specifically refer to CA operations: > > 3.4.60 self-issued certificate: A public-key certificate where > the issuer and the subject are the same entity. A CA might use > self-issued certificates, for example, during a key rollover operation > to provide trust from the old key to the new key. > > 3.4.61 self-signed certificate: A special case of self-issued > certificates where the private key used to sign the certificate > corresponds to the public key that is [certified<--contained] within the > certificate. A CA might use a self-signed certificate, for example, to > advertise their public key or other information about their operations. > > Dave K > > From paul.hoffman@vpnc.org Thu Apr 5 12:57:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF3921F85A1 for ; Thu, 5 Apr 2012 12:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59dJIgqzg1Wx for ; Thu, 5 Apr 2012 12:57:03 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4C021F859F for ; Thu, 5 Apr 2012 12:57:03 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q35Jv2jp003123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2012 12:57:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 5 Apr 2012 12:57:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <987765D8-D527-4FB9-B19F-1800CCA7242D@vpnc.org> References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org><87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> To: "Kemp, David P." X-Mailer: Apple Mail (2.1257) Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 19:57:03 -0000 On Apr 5, 2012, at 12:46 PM, Kemp, David P. wrote: > I agree with David Cooper's objection that refusing to call such > certificates "self-signed" increases confusion, not clarity. If they > cannot formally be called self-signed because they do not follow the > definition in the preceding paragraph(s), that is evidence that the > paragraphs should be generalized. This would shorten the new text by > eliminating the explanation of the conflict, because there would be no > conflict requiring explanation. Fully disagree. While it is clear to me that both X.509 and PKIX totally = muffed the definition of "self-signed" by also requiring the cA bit, we = have to life with that (and similar muffage). This thread started off with Steve "Dr. Pedantic" Kent bringing up the = issue of the self-signed definition in the DANE WG. It came as a shock = to some of us who had worked with PKIX for over a decade that the = definition of self-signed disagreed with the common notion, but he was = indeed correct based on multiple revs of this RFC. Now saying "we now = create two definitions for 'self-signed'" seems to be more likely to = create, not reduce, confusion. --Paul Hoffman From mrex@sap.com Thu Apr 5 13:40:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A97921F863E for ; Thu, 5 Apr 2012 13:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.11 X-Spam-Level: X-Spam-Status: No, score=-10.11 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbHtk+W3MVJ1 for ; Thu, 5 Apr 2012 13:40:55 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 431E821F863C for ; Thu, 5 Apr 2012 13:40:55 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q35KedIg018552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Apr 2012 22:40:40 +0200 (MEST) From: Martin Rex Message-Id: <201204052040.q35Ked7i007422@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Thu, 5 Apr 2012 22:40:39 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Apr 5, 12 01:56:46 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 20:40:56 -0000 Stephen Kent wrote: > > At 8:47 PM -0400 4/4/12, Santosh Chokhani wrote: > >This is quite silly conversation. RP should NOT reject certificate > >because the criticality flag was not per the standard. > > I think the technically correct statement replaces "should not" with > "need not." The behaviour standardized by rfc5280 is equivalent to SHOULD NOT: rfc5280 section 6.1 Basic Path Validation, 2nd paragaph: http://tools.ietf.org/html/rfc5280#section-6.1 While the certificate and CRL profiles specified in Sections 4 and 5 of this document specify values for certificate and CRL fields and extensions that are considered to be appropriate for the Internet PKI, the algorithm presented in this section is not limited to accepting certificates and CRLs that conform to these profiles. Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. -Martin From kent@bbn.com Thu Apr 5 13:41:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E9821F8649 for ; Thu, 5 Apr 2012 13:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD5AVG6TPqCp for ; Thu, 5 Apr 2012 13:41:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED5921F8646 for ; Thu, 5 Apr 2012 13:41:08 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49268) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SFtUB-000Jnq-BH; Thu, 05 Apr 2012 16:40:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org> <87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> Date: Thu, 5 Apr 2012 15:33:33 -0400 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 20:41:09 -0000 At 12:11 PM -0700 4/5/12, Paul Hoffman wrote: >On Apr 5, 2012, at 11:54 AM, Stephen Kent wrote: > >> Paul, >> >> Thanskfor the clarifications of intent, and the challenge to >>re-word the text to yield shorter sentences. >> >> How about: >> >> It is common practice to use the X.509/PKIX certificate format to >>transmit a trust anchor or the public key of an end-entity. These >>certificates are delivered via channels that are deemed secure by >>the RPs that accept them. Typically such certificates do not >>include a BasicConstraints extension that asserts the cA Boolean, >>i.e., they are not marked as CA certificates. A certificate of >>this sort is validated using the public key from the >>subjectPublicKeyInfo field, i.e., no CA has signed the certificate. >>These certificates cannot formally be called "self-signed >>certificates" or "self-issued certificates" because they do not >>follow the definition in the preceding paragraph. The use of such >>certificates is outside the scope of both X.509 and this >>specification, with regard to certificate path processing. > >Excellent, and certainly much better than mine. > >--Paul Hoffman It was a team effort! Steve From david.cooper@nist.gov Thu Apr 5 14:29:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E079421F86B6 for ; Thu, 5 Apr 2012 14:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrQPJuH02jq9 for ; Thu, 5 Apr 2012 14:29:13 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id B8E4D21F86BE for ; Thu, 5 Apr 2012 14:29:13 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q35LT390023347; Thu, 5 Apr 2012 17:29:04 -0400 Message-ID: <4F7E0E9F.7010806@nist.gov> Date: Thu, 05 Apr 2012 17:29:03 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: Paul Hoffman References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org><87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> <987765D8-D527-4FB9-B19F-1800CCA7242D@vpnc.org> In-Reply-To: <987765D8-D527-4FB9-B19F-1800CCA7242D@vpnc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "pkix@ietf.org" Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 21:29:17 -0000 Paul, X.509 says: NOTE – Use of self-issued certificates and self-signed certificates issued by other than CAs are outside the scope of this Recommendation | International Standard. So, I don't see how you can use X.509 as a basis for arguing that the term "self-signed" cannot be used. As for PKIX, if the final paragraph of Section 3.2 of RFC 5280 implies that only a CA can issue a "self-signed certificate" and yet the update to 5280 is going to discuss certificates that are not issued by CAs "where the digital signature may be verified by the public key bound into the certificate" then let's reword the current text rather than trying to insist that some certificates "where the digital signature may be verified by the public key bound into the certificate" are not "self-signed." Dave On 04/05/2012 03:57 PM, Paul Hoffman wrote: > On Apr 5, 2012, at 12:46 PM, Kemp, David P. wrote: > >> I agree with David Cooper's objection that refusing to call such >> certificates "self-signed" increases confusion, not clarity. If they >> cannot formally be called self-signed because they do not follow the >> definition in the preceding paragraph(s), that is evidence that the >> paragraphs should be generalized. This would shorten the new text by >> eliminating the explanation of the conflict, because there would be no >> conflict requiring explanation. > Fully disagree. While it is clear to me that both X.509 and PKIX totally muffed the definition of "self-signed" by also requiring the cA bit, we have to life with that (and similar muffage). > > This thread started off with Steve "Dr. Pedantic" Kent bringing up the issue of the self-signed definition in the DANE WG. It came as a shock to some of us who had worked with PKIX for over a decade that the definition of self-signed disagreed with the common notion, but he was indeed correct based on multiple revs of this RFC. Now saying "we now create two definitions for 'self-signed'" seems to be more likely to create, not reduce, confusion. > > --Paul Hoffman > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From mrex@sap.com Thu Apr 5 14:39:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C2C21F85F4 for ; Thu, 5 Apr 2012 14:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.12 X-Spam-Level: X-Spam-Status: No, score=-10.12 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrbjAh0FNos0 for ; Thu, 5 Apr 2012 14:39:09 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2EF21F85EF for ; Thu, 5 Apr 2012 14:39:09 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q35Ld361022910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Apr 2012 23:39:03 +0200 (MEST) From: Martin Rex Message-Id: <201204052139.q35Ld3QW010708@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Thu, 5 Apr 2012 23:39:03 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Apr 5, 12 03:13:01 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 21:39:10 -0000 Stephen Kent wrote: > > It occurs to me that we might be able to make this even more concise > and tighten the scope. The current text says that these certs don > contain a basic constraints extension with the CA flag set to true. > Do they contain a basic constraints extension at all? Unfortunately, this differs from the "existing practise" in the installed base, where the majority of self-signed TLS server certs in use carries the "Basic Constraints:cA=TRUE" attribute. This is probably due to the popularity of Apache+OpenSSL. IIRC only the self-signed proto-certs created by Sun JDK-1.5+ carry a Basic Constraints:cA=FALSE attribute. Data pulled from the August 2010 EFF SSL Observatory dataset about publicly accessible TLS serves on the Internet: https://www.ietf.org/mail-archive/web/dane/current/msg02348.html Peter additionally mailed this (but it was not copied to the list): = = s/acerts/all_certs (I have a copy of the db with the older acerts name = that I was querying, and forgot to edit the query to not confuse people). = = select count(*) from all_certs = where subject=issuer = and LOCATE("TRUE",`X509v3 extensions:X509v3 Basic Constraints:CA`); = +----------+ = | count(*) | = +----------+ = | 830796 | = +----------+ = = This is just the number of self-signed CA certs; there are more servers than = that because certs are duplicated. -Martin From paul.hoffman@vpnc.org Thu Apr 5 14:52:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F40821F863C for ; Thu, 5 Apr 2012 14:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH1bfSJeff+y for ; Thu, 5 Apr 2012 14:52:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3AD21F8638 for ; Thu, 5 Apr 2012 14:52:47 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q35Lqi80006452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2012 14:52:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman In-Reply-To: <4F7E0E9F.7010806@nist.gov> Date: Thu, 5 Apr 2012 14:52:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1B2A981C-A07D-4975-AD0A-C31B1F24DD4D@vpnc.org> References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org><87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> <987765D8-D527-4FB9-B19F-1800CCA7242D@vpnc.org> <4F7E0E9F.7010806@nist.gov> To: "David A. Cooper" X-Mailer: Apple Mail (2.1257) Cc: "pkix@ietf.org" Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 21:52:48 -0000 On Apr 5, 2012, at 2:29 PM, David A. Cooper wrote: > X.509 says: >=20 > NOTE =96 Use of self-issued certificates and self-signed > certificates issued by other than CAs are outside the > scope of this Recommendation | International Standard. >=20 > So, I don't see how you can use X.509 as a basis for arguing that the = term "self-signed" cannot be used. I'm completely confused by that. The quoted text says "self-signed = certificates issues by other than CAs". That's exactly what we are = talking about. > As for PKIX, if the final paragraph of Section 3.2 of RFC 5280 implies = that only a CA can issue a "self-signed certificate" and yet the update = to 5280 is going to discuss certificates that are not issued by CAs = "where the digital signature may be verified by the public key bound = into the certificate" then let's reword the current text rather than = trying to insist that some certificates "where the digital signature may = be verified by the public key bound into the certificate" are not = "self-signed." I hear that's what you want; I still think it is a bad idea to make PKIX = more confusing than it is now. --Paul Hoffman From hallam@gmail.com Thu Apr 5 16:31:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DDA21F856D for ; Thu, 5 Apr 2012 16:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqZ65r-ZqbSp for ; Thu, 5 Apr 2012 16:31:24 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1DB121F8576 for ; Thu, 5 Apr 2012 16:31:23 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2787970obb.31 for ; Thu, 05 Apr 2012 16:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pDb6jiYAVoDWt1DnUYLwcehfx/KirN+XhjviEeJjrnM=; b=c9AGYJyOj/y40jeoZ2Z2hTxKbXz50Kei+z+GnJsmfzO8xNwVoDoq+yDeRwoXQaht5f Ac1njf9LecV+RCcl14KttpIHeAJI9+zILgNr+4mjID3fnGXSp6iu7GsQz0SFPe/S7J9k hX4Vy5md5Azsz94Xa9t/S+3vxvTpVu4T6f/y2fMYMIvfJTXRBQAAEXghphSrAo1KnzOf wuhUC8otTBJ4iOP1KSJig0XuMvQz4fbFTFgc5A5QgPBS6vedue8gODkp6KymslJ8tiKn yr4imLPd0CGxoKip0KyNVfnt/miAfXUyqKbAWB+ntc/aaOHMvLYzJ9P+ncI2wN8btqCh 2WtA== MIME-Version: 1.0 Received: by 10.182.48.66 with SMTP id j2mr6444411obn.72.1333668683531; Thu, 05 Apr 2012 16:31:23 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Thu, 5 Apr 2012 16:31:23 -0700 (PDT) In-Reply-To: References: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> Date: Thu, 5 Apr 2012 19:31:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 23:31:24 -0000 Santosh, This is the second time that you have tried to pull rank on other members of the working group in the past month. I should point out that in my view you are really not qualified to pull rank as you appear to believe you are entitled. If you cannot treat others here with respect I suggest that the chairs inform you that your contributions are no longer desirable. The security issue here is that we cannot issue a certificate that does not work with the deployed Apple clients. Thus the only way it is possible to use the name constraints is to make them non-critical. Therefore this is what we are going to be doing. The proposal is to fix an obvious bug in the specification to meet a real world operational requirement. On Mon, Apr 2, 2012 at 1:17 PM, Santosh Chokhani w= rote: > Martin, > > You miss the security implication of this. > > CA can always make it NC and the clients that do not process name constra= ints will be exposed if the Sub CA is rogue, compromised or RAs it trusts g= o rouge or are compromised. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of M= artin Rex > Sent: Monday, April 02, 2012 1:14 PM > To: Erwann Abalea > Cc: pkix@ietf.org; paul.hoffman@vpnc.org > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > > Erwann Abalea wrote: >> >> > To me, that looks like a >> > perfectly valid request, and PKIX (rfc5280) is in violation of >> > rfc2119 of requiring this extension to be always made critical by >> > the CA (instead of leaving that decision to the CA to express its >> > intention). >> > >> >> How could PKIX be in violation of anything by requiring the extension >> to be critical, and why the RFC2119? Is PKIX also in violation of >> RFC2119 when requiring the serial number to be a positive integer not >> longer than 20 octets? > > http://tools.ietf.org/html/rfc2119#section-6 > > =A0 6. Guidance in the use of these Imperatives > > =A0 Imperatives of the type defined in this memo must be used with care > =A0 and sparingly. =A0In particular, they MUST only be used where it is > =A0 actually required for interoperation or to limit behavior which has > =A0 potential for causing harm (e.g., limiting retransmisssions) =A0For > =A0 example, they must not be used to try to impose a particular method > =A0 on implementors where the method is not required for > =A0 interoperability. > > > Requiring a CA to always make name constraints critical will very probabl= y impair/break interop with implementations that do not support that partic= ular type of name constraints. > > Since the CA is the entity which defines the policy of whether RPs enforc= ing this name constraints is a problem or not, the MUST can > *NOT* be justified with security. =A0There for the "MUST always be critic= al" > in rfc5280 is a clear violation of rfc2119 and therefore NULL and VOID. > That is pretty simple math. > > The only reason that this is there is a desire for some organizations to = procure specific features in COTS, rather than having to pay extra for it. = =A0Deserves to be ignored by the marketplace. > > > > The discussion of the purpose of both critical and non-critical uses of a= constraints extension is much more reasonably explained here: > > =A0http://tools.ietf.org/html/rfc3647#section-3.3.1 > > and the very same reasoning can be applied to name constraints. > It must be up to the CA that puts name constraints into a subCA cert to d= etermine whether these should be critical or not. =A0It is invalid for rfc5= 280 to unconditionally require name constraints to be marked critical by CA= s. > > > -Martin > _______________________________________________ > 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 --=20 Website: http://hallambaker.com/ From hallam@gmail.com Thu Apr 5 16:36:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214A321F85AE for ; Thu, 5 Apr 2012 16:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-tgSSvqA1sA for ; Thu, 5 Apr 2012 16:36:48 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A61621F85A7 for ; Thu, 5 Apr 2012 16:36:48 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2793353obb.31 for ; Thu, 05 Apr 2012 16:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ymITFTxkVaRNtJtpLmXRpFKpmYZgBjr4A6pGOJ97GU0=; b=aLTYgItbbKsF0hM0QkZYg9k6AlmWXkSiIGBdmIgAFcckDJ1I3m0JTD9jUDP/7POT6n ch4A0DwRcH6dDZ5VMYfQA/j1M2ok3A5zREfMROERnuLxtA14O3bs8WBZcHAS1ru8TLLD wlL6xirpGve3XRQRtNtPBNErR8jDFQc7zOfsMljm3P3+/bvICyf5FNQEskf4K41k5ncS ktUYKYBH/p0gcTNmm99Wp6wW9k0tDQMLbL9v+9vQke47Rm5lPvu7j6P09jREcH12mZr+ MsPBS7bNcn1Hke/T87Zkt9eUOO4yVfxBWJv2U93Lz2bFqheswhhV8bZ01ksJYBk+vVDN WSEg== MIME-Version: 1.0 Received: by 10.182.169.4 with SMTP id aa4mr6504476obc.62.1333669008032; Thu, 05 Apr 2012 16:36:48 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Thu, 5 Apr 2012 16:36:47 -0700 (PDT) In-Reply-To: <201204022021.q32KL7m3003456@fs4113.wdf.sap.corp> References: <201204022021.q32KL7m3003456@fs4113.wdf.sap.corp> Date: Thu, 5 Apr 2012 19:36:47 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org, Paul Hoffman Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 23:36:49 -0000 More importantly, nobody made the IESG nor the PKIX working group the authority for the industry. The WG only advised by consent and that consent has now been withdrawn. This particular argument has proved to be the last straw for many. On Mon, Apr 2, 2012 at 4:21 PM, Martin Rex wrote: > Paul Hoffman wrote: >> >> On Apr 2, 2012, at 11:51 AM, Martin Rex wrote: >> >> > rfc2119 is something like our "constitution" for standards. >> >> No, it is not. No one has pretended that until now. It is a set of >> definitions that is widely used, and is also nearly as widely abused, >> in RFCs. Note the difference? > > Most RFC (and that includes 5280) contain this disclaimer: > > =A0 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > =A0 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > =A0 document are to be interpreted as described in [RFC2119]. > > rfc2119 section 6 defines which are valid used of these imperatives, > and which are invalid uses. =A0When talking about conformance, > invalid uses of imperatives are simply defects of the spec and > irrelevant. =A0YMMV. > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From hallam@gmail.com Thu Apr 5 17:00:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91A221F8712 for ; Thu, 5 Apr 2012 17:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4hvd0jvytIE for ; Thu, 5 Apr 2012 17:00:51 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3713D21F8709 for ; Thu, 5 Apr 2012 17:00:51 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2818593obb.31 for ; Thu, 05 Apr 2012 17:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UfHxMaZUcPa6w+MLYOBodz5yORzTSkzrwXl354yy7MY=; b=lLpsXImvstj+HeAQb5LSFh6D22rlYYsuNZkAL5j5pICfKzYCJxzCEVwDwPUNmcr5va IZrUOXY3eSm3QfI82YZTTJ2gKD0OH07qy7NMTpSNO8Y8fbyDQPaWA4WRy1YR2jtJNHI1 RQdFcw0fLPhjte9FcJa7xn7wndbSZ0ND7il2oZAu7t9PoUnULflqrUrgYT+N//02h5V1 l09zrj1VDD7AqTggffUgayCuYetl8qgDd0aMZnEtOFgc0NCzzq5nvUZ6m67vF01O8erO OH25onWS++vevVfzbeuIZaA2a5neaGBNIxGZc44dBXYDM1VcFf2xkjsBB1bJVKD+2GOE MEkA== MIME-Version: 1.0 Received: by 10.60.36.100 with SMTP id p4mr6653189oej.42.1333670450839; Thu, 05 Apr 2012 17:00:50 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Thu, 5 Apr 2012 17:00:50 -0700 (PDT) In-Reply-To: References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> Date: Thu, 5 Apr 2012 20:00:50 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 00:00:51 -0000 Let us start from the beginning and forget the specification for a moment. The objective here is to reduce risk exposure in the deployed Internet PKI infrastructure by constraining the issue capabilities of enterprise CAs. Any proposal must be fully backwards compatible with deployed code. Given those constraints it is obvious that no extensions intended to support the name constraints can be marked critical. Thus there are three options: 1) Develop a new extension that duplicates the functionality of the existing PKIX extensions but does not require being marked critical. 2) Use the existing extension and modify the PKIX specifications to remove the requirement to mark the extension critical. 3) Use the existing extension and ignore the opinion of the PKIX working group. (1) is not an option so the choice for the WG is between (2) and (3). Now I should point out that if the WG wants to retain any influence in the industry whatsoever it should have a REALLY AMAZINGLY IMPORTANT REASON for forcing the industry to choose option 3. Perhaps what we should do is to shut down PKIX, wait for CABForum to fix the specs and then spin up a new WG some time in the future to write up the new system. But the current arrangement is clearly not working. From mrex@sap.com Thu Apr 5 17:04:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9446A21F86C2 for ; Thu, 5 Apr 2012 17:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.229 X-Spam-Level: X-Spam-Status: No, score=-9.229 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EFyyLBQZzNy for ; Thu, 5 Apr 2012 17:04:31 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B5EBC21F8685 for ; Thu, 5 Apr 2012 17:04:30 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3604Cn0000068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Apr 2012 02:04:17 +0200 (MEST) From: Martin Rex Message-Id: <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Fri, 6 Apr 2012 02:04:11 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Apr 5, 12 01:54:50 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 00:04:31 -0000 Stephen Kent wrote: > > > > >Correct, name constraints as "envisioned" by rfc5280 are unusable, > >in case that you find yourself unable to ignore that invalid MUST. > > nonsense. name constraints can be used in any PKI where there there > are clear lines of authority for issuing certs relative to a name > space. The fact that the public TTP trust model, at the top, does > not meet that criterion, is merely an indication of a collision > between a business model and technology. To me it appears that name constraints might be underspecified. >From how I understand the design of X.509, subject Name and subjectAltNames are alternative unique representations of the name of the subject. So in order to use name constraints securely, all name forms present in a cert would have to be subject to constraints, and all unconstrained name forms would have to be unconditionally ignored, otherwise the constraints could be evaded. looking at this example structure (using "aaaa" instead of "com" to avoid collisions with mapped DNS space) well-known trust anchor | | CN=premium subCA, O=pubTC, C=Y public subCA / \ / \ / \ CN=org-CA, OU=Foo, O=pubTC, C=Y CN=org-CA, OU=Bar, O=pubTC, C=Y organizational subCA FOO organizational subCA BAR with name constraint on with name constraint on dNSName SAN "foo.aaaa" dnsName SAN "bar.aaaa" What is lacking in this example is name constraints on the subject name (DirectoryName). Without it, certain certificate processing, based on an unconstrained name forms, can evade the name constraints. e.g. what about the Bar org-CA issuing a CRL-signer cert (non-CA cert) with a subject DName of the Foo org-CA and using it to fabricate CRLs (with an AIA extension in the CRL, distinguishing the "forged" CRL signer cert from the real Foo org-CA cert by including and AuthKeyID and AIA CRL extensions (plus the IssuingDP CRL extension that RPs expect) ? Such a concoction would fulfil the "CRL Signer cert must validate under the same trust anchor" requirement. And PKIX software that is bold enough to perform forward path discovery based on AIA for the CRL signer might be tricked to accept CRLs forged by org-CA Bar during validation of certs issued by org-CA Foo, I assume. Another problem arises from the fact that there may exist SANs (such as KRB5PrincipalName http://tools.ietf.org/html/rfc4556#page-16) or the MS-UPN SAN for which name constraints have either not been defined or not been published, so that support for name constraints for such names is fairly unlikely exist in the installed base, yet the only reason to put alternate subject names into certs is to use them (and exclusively) for authentication. -Martin From SChokhani@cygnacom.com Thu Apr 5 17:48:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA35811E8076 for ; Thu, 5 Apr 2012 17:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq7lHhfwqnqW for ; Thu, 5 Apr 2012 17:48:50 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id C49F511E8072 for ; Thu, 5 Apr 2012 17:48:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,379,1330923600"; d="scan'208";a="711592" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 05 Apr 2012 20:48:36 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 5 Apr 2012 20:48:36 -0400 From: Santosh Chokhani To: Phillip Hallam-Baker Date: Thu, 5 Apr 2012 20:48:33 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0ThDeAhuf9R88fTFSS/qptaqFJ2QACnktw Message-ID: References: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 00:48:50 -0000 PHB, You should do what you deem appropriate. My recommendation is for 5280 and those who get security. BTW, this is not the second time, it is umpteenth time and third time in re= cent memory. I suppose you rather forget about that e-mail about EC DH par= ameters asserted by a cross certified CA. -----Original Message----- From: Phillip Hallam-Baker [mailto:hallam@gmail.com]=20 Sent: Thursday, April 05, 2012 7:31 PM To: Santosh Chokhani Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Santosh, This is the second time that you have tried to pull rank on other members o= f the working group in the past month. I should point out that in my view y= ou are really not qualified to pull rank as you appear to believe you are e= ntitled. If you cannot treat others here with respect I suggest that the chairs info= rm you that your contributions are no longer desirable. The security issue here is that we cannot issue a certificate that does not= work with the deployed Apple clients. Thus the only way it is possible to = use the name constraints is to make them non-critical. Therefore this is what we are going to be doing. The proposal is to fix an obvious bug in the specification to meet a real w= orld operational requirement. On Mon, Apr 2, 2012 at 1:17 PM, Santosh Chokhani w= rote: > Martin, > > You miss the security implication of this. > > CA can always make it NC and the clients that do not process name constra= ints will be exposed if the Sub CA is rogue, compromised or RAs it trusts g= o rouge or are compromised. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf=20 > Of Martin Rex > Sent: Monday, April 02, 2012 1:14 PM > To: Erwann Abalea > Cc: pkix@ietf.org; paul.hoffman@vpnc.org > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of=20 > Name > > Erwann Abalea wrote: >> >> > To me, that looks like a >> > perfectly valid request, and PKIX (rfc5280) is in violation of >> > rfc2119 of requiring this extension to be always made critical by=20 >> > the CA (instead of leaving that decision to the CA to express its=20 >> > intention). >> > >> >> How could PKIX be in violation of anything by requiring the extension=20 >> to be critical, and why the RFC2119? Is PKIX also in violation of >> RFC2119 when requiring the serial number to be a positive integer not=20 >> longer than 20 octets? > > http://tools.ietf.org/html/rfc2119#section-6 > > =A0 6. Guidance in the use of these Imperatives > > =A0 Imperatives of the type defined in this memo must be used with care > =A0 and sparingly. =A0In particular, they MUST only be used where it is > =A0 actually required for interoperation or to limit behavior which has > =A0 potential for causing harm (e.g., limiting retransmisssions) =A0For > =A0 example, they must not be used to try to impose a particular method > =A0 on implementors where the method is not required for > =A0 interoperability. > > > Requiring a CA to always make name constraints critical will very probabl= y impair/break interop with implementations that do not support that partic= ular type of name constraints. > > Since the CA is the entity which defines the policy of whether RPs=20 > enforcing this name constraints is a problem or not, the MUST can > *NOT* be justified with security. =A0There for the "MUST always be critic= al" > in rfc5280 is a clear violation of rfc2119 and therefore NULL and VOID. > That is pretty simple math. > > The only reason that this is there is a desire for some organizations to = procure specific features in COTS, rather than having to pay extra for it. = =A0Deserves to be ignored by the marketplace. > > > > The discussion of the purpose of both critical and non-critical uses of a= constraints extension is much more reasonably explained here: > > =A0http://tools.ietf.org/html/rfc3647#section-3.3.1 > > and the very same reasoning can be applied to name constraints. > It must be up to the CA that puts name constraints into a subCA cert to d= etermine whether these should be critical or not. =A0It is invalid for rfc5= 280 to unconditionally require name constraints to be marked critical by CA= s. > > > -Martin > _______________________________________________ > 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 -- Website: http://hallambaker.com/ From hallam@gmail.com Thu Apr 5 17:50:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1029111E8085 for ; Thu, 5 Apr 2012 17:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzEJVhwb2yhB for ; Thu, 5 Apr 2012 17:50:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8290511E8072 for ; Thu, 5 Apr 2012 17:50:29 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2865410obb.31 for ; Thu, 05 Apr 2012 17:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+4IVUBW+lLx5T3ls2ybanlVcUj93J6NJR5nilaDoyWc=; b=kV7yMAMEq5jafhix4/7JSOQODtNxFYJWfRrASF+0yicJnFwXigab36cPmt1B4T6St3 3q8sZQb+42KMFqdsajLWVZY0/W6+JkyTezuP0Oq0sGehQAxVYnTdYsasMgGtIxqQl7Wf UP/8p4KHdEzhZrSefiUSSoN2zD8Z0PUIX0pWiUEohaU9frmBEZpLsakvJkLuVNqxG30Q oaFKmYJg6TuACywd4g4/r/ujQk9R4Zit2jEkawzvlhSZihInGRghnTGeUW0lXrJQdCeh Elu+6qvdttLWXGfimCzVWWu5r9QsqePwPDH+aXTPLFLaazT7fUY1CluUeY8jLN2wclsY yhcA== MIME-Version: 1.0 Received: by 10.182.74.42 with SMTP id q10mr6844072obv.52.1333673429002; Thu, 05 Apr 2012 17:50:29 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Thu, 5 Apr 2012 17:50:28 -0700 (PDT) In-Reply-To: <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> References: <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> Date: Thu, 5 Apr 2012 20:50:28 -0400 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 00:50:32 -0000 The intention of the critical flag was to provide a mechanism that could be used to implement extensions that required backwards compatibility to be broken. That is all. Marking an extension critical does not mean 'important'. An extension can be marked non critical and be very very important. Nor should applications make any use of the critical flag other than to reject certificates marked critical that they do not understand. If the application understands the extension the setting of the criticality flag MUST NOT affect the semantics of the extension. I do not care what the specification documents say on the matter, really I don't. If the specifications say that criticality means important then they are stupid and wrong and should be fixed. From hallam@gmail.com Thu Apr 5 18:01:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D2121F85AF for ; Thu, 5 Apr 2012 18:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dGl0Z9LmEr0 for ; Thu, 5 Apr 2012 18:01:46 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1603721F859A for ; Thu, 5 Apr 2012 18:01:46 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2875712obb.31 for ; Thu, 05 Apr 2012 18:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=p0qvPLM9kzLsDE2Fbc9blU1+jMIonGUQFuOCqsnAcPw=; b=lU+RXz9uszv0Ekzn1dtgbCIeo9cQ4q2w8+72OxHZmMuGWrAuay6mGoZDmCBRyoj/7S tLwciFJTtU/hfA5E10DiQh7ru9TWnQErU/1pOQI7w1SGmXa0UX2tE0zhi8Cf59Z4wCuQ +mSFX/5DdcWOSsCrrHSqbgneeIKhagN2F3EgMe/aKeZdvBgrKyk/8BEaxuMh/kxC7Pv5 d4DBKSh0Tu7azxFyeLp92Mwfj4crpERiL6FDNvczqPPgq/a0/Wgp/RrJj//7hf4sDNN6 29BuQY6NJkDAuIxjRelwuibQwCWWRUDZH1iCEZasMlSlVJ+MOs213TjrUY6X2jvvHy+p Ej4A== MIME-Version: 1.0 Received: by 10.60.36.100 with SMTP id p4mr6809156oej.42.1333674105703; Thu, 05 Apr 2012 18:01:45 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Thu, 5 Apr 2012 18:01:45 -0700 (PDT) In-Reply-To: References: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> Date: Thu, 5 Apr 2012 21:01:45 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 01:01:47 -0000 Santosh, As I stated in my message to the ADs explaining the reason why we are breaking from the PKIX work, your role has been corrosive here. I do not mind people attacking me, but I see you all behaving like a bunch of high school heathers attacking anyone else you disagree with in the same terms. I don't particularly see that I have a need to justify my credentials to you. In fact I am really not aware of any substantial contribution you have made to the field, positive or negative. I value the opinion of the people I have worked with, a list that includes multiple Turing award winners besides many other notable contributors to the field. I do not value the opinion of people who attempt to preen themselves by putting other down. You are certainly not the only person that gets security here, not by a long way. In fact I would suggest that anyone who argues in the fashion you do, through appeals to their own authority are the people who 'don't get it'. On Thu, Apr 5, 2012 at 8:48 PM, Santosh Chokhani w= rote: > PHB, > > You should do what you deem appropriate. > > My recommendation is for 5280 and those who get security. > > BTW, this is not the second time, it is umpteenth time and third time in = recent memory. =A0I suppose you rather forget about that e-mail about EC DH= parameters asserted by a cross certified CA. > > -----Original Message----- > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > Sent: Thursday, April 05, 2012 7:31 PM > To: Santosh Chokhani > Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > > Santosh, > > This is the second time that you have tried to pull rank on other members= of the working group in the past month. I should point out that in my view= you are really not qualified to pull rank as you appear to believe you are= entitled. > > If you cannot treat others here with respect I suggest that the chairs in= form you that your contributions are no longer desirable. > > > The security issue here is that we cannot issue a certificate that does n= ot work with the deployed Apple clients. Thus the only way it is possible t= o use the name constraints is to make them non-critical. > Therefore this is what we are going to be doing. > > The proposal is to fix an obvious bug in the specification to meet a real= world operational requirement. > > > On Mon, Apr 2, 2012 at 1:17 PM, Santosh Chokhani = wrote: >> Martin, >> >> You miss the security implication of this. >> >> CA can always make it NC and the clients that do not process name constr= aints will be exposed if the Sub CA is rogue, compromised or RAs it trusts = go rouge or are compromised. >> >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf >> Of Martin Rex >> Sent: Monday, April 02, 2012 1:14 PM >> To: Erwann Abalea >> Cc: pkix@ietf.org; paul.hoffman@vpnc.org >> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >> Name >> >> Erwann Abalea wrote: >>> >>> > To me, that looks like a >>> > perfectly valid request, and PKIX (rfc5280) is in violation of >>> > rfc2119 of requiring this extension to be always made critical by >>> > the CA (instead of leaving that decision to the CA to express its >>> > intention). >>> > >>> >>> How could PKIX be in violation of anything by requiring the extension >>> to be critical, and why the RFC2119? Is PKIX also in violation of >>> RFC2119 when requiring the serial number to be a positive integer not >>> longer than 20 octets? >> >> http://tools.ietf.org/html/rfc2119#section-6 >> >> =A0 6. Guidance in the use of these Imperatives >> >> =A0 Imperatives of the type defined in this memo must be used with care >> =A0 and sparingly. =A0In particular, they MUST only be used where it is >> =A0 actually required for interoperation or to limit behavior which has >> =A0 potential for causing harm (e.g., limiting retransmisssions) =A0For >> =A0 example, they must not be used to try to impose a particular method >> =A0 on implementors where the method is not required for >> =A0 interoperability. >> >> >> Requiring a CA to always make name constraints critical will very probab= ly impair/break interop with implementations that do not support that parti= cular type of name constraints. >> >> Since the CA is the entity which defines the policy of whether RPs >> enforcing this name constraints is a problem or not, the MUST can >> *NOT* be justified with security. =A0There for the "MUST always be criti= cal" >> in rfc5280 is a clear violation of rfc2119 and therefore NULL and VOID. >> That is pretty simple math. >> >> The only reason that this is there is a desire for some organizations to= procure specific features in COTS, rather than having to pay extra for it.= =A0Deserves to be ignored by the marketplace. >> >> >> >> The discussion of the purpose of both critical and non-critical uses of = a constraints extension is much more reasonably explained here: >> >> =A0http://tools.ietf.org/html/rfc3647#section-3.3.1 >> >> and the very same reasoning can be applied to name constraints. >> It must be up to the CA that puts name constraints into a subCA cert to = determine whether these should be critical or not. =A0It is invalid for rfc= 5280 to unconditionally require name constraints to be marked critical by C= As. >> >> >> -Martin >> _______________________________________________ >> 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 > > > > -- > Website: http://hallambaker.com/ --=20 Website: http://hallambaker.com/ From tgindin@us.ibm.com Thu Apr 5 18:31:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F76B21F8535 for ; Thu, 5 Apr 2012 18:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-OIbTJx9tmr for ; Thu, 5 Apr 2012 18:31:21 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3BF11E8079 for ; Thu, 5 Apr 2012 18:31:21 -0700 (PDT) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 5 Apr 2012 19:31:20 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 5 Apr 2012 19:31:11 -0600 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 0D0B2C90067 for ; Thu, 5 Apr 2012 21:31:10 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q361VANa3522680 for ; Thu, 5 Apr 2012 21:31:10 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q361VAn5015678 for ; Thu, 5 Apr 2012 21:31:10 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q361VA7i015675; Thu, 5 Apr 2012 21:31:10 -0400 In-Reply-To: <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> References: from "Stephen Kent" at Apr 5, 12 01:54:50 pm <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> To: mrex@sap.com MIME-Version: 1.0 X-KeepSent: 88E286AA:69A23216-852579D8:00047414; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Thu, 5 Apr 2012 21:31:11 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/05/2012 21:31:09, Serialize complete at 04/05/2012 21:31:09 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040601-3270-0000-0000-0000055CA727 Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 01:31:22 -0000 Martin: Actually, the way in which name constraints are most clearly underspecified is their handling of x400Address. Implementers MUST be able to process one of the GeneralName forms, and SHOULD be able to process four more. Three of the remaining four forms are explicitly excluded from this specification, but there's no reference to how x400Address should be processed (if anyone still uses it) although there's a SHOULD NOT for the CA putting in a name constraint of that form. I think that an RP is conformant if it simply rejects any certificate whose subject Alt Name has a member of type x400Address, if either permitted_subtrees or excluded_subtrees have any member of type x400Address during the processing of section 6.1.3 B and C. I have no idea whether it's intended that having permitted_subtrees contain organization-name but not teletex-organization-name means that names with teletex-organization-name (an Extension attribute) should be banned. I suspect that it is, and I wonder how many RP's enforce anything like that. In your examples, you'd have to restrict the name forms to ones covered by permitted subtrees. Otherwise, CA's could put in a single excluded subtree of each name form, covering entities which no longer exist or an IP which can't be routed. Those are constraints, but they protect very little. Tom Gindin P.S. - The opinions above are mine, and not necessarily those of my employer. From: Martin Rex To: kent@bbn.com (Stephen Kent), Cc: pkix@ietf.org Date: 04/05/2012 08:04 PM Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Sent by: pkix-bounces@ietf.org Stephen Kent wrote: > > > > >Correct, name constraints as "envisioned" by rfc5280 are unusable, > >in case that you find yourself unable to ignore that invalid MUST. > > nonsense. name constraints can be used in any PKI where there there > are clear lines of authority for issuing certs relative to a name > space. The fact that the public TTP trust model, at the top, does > not meet that criterion, is merely an indication of a collision > between a business model and technology. To me it appears that name constraints might be underspecified. >From how I understand the design of X.509, subject Name and subjectAltNames are alternative unique representations of the name of the subject. So in order to use name constraints securely, all name forms present in a cert would have to be subject to constraints, and all unconstrained name forms would have to be unconditionally ignored, otherwise the constraints could be evaded. looking at this example structure (using "aaaa" instead of "com" to avoid collisions with mapped DNS space) well-known trust anchor | | CN=premium subCA, O=pubTC, C=Y public subCA / \ / \ / \ CN=org-CA, OU=Foo, O=pubTC, C=Y CN=org-CA, OU=Bar, O=pubTC, C=Y organizational subCA FOO organizational subCA BAR with name constraint on with name constraint on dNSName SAN "foo.aaaa" dnsName SAN "bar.aaaa" What is lacking in this example is name constraints on the subject name (DirectoryName). Without it, certain certificate processing, based on an unconstrained name forms, can evade the name constraints. e.g. what about the Bar org-CA issuing a CRL-signer cert (non-CA cert) with a subject DName of the Foo org-CA and using it to fabricate CRLs (with an AIA extension in the CRL, distinguishing the "forged" CRL signer cert from the real Foo org-CA cert by including and AuthKeyID and AIA CRL extensions (plus the IssuingDP CRL extension that RPs expect) ? Such a concoction would fulfil the "CRL Signer cert must validate under the same trust anchor" requirement. And PKIX software that is bold enough to perform forward path discovery based on AIA for the CRL signer might be tricked to accept CRLs forged by org-CA Bar during validation of certs issued by org-CA Foo, I assume. Another problem arises from the fact that there may exist SANs (such as KRB5PrincipalName http://tools.ietf.org/html/rfc4556#page-16) or the MS-UPN SAN for which name constraints have either not been defined or not been published, so that support for name constraints for such names is fairly unlikely exist in the installed base, yet the only reason to put alternate subject names into certs is to use them (and exclusively) for authentication. -Martin _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From ynir@checkpoint.com Thu Apr 5 22:42:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B80421F8592 for ; Thu, 5 Apr 2012 22:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVV1UWm+0Mlh for ; Thu, 5 Apr 2012 22:42:57 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A0D3021F858E for ; Thu, 5 Apr 2012 22:42:56 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q365gi8T008549; Fri, 6 Apr 2012 08:42:44 +0300 X-CheckPoint: {4F7E8FE3-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 6 Apr 2012 08:42:44 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 6 Apr 2012 08:42:42 +0300 From: Yoav Nir To: Phillip Hallam-Baker Date: Fri, 6 Apr 2012 08:42:43 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0TuBYAQaxnQ07HSWisVvrdTGnIiQ== Message-ID: <1738B455-0911-4CDB-87F3-CBC20203D41F@checkpoint.com> References: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 05:42:57 -0000 Hi Phil On Apr 6, 2012, at 2:31 AM, Phillip Hallam-Baker wrote: > The security issue here is that we cannot issue a certificate that > does not work with the deployed Apple clients. Thus the only way it is > possible to use the name constraints is to make them non-critical. > Therefore this is what we are going to be doing. I understand your position, and I would probably do the same if I were maki= ng decisions for a CA. However, I object to this treating of deployed iOS c= lients as some part of nature that we just have to live with. Apple issues = regular updates to iOS that get pushed to all users. Those clients are not = unfixable. If Apple was willing to fix this, then the RFC 5280 would still = be quirky, but we wouldn't be having this conversation. > The proposal is to fix an obvious bug in the specification to meet a > real world operational requirement. I think the bug is in iOS. There is a large group of people here who believ= e that breaking the BC with non-compliant browsers is intentional and a goo= d thing.=20 I agree that the current specification is a barrier to deployment. Fortunat= ely for you, there is an easy way to work around it in this specification. Yoav= From SChokhani@cygnacom.com Fri Apr 6 04:45:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8407921F8656 for ; Fri, 6 Apr 2012 04:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhvsqCfGXCdf for ; Fri, 6 Apr 2012 04:45:10 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2E45921F8649 for ; Fri, 6 Apr 2012 04:45:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,381,1330923600"; d="scan'208";a="4634270" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 06 Apr 2012 07:45:05 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 6 Apr 2012 07:45:04 -0400 From: Santosh Chokhani To: Phillip Hallam-Baker Date: Fri, 6 Apr 2012 07:45:03 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0TkNdpRFI1KEcBRSGHhheK1M19IQAWcK7A Message-ID: References: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 11:45:11 -0000 PHB, I understand why you are bothered. My advice to you is focus on what is being said and not on who is saying it= . -----Original Message----- From: Phillip Hallam-Baker [mailto:hallam@gmail.com]=20 Sent: Thursday, April 05, 2012 9:02 PM To: Santosh Chokhani Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Santosh, As I stated in my message to the ADs explaining the reason why we are break= ing from the PKIX work, your role has been corrosive here. I do not mind pe= ople attacking me, but I see you all behaving like a bunch of high school h= eathers attacking anyone else you disagree with in the same terms. I don't particularly see that I have a need to justify my credentials to yo= u. In fact I am really not aware of any substantial contribution you have m= ade to the field, positive or negative. I value the opinion of the people I= have worked with, a list that includes multiple Turing award winners besid= es many other notable contributors to the field. I do not value the opinion= of people who attempt to preen themselves by putting other down. You are certainly not the only person that gets security here, not by a lon= g way. In fact I would suggest that anyone who argues in the fashion you do= , through appeals to their own authority are the people who 'don't get it'. On Thu, Apr 5, 2012 at 8:48 PM, Santosh Chokhani w= rote: > PHB, > > You should do what you deem appropriate. > > My recommendation is for 5280 and those who get security. > > BTW, this is not the second time, it is umpteenth time and third time in = recent memory. =A0I suppose you rather forget about that e-mail about EC DH= parameters asserted by a cross certified CA. > > -----Original Message----- > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > Sent: Thursday, April 05, 2012 7:31 PM > To: Santosh Chokhani > Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of=20 > Name > > Santosh, > > This is the second time that you have tried to pull rank on other members= of the working group in the past month. I should point out that in my view= you are really not qualified to pull rank as you appear to believe you are= entitled. > > If you cannot treat others here with respect I suggest that the chairs in= form you that your contributions are no longer desirable. > > > The security issue here is that we cannot issue a certificate that does n= ot work with the deployed Apple clients. Thus the only way it is possible t= o use the name constraints is to make them non-critical. > Therefore this is what we are going to be doing. > > The proposal is to fix an obvious bug in the specification to meet a real= world operational requirement. > > > On Mon, Apr 2, 2012 at 1:17 PM, Santosh Chokhani = wrote: >> Martin, >> >> You miss the security implication of this. >> >> CA can always make it NC and the clients that do not process name constr= aints will be exposed if the Sub CA is rogue, compromised or RAs it trusts = go rouge or are compromised. >> >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf=20 >> Of Martin Rex >> Sent: Monday, April 02, 2012 1:14 PM >> To: Erwann Abalea >> Cc: pkix@ietf.org; paul.hoffman@vpnc.org >> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of=20 >> Name >> >> Erwann Abalea wrote: >>> >>> > To me, that looks like a >>> > perfectly valid request, and PKIX (rfc5280) is in violation of >>> > rfc2119 of requiring this extension to be always made critical by=20 >>> > the CA (instead of leaving that decision to the CA to express its=20 >>> > intention). >>> > >>> >>> How could PKIX be in violation of anything by requiring the=20 >>> extension to be critical, and why the RFC2119? Is PKIX also in=20 >>> violation of >>> RFC2119 when requiring the serial number to be a positive integer=20 >>> not longer than 20 octets? >> >> http://tools.ietf.org/html/rfc2119#section-6 >> >> =A0 6. Guidance in the use of these Imperatives >> >> =A0 Imperatives of the type defined in this memo must be used with care >> =A0 and sparingly. =A0In particular, they MUST only be used where it is >> =A0 actually required for interoperation or to limit behavior which has >> =A0 potential for causing harm (e.g., limiting retransmisssions) =A0For >> =A0 example, they must not be used to try to impose a particular method >> =A0 on implementors where the method is not required for >> =A0 interoperability. >> >> >> Requiring a CA to always make name constraints critical will very probab= ly impair/break interop with implementations that do not support that parti= cular type of name constraints. >> >> Since the CA is the entity which defines the policy of whether RPs=20 >> enforcing this name constraints is a problem or not, the MUST can >> *NOT* be justified with security. =A0There for the "MUST always be criti= cal" >> in rfc5280 is a clear violation of rfc2119 and therefore NULL and VOID. >> That is pretty simple math. >> >> The only reason that this is there is a desire for some organizations to= procure specific features in COTS, rather than having to pay extra for it.= =A0Deserves to be ignored by the marketplace. >> >> >> >> The discussion of the purpose of both critical and non-critical uses of = a constraints extension is much more reasonably explained here: >> >> =A0http://tools.ietf.org/html/rfc3647#section-3.3.1 >> >> and the very same reasoning can be applied to name constraints. >> It must be up to the CA that puts name constraints into a subCA cert to = determine whether these should be critical or not. =A0It is invalid for rfc= 5280 to unconditionally require name constraints to be marked critical by C= As. >> >> >> -Martin >> _______________________________________________ >> 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 > > > > -- > Website: http://hallambaker.com/ -- Website: http://hallambaker.com/ From hallam@gmail.com Fri Apr 6 05:12:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EC521F85DB for ; Fri, 6 Apr 2012 05:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMORqqrF5DKN for ; Fri, 6 Apr 2012 05:12:10 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6B121F85D7 for ; Fri, 6 Apr 2012 05:12:10 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3453711obb.31 for ; Fri, 06 Apr 2012 05:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8uVUWV5oiWkXcAtL4Kp0Vwkia+VoRJ8s3aK3u1r3d8Y=; b=sDDUCh6ZVCX5AZAbPxpc7Sjn5WpV6b9zmPdB3xEXJXCHlySlkvuOn8ST161hSpyMqu JlyDjla+CRHjD5cQAaOGWXb1YqcYntpBNWoPBESoss75a/W8QMqW5bXN0rqicuTUvWVT qH2s23oIuE9ZeE+4E5pI0/q48mh9ogEUo7fThubIdDo2cYtnv9sZWWSfORsBXgosLhmu L1IK253MJhC5TYSFj/yHX8kspYl86fhNhbnR2hGMFLDMAtCPunLPo0gGkNQUlwKllO1C vzdSgZh346g3VxfDJZLCIvREfNOxaxxbJM5yKt+WZoHMHWyaueMKc6qmnFo1NR1WAyd1 ncpg== MIME-Version: 1.0 Received: by 10.60.7.200 with SMTP id l8mr8791802oea.52.1333714329941; Fri, 06 Apr 2012 05:12:09 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Fri, 6 Apr 2012 05:12:09 -0700 (PDT) In-Reply-To: <1738B455-0911-4CDB-87F3-CBC20203D41F@checkpoint.com> References: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> <1738B455-0911-4CDB-87F3-CBC20203D41F@checkpoint.com> Date: Fri, 6 Apr 2012 08:12:09 -0400 Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 12:12:11 -0000 On Fri, Apr 6, 2012 at 1:42 AM, Yoav Nir wrote: > Hi Phil > > On Apr 6, 2012, at 2:31 AM, Phillip Hallam-Baker wrote: > >> The security issue here is that we cannot issue a certificate that >> does not work with the deployed Apple clients. Thus the only way it is >> possible to use the name constraints is to make them non-critical. >> Therefore this is what we are going to be doing. > > I understand your position, and I would probably do the same if I were making decisions for a CA. However, I object to this treating of deployed iOS clients as some part of nature that we just have to live with. Well tough Cnut, that is the problem that has to be solved. PKIX was made for the Internet, not the Internet for PKIX. >Apple issues regular updates to iOS that get pushed to all users. Those clients are not unfixable. If Apple was willing to fix this, then the RFC 5280 would still be quirky, but we wouldn't be having this conversation. Those wont reach all the users. Not acceptable. We can only turn on the constraints if there is 100% backwards compatibility. >> The proposal is to fix an obvious bug in the specification to meet a >> real world operational requirement. > > I think the bug is in iOS. There is a large group of people here who believe that breaking the BC with non-compliant browsers is intentional and a good thing. You are entitled to your opinion. But is is completely nuts. What you are saying is that the opinion of this group matters more than the hundreds of thousands of Internet users that you are proposing to break their clients for no good reason other than to massage the collective ego of this group. That is not a viable approach. > I agree that the current specification is a barrier to deployment. Fortunately for you, there is an easy way to work around it in this specification. Yes, ignore PKIX and the IETF and set up our own standards organization in which the views of the stake holders like the end users actually matter. -- Website: http://hallambaker.com/ From hallam@gmail.com Fri Apr 6 05:37:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5193121F8555 for ; Fri, 6 Apr 2012 05:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbXW8Fpf5b7D for ; Fri, 6 Apr 2012 05:37:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 311E921F8552 for ; Fri, 6 Apr 2012 05:37:21 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id tb4so3478886obb.31 for ; Fri, 06 Apr 2012 05:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Dvq3DeKG3tVgF52ldQSwieeUcUaaN/I/J2sQBbmOhIc=; b=cY16eGHozFea+VIkYW390uuK6YFyFDcdYyLRqY3Q6dN3/sf5n+tBQDZLJ2UsjwMYPo EZ2XMt0IlwoGqxCzTKuTyv512klET/QAo6Hd+xW3jeGuoKRCRCvy20xJ+PQTfvK6XJYu P/ZD3/3ZifyC/kWBRvsf26JoMG37j4hcKpdccQ40K8WOLwPXj7ag8Ab3fJOvzMpssW3L 1Q4bWnZBShiQ6neVAXBUjl5w4XdZhIMp0JKoaNANTA/wNFGAuqj8cF2JfghyX5yYHfAb xbcjdsJqhgULnwVWNVaZ4ipumz7EgIG3k2LcpTqZ3b+tAilcOGXX7vLnjSrrUnJ3qYE3 ioaA== MIME-Version: 1.0 Received: by 10.60.3.99 with SMTP id b3mr8798348oeb.72.1333715841044; Fri, 06 Apr 2012 05:37:21 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Fri, 6 Apr 2012 05:37:20 -0700 (PDT) In-Reply-To: References: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> Date: Fri, 6 Apr 2012 08:37:20 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 12:37:22 -0000 How people were saying was rather more instrumental in the fork than what they were saying. I can't remember the last time I came here with a proposal and someone said 'hey how can we achieve that better'. Instead the response is always 'well thats not the way the spec works, tough noogies for you'. If you understood why I was bothered you would apologize to me and the group for your behavior. Participation in PKIX has shrunk because people just don't like interacting with a group that is considered to be needlessly obstructionist and sinks to personal insults to drive people away. I do not pull rank except when I see others doing so. On Fri, Apr 6, 2012 at 7:45 AM, Santosh Chokhani w= rote: > PHB, > > I understand why you are bothered. > > My advice to you is focus on what is being said and not on who is saying = it. > > -----Original Message----- > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > Sent: Thursday, April 05, 2012 9:02 PM > To: Santosh Chokhani > Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > > Santosh, > > As I stated in my message to the ADs explaining the reason why we are bre= aking from the PKIX work, your role has been corrosive here. I do not mind = people attacking me, but I see you all behaving like a bunch of high school= heathers attacking anyone else you disagree with in the same terms. > > > I don't particularly see that I have a need to justify my credentials to = you. In fact I am really not aware of any substantial contribution you have= made to the field, positive or negative. I value the opinion of the people= I have worked with, a list that includes multiple Turing award winners bes= ides many other notable contributors to the field. I do not value the opini= on of people who attempt to preen themselves by putting other down. > > You are certainly not the only person that gets security here, not by a l= ong way. In fact I would suggest that anyone who argues in the fashion you = do, through appeals to their own authority are the people who 'don't get it= '. > > > > > > On Thu, Apr 5, 2012 at 8:48 PM, Santosh Chokhani = wrote: >> PHB, >> >> You should do what you deem appropriate. >> >> My recommendation is for 5280 and those who get security. >> >> BTW, this is not the second time, it is umpteenth time and third time in= recent memory. =A0I suppose you rather forget about that e-mail about EC D= H parameters asserted by a cross certified CA. >> >> -----Original Message----- >> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >> Sent: Thursday, April 05, 2012 7:31 PM >> To: Santosh Chokhani >> Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org >> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >> Name >> >> Santosh, >> >> This is the second time that you have tried to pull rank on other member= s of the working group in the past month. I should point out that in my vie= w you are really not qualified to pull rank as you appear to believe you ar= e entitled. >> >> If you cannot treat others here with respect I suggest that the chairs i= nform you that your contributions are no longer desirable. >> >> >> The security issue here is that we cannot issue a certificate that does = not work with the deployed Apple clients. Thus the only way it is possible = to use the name constraints is to make them non-critical. >> Therefore this is what we are going to be doing. >> >> The proposal is to fix an obvious bug in the specification to meet a rea= l world operational requirement. >> >> >> On Mon, Apr 2, 2012 at 1:17 PM, Santosh Chokhani wrote: >>> Martin, >>> >>> You miss the security implication of this. >>> >>> CA can always make it NC and the clients that do not process name const= raints will be exposed if the Sub CA is rogue, compromised or RAs it trusts= go rouge or are compromised. >>> >>> -----Original Message----- >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf >>> Of Martin Rex >>> Sent: Monday, April 02, 2012 1:14 PM >>> To: Erwann Abalea >>> Cc: pkix@ietf.org; paul.hoffman@vpnc.org >>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>> Name >>> >>> Erwann Abalea wrote: >>>> >>>> > To me, that looks like a >>>> > perfectly valid request, and PKIX (rfc5280) is in violation of >>>> > rfc2119 of requiring this extension to be always made critical by >>>> > the CA (instead of leaving that decision to the CA to express its >>>> > intention). >>>> > >>>> >>>> How could PKIX be in violation of anything by requiring the >>>> extension to be critical, and why the RFC2119? Is PKIX also in >>>> violation of >>>> RFC2119 when requiring the serial number to be a positive integer >>>> not longer than 20 octets? >>> >>> http://tools.ietf.org/html/rfc2119#section-6 >>> >>> =A0 6. Guidance in the use of these Imperatives >>> >>> =A0 Imperatives of the type defined in this memo must be used with care >>> =A0 and sparingly. =A0In particular, they MUST only be used where it is >>> =A0 actually required for interoperation or to limit behavior which has >>> =A0 potential for causing harm (e.g., limiting retransmisssions) =A0For >>> =A0 example, they must not be used to try to impose a particular method >>> =A0 on implementors where the method is not required for >>> =A0 interoperability. >>> >>> >>> Requiring a CA to always make name constraints critical will very proba= bly impair/break interop with implementations that do not support that part= icular type of name constraints. >>> >>> Since the CA is the entity which defines the policy of whether RPs >>> enforcing this name constraints is a problem or not, the MUST can >>> *NOT* be justified with security. =A0There for the "MUST always be crit= ical" >>> in rfc5280 is a clear violation of rfc2119 and therefore NULL and VOID. >>> That is pretty simple math. >>> >>> The only reason that this is there is a desire for some organizations t= o procure specific features in COTS, rather than having to pay extra for it= . =A0Deserves to be ignored by the marketplace. >>> >>> >>> >>> The discussion of the purpose of both critical and non-critical uses of= a constraints extension is much more reasonably explained here: >>> >>> =A0http://tools.ietf.org/html/rfc3647#section-3.3.1 >>> >>> and the very same reasoning can be applied to name constraints. >>> It must be up to the CA that puts name constraints into a subCA cert to= determine whether these should be critical or not. =A0It is invalid for rf= c5280 to unconditionally require name constraints to be marked critical by = CAs. >>> >>> >>> -Martin >>> _______________________________________________ >>> 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 >> >> >> >> -- >> Website: http://hallambaker.com/ > > > > -- > Website: http://hallambaker.com/ --=20 Website: http://hallambaker.com/ From housley@vigilsec.com Fri Apr 6 05:42:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6529D21F85C6 for ; Fri, 6 Apr 2012 05:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaoceWKV-CUw for ; Fri, 6 Apr 2012 05:42:54 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6B82521F85C5 for ; Fri, 6 Apr 2012 05:42:54 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 5D2B3F24014; Fri, 6 Apr 2012 08:43:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 4nGozYw1qQtF; Fri, 6 Apr 2012 08:42:50 -0400 (EDT) Received: from [192.168.2.101] (pool-96-255-13-167.washdc.fios.verizon.net [96.255.13.167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id A72B5F24013; Fri, 6 Apr 2012 08:43:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Russ Housley In-Reply-To: Date: Fri, 6 Apr 2012 08:42:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3D004357-D337-4AAD-8FF0-2D9F4F36565D@vigilsec.com> References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 12:42:55 -0000 Phillip: All IETF standards are voluntary. While the mission of the IETF is to = make the Internet work better, let me remind you that no one is =93in = charge=94 of the Internet. Rather, many people cooperate to make the = Internet work. Each IETF participant brings a unique perspective of the Internet, and = that diversity is quite visible in this thread. As usual diversity = sometimes makes it difficult to reach consensus. In my experience, = respectful discussion is the best way to understand the perspective of = each participant. When rough consensus is achieved, there will probably be some people = that are not completely happy. The IETF process does not seek unanimous = consensus. Once rough consensus is achieved, in my experience, the = outcome is better, more clearly explained, and more strongly supported = than the initial position of any participant. And, this support is what = leads to wide deployment. Russ On Apr 5, 2012, at 8:00 PM, Phillip Hallam-Baker wrote: > Let us start from the beginning and forget the specification for a = moment. >=20 > The objective here is to reduce risk exposure in the deployed Internet > PKI infrastructure by constraining the issue capabilities of > enterprise CAs. Any proposal must be fully backwards compatible with > deployed code. >=20 > Given those constraints it is obvious that no extensions intended to > support the name constraints can be marked critical. Thus there are > three options: >=20 > 1) Develop a new extension that duplicates the functionality of the > existing PKIX extensions but does not require being marked critical. >=20 > 2) Use the existing extension and modify the PKIX specifications to > remove the requirement to mark the extension critical. >=20 > 3) Use the existing extension and ignore the opinion of the PKIX = working group. >=20 >=20 > (1) is not an option so the choice for the WG is between (2) and (3). >=20 > Now I should point out that if the WG wants to retain any influence in > the industry whatsoever it should have a REALLY AMAZINGLY IMPORTANT > REASON for forcing the industry to choose option 3. >=20 > Perhaps what we should do is to shut down PKIX, wait for CABForum to > fix the specs and then spin up a new WG some time in the future to > write up the new system. But the current arrangement is clearly not > working. From housley@vigilsec.com Fri Apr 6 05:46:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3048E21F853D for ; Fri, 6 Apr 2012 05:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SMhAOB9yRt9 for ; Fri, 6 Apr 2012 05:46:52 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id ACDC421F8535 for ; Fri, 6 Apr 2012 05:46:52 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B5560F24013 for ; Fri, 6 Apr 2012 08:47:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 8Pyrpxz20X4N for ; Fri, 6 Apr 2012 08:46:48 -0400 (EDT) Received: from [192.168.2.101] (pool-96-255-13-167.washdc.fios.verizon.net [96.255.13.167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8230FF2401E for ; Fri, 6 Apr 2012 08:47:02 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Russ Housley In-Reply-To: Date: Fri, 6 Apr 2012 08:46:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <47745555-D67D-4FF2-BC0E-6C313143B1FD@vigilsec.com> References: <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> To: IETF PKIX X-Mailer: Apple Mail (2.1084) Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 12:46:53 -0000 RFC 5280 is pretty clear about the processing. Recognized extensions = cannot be ignored, regardless of the criticality. RFC 5280 says: ... Each extension in a certificate is designated as either critical or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. Russ On Apr 5, 2012, at 8:50 PM, Phillip Hallam-Baker wrote: > The intention of the critical flag was to provide a mechanism that > could be used to implement extensions that required backwards > compatibility to be broken. That is all. >=20 > Marking an extension critical does not mean 'important'. An extension > can be marked non critical and be very very important. >=20 > Nor should applications make any use of the critical flag other than > to reject certificates marked critical that they do not understand. If > the application understands the extension the setting of the > criticality flag MUST NOT affect the semantics of the extension. >=20 >=20 > I do not care what the specification documents say on the matter, > really I don't. If the specifications say that criticality means > important then they are stupid and wrong and should be fixed. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From carl@redhoundsoftware.com Fri Apr 6 05:52:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A232221F85E7 for ; Fri, 6 Apr 2012 05:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7QPaMjSD+PJ for ; Fri, 6 Apr 2012 05:52:52 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id EA3BA21F85E6 for ; Fri, 6 Apr 2012 05:52:51 -0700 (PDT) Received: by qaea16 with SMTP id a16so345953qae.10 for ; Fri, 06 Apr 2012 05:52:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=jjEempIoHKQGty2xn3N+6CaRvmza6NS3jP4ONRNXZRw=; b=L/qVl985483DKItXP3atFcvcAI/hw9XwLMqYVBC2n1ym+5LhxHbHnJctmikQZokAq2 lNl01awurjcmzOelzXDrld0lnliKFhq4vND05hS4EkiswT6JMeplqhznSD4DrUXpZ+Ag OWL+7r9EJJpQNH+S8vUwi+PLu7FsXmo0sB7xz0MxbduyckMJPZSEHkNnlyZCqVEI9F6h HKVmj2AZVTEIPUqz9EipYc5eSrIFpv9isDeG2SMn0UBNkK3/tP/Pwjug8grM8IlZCYU/ dkEjT5JR/5DluhzyovgPR5vWfLABI12W70g3ExnIR+mWdXE8M192xYMDIncSRZyYp641 oXqA== Received: by 10.229.114.222 with SMTP id f30mr2680130qcq.13.1333716771309; Fri, 06 Apr 2012 05:52:51 -0700 (PDT) Received: from [192.168.1.4] (pool-173-79-133-63.washdc.fios.verizon.net. [173.79.133.63]) by mx.google.com with ESMTPS id eg9sm10674630qab.19.2012.04.06.05.52.37 (version=SSLv3 cipher=OTHER); Fri, 06 Apr 2012 05:52:49 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 06 Apr 2012 08:52:30 -0400 From: Carl Wallace To: Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQnGhXxOfWka4D7XjmlbzJeqCgHaBdeGwZa1Dhimai5JDPypQ4LnrTKZCx4GdBFMZlymWTbr Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 12:52:53 -0000 On 4/6/12 8:37 AM, "Phillip Hallam-Baker" wrote: >How people were saying was rather more instrumental in the fork than >what they were saying. I can't remember the last time I came here with >a proposal and someone said 'hey how can we achieve that better'. >Instead the response is always 'well thats not the way the spec works, >tough noogies for you'. Are you serious? You came here with a proposal to modify OCSP (while breaking backwards compatibility) just a few weeks ago. You offered no spec, just email. There was interest. Discussion followed. Several ideas were floated (including alternatives that preserved backwards compatibility). Does such discussion not fall into the 'hey how can we achieve that better' bucket? It would seem to. Did you welcome such discussion? No, you had a fit. Much like this one. This problem is even easier to deal with. If Apple's implementation is broken (recall the original comment came from someone who had not tested this and was relying on hearsay) they should fix it. In the meantime, add something to the Mozilla policy to allow a grace period of non-compliance with 5280 so you can work around the problem. However, the bugs might get fixed faster if, for example, Android is working fine and iOS is not. > >If you understood why I was bothered you would apologize to me and the >group for your behavior. > >Participation in PKIX has shrunk because people just don't like >interacting with a group that is considered to be needlessly >obstructionist and sinks to personal insults to drive people away. > >I do not pull rank except when I see others doing so. > > > >On Fri, Apr 6, 2012 at 7:45 AM, Santosh Chokhani >wrote: >> PHB, >> >> I understand why you are bothered. >> >> My advice to you is focus on what is being said and not on who is >>saying it. >> >> -----Original Message----- >> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >> Sent: Thursday, April 05, 2012 9:02 PM >> To: Santosh Chokhani >> Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org >> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name >> >> Santosh, >> >> As I stated in my message to the ADs explaining the reason why we are >>breaking from the PKIX work, your role has been corrosive here. I do not >>mind people attacking me, but I see you all behaving like a bunch of >>high school heathers attacking anyone else you disagree with in the same >>terms. >> >> >> I don't particularly see that I have a need to justify my credentials >>to you. In fact I am really not aware of any substantial contribution >>you have made to the field, positive or negative. I value the opinion of >>the people I have worked with, a list that includes multiple Turing >>award winners besides many other notable contributors to the field. I do >>not value the opinion of people who attempt to preen themselves by >>putting other down. >> >> You are certainly not the only person that gets security here, not by a >>long way. In fact I would suggest that anyone who argues in the fashion >>you do, through appeals to their own authority are the people who 'don't >>get it'. >> >> >> >> >> >> On Thu, Apr 5, 2012 at 8:48 PM, Santosh Chokhani >> wrote: >>> PHB, >>> >>> You should do what you deem appropriate. >>> >>> My recommendation is for 5280 and those who get security. >>> >>> BTW, this is not the second time, it is umpteenth time and third time >>>in recent memory. I suppose you rather forget about that e-mail about >>>EC DH parameters asserted by a cross certified CA. >>> >>> -----Original Message----- >>> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >>> Sent: Thursday, April 05, 2012 7:31 PM >>> To: Santosh Chokhani >>> Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org >>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>> Name >>> >>> Santosh, >>> >>> This is the second time that you have tried to pull rank on other >>>members of the working group in the past month. I should point out that >>>in my view you are really not qualified to pull rank as you appear to >>>believe you are entitled. >>> >>> If you cannot treat others here with respect I suggest that the chairs >>>inform you that your contributions are no longer desirable. >>> >>> >>> The security issue here is that we cannot issue a certificate that >>>does not work with the deployed Apple clients. Thus the only way it is >>>possible to use the name constraints is to make them non-critical. >>> Therefore this is what we are going to be doing. >>> >>> The proposal is to fix an obvious bug in the specification to meet a >>>real world operational requirement. >>> >>> >>> On Mon, Apr 2, 2012 at 1:17 PM, Santosh Chokhani >>> wrote: >>>> Martin, >>>> >>>> You miss the security implication of this. >>>> >>>> CA can always make it NC and the clients that do not process name >>>>constraints will be exposed if the Sub CA is rogue, compromised or RAs >>>>it trusts go rouge or are compromised. >>>> >>>> -----Original Message----- >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf >>>> Of Martin Rex >>>> Sent: Monday, April 02, 2012 1:14 PM >>>> To: Erwann Abalea >>>> Cc: pkix@ietf.org; paul.hoffman@vpnc.org >>>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>>> Name >>>> >>>> Erwann Abalea wrote: >>>>> >>>>> > To me, that looks like a >>>>> > perfectly valid request, and PKIX (rfc5280) is in violation of >>>>> > rfc2119 of requiring this extension to be always made critical by >>>>> > the CA (instead of leaving that decision to the CA to express its >>>>> > intention). >>>>> > >>>>> >>>>> How could PKIX be in violation of anything by requiring the >>>>> extension to be critical, and why the RFC2119? Is PKIX also in >>>>> violation of >>>>> RFC2119 when requiring the serial number to be a positive integer >>>>> not longer than 20 octets? >>>> >>>> http://tools.ietf.org/html/rfc2119#section-6 >>>> >>>> 6. Guidance in the use of these Imperatives >>>> >>>> Imperatives of the type defined in this memo must be used with care >>>> and sparingly. In particular, they MUST only be used where it is >>>> actually required for interoperation or to limit behavior which has >>>> potential for causing harm (e.g., limiting retransmisssions) For >>>> example, they must not be used to try to impose a particular method >>>> on implementors where the method is not required for >>>> interoperability. >>>> >>>> >>>> Requiring a CA to always make name constraints critical will very >>>>probably impair/break interop with implementations that do not support >>>>that particular type of name constraints. >>>> >>>> Since the CA is the entity which defines the policy of whether RPs >>>> enforcing this name constraints is a problem or not, the MUST can >>>> *NOT* be justified with security. There for the "MUST always be >>>>critical" >>>> in rfc5280 is a clear violation of rfc2119 and therefore NULL and >>>>VOID. >>>> That is pretty simple math. >>>> >>>> The only reason that this is there is a desire for some organizations >>>>to procure specific features in COTS, rather than having to pay extra >>>>for it. Deserves to be ignored by the marketplace. >>>> >>>> >>>> >>>> The discussion of the purpose of both critical and non-critical uses >>>>of a constraints extension is much more reasonably explained here: >>>> >>>> http://tools.ietf.org/html/rfc3647#section-3.3.1 >>>> >>>> and the very same reasoning can be applied to name constraints. >>>> It must be up to the CA that puts name constraints into a subCA cert >>>>to determine whether these should be critical or not. It is invalid >>>>for rfc5280 to unconditionally require name constraints to be marked >>>>critical by CAs. >>>> >>>> >>>> -Martin >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ >> >> >> >> -- >> Website: http://hallambaker.com/ > > > >-- >Website: http://hallambaker.com/ >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From turners@ieca.com Fri Apr 6 06:35:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7179521F84DA for ; Fri, 6 Apr 2012 06:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.887 X-Spam-Level: X-Spam-Status: No, score=-101.887 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mseKVCEBDl1 for ; Fri, 6 Apr 2012 06:35:40 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.93.179.12]) by ietfa.amsl.com (Postfix) with ESMTP id 902B321F84D9 for ; Fri, 6 Apr 2012 06:35:40 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id D74182B8B68D6; Fri, 6 Apr 2012 08:34:39 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id CC82B2B8B68B6 for ; Fri, 6 Apr 2012 08:34:39 -0500 (CDT) Received: from [96.231.114.27] (port=44292 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SG9JG-0003t9-Gl; Fri, 06 Apr 2012 08:34:39 -0500 Message-ID: <4F7EF0EE.3030508@ieca.com> Date: Fri, 06 Apr 2012 09:34:38 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Max Pritikin References: <260966ff0f0743ba0f04d902cca68116.squirrel@www.trepanning.net> <17E480DA-907D-4F40-BDE5-0A10930E3695@cisco.com> <7ab37b4479f2245e353fc1117171869c.squirrel@www.trepanning.net> In-Reply-To: <7ab37b4479f2245e353fc1117171869c.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-114-27.washdc.east.verizon.net (thunderfish.local) [96.231.114.27]:44292 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: pkix@ietf.org Subject: Re: [pkix] Using "CMC Simple PKI Response" rather than "certificate" X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 13:35:41 -0000 On 4/4/12 1:40 PM, Dan Harkins wrote: > > Hi Max, > > On Mon, April 2, 2012 5:34 pm, Max Pritikin wrote: >> (I've updated the subject on this thread) >> >> My thoughts on this have not solidified yet. A couple of initial >> questions, >> >> a) this requires the server to build and sign this response. Coding that >> is relatively simple with off the shelf libraries but it will require >> additional ASN1 and crypto operations that are effectively ignored. Is >> this then an effective use of server (and client!) resources? > > I don't think the building will be ignored. The server can deliver > the client's certificate and the CA certificate in one nice package. > Regarding the additional crypto operations, given the other resource use > necessary to execute this protocol I think it's noise. And this is > something of a one-off protocol too. There's no signature on a certs-only message. There's no signerInfo, which is where the signatures would go. See 3.6 of RFC 2311. Get two certs in pem format (cert1.pem and cert2.pem) and use openssl: openssl crl2pkcs7 -nocrl -certfile cert1.pem -certfile cert2.pem -out p7.pem My MacBook has OpenSSL 0.9.8r 8 Feb 2011. >> b) Should the signature on this PKCS#7 be ignored? What if the CA has >> moved on to a new key? How does it know to use an old key for this >> signing? > > Yes, I believe it's ignored. See previous answer. >> c) The Simple PKI Response section 4.1 [RFC5272] includes a variety of >> "MAY" statements (options!). If we move in this direction would there be >> support for profiling these to a more restrictive set of options? For each >> of the following statements from paragraph 2 I'm thinking: >> >> "Servers SHOULD include all intermediate certificates needed to form >> complete certification paths to one or more trust anchors, not just the >> newly issued certificate(s)." >> Change to MUST NOT. >> Justification: this is not a trust anchor management protocol, thus this >> type of flexibility isn't warranted here. > > I agree that this isn't a "trust anchor management protocol" but for > the protocol to be generally useful it would really help for the client > to have all the intermediate certificates it needs to form a complete > certification path. > > You're talking about an absolute prohibition on providing useful > information. That just doesn't sound right. SHOULD sounds fine. Max - I like the way you think, but somebody will argue that MUST NOT in this case would be against Sec 6 of 2119. It's not an interop issue or put another way what bad thing will happen if they do include it? >> "The server MAY additionally return CRLs in the CRL bag." >> Change to MUST NOT. >> Justification: This is not a CRL distribution protocol, thus the best the >> server can do is provide a CRL appropriate for this client's certificate >> at this point in time which is of minimal use. Also not including anything >> specific to the client allows the PKCS#7 to be pre-generated for /CACerts. > > MAY means "[o]ne vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that it > enhances the product...." Seems like it would be an enhancement to > provide more useful information if the market deems it necessary or > a vendor believes it enhances his product. > > Again, you're talking about an absolute prohibition on providing > useful information. You think this is of minimal use. Fine. The text > that follows the ellipses above is "while another vendor may omit the > same item." You may omit a CRL because you feel it is of minimal use. See previous answer. >> "Servers MAY include the self-signed certificates." >> (I"m assuming this means including its own self-signed certificate?) >> Change to MUST (and add "In addition the Root CA Key Update certificates >> SHOULD be included."). >> Justification: The CA certs MUST be included for /CACerts so make them >> always included (reducing options). This would allow clients to skip >> calling /CACerts for re-enroll since they'd always receive any new CA >> certs in the response. I think SHOULD would be better here. And, the reason is that self-signed certificates aren't always the TA format - granted it's likely the format 99.99999% of the time. See Sec 3 of RFC 5914. SHOULD means do this unless you got a really, really good reason not to. The only reason I could think of is that you used on of the other two options in 5914. >> "In the event clients receive a new self-signed certificate from the >> server, clients SHOULD provide a mechanism to enable the user to use the >> certificate as a trust anchor" >> Change to MUST (and make this automatic). >> Justification: Although not doing general trust anchor management we want >> to make sure CA key renewal works seamlessly. See previous answer. spt >> Thanks for continued discussion, > > And thank you! > > Dan. > >> - max >> >> On Mar 28, 2012, at 3:04 AM, Dan Harkins wrote: >> >>> >>> Hi, >>> >>> On Tue, 27 Mar 2012 at 11:25:05 Sean Turner said: >>>> Just a couple of comments the WG should consider: >>>> >>>> Technical: >>>> >>>> 1. the /simpleEnroll, /simpleReEnroll, and /serverKeyGen use PKCS#10s >>>> for >>>> the request and return the certificate(s) in a mime media type. In many >>>> instances, the "normal" query/response for a certificate is a PKCS#10 >>>> request followed by a PKCS#7 response, where the PKCS#7 is the >>>> degenerate >>>> certs-only message. Does anyone see any benefit in reusing the >>>> PKCS#10/PKCS#7 model instead of PKCS#10/certificate? Changing it would >>>> align nicely/exactly with the simple PKI request/response from CMC. >>> >>> Yes, I see value in reusing the PKCS#10/PKCS#7 model. EST is supposed >>> to implement "simple CMC" and that should use a PKCS#7 as the simple >>> response. >>> >>> regards, >>> >>> Dan. >>> >>> >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> > > > From hallam@gmail.com Fri Apr 6 06:57:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5C621F855F for ; Fri, 6 Apr 2012 06:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdmORh0fOMVF for ; Fri, 6 Apr 2012 06:57:57 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 266D221F8557 for ; Fri, 6 Apr 2012 06:57:57 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1439102ggm.31 for ; Fri, 06 Apr 2012 06:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/hXu8667et0r6AQIgC52SSbY0Qb+xFQFTskAqjjQbYM=; b=LCbmZMgnGRUNervZ0eOD2UQp6s30ZaKeNnEepmSOLqXD9aBMKyAr3RzMgbSk31nXEs 0JJ8MwtKddJTDRVVzY6HpSLapmTNDv6MK4dTR+exxSeWb+4e8oorxSYWeN4Ig3OUn096 e9Tc9a99T6/FzSzNnNb1E/w9tq+/VaR/ryWQZJCY7vDMxYJyNdklJj0OXN1f1ACebbKd Qbhb0nYOM/dOdEQzhzpYh2/IVB91BSl4Qebb8q/lynyWhtSk4WhAttMyCxpyHDRm8cxW HgQmEhDhKCJNDS78UubDgyCkarEXZBxlKCCaPtTv+WCxuDMXX1RRfKv+1puZ9YXs3MKx WmFw== MIME-Version: 1.0 Received: by 10.60.7.200 with SMTP id l8mr9265219oea.52.1333720676591; Fri, 06 Apr 2012 06:57:56 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Fri, 6 Apr 2012 06:57:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Apr 2012 09:57:56 -0400 Message-ID: From: Phillip Hallam-Baker To: Carl Wallace Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 13:57:58 -0000 I am absolutely serious. Arguing that it is more important to preserve the spec than solve real world problems without breaking stuff is not constructive comment in my view. My proposal was totally backwards compatible. Just define an extension to allow the OCSP servers that can to report 'certificate not issued'. The response was that this should be done using SCVP, a protocol the industry has no interest in supporting. Apple's implementation is 100% compliant. They are entitled to not implement the feature. As Russ also points out, marking an extension critical does not affect the semantics. So what is the reason for not changing the spec here to enable the extension to be used? I dont see you even bother to try to answer that. You just assume that the simplest course is to do as little to the spec as possible. The driving function here is that Mozilla are proposing making use of name constraints mandatory in enterprise CAs within the next few months. There is a clear industry consensus that this is a good idea provided we can arrive at an understanding of the consequences for deployed code and we break as little as possible. I would have hoped that the view of the WG was 'hey we want people to use name constraints, how can we make that work'. Instead we have you and others trying to make a point of principle on an arbitrary detail of the specification. I still have not heard anyone give a good reason for marking the extension critical in this application. What is going to happen here is: 1) Mozilla makes name constraints a requirement 2) CAs deploy certs with the constraints marked non-critical 3) The PKI specifications are eventually corrected to match practice. The only option here is what the specifications end up being called. If the WG learns from this outcome and becomes more reasonable then it is possible that we can come back into sync. But if no lessons are learned then we are going to end up with two PKIX specifications, the IETF one and the one that matters. On Fri, Apr 6, 2012 at 8:52 AM, Carl Wallace wr= ote: > > On 4/6/12 8:37 AM, "Phillip Hallam-Baker" wrote: > >>How people were saying was rather more instrumental in the fork than >>what they were saying. I can't remember the last time I came here with >>a proposal and someone said 'hey how can we achieve that better'. >>Instead the response is always 'well thats not the way the spec works, >>tough noogies for you'. > > Are you serious? =A0You came here with a proposal to modify OCSP (while > breaking backwards compatibility) just a few weeks ago. =A0You offered no > spec, just email. There was interest. =A0Discussion followed. =A0Several = ideas > were floated (including alternatives that preserved backwards > compatibility). =A0Does such discussion not fall into the 'hey how can we > achieve that better' bucket? =A0It would seem to. =A0Did you welcome such > discussion? =A0No, you had a fit. =A0Much like this one. =A0This problem = is even > easier to deal with. =A0If Apple's implementation is broken (recall the > original comment came from someone who had not tested this and was relyin= g > on hearsay) they should fix it. =A0In the meantime, add something to the > Mozilla policy to allow a grace period of non-compliance with 5280 so you > can work around the problem. =A0However, the bugs might get fixed faster = if, > for example, Android is working fine and iOS is not. > > >> >>If you understood why I was bothered you would apologize to me and the >>group for your behavior. >> >>Participation in PKIX has shrunk because people just don't like >>interacting with a group that is considered to be needlessly >>obstructionist and sinks to personal insults to drive people away. >> >>I do not pull rank except when I see others doing so. >> >> >> >>On Fri, Apr 6, 2012 at 7:45 AM, Santosh Chokhani >>wrote: >>> PHB, >>> >>> I understand why you are bothered. >>> >>> My advice to you is focus on what is being said and not on who is >>>saying it. >>> >>> -----Original Message----- >>> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >>> Sent: Thursday, April 05, 2012 9:02 PM >>> To: Santosh Chokhani >>> Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org >>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Nam= e >>> >>> Santosh, >>> >>> As I stated in my message to the ADs explaining the reason why we are >>>breaking from the PKIX work, your role has been corrosive here. I do not >>>mind people attacking me, but I see you all behaving like a bunch of >>>high school heathers attacking anyone else you disagree with in the same >>>terms. >>> >>> >>> I don't particularly see that I have a need to justify my credentials >>>to you. In fact I am really not aware of any substantial contribution >>>you have made to the field, positive or negative. I value the opinion of >>>the people I have worked with, a list that includes multiple Turing >>>award winners besides many other notable contributors to the field. I do >>>not value the opinion of people who attempt to preen themselves by >>>putting other down. >>> >>> You are certainly not the only person that gets security here, not by a >>>long way. In fact I would suggest that anyone who argues in the fashion >>>you do, through appeals to their own authority are the people who 'don't >>>get it'. >>> >>> >>> >>> >>> >>> On Thu, Apr 5, 2012 at 8:48 PM, Santosh Chokhani >>> wrote: >>>> PHB, >>>> >>>> You should do what you deem appropriate. >>>> >>>> My recommendation is for 5280 and those who get security. >>>> >>>> BTW, this is not the second time, it is umpteenth time and third time >>>>in recent memory. =A0I suppose you rather forget about that e-mail abou= t >>>>EC DH parameters asserted by a cross certified CA. >>>> >>>> -----Original Message----- >>>> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >>>> Sent: Thursday, April 05, 2012 7:31 PM >>>> To: Santosh Chokhani >>>> Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org >>>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>>> Name >>>> >>>> Santosh, >>>> >>>> This is the second time that you have tried to pull rank on other >>>>members of the working group in the past month. I should point out that >>>>in my view you are really not qualified to pull rank as you appear to >>>>believe you are entitled. >>>> >>>> If you cannot treat others here with respect I suggest that the chairs >>>>inform you that your contributions are no longer desirable. >>>> >>>> >>>> The security issue here is that we cannot issue a certificate that >>>>does not work with the deployed Apple clients. Thus the only way it is >>>>possible to use the name constraints is to make them non-critical. >>>> Therefore this is what we are going to be doing. >>>> >>>> The proposal is to fix an obvious bug in the specification to meet a >>>>real world operational requirement. >>>> >>>> >>>> On Mon, Apr 2, 2012 at 1:17 PM, Santosh Chokhani >>>> wrote: >>>>> Martin, >>>>> >>>>> You miss the security implication of this. >>>>> >>>>> CA can always make it NC and the clients that do not process name >>>>>constraints will be exposed if the Sub CA is rogue, compromised or RAs >>>>>it trusts go rouge or are compromised. >>>>> >>>>> -----Original Message----- >>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf >>>>> Of Martin Rex >>>>> Sent: Monday, April 02, 2012 1:14 PM >>>>> To: Erwann Abalea >>>>> Cc: pkix@ietf.org; paul.hoffman@vpnc.org >>>>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>>>> Name >>>>> >>>>> Erwann Abalea wrote: >>>>>> >>>>>> > To me, that looks like a >>>>>> > perfectly valid request, and PKIX (rfc5280) is in violation of >>>>>> > rfc2119 of requiring this extension to be always made critical by >>>>>> > the CA (instead of leaving that decision to the CA to express its >>>>>> > intention). >>>>>> > >>>>>> >>>>>> How could PKIX be in violation of anything by requiring the >>>>>> extension to be critical, and why the RFC2119? Is PKIX also in >>>>>> violation of >>>>>> RFC2119 when requiring the serial number to be a positive integer >>>>>> not longer than 20 octets? >>>>> >>>>> http://tools.ietf.org/html/rfc2119#section-6 >>>>> >>>>> =A0 6. Guidance in the use of these Imperatives >>>>> >>>>> =A0 Imperatives of the type defined in this memo must be used with ca= re >>>>> =A0 and sparingly. =A0In particular, they MUST only be used where it = is >>>>> =A0 actually required for interoperation or to limit behavior which h= as >>>>> =A0 potential for causing harm (e.g., limiting retransmisssions) =A0F= or >>>>> =A0 example, they must not be used to try to impose a particular meth= od >>>>> =A0 on implementors where the method is not required for >>>>> =A0 interoperability. >>>>> >>>>> >>>>> Requiring a CA to always make name constraints critical will very >>>>>probably impair/break interop with implementations that do not support >>>>>that particular type of name constraints. >>>>> >>>>> Since the CA is the entity which defines the policy of whether RPs >>>>> enforcing this name constraints is a problem or not, the MUST can >>>>> *NOT* be justified with security. =A0There for the "MUST always be >>>>>critical" >>>>> in rfc5280 is a clear violation of rfc2119 and therefore NULL and >>>>>VOID. >>>>> That is pretty simple math. >>>>> >>>>> The only reason that this is there is a desire for some organizations >>>>>to procure specific features in COTS, rather than having to pay extra >>>>>for it. =A0Deserves to be ignored by the marketplace. >>>>> >>>>> >>>>> >>>>> The discussion of the purpose of both critical and non-critical uses >>>>>of a constraints extension is much more reasonably explained here: >>>>> >>>>> =A0http://tools.ietf.org/html/rfc3647#section-3.3.1 >>>>> >>>>> and the very same reasoning can be applied to name constraints. >>>>> It must be up to the CA that puts name constraints into a subCA cert >>>>>to determine whether these should be critical or not. =A0It is invalid >>>>>for rfc5280 to unconditionally require name constraints to be marked >>>>>critical by CAs. >>>>> >>>>> >>>>> -Martin >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> >>>> -- >>>> Website: http://hallambaker.com/ >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ >> >> >> >>-- >>Website: http://hallambaker.com/ >>_______________________________________________ >>pkix mailing list >>pkix@ietf.org >>https://www.ietf.org/mailman/listinfo/pkix > > --=20 Website: http://hallambaker.com/ From carl@redhoundsoftware.com Fri Apr 6 07:27:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025D521F8546 for ; Fri, 6 Apr 2012 07:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ2IXLfrJCtv for ; Fri, 6 Apr 2012 07:27:56 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBD621F853F for ; Fri, 6 Apr 2012 07:27:56 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1697906qcs.31 for ; Fri, 06 Apr 2012 07:27:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=8N1crnUsNqQxdXWh0gwu1nO0Hk6t2+goVp3WMi7OZJ0=; b=BNKe4kf7fe1iCk2r5Hvd4Zkk1FYEbWpIlNKOSPnWqPYiYdk6Xo/3YIEYLcR1JgrzpD PF/KXaexTJZSjRtc96D5jH5ObQW4JLITDx9zdJBapA5VRrSXPbOQZ9R9hNgkn6JpuhiW aF/OV15zDPmpWN5kdkavptwJPLgkbTK6g8T/fGYMgRl2eNsglNGcyFNkbHiT8jWF7Qx8 vmAgBsr8ebvgVxLWD4xcPoKwMGLMAZV1RxmhiCxwgtg7/mLapZLBFLcCSXHAMkGapVO8 WJtyKhOgoBW3pY7RSM/0hfKVREvGAULp7iZHqcu3WnE9Xl3XhgnjIdSYi8s98E9aoUl6 yIbg== Received: by 10.224.33.134 with SMTP id h6mr9489417qad.15.1333722475987; Fri, 06 Apr 2012 07:27:55 -0700 (PDT) Received: from [192.168.1.4] (pool-173-79-133-63.washdc.fios.verizon.net. [173.79.133.63]) by mx.google.com with ESMTPS id ey9sm4871349qab.14.2012.04.06.07.27.54 (version=SSLv3 cipher=OTHER); Fri, 06 Apr 2012 07:27:55 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 06 Apr 2012 10:27:52 -0400 From: Carl Wallace To: Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQlynxGmUwQq1fF/JVTvOcucAwMQXCM18fmhpMU4kp7v/6VwVNpos6L9+6XcdxKhCNHqjMRb Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 14:27:58 -0000 On 4/6/12 9:57 AM, "Phillip Hallam-Baker" wrote: >I am absolutely serious. > >Arguing that it is more important to preserve the spec than solve real >world problems without breaking stuff is not constructive comment in >my view. > >My proposal was totally backwards compatible. Just define an extension >to allow the OCSP servers that can to report 'certificate not issued'. >The response was that this should be done using SCVP, a protocol the >industry has no interest in supporting. There were many responses in that thread, including some that supported your proposal and some that offered alternatives in an effort to improve upon it. My point was that your claim below about there never being constructive discussion is false. There was plenty of constructive discussion. There was no attempt to last call your email proposal. > > >Apple's implementation is 100% compliant. They are entitled to not >implement the feature. As Russ also points out, marking an extension >critical does not affect the semantics. This is simply false. How is Apple's implementation compliant with section 6 or with the next to last paragraph of section 4.2? The requirements for name constraints are not new. Excellent test suites have been available for many years. Many implementations get it more or less right. > >So what is the reason for not changing the spec here to enable the >extension to be used? I dont see you even bother to try to answer >that. You just assume that the simplest course is to do as little to >the spec as possible. I'm indifferent to changing the spec w.r.t. criticality since, as you note, implementations that recognize the extension must process it anyway. I don't think the legalistic RFC2119 arguments are the least bit persuasive and I think it's a slippery slope to start editing the spec to accommodate incomplete or incorrect implementations. Where is the harm in announcing the policy change, allowing a grace period of non-compliance and working with vendors to ensure name constraints are enforced in more/most cases? The aim is to make sure name constraints are enforced, right? > > >The driving function here is that Mozilla are proposing making use of >name constraints mandatory in enterprise CAs within the next few >months. There is a clear industry consensus that this is a good idea >provided we can arrive at an understanding of the consequences for >deployed code and we break as little as possible. Understood and probably long overdue. > >I would have hoped that the view of the WG was 'hey we want people to >use name constraints, how can we make that work'. Instead we have you >and others trying to make a point of principle on an arbitrary detail >of the specification. > > >I still have not heard anyone give a good reason for marking the >extension critical in this application. > >What is going to happen here is: > >1) Mozilla makes name constraints a requirement >2) CAs deploy certs with the constraints marked non-critical >3) The PKI specifications are eventually corrected to match practice. Assuming the aim is for name constraints to actually be enforced, 3) might be "Applications add support for enforcing name constraints." That the internet PKI has been operated with minimal constraints so long is the problem. Carving out room to continue lousy practices is not really the answer. > >The only option here is what the specifications end up being called. >If the WG learns from this outcome and becomes more reasonable then it >is possible that we can come back into sync. But if no lessons are >learned then we are going to end up with two PKIX specifications, the >IETF one and the one that matters. Nonsense. There are far more than two "PKIX specifications" kicking around. Else we'd not be having this discussion at all. > > > >On Fri, Apr 6, 2012 at 8:52 AM, Carl Wallace >wrote: >> >> On 4/6/12 8:37 AM, "Phillip Hallam-Baker" wrote: >> >>>How people were saying was rather more instrumental in the fork than >>>what they were saying. I can't remember the last time I came here with >>>a proposal and someone said 'hey how can we achieve that better'. >>>Instead the response is always 'well thats not the way the spec works, >>>tough noogies for you'. >> >> Are you serious? You came here with a proposal to modify OCSP (while >> breaking backwards compatibility) just a few weeks ago. You offered no >> spec, just email. There was interest. Discussion followed. Several >>ideas >> were floated (including alternatives that preserved backwards >> compatibility). Does such discussion not fall into the 'hey how can we >> achieve that better' bucket? It would seem to. Did you welcome such >> discussion? No, you had a fit. Much like this one. This problem is >>even >> easier to deal with. If Apple's implementation is broken (recall the >> original comment came from someone who had not tested this and was >>relying >> on hearsay) they should fix it. In the meantime, add something to the >> Mozilla policy to allow a grace period of non-compliance with 5280 so >>you >> can work around the problem. However, the bugs might get fixed faster >>if, >> for example, Android is working fine and iOS is not. >> >> >>> >>>If you understood why I was bothered you would apologize to me and the >>>group for your behavior. >>> >>>Participation in PKIX has shrunk because people just don't like >>>interacting with a group that is considered to be needlessly >>>obstructionist and sinks to personal insults to drive people away. >>> >>>I do not pull rank except when I see others doing so. >>> >>> >>> >>>On Fri, Apr 6, 2012 at 7:45 AM, Santosh Chokhani >>> >>>wrote: >>>> PHB, >>>> >>>> I understand why you are bothered. >>>> >>>> My advice to you is focus on what is being said and not on who is >>>>saying it. >>>> >>>> -----Original Message----- >>>> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >>>> Sent: Thursday, April 05, 2012 9:02 PM >>>> To: Santosh Chokhani >>>> Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org >>>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>>>Name >>>> >>>> Santosh, >>>> >>>> As I stated in my message to the ADs explaining the reason why we are >>>>breaking from the PKIX work, your role has been corrosive here. I do >>>>not >>>>mind people attacking me, but I see you all behaving like a bunch of >>>>high school heathers attacking anyone else you disagree with in the >>>>same >>>>terms. >>>> >>>> >>>> I don't particularly see that I have a need to justify my credentials >>>>to you. In fact I am really not aware of any substantial contribution >>>>you have made to the field, positive or negative. I value the opinion >>>>of >>>>the people I have worked with, a list that includes multiple Turing >>>>award winners besides many other notable contributors to the field. I >>>>do >>>>not value the opinion of people who attempt to preen themselves by >>>>putting other down. >>>> >>>> You are certainly not the only person that gets security here, not by >>>>a >>>>long way. In fact I would suggest that anyone who argues in the fashion >>>>you do, through appeals to their own authority are the people who >>>>'don't >>>>get it'. >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Apr 5, 2012 at 8:48 PM, Santosh Chokhani >>>> wrote: >>>>> PHB, >>>>> >>>>> You should do what you deem appropriate. >>>>> >>>>> My recommendation is for 5280 and those who get security. >>>>> >>>>> BTW, this is not the second time, it is umpteenth time and third time >>>>>in recent memory. I suppose you rather forget about that e-mail about >>>>>EC DH parameters asserted by a cross certified CA. >>>>> >>>>> -----Original Message----- >>>>> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >>>>> Sent: Thursday, April 05, 2012 7:31 PM >>>>> To: Santosh Chokhani >>>>> Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org >>>>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>>>> Name >>>>> >>>>> Santosh, >>>>> >>>>> This is the second time that you have tried to pull rank on other >>>>>members of the working group in the past month. I should point out >>>>>that >>>>>in my view you are really not qualified to pull rank as you appear to >>>>>believe you are entitled. >>>>> >>>>> If you cannot treat others here with respect I suggest that the >>>>>chairs >>>>>inform you that your contributions are no longer desirable. >>>>> >>>>> >>>>> The security issue here is that we cannot issue a certificate that >>>>>does not work with the deployed Apple clients. Thus the only way it is >>>>>possible to use the name constraints is to make them non-critical. >>>>> Therefore this is what we are going to be doing. >>>>> >>>>> The proposal is to fix an obvious bug in the specification to meet a >>>>>real world operational requirement. >>>>> >>>>> >>>>> On Mon, Apr 2, 2012 at 1:17 PM, Santosh Chokhani >>>>> wrote: >>>>>> Martin, >>>>>> >>>>>> You miss the security implication of this. >>>>>> >>>>>> CA can always make it NC and the clients that do not process name >>>>>>constraints will be exposed if the Sub CA is rogue, compromised or >>>>>>RAs >>>>>>it trusts go rouge or are compromised. >>>>>> >>>>>> -----Original Message----- >>>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf >>>>>> Of Martin Rex >>>>>> Sent: Monday, April 02, 2012 1:14 PM >>>>>> To: Erwann Abalea >>>>>> Cc: pkix@ietf.org; paul.hoffman@vpnc.org >>>>>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>>>>> Name >>>>>> >>>>>> Erwann Abalea wrote: >>>>>>> >>>>>>> > To me, that looks like a >>>>>>> > perfectly valid request, and PKIX (rfc5280) is in violation of >>>>>>> > rfc2119 of requiring this extension to be always made critical by >>>>>>> > the CA (instead of leaving that decision to the CA to express its >>>>>>> > intention). >>>>>>> > >>>>>>> >>>>>>> How could PKIX be in violation of anything by requiring the >>>>>>> extension to be critical, and why the RFC2119? Is PKIX also in >>>>>>> violation of >>>>>>> RFC2119 when requiring the serial number to be a positive integer >>>>>>> not longer than 20 octets? >>>>>> >>>>>> http://tools.ietf.org/html/rfc2119#section-6 >>>>>> >>>>>> 6. Guidance in the use of these Imperatives >>>>>> >>>>>> Imperatives of the type defined in this memo must be used with >>>>>>care >>>>>> and sparingly. In particular, they MUST only be used where it is >>>>>> actually required for interoperation or to limit behavior which >>>>>>has >>>>>> potential for causing harm (e.g., limiting retransmisssions) For >>>>>> example, they must not be used to try to impose a particular >>>>>>method >>>>>> on implementors where the method is not required for >>>>>> interoperability. >>>>>> >>>>>> >>>>>> Requiring a CA to always make name constraints critical will very >>>>>>probably impair/break interop with implementations that do not >>>>>>support >>>>>>that particular type of name constraints. >>>>>> >>>>>> Since the CA is the entity which defines the policy of whether RPs >>>>>> enforcing this name constraints is a problem or not, the MUST can >>>>>> *NOT* be justified with security. There for the "MUST always be >>>>>>critical" >>>>>> in rfc5280 is a clear violation of rfc2119 and therefore NULL and >>>>>>VOID. >>>>>> That is pretty simple math. >>>>>> >>>>>> The only reason that this is there is a desire for some >>>>>>organizations >>>>>>to procure specific features in COTS, rather than having to pay extra >>>>>>for it. Deserves to be ignored by the marketplace. >>>>>> >>>>>> >>>>>> >>>>>> The discussion of the purpose of both critical and non-critical uses >>>>>>of a constraints extension is much more reasonably explained here: >>>>>> >>>>>> http://tools.ietf.org/html/rfc3647#section-3.3.1 >>>>>> >>>>>> and the very same reasoning can be applied to name constraints. >>>>>> It must be up to the CA that puts name constraints into a subCA cert >>>>>>to determine whether these should be critical or not. It is invalid >>>>>>for rfc5280 to unconditionally require name constraints to be marked >>>>>>critical by CAs. >>>>>> >>>>>> >>>>>> -Martin >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>> >>>>> -- >>>>> Website: http://hallambaker.com/ >>>> >>>> >>>> >>>> -- >>>> Website: http://hallambaker.com/ >>> >>> >>> >>>-- >>>Website: http://hallambaker.com/ >>>_______________________________________________ >>>pkix mailing list >>>pkix@ietf.org >>>https://www.ietf.org/mailman/listinfo/pkix >> >> > > > >-- >Website: http://hallambaker.com/ From DPKemp@missi.ncsc.mil Fri Apr 6 07:47:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE5921F84FE for ; Fri, 6 Apr 2012 07:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsqBgisjgO7p for ; Fri, 6 Apr 2012 07:47:26 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 72C6921F84FB for ; Fri, 6 Apr 2012 07:47:26 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q36ElPXN010311 for ; Fri, 6 Apr 2012 10:47:25 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Apr 2012 10:47:25 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 6 Apr 2012 10:47:03 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0TiFyWoEHGBdrARl2dQnG4ZOTQSwAd4M+w References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> From: "Kemp, David P." To: X-OriginalArrivalTime: 06 Apr 2012 14:47:25.0460 (UTC) FILETIME=[2E67ED40:01CD1404] Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 14:47:27 -0000 Phill, Different assumptions are (as usual) the source of disagreement regarding conclusions drawn. Your assumptions are as you stated below. Mine are: 1) The objective here is to reduce risk exposure in the Internet PKI infrastructure built according to the specifications. (In the real world there will always be systems that don't meet spec; the purpose of a spec is to support unambiguous testable criteria for what it means to meet it). 2) Any proposal must specify conditions that support secure interoperability. (Systems that do not meet those conditions are not guaranteed to interoperate, but the steps needed to become interoperable are clearly stated). In the real world of U.S. highways, the speed limit spec is 55 mph. That spec is clearly incompatible with the behavior of a majority of drivers. Using your assumptions, any posted speed limit must be compatible with driver behavior (73? 85? 90?). Under my assumptions, posted speed limits are based on highway safety (and other more political) considerations. The spec (posted speed limit) makes it unambiguously clear that a driver going 56 mph is non-compliant. But jurisdictions have the freedom to interpret the spec as they choose, only enforcing violations that exceed their thresholds (5 miles over? 10?). Automated cameras in DC are set to trigger only at 12mph above the posted speed. There are no internet police and no mechanism to enforce PKIX standards. Compliance is completely voluntary, based on a desire to interoperate. For that reason, the standards should specify what is necessary to interoperate securely, and implementations can make exceptions to the standard whenever necessary to interoperate with other implementations that do not meet the standard. My fundamental assumption is that PKIX should document correct behavior, not document existing, incorrect behavior. Dave -----Original Message----- From: Phillip Hallam-Baker Let us start from the beginning and forget the specification for a moment. The objective here is to reduce risk exposure in the deployed Internet PKI infrastructure by constraining the issue capabilities of enterprise CAs. Any proposal must be fully backwards compatible with deployed code. From SChokhani@cygnacom.com Fri Apr 6 07:52:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E087621F8518 for ; Fri, 6 Apr 2012 07:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmEqlE+Bqq2k for ; Fri, 6 Apr 2012 07:52:29 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5936121F8523 for ; Fri, 6 Apr 2012 07:52:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,381,1330923600"; d="scan'208";a="4635969" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 06 Apr 2012 10:52:25 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 6 Apr 2012 10:52:25 -0400 From: Santosh Chokhani To: Tom Gindin , "mrex@sap.com" Date: Fri, 6 Apr 2012 10:52:23 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0TlQP7epCIBz7+RuGs0+23JBxF8AAbsFQw Message-ID: References: from "Stephen Kent" at Apr 5, 12 01:54:50 pm <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 14:52:30 -0000 Tom, In my reading 5280 is reasonably clear. It could always be made clearer. I would consider the following implementations secure: 1. If the name constraint is critical and you do not recognize one or more= name forms, reject the certificate. 2. If the name constraint is critical and you do not recognize one or more= name forms, accept the certificate if none of the unrecognized name forms = appear in the certification path, else reject the certificate. (this is ag= ainst the RFC, but I see no harm) 3, If the name constraint is non-critical and you do not recognize one or = more name forms, accept the certificate. I agree that there is some ambiguity in terms of application behavior if yo= u assume that application behavior must be the same regardless of criticali= ty if an extension is recognized. This is due to inability to process all = name forms. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Tom= Gindin Sent: Thursday, April 05, 2012 9:31 PM To: mrex@sap.com Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Martin: Actually, the way in which name constraints are most clearly unders= pecified is their handling of x400Address. Implementers MUST be able to pr= ocess one of the GeneralName forms, and SHOULD be able to process four more= . Three of the remaining four forms are explicitly excluded from this spec= ification, but there's no reference to how x400Address should be processed = (if anyone still uses it) although there's a SHOULD NOT for the CA putting = in a name constraint of that form. I think that an RP is conformant if it simply rejects any certifica= te whose subject Alt Name has a member of type x400Address, if either permi= tted_subtrees or excluded_subtrees have any member of type x400Address duri= ng the processing of section 6.1.3 B and C. I have no idea whether it's in= tended that having permitted_subtrees contain organization-name but not tel= etex-organization-name means that names with teletex-organization-name (an = Extension attribute) should be banned. I suspect that it is, and I wonder = how many RP's enforce anything like that. In your examples, you'd have to restrict the name forms to ones cov= ered by permitted subtrees. Otherwise, CA's could put in a single excluded= subtree of each name form, covering entities which no longer exist or an I= P which can't be routed. Those are constraints, but they protect very litt= le. Tom Gindin P.S. - The opinions above are mine, and not necessarily those of my employe= r. From: Martin Rex To: kent@bbn.com (Stephen Kent),=20 Cc: pkix@ietf.org Date: 04/05/2012 08:04 PM Subject: Re: [pkix] Proposal: Change the Criticality Requirement of= =20 Name Sent by: pkix-bounces@ietf.org Stephen Kent wrote: >=20 > > > >Correct, name constraints as "envisioned" by rfc5280 are unusable, > >in case that you find yourself unable to ignore that invalid MUST. >=20 > nonsense. name constraints can be used in any PKI where there there > are clear lines of authority for issuing certs relative to a name=20 > space. The fact that the public TTP trust model, at the top, does=20 > not meet that criterion, is merely an indication of a collision > between a business model and technology. To me it appears that name constraints might be underspecified. >From how I understand the design of X.509, subject Name and=20 subjectAltNames are alternative unique representations of the name of the subject. So in order to use name constraints securely, all name forms present in a cert would have to be subject to constraints, and all unconstrained name forms would have to be unconditionally ignored, otherwise the constraints could be evaded. looking at this example structure (using "aaaa" instead of "com" to avoid collisions with mapped DNS space) well-known trust anchor | | CN=3Dpremium subCA, O=3DpubTC, C=3DY public subCA / \ / \ / \ CN=3Dorg-CA, OU=3DFoo, O=3DpubTC, C=3DY CN=3Dorg-CA, OU=3DBar, O=3Dpub= TC, C=3DY organizational subCA FOO organizational subCA BAR with name constraint on with name constraint on dNSName SAN "foo.aaaa" dnsName SAN "bar.aaaa" What is lacking in this example is name constraints on the subject name (DirectoryName). Without it, certain certificate processing, based on an unconstrained name forms, can evade the name constraints. e.g. what about the Bar org-CA issuing a CRL-signer cert (non-CA cert) with a subject DName of the Foo org-CA and using it to fabricate CRLs (with an AIA extension in the CRL, distinguishing the "forged" CRL signer cert from the real Foo org-CA cert by including and AuthKeyID and AIA CRL extensions (plus the IssuingDP CRL extension that RPs expect) ? Such a concoction would fulfil the "CRL Signer cert must validate under the same trust anchor" requirement. And PKIX software that is bold enough to perform forward path discovery based on AIA for the CRL signer might be tricked to accept CRLs forged by org-CA Bar during validation of certs issued by org-CA Foo, I assume. Another problem arises from the fact that there may exist SANs (such as KRB5PrincipalName http://tools.ietf.org/html/rfc4556#page-16) or the MS-UPN SAN for which name constraints have either not been defined or not been published, so that support for name constraints for such names is fairly unlikely exist in the installed base, yet the only reason to put alternate subject names into certs is to use them (and exclusively) for authentication. -Martin _______________________________________________ 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 iesg-secretary@ietf.org Fri Apr 6 08:45:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C84121F8587; Fri, 6 Apr 2012 08:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Q9Anxlxb7TV; Fri, 6 Apr 2012 08:45:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1FC21F8548; Fri, 6 Apr 2012 08:45:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120406154510.5676.88819.idtracker@ietfa.amsl.com> Date: Fri, 06 Apr 2012 08:45:10 -0700 Cc: pkix@ietf.org Subject: [pkix] Last Call: (S/MIME Capabilities for Public Key Definitions) to Informational RFC X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 15:45:11 -0000 The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'S/MIME Capabilities for Public Key Definitions' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a set of S/MIME Capability types for ASN.1 encoding for the current set of public keys define in the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. An example of where this is used is with the OCSP Agility draft. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pkix-pubkey-caps/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pkix-pubkey-caps/ballot/ No IPR declarations have been submitted directly on this I-D. From DPKemp@missi.ncsc.mil Fri Apr 6 09:01:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6D421F850D for ; Fri, 6 Apr 2012 09:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgKpGVnfiMSg for ; Fri, 6 Apr 2012 09:01:31 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 95D6021F8501 for ; Fri, 6 Apr 2012 09:01:31 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q36G1VTR011389 for ; Fri, 6 Apr 2012 12:01:31 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Apr 2012 12:01:31 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 6 Apr 2012 12:00:40 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0T/U73QY80M3MTQ+6rfwnQYuGfQwADZvTg References: From: "Kemp, David P." To: X-OriginalArrivalTime: 06 Apr 2012 16:01:31.0132 (UTC) FILETIME=[883BA3C0:01CD140E] Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 16:01:32 -0000 Marking it critical has nothing to do with a cargo-cult desire to worship a spec without making any changes. It has to do with secure operation of the Internet (where both "secure" and "operate" are important). If 100% of CAs and 90% of RPs follow the existing spec calling for marking the extension critical, a CA that issues a forged certificate (for a server in some other CA's authorized namespace), 90% of RPs will correctly detect the forgery and 10% will correctly reject the certificate and ask the user for guidance because they cannot determine whether it is forged or not. With the same RP population, if 100% of CAs mark the extension non-critical, 90% of RPs will detect the forgery because they can, and 10% of RPs will accept the forged certificate without any hint to the user that something fishy is going on. In my book "correct" behavior is detecting a forgery and asking the user whether to proceed anyway. That is the technical, not religious, reason for marking the extension critical. When you change the RP percentage to 40% non-compliant applications from a sexy, popular supplier, it changes the market dynamics for whether CAs should mark the extension critical. CAs have good justification for weighting "operate without inconveniencing casual users" more highly than "secure" in that situation. But it does not change the specification of the correct way to achieve both interoperability and security. Dave -----Original Message----- From: Phillip Hallam-Baker I still have not heard anyone give a good reason for marking the extension critical in this application. From hallam@gmail.com Fri Apr 6 09:54:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB85D21F85F8 for ; Fri, 6 Apr 2012 09:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0PUYGU1tROm for ; Fri, 6 Apr 2012 09:54:48 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A14F21F85ED for ; Fri, 6 Apr 2012 09:54:48 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3770751obb.31 for ; Fri, 06 Apr 2012 09:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1zuoZ67CsbHA3ViLxOYfP+Oj8VBNQcy6LZyNZi0aR0I=; b=oqAOqKzjdiNqm+gUqLjJAu2Ga8s1gzsh//J2LkqDpeYNfk4IL+5UOIrGRAgMR904/8 0ZkAlrBUVT4SIbiJ7coNqxB6lbwp0r0PSr3mvU+VmYeWXb2zdJV9/w6pHA2hoaSrwMFr Z3/aVzg0/TzmgCQN8rafRkF40CiHkKUVJr0EHUNoa1wZOV6Ywlb7uGgMSlDU7SEts/KE pMxrRwrQOOFYDb5eKDCWQ2OwqLLSRNOcb18GPdMJQudZrxlc6fa69ls1GWOEAjlUL7JM TB5mkOpUfm9/MayhVo67Gu7N2GLyZBTw371knxmUAeFQB/MrX1wJ1K6/t1LNZSL23STe 4GTw== MIME-Version: 1.0 Received: by 10.182.202.68 with SMTP id kg4mr10112481obc.42.1333731288134; Fri, 06 Apr 2012 09:54:48 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Fri, 6 Apr 2012 09:54:47 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Apr 2012 12:54:47 -0400 Message-ID: From: Phillip Hallam-Baker To: Carl Wallace Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 16:54:50 -0000 There are two approaches to a slippery slope. One is crampons the other is = skis. I have picked skis for all of us. See you at the bottom. On Fri, Apr 6, 2012 at 10:27 AM, Carl Wallace w= rote: > > On 4/6/12 9:57 AM, "Phillip Hallam-Baker" wrote: > >>I am absolutely serious. >> >>Arguing that it is more important to preserve the spec than solve real >>world problems without breaking stuff is not constructive comment in >>my view. >> >>My proposal was totally backwards compatible. Just define an extension >>to allow the OCSP servers that can to report 'certificate not issued'. >>The response was that this should be done using SCVP, a protocol the >>industry has no interest in supporting. > > There were many responses in that thread, including some that supported > your proposal and some that offered alternatives in an effort to improve > upon it. =A0My point was that your claim below about there never being > constructive discussion is false. =A0There was plenty of constructive > discussion. =A0There was no attempt to last call your email proposal. > >> >> >>Apple's implementation is 100% compliant. They are entitled to not >>implement the feature. As Russ also points out, marking an extension >>critical does not affect the semantics. > > This is simply false. =A0How is Apple's implementation compliant with > section 6 or with the next to last paragraph of section 4.2? =A0The > requirements for name constraints are not new. =A0Excellent test suites h= ave > been available for many years. =A0Many implementations get it more or les= s > right. > >> >>So what is the reason for not changing the spec here to enable the >>extension to be used? I dont see you even bother to try to answer >>that. You just assume that the simplest course is to do as little to >>the spec as possible. > > I'm indifferent to changing the spec w.r.t. criticality since, as you > note, implementations that recognize the extension must process it anyway= . > =A0I don't think the legalistic RFC2119 arguments are the least bit > persuasive and I think it's a slippery slope to start editing the spec to > accommodate incomplete or incorrect implementations. =A0Where is the harm= in > announcing the policy change, allowing a grace period of non-compliance > and working with vendors to ensure name constraints are enforced in > more/most cases? =A0The aim is to make sure name constraints are enforced= , > right? > >> >> >>The driving function here is that Mozilla are proposing making use of >>name constraints mandatory in enterprise CAs within the next few >>months. There is a clear industry consensus that this is a good idea >>provided we can arrive at an understanding of the consequences for >>deployed code and we break as little as possible. > > Understood and probably long overdue. > >> >>I would have hoped that the view of the WG was 'hey we want people to >>use name constraints, how can we make that work'. Instead we have you >>and others trying to make a point of principle on an arbitrary detail >>of the specification. >> >> >>I still have not heard anyone give a good reason for marking the >>extension critical in this application. >> >>What is going to happen here is: >> >>1) Mozilla makes name constraints a requirement >>2) CAs deploy certs with the constraints marked non-critical >>3) The PKI specifications are eventually corrected to match practice. > > Assuming the aim is for name constraints to actually be enforced, 3) migh= t > be "Applications add support for enforcing name constraints." =A0That the > internet PKI has been operated with minimal constraints so long is the > problem. =A0Carving out room to continue lousy practices is not really th= e > answer. > >> >>The only option here is what the specifications end up being called. >>If the WG learns from this outcome and becomes more reasonable then it >>is possible that we can come back into sync. But if no lessons are >>learned then we are going to end up with two PKIX specifications, the >>IETF one and the one that matters. > > Nonsense. =A0There are far more than two "PKIX specifications" kicking > around. =A0Else we'd not be having this discussion at all. > >> >> >> >>On Fri, Apr 6, 2012 at 8:52 AM, Carl Wallace >>wrote: >>> >>> On 4/6/12 8:37 AM, "Phillip Hallam-Baker" wrote: >>> >>>>How people were saying was rather more instrumental in the fork than >>>>what they were saying. I can't remember the last time I came here with >>>>a proposal and someone said 'hey how can we achieve that better'. >>>>Instead the response is always 'well thats not the way the spec works, >>>>tough noogies for you'. >>> >>> Are you serious? =A0You came here with a proposal to modify OCSP (while >>> breaking backwards compatibility) just a few weeks ago. =A0You offered = no >>> spec, just email. There was interest. =A0Discussion followed. =A0Severa= l >>>ideas >>> were floated (including alternatives that preserved backwards >>> compatibility). =A0Does such discussion not fall into the 'hey how can = we >>> achieve that better' bucket? =A0It would seem to. =A0Did you welcome su= ch >>> discussion? =A0No, you had a fit. =A0Much like this one. =A0This proble= m is >>>even >>> easier to deal with. =A0If Apple's implementation is broken (recall the >>> original comment came from someone who had not tested this and was >>>relying >>> on hearsay) they should fix it. =A0In the meantime, add something to th= e >>> Mozilla policy to allow a grace period of non-compliance with 5280 so >>>you >>> can work around the problem. =A0However, the bugs might get fixed faste= r >>>if, >>> for example, Android is working fine and iOS is not. >>> >>> >>>> >>>>If you understood why I was bothered you would apologize to me and the >>>>group for your behavior. >>>> >>>>Participation in PKIX has shrunk because people just don't like >>>>interacting with a group that is considered to be needlessly >>>>obstructionist and sinks to personal insults to drive people away. >>>> >>>>I do not pull rank except when I see others doing so. >>>> >>>> >>>> >>>>On Fri, Apr 6, 2012 at 7:45 AM, Santosh Chokhani >>>> >>>>wrote: >>>>> PHB, >>>>> >>>>> I understand why you are bothered. >>>>> >>>>> My advice to you is focus on what is being said and not on who is >>>>>saying it. >>>>> >>>>> -----Original Message----- >>>>> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >>>>> Sent: Thursday, April 05, 2012 9:02 PM >>>>> To: Santosh Chokhani >>>>> Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.org >>>>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>>>>Name >>>>> >>>>> Santosh, >>>>> >>>>> As I stated in my message to the ADs explaining the reason why we are >>>>>breaking from the PKIX work, your role has been corrosive here. I do >>>>>not >>>>>mind people attacking me, but I see you all behaving like a bunch of >>>>>high school heathers attacking anyone else you disagree with in the >>>>>same >>>>>terms. >>>>> >>>>> >>>>> I don't particularly see that I have a need to justify my credentials >>>>>to you. In fact I am really not aware of any substantial contribution >>>>>you have made to the field, positive or negative. I value the opinion >>>>>of >>>>>the people I have worked with, a list that includes multiple Turing >>>>>award winners besides many other notable contributors to the field. I >>>>>do >>>>>not value the opinion of people who attempt to preen themselves by >>>>>putting other down. >>>>> >>>>> You are certainly not the only person that gets security here, not by >>>>>a >>>>>long way. In fact I would suggest that anyone who argues in the fashio= n >>>>>you do, through appeals to their own authority are the people who >>>>>'don't >>>>>get it'. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Apr 5, 2012 at 8:48 PM, Santosh Chokhani >>>>> wrote: >>>>>> PHB, >>>>>> >>>>>> You should do what you deem appropriate. >>>>>> >>>>>> My recommendation is for 5280 and those who get security. >>>>>> >>>>>> BTW, this is not the second time, it is umpteenth time and third tim= e >>>>>>in recent memory. =A0I suppose you rather forget about that e-mail ab= out >>>>>>EC DH parameters asserted by a cross certified CA. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >>>>>> Sent: Thursday, April 05, 2012 7:31 PM >>>>>> To: Santosh Chokhani >>>>>> Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; paul.hoffman@vpnc.or= g >>>>>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>>>>> Name >>>>>> >>>>>> Santosh, >>>>>> >>>>>> This is the second time that you have tried to pull rank on other >>>>>>members of the working group in the past month. I should point out >>>>>>that >>>>>>in my view you are really not qualified to pull rank as you appear to >>>>>>believe you are entitled. >>>>>> >>>>>> If you cannot treat others here with respect I suggest that the >>>>>>chairs >>>>>>inform you that your contributions are no longer desirable. >>>>>> >>>>>> >>>>>> The security issue here is that we cannot issue a certificate that >>>>>>does not work with the deployed Apple clients. Thus the only way it i= s >>>>>>possible to use the name constraints is to make them non-critical. >>>>>> Therefore this is what we are going to be doing. >>>>>> >>>>>> The proposal is to fix an obvious bug in the specification to meet a >>>>>>real world operational requirement. >>>>>> >>>>>> >>>>>> On Mon, Apr 2, 2012 at 1:17 PM, Santosh Chokhani >>>>>> wrote: >>>>>>> Martin, >>>>>>> >>>>>>> You miss the security implication of this. >>>>>>> >>>>>>> CA can always make it NC and the clients that do not process name >>>>>>>constraints will be exposed if the Sub CA is rogue, compromised or >>>>>>>RAs >>>>>>>it trusts go rouge or are compromised. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behal= f >>>>>>> Of Martin Rex >>>>>>> Sent: Monday, April 02, 2012 1:14 PM >>>>>>> To: Erwann Abalea >>>>>>> Cc: pkix@ietf.org; paul.hoffman@vpnc.org >>>>>>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>>>>>> Name >>>>>>> >>>>>>> Erwann Abalea wrote: >>>>>>>> >>>>>>>> > To me, that looks like a >>>>>>>> > perfectly valid request, and PKIX (rfc5280) is in violation of >>>>>>>> > rfc2119 of requiring this extension to be always made critical b= y >>>>>>>> > the CA (instead of leaving that decision to the CA to express it= s >>>>>>>> > intention). >>>>>>>> > >>>>>>>> >>>>>>>> How could PKIX be in violation of anything by requiring the >>>>>>>> extension to be critical, and why the RFC2119? Is PKIX also in >>>>>>>> violation of >>>>>>>> RFC2119 when requiring the serial number to be a positive integer >>>>>>>> not longer than 20 octets? >>>>>>> >>>>>>> http://tools.ietf.org/html/rfc2119#section-6 >>>>>>> >>>>>>> =A0 6. Guidance in the use of these Imperatives >>>>>>> >>>>>>> =A0 Imperatives of the type defined in this memo must be used with >>>>>>>care >>>>>>> =A0 and sparingly. =A0In particular, they MUST only be used where i= t is >>>>>>> =A0 actually required for interoperation or to limit behavior which >>>>>>>has >>>>>>> =A0 potential for causing harm (e.g., limiting retransmisssions) = =A0For >>>>>>> =A0 example, they must not be used to try to impose a particular >>>>>>>method >>>>>>> =A0 on implementors where the method is not required for >>>>>>> =A0 interoperability. >>>>>>> >>>>>>> >>>>>>> Requiring a CA to always make name constraints critical will very >>>>>>>probably impair/break interop with implementations that do not >>>>>>>support >>>>>>>that particular type of name constraints. >>>>>>> >>>>>>> Since the CA is the entity which defines the policy of whether RPs >>>>>>> enforcing this name constraints is a problem or not, the MUST can >>>>>>> *NOT* be justified with security. =A0There for the "MUST always be >>>>>>>critical" >>>>>>> in rfc5280 is a clear violation of rfc2119 and therefore NULL and >>>>>>>VOID. >>>>>>> That is pretty simple math. >>>>>>> >>>>>>> The only reason that this is there is a desire for some >>>>>>>organizations >>>>>>>to procure specific features in COTS, rather than having to pay extr= a >>>>>>>for it. =A0Deserves to be ignored by the marketplace. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The discussion of the purpose of both critical and non-critical use= s >>>>>>>of a constraints extension is much more reasonably explained here: >>>>>>> >>>>>>> =A0http://tools.ietf.org/html/rfc3647#section-3.3.1 >>>>>>> >>>>>>> and the very same reasoning can be applied to name constraints. >>>>>>> It must be up to the CA that puts name constraints into a subCA cer= t >>>>>>>to determine whether these should be critical or not. =A0It is inval= id >>>>>>>for rfc5280 to unconditionally require name constraints to be marked >>>>>>>critical by CAs. >>>>>>> >>>>>>> >>>>>>> -Martin >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Website: http://hallambaker.com/ >>>>> >>>>> >>>>> >>>>> -- >>>>> Website: http://hallambaker.com/ >>>> >>>> >>>> >>>>-- >>>>Website: http://hallambaker.com/ >>>>_______________________________________________ >>>>pkix mailing list >>>>pkix@ietf.org >>>>https://www.ietf.org/mailman/listinfo/pkix >>> >>> >> >> >> >>-- >>Website: http://hallambaker.com/ > > --=20 Website: http://hallambaker.com/ From carl@redhoundsoftware.com Fri Apr 6 10:16:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D040021F860E for ; Fri, 6 Apr 2012 10:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yetIbYMmWmxm for ; Fri, 6 Apr 2012 10:16:02 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6206C21F85F8 for ; Fri, 6 Apr 2012 10:16:02 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1788236qcs.31 for ; Fri, 06 Apr 2012 10:16:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=AyDTywfHBohWM4c6ZRunjuhENag1NhoongDkWQwSs2M=; b=WH2A6ckk+KASjXgVmilDbeAxEiT+zrCkwnnM5FT0X1BQVUjzijYZHmrqoLRrnqUlVQ BRKW1Elg6xfT3QvFVgX3jcIpQBl2PxIQJUNSYGa0Ceaskx6ITJbpuhoH7yji4/NeiWD9 NYCnY7mgtDHb3+WkIW2ChQL1SEBYEXtxXpLD0BaByxpZgty+n9i5aLqLGkqHfZduELoU lt32Hb112A3spiGVsqIk6b8SaSTRMqTmF1MgH+Vvl0CbL45+RHWa9zx2MjnhAGQVV+1k KnyRvk87H8+m8L4zMBJAmcQiOCLsqNOm2ttvOZfDMxTEIVQQsHTYM0Kemqk02Rgl+DCD RKeg== Received: by 10.224.105.65 with SMTP id s1mr10131723qao.75.1333732561867; Fri, 06 Apr 2012 10:16:01 -0700 (PDT) Received: from [192.168.1.4] (pool-173-79-133-63.washdc.fios.verizon.net. [173.79.133.63]) by mx.google.com with ESMTPS id m6sm11741012qah.2.2012.04.06.10.16.00 (version=SSLv3 cipher=OTHER); Fri, 06 Apr 2012 10:16:01 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 06 Apr 2012 13:16:01 -0400 From: Carl Wallace To: Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQk/Je1H4VFClNW9pbRSRZvsA9jVF7fciVDfeOwSa8h1BKdFq7oRm1zpEHtLyGYpgJpfC3wx Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 17:16:03 -0000 Indeed. Enjoy the race. On 4/6/12 12:54 PM, "Phillip Hallam-Baker" wrote: >There are two approaches to a slippery slope. One is crampons the other >is skis. > >I have picked skis for all of us. See you at the bottom. > > >On Fri, Apr 6, 2012 at 10:27 AM, Carl Wallace >wrote: >> >> On 4/6/12 9:57 AM, "Phillip Hallam-Baker" wrote: >> >>>I am absolutely serious. >>> >>>Arguing that it is more important to preserve the spec than solve real >>>world problems without breaking stuff is not constructive comment in >>>my view. >>> >>>My proposal was totally backwards compatible. Just define an extension >>>to allow the OCSP servers that can to report 'certificate not issued'. >>>The response was that this should be done using SCVP, a protocol the >>>industry has no interest in supporting. >> >> There were many responses in that thread, including some that supported >> your proposal and some that offered alternatives in an effort to improve >> upon it. My point was that your claim below about there never being >> constructive discussion is false. There was plenty of constructive >> discussion. There was no attempt to last call your email proposal. >> >>> >>> >>>Apple's implementation is 100% compliant. They are entitled to not >>>implement the feature. As Russ also points out, marking an extension >>>critical does not affect the semantics. >> >> This is simply false. How is Apple's implementation compliant with >> section 6 or with the next to last paragraph of section 4.2? The >> requirements for name constraints are not new. Excellent test suites >>have >> been available for many years. Many implementations get it more or less >> right. >> >>> >>>So what is the reason for not changing the spec here to enable the >>>extension to be used? I dont see you even bother to try to answer >>>that. You just assume that the simplest course is to do as little to >>>the spec as possible. >> >> I'm indifferent to changing the spec w.r.t. criticality since, as you >> note, implementations that recognize the extension must process it >>anyway. >> I don't think the legalistic RFC2119 arguments are the least bit >> persuasive and I think it's a slippery slope to start editing the spec >>to >> accommodate incomplete or incorrect implementations. Where is the harm >>in >> announcing the policy change, allowing a grace period of non-compliance >> and working with vendors to ensure name constraints are enforced in >> more/most cases? The aim is to make sure name constraints are enforced, >> right? >> >>> >>> >>>The driving function here is that Mozilla are proposing making use of >>>name constraints mandatory in enterprise CAs within the next few >>>months. There is a clear industry consensus that this is a good idea >>>provided we can arrive at an understanding of the consequences for >>>deployed code and we break as little as possible. >> >> Understood and probably long overdue. >> >>> >>>I would have hoped that the view of the WG was 'hey we want people to >>>use name constraints, how can we make that work'. Instead we have you >>>and others trying to make a point of principle on an arbitrary detail >>>of the specification. >>> >>> >>>I still have not heard anyone give a good reason for marking the >>>extension critical in this application. >>> >>>What is going to happen here is: >>> >>>1) Mozilla makes name constraints a requirement >>>2) CAs deploy certs with the constraints marked non-critical >>>3) The PKI specifications are eventually corrected to match practice. >> >> Assuming the aim is for name constraints to actually be enforced, 3) >>might >> be "Applications add support for enforcing name constraints." That the >> internet PKI has been operated with minimal constraints so long is the >> problem. Carving out room to continue lousy practices is not really the >> answer. >> >>> >>>The only option here is what the specifications end up being called. >>>If the WG learns from this outcome and becomes more reasonable then it >>>is possible that we can come back into sync. But if no lessons are >>>learned then we are going to end up with two PKIX specifications, the >>>IETF one and the one that matters. >> >> Nonsense. There are far more than two "PKIX specifications" kicking >> around. Else we'd not be having this discussion at all. >> >>> >>> >>> >>>On Fri, Apr 6, 2012 at 8:52 AM, Carl Wallace >>>wrote: >>>> >>>> On 4/6/12 8:37 AM, "Phillip Hallam-Baker" wrote: >>>> >>>>>How people were saying was rather more instrumental in the fork than >>>>>what they were saying. I can't remember the last time I came here with >>>>>a proposal and someone said 'hey how can we achieve that better'. >>>>>Instead the response is always 'well thats not the way the spec works, >>>>>tough noogies for you'. >>>> >>>> Are you serious? You came here with a proposal to modify OCSP (while >>>> breaking backwards compatibility) just a few weeks ago. You offered >>>>no >>>> spec, just email. There was interest. Discussion followed. Several >>>>ideas >>>> were floated (including alternatives that preserved backwards >>>> compatibility). Does such discussion not fall into the 'hey how can >>>>we >>>> achieve that better' bucket? It would seem to. Did you welcome such >>>> discussion? No, you had a fit. Much like this one. This problem is >>>>even >>>> easier to deal with. If Apple's implementation is broken (recall the >>>> original comment came from someone who had not tested this and was >>>>relying >>>> on hearsay) they should fix it. In the meantime, add something to the >>>> Mozilla policy to allow a grace period of non-compliance with 5280 so >>>>you >>>> can work around the problem. However, the bugs might get fixed faster >>>>if, >>>> for example, Android is working fine and iOS is not. >>>> >>>> >>>>> >>>>>If you understood why I was bothered you would apologize to me and the >>>>>group for your behavior. >>>>> >>>>>Participation in PKIX has shrunk because people just don't like >>>>>interacting with a group that is considered to be needlessly >>>>>obstructionist and sinks to personal insults to drive people away. >>>>> >>>>>I do not pull rank except when I see others doing so. >>>>> >>>>> >>>>> >>>>>On Fri, Apr 6, 2012 at 7:45 AM, Santosh Chokhani >>>>> >>>>>wrote: >>>>>> PHB, >>>>>> >>>>>> I understand why you are bothered. >>>>>> >>>>>> My advice to you is focus on what is being said and not on who is >>>>>>saying it. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >>>>>> Sent: Thursday, April 05, 2012 9:02 PM >>>>>> To: Santosh Chokhani >>>>>> Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; >>>>>>paul.hoffman@vpnc.org >>>>>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>>>>>Name >>>>>> >>>>>> Santosh, >>>>>> >>>>>> As I stated in my message to the ADs explaining the reason why we >>>>>>are >>>>>>breaking from the PKIX work, your role has been corrosive here. I do >>>>>>not >>>>>>mind people attacking me, but I see you all behaving like a bunch of >>>>>>high school heathers attacking anyone else you disagree with in the >>>>>>same >>>>>>terms. >>>>>> >>>>>> >>>>>> I don't particularly see that I have a need to justify my >>>>>>credentials >>>>>>to you. In fact I am really not aware of any substantial contribution >>>>>>you have made to the field, positive or negative. I value the opinion >>>>>>of >>>>>>the people I have worked with, a list that includes multiple Turing >>>>>>award winners besides many other notable contributors to the field. I >>>>>>do >>>>>>not value the opinion of people who attempt to preen themselves by >>>>>>putting other down. >>>>>> >>>>>> You are certainly not the only person that gets security here, not >>>>>>by >>>>>>a >>>>>>long way. In fact I would suggest that anyone who argues in the >>>>>>fashion >>>>>>you do, through appeals to their own authority are the people who >>>>>>'don't >>>>>>get it'. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 5, 2012 at 8:48 PM, Santosh Chokhani >>>>>> wrote: >>>>>>> PHB, >>>>>>> >>>>>>> You should do what you deem appropriate. >>>>>>> >>>>>>> My recommendation is for 5280 and those who get security. >>>>>>> >>>>>>> BTW, this is not the second time, it is umpteenth time and third >>>>>>>time >>>>>>>in recent memory. I suppose you rather forget about that e-mail >>>>>>>about >>>>>>>EC DH parameters asserted by a cross certified CA. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >>>>>>> Sent: Thursday, April 05, 2012 7:31 PM >>>>>>> To: Santosh Chokhani >>>>>>> Cc: mrex@sap.com; Erwann Abalea; pkix@ietf.org; >>>>>>>paul.hoffman@vpnc.org >>>>>>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>>>>>> Name >>>>>>> >>>>>>> Santosh, >>>>>>> >>>>>>> This is the second time that you have tried to pull rank on other >>>>>>>members of the working group in the past month. I should point out >>>>>>>that >>>>>>>in my view you are really not qualified to pull rank as you appear >>>>>>>to >>>>>>>believe you are entitled. >>>>>>> >>>>>>> If you cannot treat others here with respect I suggest that the >>>>>>>chairs >>>>>>>inform you that your contributions are no longer desirable. >>>>>>> >>>>>>> >>>>>>> The security issue here is that we cannot issue a certificate that >>>>>>>does not work with the deployed Apple clients. Thus the only way it >>>>>>>is >>>>>>>possible to use the name constraints is to make them non-critical. >>>>>>> Therefore this is what we are going to be doing. >>>>>>> >>>>>>> The proposal is to fix an obvious bug in the specification to meet >>>>>>>a >>>>>>>real world operational requirement. >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 2, 2012 at 1:17 PM, Santosh Chokhani >>>>>>> wrote: >>>>>>>> Martin, >>>>>>>> >>>>>>>> You miss the security implication of this. >>>>>>>> >>>>>>>> CA can always make it NC and the clients that do not process name >>>>>>>>constraints will be exposed if the Sub CA is rogue, compromised or >>>>>>>>RAs >>>>>>>>it trusts go rouge or are compromised. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On >>>>>>>>Behalf >>>>>>>> Of Martin Rex >>>>>>>> Sent: Monday, April 02, 2012 1:14 PM >>>>>>>> To: Erwann Abalea >>>>>>>> Cc: pkix@ietf.org; paul.hoffman@vpnc.org >>>>>>>> Subject: Re: [pkix] Proposal: Change the Criticality Requirement >>>>>>>>of >>>>>>>> Name >>>>>>>> >>>>>>>> Erwann Abalea wrote: >>>>>>>>> >>>>>>>>> > To me, that looks like a >>>>>>>>> > perfectly valid request, and PKIX (rfc5280) is in violation of >>>>>>>>> > rfc2119 of requiring this extension to be always made critical >>>>>>>>>by >>>>>>>>> > the CA (instead of leaving that decision to the CA to express >>>>>>>>>its >>>>>>>>> > intention). >>>>>>>>> > >>>>>>>>> >>>>>>>>> How could PKIX be in violation of anything by requiring the >>>>>>>>> extension to be critical, and why the RFC2119? Is PKIX also in >>>>>>>>> violation of >>>>>>>>> RFC2119 when requiring the serial number to be a positive integer >>>>>>>>> not longer than 20 octets? >>>>>>>> >>>>>>>> http://tools.ietf.org/html/rfc2119#section-6 >>>>>>>> >>>>>>>> 6. Guidance in the use of these Imperatives >>>>>>>> >>>>>>>> Imperatives of the type defined in this memo must be used with >>>>>>>>care >>>>>>>> and sparingly. In particular, they MUST only be used where it >>>>>>>>is >>>>>>>> actually required for interoperation or to limit behavior which >>>>>>>>has >>>>>>>> potential for causing harm (e.g., limiting retransmisssions) >>>>>>>>For >>>>>>>> example, they must not be used to try to impose a particular >>>>>>>>method >>>>>>>> on implementors where the method is not required for >>>>>>>> interoperability. >>>>>>>> >>>>>>>> >>>>>>>> Requiring a CA to always make name constraints critical will very >>>>>>>>probably impair/break interop with implementations that do not >>>>>>>>support >>>>>>>>that particular type of name constraints. >>>>>>>> >>>>>>>> Since the CA is the entity which defines the policy of whether RPs >>>>>>>> enforcing this name constraints is a problem or not, the MUST can >>>>>>>> *NOT* be justified with security. There for the "MUST always be >>>>>>>>critical" >>>>>>>> in rfc5280 is a clear violation of rfc2119 and therefore NULL and >>>>>>>>VOID. >>>>>>>> That is pretty simple math. >>>>>>>> >>>>>>>> The only reason that this is there is a desire for some >>>>>>>>organizations >>>>>>>>to procure specific features in COTS, rather than having to pay >>>>>>>>extra >>>>>>>>for it. Deserves to be ignored by the marketplace. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The discussion of the purpose of both critical and non-critical >>>>>>>>uses >>>>>>>>of a constraints extension is much more reasonably explained here: >>>>>>>> >>>>>>>> http://tools.ietf.org/html/rfc3647#section-3.3.1 >>>>>>>> >>>>>>>> and the very same reasoning can be applied to name constraints. >>>>>>>> It must be up to the CA that puts name constraints into a subCA >>>>>>>>cert >>>>>>>>to determine whether these should be critical or not. It is >>>>>>>>invalid >>>>>>>>for rfc5280 to unconditionally require name constraints to be >>>>>>>>marked >>>>>>>>critical by CAs. >>>>>>>> >>>>>>>> >>>>>>>> -Martin >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Website: http://hallambaker.com/ >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Website: http://hallambaker.com/ >>>>> >>>>> >>>>> >>>>>-- >>>>>Website: http://hallambaker.com/ >>>>>_______________________________________________ >>>>>pkix mailing list >>>>>pkix@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/pkix >>>> >>>> >>> >>> >>> >>>-- >>>Website: http://hallambaker.com/ >> >> > > > >-- >Website: http://hallambaker.com/ From david.cooper@nist.gov Fri Apr 6 10:49:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEC321F8610 for ; Fri, 6 Apr 2012 10:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93RZgIjDgFvy for ; Fri, 6 Apr 2012 10:49:40 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id C1A8221F860B for ; Fri, 6 Apr 2012 10:49:40 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q36HnTRY019146; Fri, 6 Apr 2012 13:49:29 -0400 Message-ID: <4F7F2CA9.2050200@nist.gov> Date: Fri, 06 Apr 2012 13:49:29 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: Santosh Chokhani , "pkix@ietf.org" References: from "Stephen Kent" at Apr 5, 12 01:54:50 pm <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 17:49:41 -0000 On 04/06/2012 10:52 AM, Santosh Chokhani wrote: > 2. If the name constraint is critical and you do not recognize one or more name forms, accept the certificate if none of the unrecognized name forms appear in the certification path, else reject the certificate. (this is against the RFC, but I see no harm) Santosh, Actually, this not against the RFC: If a name constraints extension that is marked as critical imposes constraints on a particular name form, and an instance of that name form appears in the subject field or subjectAltName extension of a subsequent certificate, then the application MUST either process the constraint or reject the certificate. From SChokhani@cygnacom.com Fri Apr 6 10:58:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599C221F8623 for ; Fri, 6 Apr 2012 10:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maQjyf3EvwhR for ; Fri, 6 Apr 2012 10:58:33 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id B39F221F8514 for ; Fri, 6 Apr 2012 10:58:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,381,1330923600"; d="scan'208";a="715525" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 06 Apr 2012 13:58:21 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 6 Apr 2012 13:58:20 -0400 From: Santosh Chokhani To: "David A. Cooper" , "pkix@ietf.org" Date: Fri, 6 Apr 2012 13:58:18 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0UHaQUPJo1h+wZQ8qXBD2/V1ptjAAAR6cQ Message-ID: References: from "Stephen Kent" at Apr 5, 12 01:54:50 pm <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> <4F7F2CA9.2050200@nist.gov> In-Reply-To: <4F7F2CA9.2050200@nist.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 17:58:34 -0000 David, Thanks for correcting me. I read the same language, but must have skipped = over part of the sentence. -----Original Message----- From: David A. Cooper [mailto:david.cooper@nist.gov]=20 Sent: Friday, April 06, 2012 1:49 PM To: Santosh Chokhani; pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name On 04/06/2012 10:52 AM, Santosh Chokhani wrote: > 2. If the name constraint is critical and you do not recognize one or mo= re name forms, accept the certificate if none of the unrecognized name form= s appear in the certification path, else reject the certificate. (this is = against the RFC, but I see no harm) Santosh, Actually, this not against the RFC: If a name constraints extension that is marked as critical imposes constraints on a particular name form, and an instance of that name form appears in the subject field or subjectAltName extension of a subsequent certificate, then the application MUST either process the constraint or reject the certificate. From hallam@gmail.com Fri Apr 6 11:41:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCCB21F8645 for ; Fri, 6 Apr 2012 11:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFMz3yHJ-wka for ; Fri, 6 Apr 2012 11:40:59 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFEC21F8644 for ; Fri, 6 Apr 2012 11:40:59 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3889432obb.31 for ; Fri, 06 Apr 2012 11:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tx64DuFQ28li1k5pFcDczF4iw5s4fnaS0ZPzthWmUu8=; b=v0SvL+26x9mUipwt1NXn5GOte4mzUiSDm+xgEwzT+L3o5IeT6n0NMpMCJIvlOL5HMi Yp+jlsEu37rjKCcRFQUFvskyZit0M5Gsq+9dYcz/56MvTJlZ/haornw8S/SaKgrcjroJ ydAn2HM3DGrnMgd8nvTcAEsXmg90aiar0IGX7KvYSmDlSFCkebVJzt8oj8t9gz7wp1lm TIhdAN9hA1m5fnTWjeB1cy9WS6r0MsuYLfHXcCQSKQMwfj4yoYEzkDHrcjpX9eLsuXS3 fxnavGfOYVvIxTnegCcpJ6Oxg7WlCIWWeBf2lbKsoVUu+k3eqplpFQeVVL2Vmk4wrDz9 NmoQ== MIME-Version: 1.0 Received: by 10.182.202.68 with SMTP id kg4mr10536916obc.42.1333737658592; Fri, 06 Apr 2012 11:40:58 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Fri, 6 Apr 2012 11:40:58 -0700 (PDT) In-Reply-To: References: <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> Date: Fri, 6 Apr 2012 14:40:58 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 18:41:00 -0000 As has been pointed out by Russ the specification requires that the client process all extensions that it understands regardless of whether they are marked critical or not. The only function of the critical flag is to specify cases in which it is desirable for a client to break rather than accept a certificate it may not understand correctly. Since we want the opposite behavior here there is no reason to mark the extension critical. So your example 3 describes a client that is non-compliant with the specification. On Fri, Apr 6, 2012 at 10:52 AM, Santosh Chokhani wrote: > Tom, > > In my reading 5280 is reasonably clear. =A0It could always be made cleare= r. > > I would consider the following implementations secure: > > 1. =A0If the name constraint is critical and you do not recognize one or = more name forms, reject the certificate. > > 2. =A0If the name constraint is critical and you do not recognize one or = more name forms, accept the certificate if none of the unrecognized name fo= rms appear in the certification path, else reject the certificate. =A0(this= is against the RFC, but I see no harm) > > 3, =A0If the name constraint is non-critical and you do not recognize one= or more name forms, accept the certificate. > > I agree that there is some ambiguity in terms of application behavior if = you assume that application behavior must be the same regardless of critica= lity if an extension is recognized. =A0This is due to inability to process = all name forms. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of T= om Gindin > Sent: Thursday, April 05, 2012 9:31 PM > To: mrex@sap.com > Cc: pkix@ietf.org > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > > =A0 =A0 =A0 =A0Martin: > > =A0 =A0 =A0 =A0Actually, the way in which name constraints are most clear= ly underspecified is their handling of x400Address. =A0Implementers MUST be= able to process one of the GeneralName forms, and SHOULD be able to proces= s four more. =A0Three of the remaining four forms are explicitly excluded f= rom this specification, but there's no reference to how x400Address should = be processed (if anyone still uses it) although there's a SHOULD NOT for th= e CA putting in a name constraint of that form. > =A0 =A0 =A0 =A0I think that an RP is conformant if it simply rejects any = certificate whose subject Alt Name has a member of type x400Address, if eit= her permitted_subtrees or excluded_subtrees have any member of type x400Add= ress during the processing of section 6.1.3 B and C. =A0I have no idea whet= her it's intended that having permitted_subtrees contain organization-name = but not teletex-organization-name means that names with teletex-organizatio= n-name (an Extension attribute) should be banned. =A0I suspect that it is, = and I wonder how many RP's enforce anything like that. > =A0 =A0 =A0 =A0In your examples, you'd have to restrict the name forms to= ones covered by permitted subtrees. =A0Otherwise, CA's could put in a sing= le excluded subtree of each name form, covering entities which no longer ex= ist or an IP which can't be routed. =A0Those are constraints, but they prot= ect very little. > > Tom Gindin > > P.S. - The opinions above are mine, and not necessarily those of my emplo= yer. > > > > > > From: =A0 Martin Rex > To: =A0 =A0 kent@bbn.com (Stephen Kent), > Cc: =A0 =A0 pkix@ietf.org > Date: =A0 04/05/2012 08:04 PM > Subject: =A0 =A0 =A0 =A0Re: [pkix] Proposal: Change the Criticality Requi= rement of > Name > Sent by: =A0 =A0 =A0 =A0pkix-bounces@ietf.org > > > > Stephen Kent wrote: >> >> > >> >Correct, name constraints as "envisioned" by rfc5280 are unusable, >> >in case that you find yourself unable to ignore that invalid MUST. >> >> nonsense. name constraints can be used in any PKI where there there >> are clear lines of authority for issuing certs relative to a name >> space. =A0The fact that the public TTP trust model, at the top, does >> not meet that criterion, is merely an indication of a collision >> between a business model and technology. > > > To me it appears that name constraints might be underspecified. > From how I understand the design of X.509, subject Name and > subjectAltNames > are alternative unique representations of the name of the subject. > So in order to use name constraints securely, all name forms present > in a cert would have to be subject to constraints, and all unconstrained > name forms would have to be unconditionally ignored, otherwise the > constraints could be evaded. > > looking at this example structure > (using "aaaa" instead of "com" to avoid collisions with mapped DNS space) > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 well-known trust anchor > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CN=3Dpremium subCA, O=3DpubTC, C=3DY > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 public subCA > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0= \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0\ > =A0CN=3Dorg-CA, OU=3DFoo, O=3DpubTC, C=3DY =A0 =A0CN=3Dorg-CA, OU=3DBar, = O=3DpubTC, C=3DY > =A0 =A0 =A0 =A0organizational subCA FOO =A0 =A0 =A0organizational subCA B= AR > =A0 =A0 =A0 =A0with name constraint on =A0 =A0 =A0 with name constraint o= n > =A0 =A0 =A0 =A0 dNSName SAN "foo.aaaa" =A0 =A0 =A0 =A0dnsName SAN "bar.aa= aa" > > What is lacking in this example is name constraints on the subject name > (DirectoryName). =A0Without it, certain certificate processing, based on > an unconstrained name forms, can evade the name constraints. > > e.g. what about the Bar org-CA issuing a CRL-signer cert (non-CA cert) > with a subject DName of the Foo org-CA and using it to fabricate CRLs > (with an AIA extension in the CRL, distinguishing the "forged" > CRL signer cert from the real Foo org-CA cert by including and > AuthKeyID and AIA CRL extensions (plus the IssuingDP CRL extension > that RPs expect) ? > > Such a concoction would fulfil the "CRL Signer cert must validate > under the same trust anchor" requirement. =A0And PKIX software that > is bold enough to perform forward path discovery based on AIA for the > CRL signer might be tricked to accept CRLs forged by org-CA Bar during > validation of certs issued by org-CA Foo, I assume. > > Another problem arises from the fact that there may exist SANs > (such as KRB5PrincipalName =A0http://tools.ietf.org/html/rfc4556#page-16) > or the MS-UPN SAN for which name constraints have either not been > defined or not been published, so that support for name constraints > for such names is fairly unlikely exist in the installed base, > yet the only reason to put alternate subject names into certs is to > use them (and exclusively) for authentication. > > > -Martin > _______________________________________________ > 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 --=20 Website: http://hallambaker.com/ From hallam@gmail.com Fri Apr 6 11:44:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B990A11E808E for ; Fri, 6 Apr 2012 11:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qMRteKI+tB0 for ; Fri, 6 Apr 2012 11:44:24 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDC511E8085 for ; Fri, 6 Apr 2012 11:44:23 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3893040obb.31 for ; Fri, 06 Apr 2012 11:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CVZQXdO0CbYVZI2LLYlSX7gGJU652drDVPyhL7VmDDQ=; b=mglJnaSEN2PnRTHFihAYyHCm2TbOe+zfon7Ny+rR302jTtO3A9x5Z4UQ5oRw3aA7kI zN5l0204GQBSoJ4ZjehaATJy9DuW5bH0wF8q9Hp61z9+qS2NtNjEL0eWY3xm9/CYYhC0 QJeRpbOaw4R9VTRe9Qc2uo0YFNCxotGsmDIEhK4dW1p5uV2+2Y4LVci/2ycjwp7uXhIi yDJSr0D1Akf5Q0U4qrY8IV8t6VmDCv1n4b23WnepyQwgMZFMPLkhJKFbrRhkr27cEAHU GUWcDh3dZcppIGXPhcuWsisMuMS/jq21AKV9iuBQx+rpmStmX3oDBrU4LSWwkH5Y4oq2 B4Dg== MIME-Version: 1.0 Received: by 10.182.202.68 with SMTP id kg4mr10550188obc.42.1333737863706; Fri, 06 Apr 2012 11:44:23 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Fri, 6 Apr 2012 11:44:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Apr 2012 14:44:23 -0400 Message-ID: From: Phillip Hallam-Baker To: "Kemp, David P." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 18:44:24 -0000 The function of the critical bit is to state cases where it is better to break interoperability than accept a certificate that may be misinterpreted. This condition does not apply here. Ergo the bit shall not be set. Now maybe if you ever get to STANDARD status then you can wave it as us and tell us we are wrong but until then all you have is a Request For Comments and our comment is we intend to do what makes sense, not what is written in the DRAFT. On Fri, Apr 6, 2012 at 12:00 PM, Kemp, David P. wro= te: > Marking it critical has nothing to do with a cargo-cult desire to > worship a spec without making any changes. =A0It has to do with secure > operation of the Internet (where both "secure" and "operate" are > important). > > If 100% of CAs and 90% of RPs follow the existing spec calling for > marking the extension critical, a CA that issues a forged certificate > (for a server in some other CA's authorized namespace), 90% of RPs will > correctly detect the forgery and 10% will correctly reject the > certificate and ask the user for guidance because they cannot determine > whether it is forged or not. > > With the same RP population, if 100% of CAs mark the extension > non-critical, 90% of RPs will detect the forgery because they can, and > 10% of RPs will accept the forged certificate without any hint to the > user that something fishy is going on. > > In my book "correct" behavior is detecting a forgery and asking the user > whether to proceed anyway. =A0That is the technical, not religious, reaso= n > for marking the extension critical. > > When you change the RP percentage to 40% non-compliant applications from > a sexy, popular supplier, it changes the market dynamics for whether CAs > should mark the extension critical. =A0CAs have good justification for > weighting "operate without inconveniencing casual users" more highly > than "secure" in that situation. =A0But it does not change the > specification of the correct way to achieve both interoperability and > security. > > Dave > > > -----Original Message----- > From: Phillip Hallam-Baker > > I still have not heard anyone give a good reason for marking the > extension critical in this application. > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From hallam@gmail.com Fri Apr 6 12:14:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4211E8098 for ; Fri, 6 Apr 2012 12:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HY+kwsf3jDfd for ; Fri, 6 Apr 2012 12:14:52 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3725111E8093 for ; Fri, 6 Apr 2012 12:14:52 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3927909obb.31 for ; Fri, 06 Apr 2012 12:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OauW+kdEqE2CHGggnIkQVKgzaW0i6RLKhVCG0hqfHCA=; b=z3bQXp+Uk+QLv6ikomj4kSOPi+KJbLE04ml10IBmGXRk2T2GgQMFAcUPWknpxv2/vj 8T1j1q8hfeZ+MIozMEMljNCLCpoPahZ5WW+7cPMa3fcMYcVedBsBsVGaWKz0ojyDmQAO 6w+XEOgRmHbuw/OA3Ix4vpLKunQl+mnlsxqmCkG/TErUVL/ZHzfP+sjGR6j7Fi7GhN84 z8Z0kOFoeQPAEQJucoUA8TBdRE0T28s/S3YD/ahAB7U1M33OUhP7OUvjMTnLnpFnpcHd M+TaMAIwz6kTi1WGyY1l8QGPuKHBdkga9Lxqyl40rJDA/y6ZTyPpJFKP/W930ozkAiHR gkng== MIME-Version: 1.0 Received: by 10.60.7.200 with SMTP id l8mr10524232oea.52.1333739691746; Fri, 06 Apr 2012 12:14:51 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Fri, 6 Apr 2012 12:14:51 -0700 (PDT) In-Reply-To: <4F7F2CA9.2050200@nist.gov> References: <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> <4F7F2CA9.2050200@nist.gov> Date: Fri, 6 Apr 2012 15:14:51 -0400 Message-ID: From: Phillip Hallam-Baker To: "David A. Cooper" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 19:14:53 -0000 As I read the specifications it appears to me that they already mandate precisely the desired behavior of relying apps: * If the extension is marked critical and not understood, reject the cert * If the extension is understood and present it MUST be processed [or the cert rejected]. The only part that there is a problem with is the instruction that the name constraints MUST be marked critical. Drop that down to a SHOULD and the problem goes away completely. Note that while a client app could in theory reject a cert if there is a name constraint present and not marked critical that this is not a requirement of the spec. The fact that a cert is not compliant with the PKIX profile does not mean it has to be rejected. As Martin points out, this particular MUST is not motivated by a security requirement, nor is it motivated by an interoperability requirement. The only valid reason for not changing the spec that I can see is that the group would like to avoid the IETF overhead that would incur. So now we have got to the point where a major browser provider is going to mandate a non-PKIX compliant profile as a pre-condition for inclusion in their root program. I am not trying to persuade here. I am merely trying to impress upon you all that what is about to happen is entirely your fault and that being unreasonable has consequences. On Fri, Apr 6, 2012 at 1:49 PM, David A. Cooper wro= te: > > On 04/06/2012 10:52 AM, Santosh Chokhani wrote: >> >> 2. =A0If the name constraint is critical and you do not recognize one or >> more name forms, accept the certificate if none of the unrecognized name >> forms appear in the certification path, else reject the certificate. =A0= (this >> is against the RFC, but I see no harm) > > > Santosh, > > Actually, this not against the RFC: > > =A0 If a name constraints extension that is marked as critical > =A0 imposes constraints on a particular name form, and an instance of > =A0 that name form appears in the subject field or subjectAltName > =A0 extension of a subsequent certificate, then the application MUST > =A0 either process the constraint or reject the certificate. > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From pritikin@cisco.com Fri Apr 6 15:09:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3865911E8099 for ; Fri, 6 Apr 2012 15:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbEA21NCjuSj for ; Fri, 6 Apr 2012 15:09:40 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9E63111E8098 for ; Fri, 6 Apr 2012 15:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=4093; q=dns/txt; s=iport; t=1333750180; x=1334959780; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1rbH2DZukICOafJBc27Iqw8+4kYEXWPHE+OmICW7KtY=; b=LIMjN6p+eZpXesU41XNz7xfF1tWpvd6K9VoF5TVti2mHUbUSOA32iliD sXq8T9xkIe2A2LfIyFLU9MWgt4k9LfaQtAH7qBTI98FHbj+DskHaJzb67 H0DIQqsFSOoksACQLJdKPIij9szXSAnwfI2nLHWnsy/IMVD6PZF2qofPR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4GAENpf0+rRDoG/2dsb2JhbABEgyC2BIEHggkBAQEDAQEBAQ8BWwsFCwsYLicwBhMbB4dnBAyaYJ9Qj21jBIhajRKBEYRhiFuBaYMG X-IronPort-AV: E=Sophos;i="4.75,383,1330905600"; d="scan'208";a="39345241" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 06 Apr 2012 22:09:40 +0000 Received: from [10.21.0.51] ([10.21.0.51]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q36M9dkL015915; Fri, 6 Apr 2012 22:09:40 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Max Pritikin In-Reply-To: Date: Fri, 6 Apr 2012 16:09:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <34A830C8-31CC-4A8D-85C7-550BE769D464@cisco.com> References: <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> <4F7F2CA9.2050200@nist.gov> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1257) Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 22:09:41 -0000 Why isn't it the CA vendor's responsibility to decide if the Name = Constraints is "critical" or just "best effort"? Why is this codified in = the standard? I absolutely agree with the perspective that a "best effort" name = constraint is weak-sauce, particularly when a lot of clients are = understood not to actually check this field. But isn't it the = responsibility of the CA vendor, or maybe the CABF, to decide what makes = the most sense in their problem space? Just because I wouldn't want to = implement a "fail-open" solution doesn't mean they don't have every = right to reduce their security. Especially since their alternative is to = not use name constraints at all (aka "always fail-open with no recourse = for improvement").=20 It sounds like the main concern about non-critical name constraints is = that they're weak and that their use is a concession to weak clients.=20 Even if true I find it difficult to argue with the idea that adding them = is a "step in the right direction". And once a significant number of = products are checking these constraints it becomes possible to publicly = humiliate the vendors that don't properly check this field -- because = those venders have demonstrable security vulnerabilities. I'm sure I'm missing something. What is it? Thanks, - max On Apr 6, 2012, at 1:14 PM, Phillip Hallam-Baker wrote: > As I read the specifications it appears to me that they already > mandate precisely the desired behavior of relying apps: >=20 > * If the extension is marked critical and not understood, reject the = cert >=20 > * If the extension is understood and present it MUST be processed [or > the cert rejected]. >=20 > The only part that there is a problem with is the instruction that the > name constraints MUST be marked critical. Drop that down to a SHOULD > and the problem goes away completely. >=20 > Note that while a client app could in theory reject a cert if there is > a name constraint present and not marked critical that this is not a > requirement of the spec. The fact that a cert is not compliant with > the PKIX profile does not mean it has to be rejected. >=20 >=20 > As Martin points out, this particular MUST is not motivated by a > security requirement, nor is it motivated by an interoperability > requirement. >=20 > The only valid reason for not changing the spec that I can see is that > the group would like to avoid the IETF overhead that would incur. So > now we have got to the point where a major browser provider is going > to mandate a non-PKIX compliant profile as a pre-condition for > inclusion in their root program. >=20 > I am not trying to persuade here. I am merely trying to impress upon > you all that what is about to happen is entirely your fault and that > being unreasonable has consequences. >=20 >=20 > On Fri, Apr 6, 2012 at 1:49 PM, David A. Cooper = wrote: >>=20 >> On 04/06/2012 10:52 AM, Santosh Chokhani wrote: >>>=20 >>> 2. If the name constraint is critical and you do not recognize one = or >>> more name forms, accept the certificate if none of the unrecognized = name >>> forms appear in the certification path, else reject the certificate. = (this >>> is against the RFC, but I see no harm) >>=20 >>=20 >> Santosh, >>=20 >> Actually, this not against the RFC: >>=20 >> If a name constraints extension that is marked as critical >> imposes constraints on a particular name form, and an instance of >> that name form appears in the subject field or subjectAltName >> extension of a subsequent certificate, then the application MUST >> either process the constraint or reject the certificate. >>=20 >>=20 >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From tgindin@us.ibm.com Fri Apr 6 15:44:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF1111E80BE for ; Fri, 6 Apr 2012 15:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruW7zPYpOPNT for ; Fri, 6 Apr 2012 15:44:19 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id EEAE611E80BC for ; Fri, 6 Apr 2012 15:44:18 -0700 (PDT) Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 6 Apr 2012 16:44:18 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 6 Apr 2012 16:44:15 -0600 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 1DC24C90052 for ; Fri, 6 Apr 2012 18:44:14 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q36MiEFX297164 for ; Fri, 6 Apr 2012 18:44:14 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q374F7rJ004758 for ; Sat, 7 Apr 2012 00:15:07 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q374F7O4004755; Sat, 7 Apr 2012 00:15:07 -0400 In-Reply-To: References: To: "Kemp, David P." MIME-Version: 1.0 X-KeepSent: 90611467:F85A643F-852579D8:005C74C2; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Fri, 6 Apr 2012 18:43:55 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/06/2012 18:44:14, Serialize complete at 04/06/2012 18:44:14 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040622-6148-0000-0000-000004DCDCB8 Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 22:44:20 -0000 Dave: That's not the actual CA behavior which is likely, or which we've observed to date. The alternatives are closer to having 20% of CA's mark it critical and 80% omit it with the current rules, while 10% mark it critical, 50% mark it non-critical, and 40% omit it with my proposed change. If you assume that no CA which would prefer to emit a non-critical constraint chooses to omit the constraint entirely when criticality is required, then requiring criticality improves global security. I consider that assumption to have been disproved by experience. As an example, the trust store of one of my workstations has collected 28 intermediate certificates. Only four of them have name constraints extensions - two with excluded subtrees, and two others with permitted ones. Every entry in those subtrees is a directory name referring to an entity under the control of the US Department of Defense. The other 24 intermediates don't use name constraints. Tom Gindin From: "Kemp, David P." To: , Date: 04/06/2012 12:01 PM Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Sent by: pkix-bounces@ietf.org Marking it critical has nothing to do with a cargo-cult desire to worship a spec without making any changes. It has to do with secure operation of the Internet (where both "secure" and "operate" are important). If 100% of CAs and 90% of RPs follow the existing spec calling for marking the extension critical, a CA that issues a forged certificate (for a server in some other CA's authorized namespace), 90% of RPs will correctly detect the forgery and 10% will correctly reject the certificate and ask the user for guidance because they cannot determine whether it is forged or not. With the same RP population, if 100% of CAs mark the extension non-critical, 90% of RPs will detect the forgery because they can, and 10% of RPs will accept the forged certificate without any hint to the user that something fishy is going on. In my book "correct" behavior is detecting a forgery and asking the user whether to proceed anyway. That is the technical, not religious, reason for marking the extension critical. When you change the RP percentage to 40% non-compliant applications from a sexy, popular supplier, it changes the market dynamics for whether CAs should mark the extension critical. CAs have good justification for weighting "operate without inconveniencing casual users" more highly than "secure" in that situation. But it does not change the specification of the correct way to achieve both interoperability and security. Dave -----Original Message----- From: Phillip Hallam-Baker I still have not heard anyone give a good reason for marking the extension critical in this application. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From ynir@checkpoint.com Fri Apr 6 23:40:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E06521F8522 for ; Fri, 6 Apr 2012 23:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCRO106doVH5 for ; Fri, 6 Apr 2012 23:40:33 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A2EE421F851E for ; Fri, 6 Apr 2012 23:40:32 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q376eTuD005872; Sat, 7 Apr 2012 09:40:29 +0300 X-CheckPoint: {4F7FEEDD-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 7 Apr 2012 09:40:29 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 7 Apr 2012 09:40:27 +0300 From: Yoav Nir To: "Kemp, David P." Date: Sat, 7 Apr 2012 09:40:29 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0UiVGBmrQszxZXSRucZaemwzH1eg== Message-ID: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 06:40:33 -0000 On Apr 6, 2012, at 7:00 PM, Kemp, David P. wrote: > Marking it critical has nothing to do with a cargo-cult desire to > worship a spec without making any changes. It has to do with secure > operation of the Internet (where both "secure" and "operate" are > important). >=20 > If 100% of CAs and 90% of RPs follow the existing spec calling for > marking the extension critical, a CA that issues a forged certificate > (for a server in some other CA's authorized namespace), 90% of RPs will > correctly detect the forgery and 10% will correctly reject the > certificate and ask the user for guidance because they cannot determine > whether it is forged or not. >=20 > With the same RP population, if 100% of CAs mark the extension > non-critical, 90% of RPs will detect the forgery because they can, and > 10% of RPs will accept the forged certificate without any hint to the > user that something fishy is going on. >=20 > In my book "correct" behavior is detecting a forgery and asking the user > whether to proceed anyway. That is the technical, not religious, reason > for marking the extension critical. >=20 > When you change the RP percentage to 40% non-compliant applications from > a sexy, popular supplier, it changes the market dynamics for whether CAs > should mark the extension critical. CAs have good justification for > weighting "operate without inconveniencing casual users" more highly > than "secure" in that situation. But it does not change the > specification of the correct way to achieve both interoperability and > security. I disagree. The E in IETF in engineering. A spec that considers only the "s= ecure" and not the "operate without inconveniencing casual users" is bad en= gineering. Engineering has to consider the operating environment and constr= aints of those who need to follow the spec. The requirement to mark certain extensions as critical means that you canno= t use those extensions with relying parties that do not support those exten= sions. This misses the operating environment of commercial CAs, that have t= o work with all deployed browsers, so it's not good engineering. Until now,= they just didn't use name constraints. Mozilla is the first to require nam= e constraints of the CAs, and they don't mind if the extension is not criti= cal (because they understand it). Why should we think we know better than t= hose making the requirements? I think in this particular case, it could be fixed without changing the spe= c, because there's only one implementation out there that fails, and that o= ne regularly pushes updates to all users. I would similarly be not concerne= d about working around a bug in Chrome or recent Firefox, because those als= o update automatically. I *would* be concerned about working around IE on W= inXP, or Firefox 3.5 or Safari on MacOS prior to the current version, becau= se those don't get updated. But iOS? Apple could fix it tomorrow. Yoav From ryan-pkix@sleevi.com Sat Apr 7 00:49:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F12621F8528 for ; Sat, 7 Apr 2012 00:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqBBzUNtGgP0 for ; Sat, 7 Apr 2012 00:49:53 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA5221F84FC for ; Sat, 7 Apr 2012 00:49:53 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id F373B50808D; Sat, 7 Apr 2012 00:49:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= sleevi.com; b=RDai9vMMQLG0y3h47RGHTRTnprbVQcx77IWFKnBKiSjASsCSa0 a+bXD8u/6MOgd2wPaGgWDS+3Bt8PfN8MlmlKoXTyQ4PScY4jGKD9QkQDoGxH6uKY kD/aSvJhXrKvCcOlCnth/oa6+PviO5lDbeQL3MeJTQnn7tPrKVFg1GK54= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=UO1grVes8Lv8+QR1/oC/U+AKr3Y=; b=aoNltorGCg9kwW/gD b+VpFs2JI6TPq6xVOGzf0sevvXMeAxLUetqJCf8706Bo77ga7pfx94AH37yHH6U7 R9TTQuCPfC2VpVwZsmG4MuRaFVkDjdqgc4YuX22z1MF5zq7oL7WIhZraY+fIHUV6 /kPLSYbSGdsPR9yw8HMWIA99SA= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id 9BB1950808C; Sat, 7 Apr 2012 00:49:52 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Sat, 7 Apr 2012 00:49:52 -0700 Message-ID: <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> In-Reply-To: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> Date: Sat, 7 Apr 2012 00:49:52 -0700 From: "Ryan Sleevi" To: "Yoav Nir" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-pkix@sleevi.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 07:49:54 -0000 > > I think in this particular case, it could be fixed without changing th= e > spec, because there's only one implementation out there that fails, an= d > that one regularly pushes updates to all users. I would similarly be n= ot > concerned about working around a bug in Chrome or recent Firefox, beca= use > those also update automatically. I *would* be concerned about working > around IE on WinXP, or Firefox 3.5 or Safari on MacOS prior to the cur= rent > version, because those don't get updated. But iOS? Apple could fix it > tomorrow. > > Yoav Just to chime in here on the whole criticality thing: While Apple's OS X (desktop) implementation will not choke if Name Constraints is marked critical, it does not support processing name constraints and will not enforce them - critical or not. It does not quit= e implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 require that it fail processing if it does not process a critical extension (although 5280 does). So while we can talk at length about the intent of the critical bit, what it means for security, and why it should be there, in practice, deployed clients and deployed implementations will happily ignore processing these critical extensions and carry on their merry way. While OS X will fail on critical extensions that it does not know how to *parse*, it applies very little to actual path building and verification, and will happily accept critical extensions it recognizes but does not know how to *process* without compliant or signal. Not to mention all of the many, many scripting languages and toolsets (such as OpenSSL), which by default do not enforce name constraints BUT, because they support parsing them, will not raise any signals. The actual sources for OS X's trust module can be found at http://opensource.apple.com/, and is named libsecurity_apple_x509_tp. The core function is called tp_policyVerify, located in lib/tpPolicies.cpp. In the spirit of 3280 -> 5280, which saw both policy constraints and policy mappings go from MUST to RECOMMDED criticality, I would see name constraints do the same. Further, I support the assertions that Phillip Hallam-Baker has made thus far, and strongly believe that name constraints, as measured by the market of RPs and CAs that most Internet users interact with, have failed to provide meaningful security by being marked critical. As Yoav has pointed out, Name Constraints applying to subjectAltNames is optional for RPs, even within RFC 5280, so that is yet another failing of actually usable security. If the opponents to making it non-critical believe that requiring they be marked critical somehow leads to more secure RPs, than they should be disabused of the notion, as it simply does not match the reality of the RPs today. Requiring it be critical will break some clients entirely, while others will continue to happily (and silently) ignore them with relation to subjectAltNames, and thus their actual value for Internet PKI will be diminished. Meanwhile, the opportunity to actually begin deploying name constraints will be missed, because of the staunch refusal to consider making it non-critical. In the worst case, a non-critical name constraint offers no worse security today than the unconstrained sub-CAs that any major CA is issuing. In the best, and more likely, case, non-critical name constraint= s afford better security for the clients/RPs that implement them (and apply them to the subjectAltName), which allows market forces such as users and negative publicity to name and shame the non-implementing vendors into th= e wonderful world of RFC 5280 and half-way sane implementations. I suspect and support the argument that browsers and other root store operators will simply require non-critical name constraints, and in the end, the only casualty will be the idea that implementing RFC 5280 is needed to operate on the Internet PKI - or even a good idea. Which will be, understandably, unfortunate. Cheers, Ryan From eabalea@gmail.com Sat Apr 7 03:24:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FC421F8550 for ; Sat, 7 Apr 2012 03:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7T83PJzWgxR for ; Sat, 7 Apr 2012 03:24:10 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A91B121F8495 for ; Sat, 7 Apr 2012 03:24:10 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1625140yhk.31 for ; Sat, 07 Apr 2012 03:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rjOQzLNJCYsbf4M2F2ZGW7HP4sFOV3KgGSe+U6q8VFg=; b=VMoVcnPORVDX2gwXHC5iCxYv6V3/D2sES8HqQNCtqEhacbXwNNQSQP+MzIthNa8SbJ mHpl9S47fzEjn6E8+WJMEg+krHtr4HisXINQViD7jiN1wG+HO5Qp5JcDaQHqOSRoztRV NMbIXHs4gKpQoAIJM3Qy23r76w/bYcYsEUonQA7W49LbwNuibBO7q8tafnxzTSEvluOs yCRgvy3Si3aVm7Id3bS2XpOw/Rg2pI6eJL81GJLZvX6/qYaw39Ux5kbeYt4VkHW8Hqp1 Ip+Teyfjs5nKWJgj0NIGn23O8L1MHL0P7CSfyamCGCwZmBCTq6zcSUy3j9I84uF3Ruma LsUw== MIME-Version: 1.0 Received: by 10.236.170.41 with SMTP id o29mr704851yhl.83.1333794250066; Sat, 07 Apr 2012 03:24:10 -0700 (PDT) Received: by 10.236.76.199 with HTTP; Sat, 7 Apr 2012 03:24:09 -0700 (PDT) In-Reply-To: <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> Date: Sat, 7 Apr 2012 12:24:09 +0200 Message-ID: From: Erwann Abalea To: ryan-pkix@sleevi.com Content-Type: multipart/alternative; boundary=20cf303b38e37a8a8e04bd142cb1 Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 10:24:11 -0000 --20cf303b38e37a8a8e04bd142cb1 Content-Type: text/plain; charset=UTF-8 2012/4/7 Ryan Sleevi > > > > I think in this particular case, it could be fixed without changing the > > spec, because there's only one implementation out there that fails, and > > that one regularly pushes updates to all users. I would similarly be not > > concerned about working around a bug in Chrome or recent Firefox, > because > > those also update automatically. I *would* be concerned about working > > around IE on WinXP, or Firefox 3.5 or Safari on MacOS prior to the > current > > version, because those don't get updated. But iOS? Apple could fix it > > tomorrow. > > > > Yoav > > Just to chime in here on the whole criticality thing: > > While Apple's OS X (desktop) implementation will not choke if Name > Constraints is marked critical, it does not support processing name > constraints and will not enforce them - critical or not. It does not quite > implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 require > that it fail processing if it does not process a critical extension > (although 5280 does). > That's nitpicking. 4.2. RFC2459/3280 say this: ----- A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension may be ignored if it is not recognized. ----- while RFC5280 says this: ----- A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. ----- However, in the same chapter, 3 paragraphs below, the 3 RFCs agree on this: ----- At a minimum, applications conforming to this profile MUST recognize the extensions which must or may be critical in this specification. These extensions are: key usage (see sec. 4.2.1.3), certificate policies (see sec. 4.2.1.5), the subject alternative name (see sec. 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and extended key usage (see sec. 4.2.1.13). ----- +inhibitAnyPolicy for RFC{3,5}280. So. This implementation "recognizes" it (it can parse it), but doesn't "process" it. Or how to take only interesting bits of a standard. Were these implementation details responsible for non enforcing critical basicConstraints:CA=False? The basic path validation algorithm in RFC2459 is also clear about nameConstraints (see 6.1, steps j and k), and the algorithm has been extended for less confusion in RFC3280. > So while we can talk at length about the intent of the critical bit, what > it means for security, and why it should be there, in practice, deployed > clients and deployed implementations will happily ignore processing these > critical extensions and carry on their merry way. While OS X will fail on > critical extensions that it does not know how to *parse*, it applies very > little to actual path building and verification, and will happily accept > critical extensions it recognizes but does not know how to *process* > without compliant or signal. Not to mention all of the many, many > scripting languages and toolsets (such as OpenSSL), which by default do > not enforce name constraints BUT, because they support parsing them, will > not raise any signals. > OpenSSL 1.0.0 does enforce nameConstraints. mod_ssl, when using older versions of OpenSSL, rejects a certificate containing a critical nameConstraints extension. > The actual sources for OS X's trust module can be found at > http://opensource.apple.com/, and is named libsecurity_apple_x509_tp. The > core function is called tp_policyVerify, located in lib/tpPolicies.cpp. > > In the spirit of 3280 -> 5280, which saw both policy constraints and > policy mappings go from MUST to RECOMMDED criticality, Wrong. The criticality of: policyMapping went from MUST NOT to SHOULD. policyConstraints went from MAY to MUST. > I would see name > constraints do the same. Further, I support the assertions that Phillip > Hallam-Baker has made thus far, and strongly believe that name > constraints, as measured by the market of RPs and CAs that most Internet > users interact with, have failed to provide meaningful security by being > marked critical. As Yoav has pointed out, Name Constraints applying to > subjectAltNames is optional for RPs, even within RFC 5280, so that is yet > another failing of actually usable security. > > If the opponents to making it non-critical believe that requiring they be > marked critical somehow leads to more secure RPs, than they should be > disabused of the notion, as it simply does not match the reality of the > RPs today. Requiring it be critical will break some clients entirely, > while others will continue to happily (and silently) ignore them with > relation to subjectAltNames, and thus their actual value for Internet PKI > will be diminished. > And how is marking this extension non critical going to help the cause? -- Erwann. --20cf303b38e37a8a8e04bd142cb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

2012/4/7 Ryan Sleevi &= lt;ryan-pkix@sleevi.com>
>
> =C2=A0I think in this particular case, it could be fixed without chang= ing the
> =C2=A0spec, because there's only one implementation out there that= fails, and
> =C2=A0that one regularly pushes updates to all users. I would similarl= y be not
> =C2=A0concerned about working around a bug in Chrome or recent Firefox= , because
> =C2=A0those also update automatically. I *would* be concerned about wo= rking
> =C2=A0around IE on WinXP, or Firefox 3.5 or Safari on MacOS prior to t= he current
> =C2=A0version, because those don't get updated. But iOS? =C2=A0App= le could fix it
> =C2=A0tomorrow.
>
> =C2=A0Yoav

Just to chime in here on the whole criticality thing:

While Apple's OS X (desktop) implementation will not choke if Name
Constraints is marked critical, it does not support processing name
constraints and will not enforce them - critical or not. It does not quite<= br> implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 require that it fail processing if it does not process a critical extension
(although 5280 does).

That's nitpic= king.

4.2. RFC2459/3280 say this:
-----<= /div>
A certificate using system MUST reject the certificate if it encounters
a critical extension it does not recognize; however, a non-critical
extension may be ignored if it is not recognized.
--= ---

while RFC5280 says this:
-----
= 
A certificate-using system MUST reject the certificate if it encounters
a critical extension it does not recognize or a critical extension
that contains information that it cannot process.  A non-critical
extension MAY be ignored if it is not recognized, but MUST be
processed if it is recognized.
-----

<= /div>
However, in the same chapter, 3 paragraphs below, the 3 RFCs agre= e on this:
-----
At a minimum, applications conforming to this profile MUST recognize
the extensions which must or may be critical in this specification.
These extensions are:  key usage (see sec. 4.2.1.3), certificate
policies (see sec. 4.2.1.5), the subject alternative name (see sec.
4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints
(see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and
extended key usage (see sec. 4.2.1.13).
-----
<= div>
+inhibitAnyPolicy for RFC{3,5}280.

<= div>So. This implementation "recognizes" it (it can parse it), bu= t doesn't "process" it. Or how to take only interesting bits = of a standard.
Were these implementation details responsible for non enforcing critic= al basicConstraints:CA=3DFalse?

The basic path val= idation algorithm in RFC2459 is also clear about nameConstraints (see 6.1, = steps j and k), and the algorithm has been extended for less confusion in R= FC3280.
=C2=A0
So while we can talk at length about the intent of the critical bit, what it means for security, and why it should be there, in practice, deployed clients and deployed implementations will happily ignore processing these critical extensions and carry on their merry way. While OS X will fail on critical extensions that it does not know how to *parse*, it applies very little to actual path building and verification, and will happily accept critical extensions it recognizes but does not know how to *process*
without compliant or signal. Not to mention all of the many, many
scripting languages and toolsets (such as OpenSSL), which by default do
not enforce name constraints BUT, because they support parsing them, will not raise any signals.

OpenSSL 1.0.0 do= es enforce nameConstraints. mod_ssl, when using older versions of OpenSSL, = rejects a certificate containing a critical nameConstraints extension.
=C2=A0
The actual sources for OS X's trust module can be found at
http://opensourc= e.apple.com/, and is named libsecurity_apple_x509_tp. The
core function is called tp_policyVerify, located in lib/tpPolicies.cpp.

In the spirit of 3280 -> 5280, which saw both policy constraints and
policy mappings go from MUST to RECOMMDED criticality,
Wrong. The criticality of:
=C2=A0 policyMapping went= from MUST NOT to SHOULD.
=C2=A0 policyConstraints went from MAY = to MUST.

=C2=A0
I would see = name
constraints do the same. Further, I support the assertions that Phillip
Hallam-Baker has made thus far, and strongly believe that name
constraints, as measured by the market of RPs and CAs that most Internet users interact with, have failed to provide meaningful security by being marked critical. As Yoav has pointed out, Name Constraints applying to
subjectAltNames is optional for RPs, even within RFC 5280, so that is yet another failing of actually usable security.

If the opponents to making it non-critical believe that requiring they be marked critical somehow leads to more secure RPs, than they should be
disabused of the notion, as it simply does not match the reality of the
RPs today. Requiring it be critical will break some clients entirely,
while others will continue to happily (and silently) ignore them with
relation to subjectAltNames, and thus their actual value for Internet PKI will be diminished.

And how is marking = this extension non critical going to help the cause?

--
Erwann.
--20cf303b38e37a8a8e04bd142cb1-- From SChokhani@cygnacom.com Sat Apr 7 06:11:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A5B21F858B for ; Sat, 7 Apr 2012 06:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SOeHzCkBl2t for ; Sat, 7 Apr 2012 06:11:15 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 66D7121F858A for ; Sat, 7 Apr 2012 06:11:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,385,1330923600"; d="scan'208";a="4641532" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 07 Apr 2012 09:11:02 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sat, 7 Apr 2012 09:11:02 -0400 From: Santosh Chokhani To: "ryan-pkix@sleevi.com" , Yoav Nir Date: Sat, 7 Apr 2012 09:11:01 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0UkxDr+Xpttu7rTHacUXA7+xH0YwALCNYg Message-ID: References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> In-Reply-To: <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 13:11:16 -0000 Section 4.2 of 2459 says: " A certificate using system MUST reject the cert= ificate if it encounters a critical extension it does not recognize". So, the implementation you mention is not compliant with 2459. If the RP ignores criticality, why have a debate. This is software and not laws of physics. Anyone can write software that e= ven does not verify signatures. The reason for keeping it critical is that those RP who comply with the sta= ndard are afforded the security implied by the standard. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rya= n Sleevi Sent: Saturday, April 07, 2012 3:50 AM To: Yoav Nir Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > > I think in this particular case, it could be fixed without changing=20 > the spec, because there's only one implementation out there that=20 > fails, and that one regularly pushes updates to all users. I would=20 > similarly be not concerned about working around a bug in Chrome or=20 > recent Firefox, because those also update automatically. I *would* be=20 > concerned about working around IE on WinXP, or Firefox 3.5 or Safari=20 > on MacOS prior to the current version, because those don't get=20 > updated. But iOS? Apple could fix it tomorrow. > > Yoav Just to chime in here on the whole criticality thing: While Apple's OS X (desktop) implementation will not choke if Name Constrai= nts is marked critical, it does not support processing name constraints and= will not enforce them - critical or not. It does not quite implement all o= f RFC 2459, let alone 3280 or 5280, nor does 2459 require that it fail proc= essing if it does not process a critical extension (although 5280 does). So while we can talk at length about the intent of the critical bit, what i= t means for security, and why it should be there, in practice, deployed cli= ents and deployed implementations will happily ignore processing these crit= ical extensions and carry on their merry way. While OS X will fail on criti= cal extensions that it does not know how to *parse*, it applies very little= to actual path building and verification, and will happily accept critical= extensions it recognizes but does not know how to *process* without compli= ant or signal. Not to mention all of the many, many scripting languages and= toolsets (such as OpenSSL), which by default do not enforce name constrain= ts BUT, because they support parsing them, will not raise any signals. The actual sources for OS X's trust module can be found at http://opensourc= e.apple.com/, and is named libsecurity_apple_x509_tp. The core function is = called tp_policyVerify, located in lib/tpPolicies.cpp. In the spirit of 3280 -> 5280, which saw both policy constraints and policy= mappings go from MUST to RECOMMDED criticality, I would see name constrain= ts do the same. Further, I support the assertions that Phillip Hallam-Baker= has made thus far, and strongly believe that name constraints, as measured= by the market of RPs and CAs that most Internet users interact with, have = failed to provide meaningful security by being marked critical. As Yoav has= pointed out, Name Constraints applying to subjectAltNames is optional for = RPs, even within RFC 5280, so that is yet another failing of actually usabl= e security. If the opponents to making it non-critical believe that requiring they be m= arked critical somehow leads to more secure RPs, than they should be disabu= sed of the notion, as it simply does not match the reality of the RPs today= . Requiring it be critical will break some clients entirely, while others w= ill continue to happily (and silently) ignore them with relation to subject= AltNames, and thus their actual value for Internet PKI will be diminished. Meanwhile, the opportunity to actually begin deploying name constraints wil= l be missed, because of the staunch refusal to consider making it non-criti= cal. In the worst case, a non-critical name constraint offers no worse secu= rity today than the unconstrained sub-CAs that any major CA is issuing. In = the best, and more likely, case, non-critical name constraints afford bette= r security for the clients/RPs that implement them (and apply them to the s= ubjectAltName), which allows market forces such as users and negative publi= city to name and shame the non-implementing vendors into the wonderful worl= d of RFC 5280 and half-way sane implementations. I suspect and support the argument that browsers and other root store opera= tors will simply require non-critical name constraints, and in the end, the= only casualty will be the idea that implementing RFC 5280 is needed to ope= rate on the Internet PKI - or even a good idea. Which will be, understandab= ly, unfortunate. Cheers, Ryan _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From tmiller@mitre.org Sat Apr 7 07:40:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A774E21F8562 for ; Sat, 7 Apr 2012 07:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.96 X-Spam-Level: X-Spam-Status: No, score=-4.96 tagged_above=-999 required=5 tests=[AWL=1.639, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo4fX49GSKtB for ; Sat, 7 Apr 2012 07:40:58 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F11D121F8555 for ; Sat, 7 Apr 2012 07:40:57 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B641D21B1605 for ; Sat, 7 Apr 2012 10:40:56 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A448C21B1602 for ; Sat, 7 Apr 2012 10:40:56 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.233]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Sat, 7 Apr 2012 10:40:56 -0400 From: "Miller, Timothy J." To: PKIX PKIX Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: AQHNEPPvquDEc5XKr0iEIGU8AH05gZaICg8AgAUfg4CAABWQgIAAA7CAgACzvICAAA6cAIAABD0AgAASSACAACJKAIAA9dKAgAATYgCAAFm7gIAAGR6A Date: Sat, 7 Apr 2012 14:40:55 +0000 Message-ID: References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.47.137] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 14:40:58 -0000 So let's see if I can summarize, since this has been a long thread and I'm = still trying to think it through: Current spec: Operative clauses: If NC is present: - it MUST be marked critical - SHOULD NOT apply NC to x400Address - MUST NOT be empty - MUST only appear in a CA cert - minimum MUST be zero - maximum MUST be absent Implementations: - MUST process NC for DNs - SHOULD process for IP, DNS, email, and URI name types - MUST process NC for a matching name type if present in the chain or rej= ect if NC is present and critical - MUST process minimum and/or maximum if present with any value or reject= if NC is present and critical Pseudo-operative clauses (not using RFC 2119 language): - NC only apply when a name type is present that matches a name type in th= e NC extension - NC are not applied to self-signed certs unless the cert is a TA - excluded takes precedence over included (I've left out the clauses relating to applying NC rules for specific name = forms; I'm only looking at the extension itself here.) Proposal: - Change "MUST be marked critical" to "SHOULD be marked critical" or "MAY b= e marked critical". Pro: - Permits issuers to assert NC without causing rejection by conformant RPs = that may not be able to process NC at all or are unable to process NC for a= specific name type. Con: - Reduces the issuer's assurance guarantees because the RP won't reject the= certificate if a name type can't be processed. Neutral: - Non-conformant application behavior remains undefined with this change (i= .e., a non-conformant application may process NC and reject or accept witho= ut reference to the specification) Is this an accurate summary? Assuming so, I think I have to come down on the "con" side. The problem is= the RP code that processes a certificate *is not always* responsible for e= xtracting and using names included in the cert.=20 Consider an implementation of an S/MIME client using an X.509 library that = implements NC but does not implement the RFC822 NC rules. Assume this clie= nt receives a signed email where the signature chain asserts a permitted-su= btree NC for rfc822Name, but the signature cert has a name that is outside = this subtree. What happens at the RP? Under the proposal, NC is not criti= cal; the RP is correct to accept this cert because it cannot process the na= me type; the S/MIME client will then match the rfc822Name to the sender and= tell the user the signature is valid. That would be a Potentially Bad Thi= ng. (Yes, this is an artificial case, but you get the point?) -- T From hallam@gmail.com Sat Apr 7 09:00:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613CB21F855F for ; Sat, 7 Apr 2012 09:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIwbp9flz3Et for ; Sat, 7 Apr 2012 09:00:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F326521F8562 for ; Sat, 7 Apr 2012 09:00:15 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so4777887obb.31 for ; Sat, 07 Apr 2012 09:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XOJ8aZ5B5p0OJpVQpF6aNiOlWelemtM1HhJNwhYi6/k=; b=FyyI8XWlK7kMxsnh2BnSPeqLpYRg/u2zyXW0XKdE9OrpJccLx6ZKrmFUiJbof7OIWP lqrDYvpPAXaGIglOUD4jHu4z8GfHR9soOyoBL35h8D4CyTqqj8HkaR9/ymrO2mdVZ8D/ GUTgeRd6pWmrjTo4RNJcGQA+PuWz/dxOW3ljxcdffpqYKnoZfj+d2wnIU/ZDeWm1Sbhn 64QhXQVdNBGW0mOO+WkCxmEET4fJRGxNwRdNsCHQOr0hS/m9EpY322+3oRbmZX8QWs9T 49BK/WnC4ioZtiFQj4ZlwyeY/Hflr76/5mydyBU+wPbdHnCgTZ37nifarY8xRf8aDQAL 2h7Q== MIME-Version: 1.0 Received: by 10.60.7.200 with SMTP id l8mr2309826oea.52.1333814415494; Sat, 07 Apr 2012 09:00:15 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Sat, 7 Apr 2012 09:00:15 -0700 (PDT) In-Reply-To: References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> Date: Sat, 7 Apr 2012 12:00:15 -0400 Message-ID: From: Phillip Hallam-Baker To: "Miller, Timothy J." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: PKIX PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 16:00:17 -0000 Why do you imagine that you are the right person to decide whether the pro outweighs the con rather than the issuer? This is something that CAs are going to decide for themselves. Compliance with the DRAFT PKIX profile is not a requirement that the Browser providers seem interested in enforcing. As I read the Mozilla requirement it does not force Comodo to make an immediate change to operating procedures as we retain control of the private key for the systems in question. To the extent that there is a direct commercial interest it would be nice to be able to employ name constraints as an additional control even if this is not a requirement. It should be obvious that no CA is going to do that if doing so would break backwards compatibility with even 1% of the deployed base. That is twenty million users that will be inconvenienced. And don't forget that most cell phones cannot even be updated. People switch their cell phones regularly in the developed world of course. Have you ever given a thought to what happens to the old ones that are traded in? Out in parts of Africa or India a second hand smart phone is the basis for a person's livelihood in just the way that a rickshaw or a scooter might be. Backwards compatibility matters to those people. As a CA I have a responsibility to those people. I do not have any responsibility towards this group. What drives the immediate concern is not the direct commercial interest but an indirect one. An attack on one of us is an attack on all. Like Mozilla we have an interest in mitigating risk exposure in all issued certificates, not just those we issue directly. This is not a decision that the industry is willing to leave to this group. Perhaps it is time that PKIX was shut down and the plans for a OCSP DRAFT and a bis on 5280 abandoned. Rather than attempting to make this particular forum relevant again, make rapid progress in the new forum and then when everything has settled down again spin up a new IETF WG to document the new approach as bis RFCs. On Sat, Apr 7, 2012 at 10:40 AM, Miller, Timothy J. wro= te: > So let's see if I can summarize, since this has been a long thread and I'= m still trying to think it through: > > Current spec: > > Operative clauses: > > =A0 =A0 =A0 =A0If NC is present: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- it MUST be marked critical > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- SHOULD NOT apply NC to x400Address > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- MUST NOT be empty > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- MUST only appear in a CA cert > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- minimum MUST be zero > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- maximum MUST be absent > > =A0 =A0 =A0 =A0Implementations: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- MUST process NC for DNs > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- SHOULD process for IP, DNS, email, and U= RI name types > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- MUST process NC for a matching name type= if present in the chain or reject if NC is present and critical > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- MUST process minimum and/or maximum if p= resent with any value or reject if NC is present and critical > > Pseudo-operative clauses (not using RFC 2119 language): > > =A0 =A0 =A0 =A0- NC only apply when a name type is present that matches a= name type in the NC extension > =A0 =A0 =A0 =A0- NC are not applied to self-signed certs unless the cert = is a TA > =A0 =A0 =A0 =A0- excluded takes precedence over included > > (I've left out the clauses relating to applying NC rules for specific nam= e forms; I'm only looking at the extension itself here.) > > Proposal: > > - Change "MUST be marked critical" to "SHOULD be marked critical" or "MAY= be marked critical". > > Pro: > > - Permits issuers to assert NC without causing rejection by conformant RP= s that may not be able to process NC at all or are unable to process NC for= a specific name type. > > Con: > > - Reduces the issuer's assurance guarantees because the RP won't reject t= he certificate if a name type can't be processed. > > Neutral: > > - Non-conformant application behavior remains undefined with this change = (i.e., a non-conformant application may process NC and reject or accept wit= hout reference to the specification) > > Is this an accurate summary? > > Assuming so, I think I have to come down on the "con" side. =A0The proble= m is the RP code that processes a certificate *is not always* responsible f= or extracting and using names included in the cert. > > Consider an implementation of an S/MIME client using an X.509 library tha= t implements NC but does not implement the RFC822 NC rules. =A0Assume this = client receives a signed email where the signature chain asserts a permitte= d-subtree NC for rfc822Name, but the signature cert has a name that is outs= ide this subtree. =A0What happens at the RP? =A0Under the proposal, NC is n= ot critical; the RP is correct to accept this cert because it cannot proces= s the name type; the S/MIME client will then match the rfc822Name to the se= nder and tell the user the signature is valid. =A0That would be a Potential= ly Bad Thing. > > (Yes, this is an artificial case, but you get the point?) > > -- T > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From tmiller@mitre.org Sat Apr 7 10:58:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9B521F84C5 for ; Sat, 7 Apr 2012 10:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.78 X-Spam-Level: X-Spam-Status: No, score=-5.78 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqqCxKpNFjRe for ; Sat, 7 Apr 2012 10:58:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3E87021F84C4 for ; Sat, 7 Apr 2012 10:58:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3C05921B0D95; Sat, 7 Apr 2012 13:58:54 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 2A26221B0BCF; Sat, 7 Apr 2012 13:58:54 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.233]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Sat, 7 Apr 2012 13:58:54 -0400 From: "Miller, Timothy J." To: Phillip Hallam-Baker Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: AQHNEPPvquDEc5XKr0iEIGU8AH05gZaICg8AgAUfg4CAABWQgIAAA7CAgACzvICAAA6cAIAABD0AgAASSACAACJKAIAA9dKAgAATYgCAAFm7gIAAGR6AgAAWKoCAACEkAA== Date: Sat, 7 Apr 2012 17:58:53 +0000 Message-ID: <50A44A48-7103-4461-B937-E044087C7758@mitre.org> References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.46.114] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6D2216F26CB07D4AB23E232636399B9F@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: PKIX PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 17:58:55 -0000 On Apr 7, 2012, at 11:00 AM, Phillip Hallam-Baker wrote: > Why do you imagine that you are the right person to decide whether the > pro outweighs the con rather than the issuer? Don't put words in my mouth. I gave my goddamn opinion, that's all. -- T From tmiller@mitre.org Sat Apr 7 11:08:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153BD21F84D9 for ; Sat, 7 Apr 2012 11:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.053 X-Spam-Level: X-Spam-Status: No, score=-6.053 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmlFTbwEKtcv for ; Sat, 7 Apr 2012 11:08:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6222721F84D8 for ; Sat, 7 Apr 2012 11:08:16 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0520421B1021 for ; Sat, 7 Apr 2012 14:08:16 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E757E21B0E80 for ; Sat, 7 Apr 2012 14:08:15 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.233]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Sat, 7 Apr 2012 14:08:15 -0400 From: "Miller, Timothy J." To: PKIX PKIX Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: AQHNEPPvquDEc5XKr0iEIGU8AH05gZaICg8AgAUfg4CAABWQgIAAA7CAgACzvICAAA6cAIAABD0AgAASSACAACJKAIAA9dKAgAATYgCAAFm7gIAAGR6AgAA57AA= Date: Sat, 7 Apr 2012 18:08:14 +0000 Message-ID: <41D727A3-0664-4770-97B6-A45650ED22C8@mitre.org> References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.46.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <3091BB2877E3654E90DF78DD99B1DD6A@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 18:08:17 -0000 So maybe this needs clarification: "Pro" is the current argument for the P= roposal, "Con" is the argument against. These are not strictly speaking st= atements evaluating the Proposal, rather are summations of the two apparent= camps. If that wasn't clear, my apologies. -- T On Apr 7, 2012, at 9:40 AM, Miller, Timothy J. wrote: > So let's see if I can summarize, since this has been a long thread and I'= m still trying to think it through: >=20 > Current spec: >=20 > Operative clauses: >=20 > If NC is present: > - it MUST be marked critical > - SHOULD NOT apply NC to x400Address > - MUST NOT be empty > - MUST only appear in a CA cert > - minimum MUST be zero > - maximum MUST be absent >=20 > Implementations: > - MUST process NC for DNs > - SHOULD process for IP, DNS, email, and URI name types > - MUST process NC for a matching name type if present in the chain or r= eject if NC is present and critical > - MUST process minimum and/or maximum if present with any value or reje= ct if NC is present and critical >=20 > Pseudo-operative clauses (not using RFC 2119 language): >=20 > - NC only apply when a name type is present that matches a name type in = the NC extension > - NC are not applied to self-signed certs unless the cert is a TA > - excluded takes precedence over included >=20 > (I've left out the clauses relating to applying NC rules for specific nam= e forms; I'm only looking at the extension itself here.) >=20 > Proposal: >=20 > - Change "MUST be marked critical" to "SHOULD be marked critical" or "MAY= be marked critical". >=20 > Pro: >=20 > - Permits issuers to assert NC without causing rejection by conformant RP= s that may not be able to process NC at all or are unable to process NC for= a specific name type. >=20 > Con: >=20 > - Reduces the issuer's assurance guarantees because the RP won't reject t= he certificate if a name type can't be processed. >=20 > Neutral: >=20 > - Non-conformant application behavior remains undefined with this change = (i.e., a non-conformant application may process NC and reject or accept wit= hout reference to the specification) >=20 > Is this an accurate summary? >=20 > Assuming so, I think I have to come down on the "con" side. The problem = is the RP code that processes a certificate *is not always* responsible for= extracting and using names included in the cert.=20 >=20 > Consider an implementation of an S/MIME client using an X.509 library tha= t implements NC but does not implement the RFC822 NC rules. Assume this cl= ient receives a signed email where the signature chain asserts a permitted-= subtree NC for rfc822Name, but the signature cert has a name that is outsid= e this subtree. What happens at the RP? Under the proposal, NC is not cri= tical; the RP is correct to accept this cert because it cannot process the = name type; the S/MIME client will then match the rfc822Name to the sender a= nd tell the user the signature is valid. That would be a Potentially Bad T= hing. >=20 > (Yes, this is an artificial case, but you get the point?) >=20 > -- T >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From housley@vigilsec.com Sat Apr 7 12:30:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186C321F84E6 for ; Sat, 7 Apr 2012 12:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE0hFLdc+gRp for ; Sat, 7 Apr 2012 12:30:37 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 845EA21F84E1 for ; Sat, 7 Apr 2012 12:30:37 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 03624F24028; Sat, 7 Apr 2012 15:30:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id qRC1LluU2EGb; Sat, 7 Apr 2012 15:30:36 -0400 (EDT) Received: from [192.168.2.102] (pool-96-255-13-167.washdc.fios.verizon.net [96.255.13.167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 54B52F24014; Sat, 7 Apr 2012 15:30:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> Date: Sat, 7 Apr 2012 15:30:35 -0400 Content-Transfer-Encoding: 7bit Message-Id: <363FBDD8-9103-4A5C-92EA-89F0ABFF2566@vigilsec.com> References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> To: ryan-pkix@sleevi.com X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 19:30:38 -0000 Ryan: > While Apple's OS X (desktop) implementation will not choke if Name > Constraints is marked critical, it does not support processing name > constraints and will not enforce them - critical or not. It does not quite > implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 require > that it fail processing if it does not process a critical extension > (although 5280 does). RFC 2459 says: ... A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension may be ignored if it is not recognized. ... So, this is not a concept that was added in RFC 3280 or 5280. Russ From hallam@gmail.com Sat Apr 7 12:39:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB68421F84FB for ; Sat, 7 Apr 2012 12:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGFjz4JArDxF for ; Sat, 7 Apr 2012 12:39:26 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5F5621F84F8 for ; Sat, 7 Apr 2012 12:39:25 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so4923459obb.31 for ; Sat, 07 Apr 2012 12:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1If+FWFnGieVKAvo9JvI4cA/Z3R3Y8xU+O83J7e7uEc=; b=fiuyMWq+oeRxwQ4KTaUQ8NYYLjfPQqGFCoCJNPm6W8kfjkn+PtrmhldwKQXAGktcl/ NAcYDQwcy4C74G0HcDzSlXyMKFfOFnO6C5dXaP77aOUPgC7LfT4DOU9QP3JqhyYQIhfn 3DO8gQ8ZZ0yzKgmrOaa0L1dfi7sRmFkm6xcP5enNsiYbmBsuVksIyAVsb4Txn4spm72r LInbJkaa+4zV+v70bpNrrlBlYV6dTtSMNqVwF/JAy9wXT5T+MElinYSe2ArT/wQdp276 zhCXvtwfl8oicSALg3HaPuShjbtGl3f9zxFB4+6ke5EUn2bblSCLcgmFP1owNq4wvUYA 1cqA== MIME-Version: 1.0 Received: by 10.60.28.33 with SMTP id y1mr2915616oeg.62.1333827565592; Sat, 07 Apr 2012 12:39:25 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Sat, 7 Apr 2012 12:39:25 -0700 (PDT) In-Reply-To: <363FBDD8-9103-4A5C-92EA-89F0ABFF2566@vigilsec.com> References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> <363FBDD8-9103-4A5C-92EA-89F0ABFF2566@vigilsec.com> Date: Sat, 7 Apr 2012 15:39:25 -0400 Message-ID: From: Phillip Hallam-Baker To: Russ Housley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 19:39:26 -0000 Isn't it an X509v3 requirement in any case? On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley wrote: > Ryan: > >> While Apple's OS X (desktop) implementation will not choke if Name >> Constraints is marked critical, it does not support processing name >> constraints and will not enforce them - critical or not. It does not qui= te >> implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 require >> that it fail processing if it does not process a critical extension >> (although 5280 does). > > RFC 2459 says: > > =A0 ... =A0A > =A0 certificate using system MUST reject the certificate if it encounters > =A0 a critical extension it does not recognize; however, a non-critical > =A0 extension may be ignored if it is not recognized. =A0... > > So, this is not a concept that was added in RFC 3280 or 5280. > > Russ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From hallam@gmail.com Sat Apr 7 12:42:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9798D21F84F8 for ; Sat, 7 Apr 2012 12:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8bHn0Z+sp8l for ; Sat, 7 Apr 2012 12:42:41 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E42ED21F84A2 for ; Sat, 7 Apr 2012 12:42:40 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so4925454obb.31 for ; Sat, 07 Apr 2012 12:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QHZOMQqryAwKHkMJbhnk98PnY8nt5x5kJEXBMVy97Xs=; b=edMfRIkDUcmuNv99Q6gv2LJqYlZdwstIFThXQaDl42enUIH7I4aLUjEs5EfRYkPImZ eUsFtfE34ZG2eAWySmKvvkx2JsAb31F25w60k50jwQQGuxhkFFW0A5AIhPrzzxASNXgL zdeb9uzsoJK4tNF++VCp/wUdIO6CpFTzUh4Dd8N9JbibB8ge4GcKNTIl+zkE2ZaiW2YP MF0WsAzS1ocE2SVOoP1awaWIX/OfG2Ffzg5FiQZnckdxZEE+l8cr8yOAj1wHxKkmNj9M LuFSrlEsyZTezdsJt7c8J2Oxl2BtI7QDE14YB/j5vb2T5mXo3Cvbcy5tFjzyjTXolOTZ O8Dw== MIME-Version: 1.0 Received: by 10.182.169.4 with SMTP id aa4mr2910884obc.62.1333827760534; Sat, 07 Apr 2012 12:42:40 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Sat, 7 Apr 2012 12:42:40 -0700 (PDT) In-Reply-To: <50A44A48-7103-4461-B937-E044087C7758@mitre.org> References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> <50A44A48-7103-4461-B937-E044087C7758@mitre.org> Date: Sat, 7 Apr 2012 15:42:40 -0400 Message-ID: From: Phillip Hallam-Baker To: "Miller, Timothy J." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: PKIX PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 19:42:41 -0000 Your opinion was that your opinion on the matter is so important that we should not change the spec. What is being discussed here is not what the idea state of PKI should be but whether the PKIX specification should allow CAs the flexibility to deal with real world security tradeoffs as they see best. On Sat, Apr 7, 2012 at 1:58 PM, Miller, Timothy J. wrot= e: > On Apr 7, 2012, at 11:00 AM, Phillip Hallam-Baker wrote: > >> Why do you imagine that you are the right person to decide whether the >> pro outweighs the con rather than the issuer? > > Don't put words in my mouth. =A0I gave my goddamn opinion, that's all. > > -- T > > --=20 Website: http://hallambaker.com/ From housley@vigilsec.com Sat Apr 7 12:49:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0359D21F853B for ; Sat, 7 Apr 2012 12:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7d0+OCM8DnT for ; Sat, 7 Apr 2012 12:49:30 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB3721F84F8 for ; Sat, 7 Apr 2012 12:49:30 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 3215EF24027 for ; Sat, 7 Apr 2012 15:49:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 6ywXe7kAn4dm for ; Sat, 7 Apr 2012 15:49:27 -0400 (EDT) Received: from [192.168.2.102] (pool-96-255-13-167.washdc.fios.verizon.net [96.255.13.167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8BE14F24014 for ; Sat, 7 Apr 2012 15:49:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Russ Housley In-Reply-To: Date: Sat, 7 Apr 2012 15:49:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <71E02FB2-0962-42CB-8D5D-64E874C36C0B@vigilsec.com> References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> <363FBDD8-9103-4A5C-92EA-89F0ABFF2566@vigilsec.com> To: IETF PKIX X-Mailer: Apple Mail (2.1084) Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 19:49:31 -0000 >>> While Apple's OS X (desktop) implementation will not choke if Name >>> Constraints is marked critical, it does not support processing name >>> constraints and will not enforce them - critical or not. It does not = quite >>> implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 = require >>> that it fail processing if it does not process a critical extension >>> (although 5280 does). >>=20 >> RFC 2459 says: >>=20 >> ... A >> certificate using system MUST reject the certificate if it = encounters >> a critical extension it does not recognize; however, a non-critical >> extension may be ignored if it is not recognized. ... >>=20 >> So, this is not a concept that was added in RFC 3280 or 5280. >>=20 > Isn't it an X509v3 requirement in any case? Indeed, but many people implement solely form the information in the = RFCs. This requirement has been in the RFCs from the beginning. Russ From kyanha@kyanha.net Sat Apr 7 13:43:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E213821F84CD for ; Sat, 7 Apr 2012 13:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+xWZJUJEvRs for ; Sat, 7 Apr 2012 13:43:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C75421F852B for ; Sat, 7 Apr 2012 13:43:54 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so4962758obb.31 for ; Sat, 07 Apr 2012 13:43:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=TiIsM1NsHkTpHCbWqOLIsdg9oCdypeM9oZyIgcrwLEY=; b=V4KEAGT2ibGlVJvVj8+mwuseYuRNWJ2GoDkiODTYUfGKz1TT6QYH5x5o8+M4z7dN5b DtFSoeBw0yzePnDYsfjztn+90yQDt+XunBj4/wwO4XIix4GI7eq1sDWFwoogkqkCutoF JfO/3gmWgioPnuvlXmKc4Nfvpu/G9djwZUrpQbXjz9D5T4IZw5FcBY3s6N6+DEp9CCRk 9EwLWTrBUH6F1qIYztFgFZ0Bp/L+bcCAcBqaWHW3AFB0BU2Ag/0wqI2rKek3f6JV5Kly gvQ8Se/+gMTILboxH9DXt78neyYlcN17takZ+VW9gS1dgACpKmjxXfrpj3Z/s+SqB1u3 KvTw== MIME-Version: 1.0 Received: by 10.60.20.230 with SMTP id q6mr3215413oee.60.1333831433885; Sat, 07 Apr 2012 13:43:53 -0700 (PDT) Received: by 10.60.147.196 with HTTP; Sat, 7 Apr 2012 13:43:53 -0700 (PDT) In-Reply-To: <4F7B6055.7020900@nist.gov> References: <201204021848.q32ImEnH028123@fs4113.wdf.sap.corp> <4F7B6055.7020900@nist.gov> Date: Sat, 7 Apr 2012 13:43:53 -0700 Message-ID: From: Kyle Hamilton To: "David A. Cooper" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm6KkDo1pX/xjt18vwwmW3N281/dKDq2cFzqtfAz9Y8gtexO4HZyK7QMo1y35dwu0AR3O0b Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 20:43:55 -0000 On Tue, Apr 3, 2012 at 1:40 PM, David A. Cooper wro= te: > While it may be true in a hierarchical PKI that a hierarchically superior= CA > may procedurally impose restrictions on the certificates that may be issu= ed > by its subordinate CAs and then may include constraints extensions that > reflect those restrictions, it would be incorrect to suggest that > constraints extensions always work this way. > =A0The nameConstraints extension in the cross-certificate would not be a > promise to the RP that no CA in the Federal PKI will issue outside of the > constraint, nor is it an indication that any certificates issued outside = the > constraint are illegitimate or a "violation." =A0The nameConstraints exte= nsion > would only indicate that DoD does not want its relying parties to accept > certificates that are outside of the constraint. X.509 itself doesn't mandate criticality. Compliant parsers cannot complain about it being non-critical. I've changed my mind: I support dropping the MUST criticality requirement. There isn't anything out there that can legitimately complain about its noncriticality, so there is very little sense in destroying what modicum of interoperability actually does exist. The reason why we're having so many problems here is because the participants on this list have yet to realize that there is no One True Profile. Apple implemented X.509, not PKIX. -Kyle H From kyanha@kyanha.net Sat Apr 7 13:53:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC43121F8550 for ; Sat, 7 Apr 2012 13:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-vBKTUWg2Lm for ; Sat, 7 Apr 2012 13:53:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9D2021F8546 for ; Sat, 7 Apr 2012 13:53:34 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so4968225obb.31 for ; Sat, 07 Apr 2012 13:53:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=iZfTUr6i0mdHT+X/bygc3o5QtipqOu8TQxLo/XQ4zjI=; b=lK6eezm0UkpB1DvUVHkITUoXwNuH7dGhDws6lNqSnOooPGxl1oqc9XXw1QIRp3ILdG M41mKjPEO/7Fe/cj5vgjUnE8pnvIaC7FLQzYKemGJSA5mcUQlgJzSIy1Ckum9ZUxyD7a mm4vYePshXIlSTnb1+UopqIu6Wfi7gyqbW2T1ZkFJrFulvEomoZ0RM8vCsTcI1gbcgCy ttH2TT/wRdKGfRFnVy96tj7t5lzK3lB2As4c3+YOpEdY5Z5nhyUyUnrYT2VtX68mk5X2 Y8GEGE+6vCQd/BsENrdhYfL8ITFAE9f+QCYuMmu3dyMFLfS9DfanxsgUslm0ZRuSoJ1i e8+w== MIME-Version: 1.0 Received: by 10.182.141.9 with SMTP id rk9mr3185947obb.50.1333832014571; Sat, 07 Apr 2012 13:53:34 -0700 (PDT) Received: by 10.60.147.196 with HTTP; Sat, 7 Apr 2012 13:53:34 -0700 (PDT) In-Reply-To: References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> <363FBDD8-9103-4A5C-92EA-89F0ABFF2566@vigilsec.com> Date: Sat, 7 Apr 2012 13:53:34 -0700 Message-ID: From: Kyle Hamilton To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmkvgCnfej1wb6qclDzSIJsZcyh7n0/ahMA/+sSfId5wnbTxBSR022bwxxedQ2C0k/dhjJw Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 20:53:35 -0000 Nope. X.509/2008 page 33, section 8.4.2.2: [...] This extension may, at the option of the certificate issuer, be either critical or non-critical . It is recommended that it be flagged critical, otherwise a certificate user may not check that subsequent certificates in a certification path are located in the name space intended by the issuing CA. [...] The criticality mandate is all PKIX. -Kyle H On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker wr= ote: > Isn't it an X509v3 requirement in any case? > > On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley wrote= : >> Ryan: >> >>> While Apple's OS X (desktop) implementation will not choke if Name >>> Constraints is marked critical, it does not support processing name >>> constraints and will not enforce them - critical or not. It does not qu= ite >>> implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 requir= e >>> that it fail processing if it does not process a critical extension >>> (although 5280 does). >> >> RFC 2459 says: >> >> =A0 ... =A0A >> =A0 certificate using system MUST reject the certificate if it encounter= s >> =A0 a critical extension it does not recognize; however, a non-critical >> =A0 extension may be ignored if it is not recognized. =A0... >> >> So, this is not a concept that was added in RFC 3280 or 5280. >> >> Russ >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From paul.hoffman@vpnc.org Sat Apr 7 14:04:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9194D21F8548 for ; Sat, 7 Apr 2012 14:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9HVu0oFfIv0 for ; Sat, 7 Apr 2012 14:04:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D26C21F8546 for ; Sat, 7 Apr 2012 14:04:29 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q37L4Rha084639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 7 Apr 2012 14:04:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Sat, 7 Apr 2012 14:04:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <27721ED0-215B-4C7F-B008-5C5ED8A31F86@vpnc.org> References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> <50A44A48-7103-4461-B937-E044087C7758@mitre.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1257) Cc: PKIX PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 21:04:30 -0000 On Apr 7, 2012, at 12:42 PM, Phillip Hallam-Baker wrote: > What is being discussed here is not what the idea state of PKI should > be but whether the PKIX specification should allow CAs the flexibility > to deal with real world security tradeoffs as they see best. Earlier, you said that the CABrowser forum was going to do this work. If = you want the CABrowser forum to do the work, we don't have to discuss it = in this WG. However, this text sounds like you want this WG to do the = work (presumably under its current procedures, leadership, and history). Can you be more specific about who you think is going to do the work? --Paul Hoffman From eabalea@gmail.com Sat Apr 7 14:15:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026EC21F8565 for ; Sat, 7 Apr 2012 14:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVf1D1W5Hbts for ; Sat, 7 Apr 2012 14:15:06 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4D5D21F855D for ; Sat, 7 Apr 2012 14:15:05 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1715693ggm.31 for ; Sat, 07 Apr 2012 14:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A0iWTEWaANRLjNT6ECQiO919OY/th6z6PNhULCXxMbc=; b=gNu7sWJIudvb30FQODamTtnCIZx/86ilGeVj1M/bscBHnM+1xg5WXoKMspv2SN/4FW QyI0Ce0myi48VXvwzG0fiQp5SGYiGDoNk2/P3K2DYfxOLcALhYDm5QiMF5esILR5fs77 BdFoHg49A3Urf2of0TrUnops+O1TXhdabMhIK+cQCjM37ZlD9RM1s7oV3HmQwHClXwnF EBz54XMHAElJoHKIYC3l7su4NKk7CIaaSiHowOkS4AnvTiT5UEIupKWENSLApPRtxiza cq6rvGuPITwNKwVVHOLcYPOlLN8+DMwJTB8uX32O3y7TS5kSsoXBvpqI15AXticmNl8S sEag== MIME-Version: 1.0 Received: by 10.236.192.164 with SMTP id i24mr1951583yhn.9.1333833305492; Sat, 07 Apr 2012 14:15:05 -0700 (PDT) Received: by 10.236.76.199 with HTTP; Sat, 7 Apr 2012 14:15:05 -0700 (PDT) In-Reply-To: References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> <18a0a280b02bdaffdcc0cef5624f3b9b.squirrel@webmail.dreamhost.com> <363FBDD8-9103-4A5C-92EA-89F0ABFF2566@vigilsec.com> Date: Sat, 7 Apr 2012 23:15:05 +0200 Message-ID: From: Erwann Abalea To: Kyle Hamilton Content-Type: multipart/alternative; boundary=20cf305642d75d0d0504bd1d44db Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 21:15:07 -0000 --20cf305642d75d0d0504bd1d44db Content-Type: text/plain; charset=UTF-8 I think the "X.509 requirement in any case" is to reject any certificate containing an unknown critical extension. 2012/4/7 Kyle Hamilton > Nope. X.509/2008 page 33, section 8.4.2.2: > [...] > This extension may, at the option of the certificate issuer, be either > critical or non-critical . It is recommended that it be > flagged critical, otherwise a certificate user may not check that > subsequent certificates in a certification path are located > in the name space intended by the issuing CA. > [...] > > The criticality mandate is all PKIX. > > -Kyle H > > On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker > wrote: > > Isn't it an X509v3 requirement in any case? > > > > On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley > wrote: > >> Ryan: > >> > >>> While Apple's OS X (desktop) implementation will not choke if Name > >>> Constraints is marked critical, it does not support processing name > >>> constraints and will not enforce them - critical or not. It does not > quite > >>> implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 > require > >>> that it fail processing if it does not process a critical extension > >>> (although 5280 does). > >> > >> RFC 2459 says: > >> > >> ... A > >> certificate using system MUST reject the certificate if it encounters > >> a critical extension it does not recognize; however, a non-critical > >> extension may be ignored if it is not recognized. ... > >> > >> So, this is not a concept that was added in RFC 3280 or 5280. > >> > >> Russ > >> _______________________________________________ > >> pkix mailing list > >> pkix@ietf.org > >> https://www.ietf.org/mailman/listinfo/pkix > > > > > > > > -- > > Website: http://hallambaker.com/ > > _______________________________________________ > > 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. --20cf305642d75d0d0504bd1d44db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the "X.509 requirement in any case" is to reject any cert= ificate containing an unknown critical extension.

2012/4/7 Kyle Hamilton <kyanha@kyanha.net>
Nope. =C2=A0X.509/2008 page 33, section 8.4.2.2:
[...]
This extension may, at the option of the certificate issuer, be either
critical or non-critical . It is recommended that it be
flagged critical, otherwise a certificate user may not check that
subsequent certificates in a certification path are located
in the name space intended by the issuing CA.
[...]

The criticality mandate is all PKIX.

-Kyle H

On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> Isn't it an X509v3 requirement in any case?
>
> On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley <housley@vigilsec.com> wrote:
>> Ryan:
>>
>>> While Apple's OS X (desktop) implementation will not choke= if Name
>>> Constraints is marked critical, it does not support processing= name
>>> constraints and will not enforce them - critical or not. It do= es not quite
>>> implement all of RFC 2459, let alone 3280 or 5280, nor does 24= 59 require
>>> that it fail processing if it does not process a critical exte= nsion
>>> (although 5280 does).
>>
>> RFC 2459 says:
>>
>> =C2=A0 ... =C2=A0A
>> =C2=A0 certificate using system MUST reject the certificate if it = encounters
>> =C2=A0 a critical extension it does not recognize; however, a non-= critical
>> =C2=A0 extension may be ignored if it is not recognized. =C2=A0...=
>>
>> So, this is not a concept that was added in RFC 3280 or 5280.
>>
>> Russ
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>
>
>
> --
> Website: http://= hallambaker.com/
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix



--
= Erwann.
--20cf305642d75d0d0504bd1d44db-- From stefan@aaa-sec.com Sat Apr 7 17:13:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFB221F8562 for ; Sat, 7 Apr 2012 17:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzAYwsEWCkWN for ; Sat, 7 Apr 2012 17:13:21 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id B68B621F8595 for ; Sat, 7 Apr 2012 17:13:19 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id E7AD41E1C126 for ; Sun, 8 Apr 2012 02:11:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YNyvJF8w4ibj for ; Sun, 8 Apr 2012 02:11:21 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 709FC1E1C0EA for ; Sun, 8 Apr 2012 02:11:21 +0200 (CEST) Received: (qmail 71311 invoked from network); 8 Apr 2012 00:11:21 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.2]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Apr 2012 00:11:21 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sun, 08 Apr 2012 02:11:11 +0200 From: Stefan Santesson To: Kyle Hamilton , Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 00:13:22 -0000 Being away for some days, it was quite a read before anyone cared to look in the X.509 spec :) I regret the flaming in this thread, enough said about that. I believe PKIX made a mistake requiring CAs to mark this extension critical, while X.509 allows it to be non-critical. The requirement does not affect client behavior (thoroughly examined in this thread). It just imposes policy on the CA that actually should be up to the CA to decide. A CA that concludes that criticality is important, can always set it critical. IOS as well as OS X are clearly not compliant with RFC 5280, but that is not a good argument to require criticality. /Stefan On 12-04-07 10:53 PM, "Kyle Hamilton" wrote: >Nope. X.509/2008 page 33, section 8.4.2.2: >[...] >This extension may, at the option of the certificate issuer, be either >critical or non-critical . It is recommended that it be >flagged critical, otherwise a certificate user may not check that >subsequent certificates in a certification path are located >in the name space intended by the issuing CA. >[...] > >The criticality mandate is all PKIX. > >-Kyle H > >On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker >wrote: >> Isn't it an X509v3 requirement in any case? >> >> On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley >>wrote: >>> Ryan: >>> >>>> While Apple's OS X (desktop) implementation will not choke if Name >>>> Constraints is marked critical, it does not support processing name >>>> constraints and will not enforce them - critical or not. It does not >>>>quite >>>> implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 >>>>require >>>> that it fail processing if it does not process a critical extension >>>> (although 5280 does). >>> >>> RFC 2459 says: >>> >>> ... A >>> certificate using system MUST reject the certificate if it encounters >>> a critical extension it does not recognize; however, a non-critical >>> extension may be ignored if it is not recognized. ... >>> >>> So, this is not a concept that was added in RFC 3280 or 5280. >>> >>> Russ >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> 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 SChokhani@cygnacom.com Sun Apr 8 12:09:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D0C21F854D for ; Sun, 8 Apr 2012 12:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNk45JjZS0vY for ; Sun, 8 Apr 2012 12:09:27 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id E608121F855F for ; Sun, 8 Apr 2012 12:09:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,390,1330923600"; d="scan'208";a="4645874" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 08 Apr 2012 15:09:26 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sun, 8 Apr 2012 15:09:25 -0400 From: Santosh Chokhani To: Stefan Santesson , Kyle Hamilton , Phillip Hallam-Baker Date: Sun, 8 Apr 2012 15:09:24 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0VHG+5XWK5F6fHRVqWeI8DpR70ggAnkHgQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 19:09:28 -0000 Stefan, Consider the following facts: 1. X.509 does not require any of the certificate extensions to be critical= . 2. 5280 is a profile of X.509 as the very first sentence of 5280 abstract = says. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ste= fan Santesson Sent: Saturday, April 07, 2012 8:11 PM To: Kyle Hamilton; Phillip Hallam-Baker Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Being away for some days, it was quite a read before anyone cared to look i= n the X.509 spec :) I regret the flaming in this thread, enough said about that. I believe PKIX made a mistake requiring CAs to mark this extension critical= , while X.509 allows it to be non-critical. The requirement does not affect client behavior (thoroughly examined in thi= s thread). It just imposes policy on the CA that actually should be up to t= he CA to decide. A CA that concludes that criticality is important, can alw= ays set it critical. IOS as well as OS X are clearly not compliant with RFC 5280, but that is no= t a good argument to require criticality. /Stefan On 12-04-07 10:53 PM, "Kyle Hamilton" wrote: >Nope. X.509/2008 page 33, section 8.4.2.2: >[...] >This extension may, at the option of the certificate issuer, be either=20 >critical or non-critical . It is recommended that it be flagged=20 >critical, otherwise a certificate user may not check that subsequent=20 >certificates in a certification path are located in the name space=20 >intended by the issuing CA. >[...] > >The criticality mandate is all PKIX. > >-Kyle H > >On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker=20 > >wrote: >> Isn't it an X509v3 requirement in any case? >> >> On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley >>wrote: >>> Ryan: >>> >>>> While Apple's OS X (desktop) implementation will not choke if Name =20 >>>>Constraints is marked critical, it does not support processing name =20 >>>>constraints and will not enforce them - critical or not. It does not=20 >>>>quite implement all of RFC 2459, let alone 3280 or 5280, nor does=20 >>>>2459 require that it fail processing if it does not process a=20 >>>>critical extension (although 5280 does). >>> >>> RFC 2459 says: >>> >>> ... A >>> certificate using system MUST reject the certificate if it encounters >>> a critical extension it does not recognize; however, a non-critical >>> extension may be ignored if it is not recognized. ... >>> >>> So, this is not a concept that was added in RFC 3280 or 5280. >>> >>> Russ >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> 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 stefan@aaa-sec.com Sun Apr 8 13:47:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CF021F84FA for ; Sun, 8 Apr 2012 13:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ3SP3+HLNyK for ; Sun, 8 Apr 2012 13:47:41 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 798E721F84F4 for ; Sun, 8 Apr 2012 13:47:40 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id F284E1D7DBA7 for ; Sun, 8 Apr 2012 22:47:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RNVItEYqcofj for ; Sun, 8 Apr 2012 22:47:38 +0200 (CEST) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 8DC971D7C774 for ; Sun, 8 Apr 2012 22:47:38 +0200 (CEST) Received: (qmail 17282 invoked from network); 8 Apr 2012 20:47:38 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.204]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Apr 2012 20:47:38 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sun, 08 Apr 2012 22:47:12 +0200 From: Stefan Santesson To: Santosh Chokhani , Kyle Hamilton , Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 20:47:42 -0000 Santosh, I have considered that. Neither of these facts are in my mind any good reason for requiring criticality. /Stefan On 12-04-08 9:09 PM, "Santosh Chokhani" wrote: >Stefan, > >Consider the following facts: > >1. X.509 does not require any of the certificate extensions to be >critical. > >2. 5280 is a profile of X.509 as the very first sentence of 5280 >abstract says. > >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Stefan Santesson >Sent: Saturday, April 07, 2012 8:11 PM >To: Kyle Hamilton; Phillip Hallam-Baker >Cc: IETF PKIX >Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > >Being away for some days, it was quite a read before anyone cared to look >in the X.509 spec :) > >I regret the flaming in this thread, enough said about that. > >I believe PKIX made a mistake requiring CAs to mark this extension >critical, while X.509 allows it to be non-critical. > >The requirement does not affect client behavior (thoroughly examined in >this thread). It just imposes policy on the CA that actually should be up >to the CA to decide. A CA that concludes that criticality is important, >can always set it critical. > >IOS as well as OS X are clearly not compliant with RFC 5280, but that is >not a good argument to require criticality. > >/Stefan > > >On 12-04-07 10:53 PM, "Kyle Hamilton" wrote: > >>Nope. X.509/2008 page 33, section 8.4.2.2: >>[...] >>This extension may, at the option of the certificate issuer, be either >>critical or non-critical . It is recommended that it be flagged >>critical, otherwise a certificate user may not check that subsequent >>certificates in a certification path are located in the name space >>intended by the issuing CA. >>[...] >> >>The criticality mandate is all PKIX. >> >>-Kyle H >> >>On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker >> >>wrote: >>> Isn't it an X509v3 requirement in any case? >>> >>> On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley >>>wrote: >>>> Ryan: >>>> >>>>> While Apple's OS X (desktop) implementation will not choke if Name >>>>>Constraints is marked critical, it does not support processing name >>>>>constraints and will not enforce them - critical or not. It does not >>>>>quite implement all of RFC 2459, let alone 3280 or 5280, nor does >>>>>2459 require that it fail processing if it does not process a >>>>>critical extension (although 5280 does). >>>> >>>> RFC 2459 says: >>>> >>>> ... A >>>> certificate using system MUST reject the certificate if it >>>>encounters >>>> a critical extension it does not recognize; however, a non-critical >>>> extension may be ignored if it is not recognized. ... >>>> >>>> So, this is not a concept that was added in RFC 3280 or 5280. >>>> >>>> Russ >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ >>> _______________________________________________ >>> 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 SChokhani@cygnacom.com Sun Apr 8 14:53:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3C221F8537 for ; Sun, 8 Apr 2012 14:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+oD+-X5slfm for ; Sun, 8 Apr 2012 14:53:22 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id E5CE721F8527 for ; Sun, 8 Apr 2012 14:53:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,391,1330923600"; d="scan'208";a="721114" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 08 Apr 2012 17:53:06 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sun, 8 Apr 2012 17:53:06 -0400 From: Santosh Chokhani To: Stefan Santesson , Kyle Hamilton , Phillip Hallam-Baker Date: Sun, 8 Apr 2012 17:53:05 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0VyN30ggpT+YAWRqyBdVeeI2sSKwACPo0Q Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 21:53:22 -0000 Stefan, What is your reason for making it non critical? -----Original Message----- From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Sunday, April 08, 2012 4:47 PM To: Santosh Chokhani; Kyle Hamilton; Phillip Hallam-Baker Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Santosh, I have considered that. Neither of these facts are in my mind any good reas= on for requiring criticality. /Stefan On 12-04-08 9:09 PM, "Santosh Chokhani" wrote: >Stefan, > >Consider the following facts: > >1. X.509 does not require any of the certificate extensions to be=20 >critical. > >2. 5280 is a profile of X.509 as the very first sentence of 5280=20 >abstract says. > >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of=20 >Stefan Santesson >Sent: Saturday, April 07, 2012 8:11 PM >To: Kyle Hamilton; Phillip Hallam-Baker >Cc: IETF PKIX >Subject: Re: [pkix] Proposal: Change the Criticality Requirement of=20 >Name > >Being away for some days, it was quite a read before anyone cared to=20 >look in the X.509 spec :) > >I regret the flaming in this thread, enough said about that. > >I believe PKIX made a mistake requiring CAs to mark this extension=20 >critical, while X.509 allows it to be non-critical. > >The requirement does not affect client behavior (thoroughly examined in=20 >this thread). It just imposes policy on the CA that actually should be=20 >up to the CA to decide. A CA that concludes that criticality is=20 >important, can always set it critical. > >IOS as well as OS X are clearly not compliant with RFC 5280, but that=20 >is not a good argument to require criticality. > >/Stefan > > >On 12-04-07 10:53 PM, "Kyle Hamilton" wrote: > >>Nope. X.509/2008 page 33, section 8.4.2.2: >>[...] >>This extension may, at the option of the certificate issuer, be either=20 >>critical or non-critical . It is recommended that it be flagged=20 >>critical, otherwise a certificate user may not check that subsequent=20 >>certificates in a certification path are located in the name space=20 >>intended by the issuing CA. >>[...] >> >>The criticality mandate is all PKIX. >> >>-Kyle H >> >>On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker=20 >> >>wrote: >>> Isn't it an X509v3 requirement in any case? >>> >>> On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley >>>wrote: >>>> Ryan: >>>> >>>>> While Apple's OS X (desktop) implementation will not choke if Name=20 >>>>>Constraints is marked critical, it does not support processing name=20 >>>>>constraints and will not enforce them - critical or not. It does=20 >>>>>not quite implement all of RFC 2459, let alone 3280 or 5280, nor=20 >>>>>does >>>>>2459 require that it fail processing if it does not process a=20 >>>>>critical extension (although 5280 does). >>>> >>>> RFC 2459 says: >>>> >>>> ... A >>>> certificate using system MUST reject the certificate if it=20 >>>>encounters >>>> a critical extension it does not recognize; however, a non-critical >>>> extension may be ignored if it is not recognized. ... >>>> >>>> So, this is not a concept that was added in RFC 3280 or 5280. >>>> >>>> Russ >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ >>> _______________________________________________ >>> 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 stefan@aaa-sec.com Sun Apr 8 15:24:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41C221F8503 for ; Sun, 8 Apr 2012 15:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpVi3SU253Y4 for ; Sun, 8 Apr 2012 15:24:20 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 8B25621F84FB for ; Sun, 8 Apr 2012 15:24:20 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 2B9AB1D9791E for ; Mon, 9 Apr 2012 00:24:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hf_bzeiZtXSC for ; Mon, 9 Apr 2012 00:24:18 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A64C21DCA1B1 for ; Mon, 9 Apr 2012 00:24:18 +0200 (CEST) Received: (qmail 37156 invoked from network); 8 Apr 2012 22:24:18 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.204]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Apr 2012 22:24:18 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 09 Apr 2012 00:24:03 +0200 From: Stefan Santesson To: Santosh Chokhani , Kyle Hamilton , Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 22:24:22 -0000 Santosh, Not proposing making it non-critical. Relaxing the SHALL requirement to a SHOULD would be appropriate. The reason is what I recently posted. I see no cons with a SHALL requirement. Neither from a security nor from an interop perspective. Relaxing SHALL to SHOULD: - Does not affect the way RPs process and enforce the extension (regardless of criticality). - RPs can protect their interests by correctly implementing the extension - CAs can protect their interests by setting the extension critical. - No harm is done to any defenseless third party. What do you think is missing? What, if anything, is your reasons for defending a SHALL requirement. /Stefan On 12-04-08 11:53 PM, "Santosh Chokhani" wrote: >Stefan, > >What is your reason for making it non critical? > >-----Original Message----- >From: Stefan Santesson [mailto:stefan@aaa-sec.com] >Sent: Sunday, April 08, 2012 4:47 PM >To: Santosh Chokhani; Kyle Hamilton; Phillip Hallam-Baker >Cc: IETF PKIX >Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > >Santosh, > >I have considered that. Neither of these facts are in my mind any good >reason for requiring criticality. > >/Stefan > >On 12-04-08 9:09 PM, "Santosh Chokhani" wrote: > >>Stefan, >> >>Consider the following facts: >> >>1. X.509 does not require any of the certificate extensions to be >>critical. >> >>2. 5280 is a profile of X.509 as the very first sentence of 5280 >>abstract says. >> >>-----Original Message----- >>From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>Stefan Santesson >>Sent: Saturday, April 07, 2012 8:11 PM >>To: Kyle Hamilton; Phillip Hallam-Baker >>Cc: IETF PKIX >>Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>Name >> >>Being away for some days, it was quite a read before anyone cared to >>look in the X.509 spec :) >> >>I regret the flaming in this thread, enough said about that. >> >>I believe PKIX made a mistake requiring CAs to mark this extension >>critical, while X.509 allows it to be non-critical. >> >>The requirement does not affect client behavior (thoroughly examined in >>this thread). It just imposes policy on the CA that actually should be >>up to the CA to decide. A CA that concludes that criticality is >>important, can always set it critical. >> >>IOS as well as OS X are clearly not compliant with RFC 5280, but that >>is not a good argument to require criticality. >> >>/Stefan >> >> >>On 12-04-07 10:53 PM, "Kyle Hamilton" wrote: >> >>>Nope. X.509/2008 page 33, section 8.4.2.2: >>>[...] >>>This extension may, at the option of the certificate issuer, be either >>>critical or non-critical . It is recommended that it be flagged >>>critical, otherwise a certificate user may not check that subsequent >>>certificates in a certification path are located in the name space >>>intended by the issuing CA. >>>[...] >>> >>>The criticality mandate is all PKIX. >>> >>>-Kyle H >>> >>>On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker >>> >>>wrote: >>>> Isn't it an X509v3 requirement in any case? >>>> >>>> On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley >>>>wrote: >>>>> Ryan: >>>>> >>>>>> While Apple's OS X (desktop) implementation will not choke if Name >>>>>>Constraints is marked critical, it does not support processing name >>>>>>constraints and will not enforce them - critical or not. It does >>>>>>not quite implement all of RFC 2459, let alone 3280 or 5280, nor >>>>>>does >>>>>>2459 require that it fail processing if it does not process a >>>>>>critical extension (although 5280 does). >>>>> >>>>> RFC 2459 says: >>>>> >>>>> ... A >>>>> certificate using system MUST reject the certificate if it >>>>>encounters >>>>> a critical extension it does not recognize; however, a non-critical >>>>> extension may be ignored if it is not recognized. ... >>>>> >>>>> So, this is not a concept that was added in RFC 3280 or 5280. >>>>> >>>>> Russ >>>>> _______________________________________________ >>>>> pkix mailing list >>>>> pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>>> >>>> >>>> -- >>>> Website: http://hallambaker.com/ >>>> _______________________________________________ >>>> 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 hallam@gmail.com Sun Apr 8 16:13:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC9D21F8584 for ; Sun, 8 Apr 2012 16:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ubZ6Q2pqB7k for ; Sun, 8 Apr 2012 16:13:59 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C97121F8557 for ; Sun, 8 Apr 2012 16:13:55 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1867089ghb.31 for ; Sun, 08 Apr 2012 16:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Qm94BpXXKI+M1/tHk2B8yduhi6WGXvVH72XK+/QJ2uM=; b=v8DCGEIGKyi0VQangcgIQ1bLBjD1pvtjKMGy1akELPcS+Fij/XqAhZy36rmyFAF2HC Sn3NbJ6AwDIXUXBt6PAE2oTIuYgQkJa5uEDL23k8e/8GZ7q1wFyaQp6tjJuSVquu4Frq +ZB4s0z/aR2y3XH4snKs6fy3suLXAOBNIu2nx2O8TnkjoLmLURkNb1ZdqClTseUZItUP kcSxPRDeYL/NUPKnxOnu+OdvtsxFJshWEkBBIGEhFpILVHKOfxMBD0AJKONHdnY5yx4W uLoZbLvUEPT2JmIXebc6iExgB4r5AtfdR0ll6PGMCPJbWtw/lYCN4m9tmVVxU256yNVV gnpA== MIME-Version: 1.0 Received: by 10.236.170.70 with SMTP id o46mr4249703yhl.122.1333926834774; Sun, 08 Apr 2012 16:13:54 -0700 (PDT) Received: by 10.147.11.5 with HTTP; Sun, 8 Apr 2012 16:13:54 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 Apr 2012 19:13:54 -0400 Message-ID: From: Phillip Hallam-Baker To: Stefan Santesson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 23:13:59 -0000 Exactly, nobody is suggesting that the requirement prohibit setting this extension critical. If your think your security needs indicate it should be critical, then mark it so. Our needs can only be met by not marking it critical so we have the following choices: 1) Don't use name constraints at all 2) Use name constraints without marking them critical The lack of understanding of the criticality flag in PKIX is the reason that I wrote the SAML spec with 'Conditions' instead. The only extensions that should ever be marked critical in my view are extensions that specify conditions that affect the validity of the assertion. In the case of X.509v3 that would be a revocation condition. On Sun, Apr 8, 2012 at 6:24 PM, Stefan Santesson wrote= : > Santosh, > > Not proposing making it non-critical. Relaxing the SHALL requirement to a > SHOULD would be appropriate. > > The reason is what I recently posted. I see no cons with a SHALL > requirement. Neither from a security nor from an interop perspective. > > Relaxing SHALL to SHOULD: > - Does not affect the way RPs process and enforce the extension > (regardless of criticality). > - RPs can protect their interests by correctly implementing the extension > - CAs can protect their interests by setting the extension critical. > - No harm is done to any defenseless third party. > > What do you think is missing? > What, if anything, is your reasons for defending a SHALL requirement. > > /Stefan > > On 12-04-08 11:53 PM, "Santosh Chokhani" wrote: > >>Stefan, >> >>What is your reason for making it non critical? >> >>-----Original Message----- >>From: Stefan Santesson [mailto:stefan@aaa-sec.com] >>Sent: Sunday, April 08, 2012 4:47 PM >>To: Santosh Chokhani; Kyle Hamilton; Phillip Hallam-Baker >>Cc: IETF PKIX >>Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name >> >>Santosh, >> >>I have considered that. Neither of these facts are in my mind any good >>reason for requiring criticality. >> >>/Stefan >> >>On 12-04-08 9:09 PM, "Santosh Chokhani" wrote: >> >>>Stefan, >>> >>>Consider the following facts: >>> >>>1. =A0X.509 does not require any of the certificate extensions to be >>>critical. >>> >>>2. =A05280 is a profile of X.509 as the very first sentence of 5280 >>>abstract says. >>> >>>-----Original Message----- >>>From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>>Stefan Santesson >>>Sent: Saturday, April 07, 2012 8:11 PM >>>To: Kyle Hamilton; Phillip Hallam-Baker >>>Cc: IETF PKIX >>>Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >>>Name >>> >>>Being away for some days, it was quite a read before anyone cared to >>>look in the X.509 spec :) >>> >>>I regret the flaming in this thread, enough said about that. >>> >>>I believe PKIX made a mistake requiring CAs to mark this extension >>>critical, while X.509 allows it to be non-critical. >>> >>>The requirement does not affect client behavior (thoroughly examined in >>>this thread). It just imposes policy on the CA that actually should be >>>up to the CA to decide. A CA that concludes that criticality is >>>important, can always set it critical. >>> >>>IOS as well as OS X are clearly not compliant with RFC 5280, but that >>>is not a good argument to require criticality. >>> >>>/Stefan >>> >>> >>>On 12-04-07 10:53 PM, "Kyle Hamilton" wrote: >>> >>>>Nope. =A0X.509/2008 page 33, section 8.4.2.2: >>>>[...] >>>>This extension may, at the option of the certificate issuer, be either >>>>critical or non-critical . It is recommended that it be flagged >>>>critical, otherwise a certificate user may not check that subsequent >>>>certificates in a certification path are located in the name space >>>>intended by the issuing CA. >>>>[...] >>>> >>>>The criticality mandate is all PKIX. >>>> >>>>-Kyle H >>>> >>>>On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker >>>> >>>>wrote: >>>>> Isn't it an X509v3 requirement in any case? >>>>> >>>>> On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley >>>>>wrote: >>>>>> Ryan: >>>>>> >>>>>>> While Apple's OS X (desktop) implementation will not choke if Name >>>>>>>Constraints is marked critical, it does not support processing name >>>>>>>constraints and will not enforce them - critical or not. It does >>>>>>>not quite =A0implement all of RFC 2459, let alone 3280 or 5280, nor >>>>>>>does >>>>>>>2459 require =A0that it fail processing if it does not process a >>>>>>>critical extension =A0(although 5280 does). >>>>>> >>>>>> RFC 2459 says: >>>>>> >>>>>> =A0 ... =A0A >>>>>> =A0 certificate using system MUST reject the certificate if it >>>>>>encounters >>>>>> =A0 a critical extension it does not recognize; however, a non-criti= cal >>>>>> =A0 extension may be ignored if it is not recognized. =A0... >>>>>> >>>>>> So, this is not a concept that was added in RFC 3280 or 5280. >>>>>> >>>>>> Russ >>>>>> _______________________________________________ >>>>>> pkix mailing list >>>>>> pkix@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pkix >>>>> >>>>> >>>>> >>>>> -- >>>>> Website: http://hallambaker.com/ >>>>> _______________________________________________ >>>>> 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 >> >> > > --=20 Website: http://hallambaker.com/ From stephen.farrell@cs.tcd.ie Sun Apr 8 16:26:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18F421F847C for ; Sun, 8 Apr 2012 16:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rkRByW3tpCU for ; Sun, 8 Apr 2012 16:26:57 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 23B1121F847A for ; Sun, 8 Apr 2012 16:26:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A6D2F171477; Mon, 9 Apr 2012 00:26:54 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333927614; bh=iZW9/L1+kzcsA7 Qt+1TynSpoRyjK51U6Vkdn0Uq7LPE=; b=DIeARCz3CRg4o+ASVtpQfDTrebagB1 E/WcAKoVYCKxFfo0odaGLQzVshWvr+xK3hU7JppQzg4Qwn661aBMRSz7XBK6ytcu nJkhf9PKU6VURuqMpYhUYPLdrA5VQE1yu/v/eduNvw51Pcp1yberW+QC6Xlu2ppS mZI6a4AZa89qshBsIsVhKt9CWwCjwzBl171t4GU2BXWGSIMDobVbVdJh9tfMmlmj QhFIorWbCnVf6buV9KhQJt/GK0B1sJ1gMmyzfs1TkvslOafzRDQiORoUOGw97s4g E4RT5AuKkp6M7Cri+jWsY9Kbx74icDLcw4G9UAmtSKuyjsKm0fdnwXpw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id H6ZtP7WAHDoP; Mon, 9 Apr 2012 00:26:54 +0100 (IST) Received: from [10.87.48.4] (unknown [86.41.5.213]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D3CC7171471; Mon, 9 Apr 2012 00:26:52 +0100 (IST) Message-ID: <4F821EBB.5010506@cs.tcd.ie> Date: Mon, 09 Apr 2012 00:26:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stefan Santesson , IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 23:26:57 -0000 Hi Phill, On 04/09/2012 12:13 AM, Phillip Hallam-Baker wrote: > Our needs can only be met by not marking it critical I understand the need to work with deployed code. We can (dis)agree about its relative importance here, but I've a different question. I do not understand how a non-critical NC meets the need to prevent entreprise CAs issuing certs beyond the relevant scope. (RPs that don't support NC will be vulnerable, and presumably that's most-to-nearly-all RPs.) If you're saying that you don't have a need to prevent that, but only a need to detect it (e.g. via something like the ssl-observatory) then that seems to require a bigger change vs.5280. I've not looked at the text just now, but as I recall it, NC is designed for prevention and not for detection. Defining a new typically non-critical NC-like extension for detection would seem like the right thing to do. (And I'd imagine the putative new extension could have simpler syntax and more precise semantics for what is a now-real use-case:-) So, another question: why is not a new non-critical NC-like extension not better here? The ssl-observatory approach would work just as well with that. Cheers, S. From stefan@aaa-sec.com Sun Apr 8 16:54:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2B221F8546 for ; Sun, 8 Apr 2012 16:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6btyhlBiTnR for ; Sun, 8 Apr 2012 16:54:49 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id CF13521F853B for ; Sun, 8 Apr 2012 16:54:47 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 70B271DE9002 for ; Mon, 9 Apr 2012 01:54:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HSt1Vi-Pk8lJ for ; Mon, 9 Apr 2012 01:54:46 +0200 (CEST) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 28B881DE6F53 for ; Mon, 9 Apr 2012 01:54:46 +0200 (CEST) Received: (qmail 71035 invoked from network); 8 Apr 2012 23:54:46 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.204]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Apr 2012 23:54:46 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 09 Apr 2012 01:54:35 +0200 From: Stefan Santesson To: Stephen Farrell , Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: <4F821EBB.5010506@cs.tcd.ie> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 23:54:49 -0000 Stephen, A non critical setting would ensure that any 5280 compliant RP would enforce the NC, while allowing no conforming RPs to accept the cert chain at their own risk. Why would that never be a useful tradeoff? Given that Apple has failed to correctly implement the current extension in 10 years, I doubt that a new extension will solve the problems any better. Plus, I would hate to se two extensions solving the same problem in slightly different ways. /Stefan On 12-04-09 1:26 AM, "Stephen Farrell" wrote: > >Hi Phill, > >On 04/09/2012 12:13 AM, Phillip Hallam-Baker wrote: >> Our needs can only be met by not marking it critical > >I understand the need to work with deployed code. We >can (dis)agree about its relative importance here, but >I've a different question. > >I do not understand how a non-critical NC meets the >need to prevent entreprise CAs issuing certs beyond the >relevant scope. (RPs that don't support NC will be >vulnerable, and presumably that's most-to-nearly-all RPs.) > >If you're saying that you don't have a need to prevent >that, but only a need to detect it (e.g. via something like >the ssl-observatory) then that seems to require a bigger >change vs.5280. I've not looked at the text just now, but >as I recall it, NC is designed for prevention and not for >detection. > >Defining a new typically non-critical NC-like extension >for detection would seem like the right thing to do. (And >I'd imagine the putative new extension could have simpler >syntax and more precise semantics for what is a now-real >use-case:-) > >So, another question: why is not a new non-critical NC-like >extension not better here? The ssl-observatory approach would >work just as well with that. > >Cheers, >S. > From hallam@gmail.com Sun Apr 8 17:00:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEDC21F856A for ; Sun, 8 Apr 2012 17:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftTdIblgFBIf for ; Sun, 8 Apr 2012 17:00:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3E521F849C for ; Sun, 8 Apr 2012 17:00:55 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so5849762obb.31 for ; Sun, 08 Apr 2012 17:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lGbKiTPI04mD9DsNDsSEIcMLN2kqRMaofMqtH9t2Iqs=; b=dCvP6VBcB/NEzm76JSOKifH4olTissUjPBURTLMyqih3jzE8Rj8msUq9TsDCAZ0Iza ONFCJpyx35SMajSmq0ONkd8HyAuJDr+vytRjv7GLwCP/YknPflIR6sEqIyFgpPK8rCke /GNNNPtf8oQeG7ItkD2SIESdoLz9/ndUMkTN8zbJAkeas3cCh/gVKExdcv0xHyQi/AgH 4/MNBvzIe+8RSZaF42uZpHo34ij76SOkT8cuP17YRnpf7CrPBDLqDd/REw7D6U8oVLJh E83MsQggAiVPAOcksJ0ocGamjOfTrLHXF9asGIFdqQpGlJnd1kqqZof6PgHOO7MhLcOz 85Zg== MIME-Version: 1.0 Received: by 10.60.7.200 with SMTP id l8mr7391242oea.52.1333929655234; Sun, 08 Apr 2012 17:00:55 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Sun, 8 Apr 2012 17:00:55 -0700 (PDT) In-Reply-To: <4F821EBB.5010506@cs.tcd.ie> References: <4F821EBB.5010506@cs.tcd.ie> Date: Sun, 8 Apr 2012 20:00:55 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stefan Santesson , IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 00:00:56 -0000 On Sun, Apr 8, 2012 at 7:26 PM, Stephen Farrell wrote: > > Hi Phill, > > > On 04/09/2012 12:13 AM, Phillip Hallam-Baker wrote: >> >> =A0Our needs can only be met by not marking it critical > > > I understand the need to work with deployed code. We > can (dis)agree about its relative importance here, but > I've a different question. > > I do not understand how a non-critical NC meets the > need to prevent entreprise CAs issuing certs beyond the > relevant scope. (RPs that don't support NC will be > vulnerable, and presumably that's most-to-nearly-all RPs.) The spec is clear that either the extension must be processed or the cert rejected regardless of the NC flag if the client understands the extension. None of the clients checked appear to reject if the extension is not marked critical. > If you're saying that you don't have a need to prevent > that, but only a need to detect it (e.g. via something like > the ssl-observatory) then that seems to require a bigger > change vs.5280. I've not looked at the text just now, but > as I recall it, NC is designed for prevention and not for > detection. The desired outcome here is: * Clients that process NCs have protection * Clients that do not process NCs do not reject valid certs There are two issues here, false positives (reject a valid cert) and false negatives (accept a bogus cert). Since the number of false negatives has been negligible to date the false positives concern is considerably greater than the false negatives. It is unacceptable for a legacy client to reject a legitimate cert. > Defining a new typically non-critical NC-like extension > for detection would seem like the right thing to do. (And > I'd imagine the putative new extension could have simpler > syntax and more precise semantics for what is a now-real > use-case:-) That may be something that we would want to look at in addition. But 2012 is not 2010. We now have an active attacker and a very short time horizon. There is deployed code that can be used to provide a degree of protection now. > So, another question: why is not a new non-critical NC-like > extension not better here? The ssl-observatory approach would > work just as well with that. If nobody had implemented the old NC system that would make sense. But there are code paths we can and will use now. Why not change the SHALL on the legacy NC scheme to a SHOULD so that we can start using it now and then have a discussion on new proposals for NC like things? --=20 Website: http://hallambaker.com/ From stephen.farrell@cs.tcd.ie Sun Apr 8 17:07:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753F821F84B5 for ; Sun, 8 Apr 2012 17:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLZ1hZR4IuDj for ; Sun, 8 Apr 2012 17:07:42 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDE721F84AE for ; Sun, 8 Apr 2012 17:07:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B6413171477; Mon, 9 Apr 2012 01:07:41 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333930061; bh=qFoHnj51rcWP+/ gndAFT5vn4AWiyBRxdp6Pm6wOoDeY=; b=o9TLAajcqbc0pKgRHBGMNLaPiMnypr VvIe+wdGKDhieT/1YNiOtvO0OR5RoGg7yk7cH/BgO33PAgmuuKScsC/PlLMjX48n jkJMAxVFvM2W6Z5S0qvtUlgugaqd6DSUm1UTdX24FnBdpZNfApzdjUtZ8zhJLkT7 rnyW5y7l1uaiDTrEIDO55//FZtveW1DvleUpoWjVdDw39zmB+U/KN64JTtCm89kO Lb1emxVHo6k0AUQCxa6fJBLO9nsiqA87Ng0MzGraljJHGKCkDMHQWea9jc3EOjpI bbuen6gEi4fA72bAjhFwMPgChipcmL3OeduVN6hWswhiQTqXdcDQlrCA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id BjaZrv8Hk2EK; Mon, 9 Apr 2012 01:07:41 +0100 (IST) Received: from [10.87.48.4] (unknown [86.41.5.213]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0F977171471; Mon, 9 Apr 2012 01:07:40 +0100 (IST) Message-ID: <4F82284C.2080005@cs.tcd.ie> Date: Mon, 09 Apr 2012 01:07:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4F821EBB.5010506@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stefan Santesson , IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 00:07:43 -0000 So is this a fair summary? The goal is prevention, but the proposal is recognised to be an imperfect way to achieve that given the current deployed codebase, (arguably better than the status quo ante but with a known vulnerability). Not saying what I think but just trying to help clarify what's at issue. S. PS: All the above as a 5280 co-author/interested party, in case that wasn't clear. On 04/09/2012 01:00 AM, Phillip Hallam-Baker wrote: > On Sun, Apr 8, 2012 at 7:26 PM, Stephen Farrell > wrote: >> >> Hi Phill, >> >> >> On 04/09/2012 12:13 AM, Phillip Hallam-Baker wrote: >>> >>> Our needs can only be met by not marking it critical >> >> >> I understand the need to work with deployed code. We >> can (dis)agree about its relative importance here, but >> I've a different question. >> >> I do not understand how a non-critical NC meets the >> need to prevent entreprise CAs issuing certs beyond the >> relevant scope. (RPs that don't support NC will be >> vulnerable, and presumably that's most-to-nearly-all RPs.) > > The spec is clear that either the extension must be processed or the > cert rejected regardless of the NC flag if the client understands the > extension. None of the clients checked appear to reject if the > extension is not marked critical. > > >> If you're saying that you don't have a need to prevent >> that, but only a need to detect it (e.g. via something like >> the ssl-observatory) then that seems to require a bigger >> change vs.5280. I've not looked at the text just now, but >> as I recall it, NC is designed for prevention and not for >> detection. > > The desired outcome here is: > > * Clients that process NCs have protection > * Clients that do not process NCs do not reject valid certs > > There are two issues here, false positives (reject a valid cert) and > false negatives (accept a bogus cert). Since the number of false > negatives has been negligible to date the false positives concern is > considerably greater than the false negatives. It is unacceptable for > a legacy client to reject a legitimate cert. > > >> Defining a new typically non-critical NC-like extension >> for detection would seem like the right thing to do. (And >> I'd imagine the putative new extension could have simpler >> syntax and more precise semantics for what is a now-real >> use-case:-) > > That may be something that we would want to look at in addition. But > 2012 is not 2010. We now have an active attacker and a very short time > horizon. There is deployed code that can be used to provide a degree > of protection now. > > >> So, another question: why is not a new non-critical NC-like >> extension not better here? The ssl-observatory approach would >> work just as well with that. > > If nobody had implemented the old NC system that would make sense. But > there are code paths we can and will use now. > > Why not change the SHALL on the legacy NC scheme to a SHOULD so that > we can start using it now and then have a discussion on new proposals > for NC like things? > > From paul.hoffman@vpnc.org Sun Apr 8 17:18:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259F321F858E for ; Sun, 8 Apr 2012 17:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSjmvrec3SXO for ; Sun, 8 Apr 2012 17:18:03 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 993AE21F8582 for ; Sun, 8 Apr 2012 17:18:03 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q390I1Ua018713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Apr 2012 17:18:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Sun, 8 Apr 2012 17:18:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3259A94A-01CC-487F-BA80-C18AB55ED3FF@vpnc.org> References: <4F821EBB.5010506@cs.tcd.ie> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1257) Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 00:18:04 -0000 On Apr 8, 2012, at 5:00 PM, Phillip Hallam-Baker wrote: > Why not change the SHALL on the legacy NC scheme to a SHOULD so that > we can start using it now and then have a discussion on new proposals > for NC like things? Because it would break clients that check the MUST from 5280. = Presumably, some do. Presumably from your earlier messages, none of the = ones you care about do. Why not just issue the certs you think you should issue and not worry so = much about what the spec requires? You have done your analysis and have = a business case for your actions. There are probably other parts of PKIX = that various public CAs are not following exactly, and yet they are not = removed from our root piles. --Paul Hoffman From tgindin@us.ibm.com Sun Apr 8 17:37:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BCA21F851D for ; Sun, 8 Apr 2012 17:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eVjij0Onk+F for ; Sun, 8 Apr 2012 17:37:38 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDE721F8518 for ; Sun, 8 Apr 2012 17:37:37 -0700 (PDT) Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 8 Apr 2012 18:37:37 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sun, 8 Apr 2012 18:37:35 -0600 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 9A63BC9005C for ; Sun, 8 Apr 2012 20:37:33 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q390bYIF238530 for ; Sun, 8 Apr 2012 20:37:34 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q390bY43006199 for ; Sun, 8 Apr 2012 20:37:34 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q390bYNQ006196; Sun, 8 Apr 2012 20:37:34 -0400 In-Reply-To: References: from "Stephen Kent" at Apr 5, 12 01:54:50 pm <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> To: Santosh Chokhani MIME-Version: 1.0 X-KeepSent: 8860DFB3:AEF99687-852579D8:005841DB; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Sun, 8 Apr 2012 20:37:18 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/08/2012 20:37:34, Serialize complete at 04/08/2012 20:37:34 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040900-7282-0000-0000-00000807F15C Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 00:37:39 -0000 The description of the processing of X.400 name constraints is not clear. There's one quite clear statement that CA's SHOULD NOT set them, and a less clear one that RP's are permitted to follow your second point (the last sentence of page 40, quoted in Dave Cooper's earlier message). That permission is sufficiently unclear that you described it as "against the RFC", and I hedged on whether it's conformant. If we don't think it's obvious, even though Dave Cooper does, how many implementors will? The actual processing of X.400 name constraints is almost unspecified in both RFC 5280 and X.509-2008. This is far more of a weakness for X.509 than for RFC 5280, which at least makes it clear that it doesn't advocate such name constraints. The issue I'm bringing up is that an RP may recognize an X.400 name form while not knowing how to fully implement name constraints for it. IMHO would be much easier to implement meaningful name constraints for Registered ID or EDIPartyName than for X400Address. It would also be simpler to implement constraints for the PI Other-Name. Tom Gindin From: Santosh Chokhani To: Tom Gindin/Watson/IBM@IBMUS, "mrex@sap.com" , Cc: "pkix@ietf.org" Date: 04/06/2012 10:53 AM Subject: RE: [pkix] Proposal: Change the Criticality Requirement of Name Tom, In my reading 5280 is reasonably clear. It could always be made clearer. I would consider the following implementations secure: 1. If the name constraint is critical and you do not recognize one or more name forms, reject the certificate. 2. If the name constraint is critical and you do not recognize one or more name forms, accept the certificate if none of the unrecognized name forms appear in the certification path, else reject the certificate. (this is against the RFC, but I see no harm) 3, If the name constraint is non-critical and you do not recognize one or more name forms, accept the certificate. I agree that there is some ambiguity in terms of application behavior if you assume that application behavior must be the same regardless of criticality if an extension is recognized. This is due to inability to process all name forms. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Tom Gindin Sent: Thursday, April 05, 2012 9:31 PM To: mrex@sap.com Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Martin: Actually, the way in which name constraints are most clearly underspecified is their handling of x400Address. Implementers MUST be able to process one of the GeneralName forms, and SHOULD be able to process four more. Three of the remaining four forms are explicitly excluded from this specification, but there's no reference to how x400Address should be processed (if anyone still uses it) although there's a SHOULD NOT for the CA putting in a name constraint of that form. I think that an RP is conformant if it simply rejects any certificate whose subject Alt Name has a member of type x400Address, if either permitted_subtrees or excluded_subtrees have any member of type x400Address during the processing of section 6.1.3 B and C. I have no idea whether it's intended that having permitted_subtrees contain organization-name but not teletex-organization-name means that names with teletex-organization-name (an Extension attribute) should be banned. I suspect that it is, and I wonder how many RP's enforce anything like that. In your examples, you'd have to restrict the name forms to ones covered by permitted subtrees. Otherwise, CA's could put in a single excluded subtree of each name form, covering entities which no longer exist or an IP which can't be routed. Those are constraints, but they protect very little. Tom Gindin P.S. - The opinions above are mine, and not necessarily those of my employer. From: Martin Rex To: kent@bbn.com (Stephen Kent), Cc: pkix@ietf.org Date: 04/05/2012 08:04 PM Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Sent by: pkix-bounces@ietf.org Stephen Kent wrote: > > > > >Correct, name constraints as "envisioned" by rfc5280 are unusable, > >in case that you find yourself unable to ignore that invalid MUST. > > nonsense. name constraints can be used in any PKI where there there > are clear lines of authority for issuing certs relative to a name > space. The fact that the public TTP trust model, at the top, does > not meet that criterion, is merely an indication of a collision > between a business model and technology. To me it appears that name constraints might be underspecified. >From how I understand the design of X.509, subject Name and subjectAltNames are alternative unique representations of the name of the subject. So in order to use name constraints securely, all name forms present in a cert would have to be subject to constraints, and all unconstrained name forms would have to be unconditionally ignored, otherwise the constraints could be evaded. looking at this example structure (using "aaaa" instead of "com" to avoid collisions with mapped DNS space) well-known trust anchor | | CN=premium subCA, O=pubTC, C=Y public subCA / \ / \ / \ CN=org-CA, OU=Foo, O=pubTC, C=Y CN=org-CA, OU=Bar, O=pubTC, C=Y organizational subCA FOO organizational subCA BAR with name constraint on with name constraint on dNSName SAN "foo.aaaa" dnsName SAN "bar.aaaa" What is lacking in this example is name constraints on the subject name (DirectoryName). Without it, certain certificate processing, based on an unconstrained name forms, can evade the name constraints. e.g. what about the Bar org-CA issuing a CRL-signer cert (non-CA cert) with a subject DName of the Foo org-CA and using it to fabricate CRLs (with an AIA extension in the CRL, distinguishing the "forged" CRL signer cert from the real Foo org-CA cert by including and AuthKeyID and AIA CRL extensions (plus the IssuingDP CRL extension that RPs expect) ? Such a concoction would fulfil the "CRL Signer cert must validate under the same trust anchor" requirement. And PKIX software that is bold enough to perform forward path discovery based on AIA for the CRL signer might be tricked to accept CRLs forged by org-CA Bar during validation of certs issued by org-CA Foo, I assume. Another problem arises from the fact that there may exist SANs (such as KRB5PrincipalName http://tools.ietf.org/html/rfc4556#page-16) or the MS-UPN SAN for which name constraints have either not been defined or not been published, so that support for name constraints for such names is fairly unlikely exist in the installed base, yet the only reason to put alternate subject names into certs is to use them (and exclusively) for authentication. -Martin _______________________________________________ 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 stefan@aaa-sec.com Sun Apr 8 17:38:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1374921F8584 for ; Sun, 8 Apr 2012 17:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtFFXbJFwbWW for ; Sun, 8 Apr 2012 17:38:05 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 2F83C21F8562 for ; Sun, 8 Apr 2012 17:38:05 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 2833C1D9DF33 for ; Mon, 9 Apr 2012 02:38:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DOxdywKaJgiM for ; Mon, 9 Apr 2012 02:38:03 +0200 (CEST) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id BB8391D85453 for ; Mon, 9 Apr 2012 02:38:03 +0200 (CEST) Received: (qmail 79618 invoked from network); 9 Apr 2012 00:38:01 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.204]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Apr 2012 00:38:01 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 09 Apr 2012 02:37:53 +0200 From: Stefan Santesson To: Stephen Farrell , Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: <4F82284C.2080005@cs.tcd.ie> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 00:38:06 -0000 Stephen, Just for clarity. What in your mind is the vulnerability? Given that nothing prevents a CA from marking the extension critical. /Stefan On 12-04-09 2:07 AM, "Stephen Farrell" wrote: > >So is this a fair summary? > >The goal is prevention, but the proposal is recognised >to be an imperfect way to achieve that given the current >deployed codebase, (arguably better than the status quo >ante but with a known vulnerability). > >Not saying what I think but just trying to help clarify >what's at issue. > >S. > >PS: All the above as a 5280 co-author/interested >party, in case that wasn't clear. > >On 04/09/2012 01:00 AM, Phillip Hallam-Baker wrote: >> On Sun, Apr 8, 2012 at 7:26 PM, Stephen Farrell >> wrote: >>> >>> Hi Phill, >>> >>> >>> On 04/09/2012 12:13 AM, Phillip Hallam-Baker wrote: >>>> >>>> Our needs can only be met by not marking it critical >>> >>> >>> I understand the need to work with deployed code. We >>> can (dis)agree about its relative importance here, but >>> I've a different question. >>> >>> I do not understand how a non-critical NC meets the >>> need to prevent entreprise CAs issuing certs beyond the >>> relevant scope. (RPs that don't support NC will be >>> vulnerable, and presumably that's most-to-nearly-all RPs.) >> >> The spec is clear that either the extension must be processed or the >> cert rejected regardless of the NC flag if the client understands the >> extension. None of the clients checked appear to reject if the >> extension is not marked critical. >> >> >>> If you're saying that you don't have a need to prevent >>> that, but only a need to detect it (e.g. via something like >>> the ssl-observatory) then that seems to require a bigger >>> change vs.5280. I've not looked at the text just now, but >>> as I recall it, NC is designed for prevention and not for >>> detection. >> >> The desired outcome here is: >> >> * Clients that process NCs have protection >> * Clients that do not process NCs do not reject valid certs >> >> There are two issues here, false positives (reject a valid cert) and >> false negatives (accept a bogus cert). Since the number of false >> negatives has been negligible to date the false positives concern is >> considerably greater than the false negatives. It is unacceptable for >> a legacy client to reject a legitimate cert. >> >> >>> Defining a new typically non-critical NC-like extension >>> for detection would seem like the right thing to do. (And >>> I'd imagine the putative new extension could have simpler >>> syntax and more precise semantics for what is a now-real >>> use-case:-) >> >> That may be something that we would want to look at in addition. But >> 2012 is not 2010. We now have an active attacker and a very short time >> horizon. There is deployed code that can be used to provide a degree >> of protection now. >> >> >>> So, another question: why is not a new non-critical NC-like >>> extension not better here? The ssl-observatory approach would >>> work just as well with that. >> >> If nobody had implemented the old NC system that would make sense. But >> there are code paths we can and will use now. >> >> Why not change the SHALL on the legacy NC scheme to a SHOULD so that >> we can start using it now and then have a discussion on new proposals >> for NC like things? >> >> From stefan@aaa-sec.com Sun Apr 8 17:48:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7232821F84F6 for ; Sun, 8 Apr 2012 17:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGGXWXK3DyPM for ; Sun, 8 Apr 2012 17:48:16 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id DFFD221F84DD for ; Sun, 8 Apr 2012 17:48:15 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 39CC71DE67F6 for ; Mon, 9 Apr 2012 02:46:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rcEf25Ac4boT for ; Mon, 9 Apr 2012 02:46:34 +0200 (CEST) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0195F1DE6643 for ; Mon, 9 Apr 2012 02:46:34 +0200 (CEST) Received: (qmail 10849 invoked from network); 9 Apr 2012 00:46:33 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.204]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Apr 2012 00:46:33 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 09 Apr 2012 02:46:23 +0200 From: Stefan Santesson To: Paul Hoffman , Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: <3259A94A-01CC-487F-BA80-C18AB55ED3FF@vpnc.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 00:48:16 -0000 Paul, On 12-04-09 2:18 AM, "Paul Hoffman" wrote: >Because it would break clients that check the MUST from 5280. Exactly how would that happen in practice? An RP will only see if the extension has criticality or not. To break anything the RP client would have to reject the cert just because it finds a NC with non-critical flag. This is not a behavior caused by any existing RFC 5280 requirement. Even if this would be the case. Isn't it up to the CA to decide what RP clients they need to interoperate with? /Stefan From stephen.farrell@cs.tcd.ie Sun Apr 8 17:50:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6029621F8534 for ; Sun, 8 Apr 2012 17:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQEJKEUnLmXO for ; Sun, 8 Apr 2012 17:50:23 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id F19AD21F84F6 for ; Sun, 8 Apr 2012 17:50:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 22E52171477; Mon, 9 Apr 2012 01:50:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333932613; bh=3EAjNI0/lY5NJx i+2osOeabOR1sYDqzyTjNr96oPFrk=; b=SNtcgNuUGEdp6eruh35rzDfb3GmGtK IypbCSmwD+dI69wBCt24jfJzXZKFFqGIVYbUbZt4C6flweTDKEDAM3KweWBTCWgR KctwjyLRbhvTHihBrEjbb+4z1EhJ9BfRTAYhCktNb27wTHi+rQjoQA82gHdA+jYm 5jg+9Xxvyu/9cN08Rh3ju6WVdCPvPLZBcmNs3ddvGiiFRHyKw5I/rTp3B3UCWpvh zmpk41A5+qmsempRrlCKS6nV31nOc+JYBWwPqckTLh1b/fvhrMDgB0S1wJAbqECh qQ0XnF+yjEtmO7WO7J0erUO8Qkf1AFapNDC58Xsqp2kAt6OZCGy78BQA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id nSB6IB9MQlZK; Mon, 9 Apr 2012 01:50:13 +0100 (IST) Received: from [10.87.48.4] (unknown [86.41.5.213]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 71DE8171471; Mon, 9 Apr 2012 01:50:13 +0100 (IST) Message-ID: <4F823244.7030005@cs.tcd.ie> Date: Mon, 09 Apr 2012 01:50:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 00:50:24 -0000 On 04/09/2012 01:37 AM, Stefan Santesson wrote: > Stephen, > > Just for clarity. What in your mind is the vulnerability? > Given that nothing prevents a CA from marking the extension critical. The vulnerability is that if an enterprise CA is issued a non-critical NC for example.com by a public CA, then the enterprise CA can issue certs for example.net and an RP that doesn't implement NC will accept the cert for example.net from example.com. Setting NC critical avoids that issue. I understand that mitigating that exact vulnerability is the reason that a browser want to introduce NC as a requirement for CAs, so this is a non-trivial issue with the proposal. If the argument for this proposal is that it'd help get over a deployment hump then maybe it'd be better separated out from an 5280 update, since presumably widespread use would cause the non-complying deployments to get fixed over time. I've been told that other than one RP, most other that are widely deployed do support NC. In response to Paul's question, I'd be interested to know if anyone's tested if any of those NC-supporting RP's barf on a cert with a non-critical NC or not. If deployed NC-supporting code did that then that'd be significant for the discussion I'd say. (We'd have two sets of conflictingly different bad implementations from the 5280-purist p-o-v, rather than one.) S > > /Stefan > > On 12-04-09 2:07 AM, "Stephen Farrell" wrote: > >> >> So is this a fair summary? >> >> The goal is prevention, but the proposal is recognised >> to be an imperfect way to achieve that given the current >> deployed codebase, (arguably better than the status quo >> ante but with a known vulnerability). >> >> Not saying what I think but just trying to help clarify >> what's at issue. >> >> S. >> >> PS: All the above as a 5280 co-author/interested >> party, in case that wasn't clear. >> >> On 04/09/2012 01:00 AM, Phillip Hallam-Baker wrote: >>> On Sun, Apr 8, 2012 at 7:26 PM, Stephen Farrell >>> wrote: >>>> >>>> Hi Phill, >>>> >>>> >>>> On 04/09/2012 12:13 AM, Phillip Hallam-Baker wrote: >>>>> >>>>> Our needs can only be met by not marking it critical >>>> >>>> >>>> I understand the need to work with deployed code. We >>>> can (dis)agree about its relative importance here, but >>>> I've a different question. >>>> >>>> I do not understand how a non-critical NC meets the >>>> need to prevent entreprise CAs issuing certs beyond the >>>> relevant scope. (RPs that don't support NC will be >>>> vulnerable, and presumably that's most-to-nearly-all RPs.) >>> >>> The spec is clear that either the extension must be processed or the >>> cert rejected regardless of the NC flag if the client understands the >>> extension. None of the clients checked appear to reject if the >>> extension is not marked critical. >>> >>> >>>> If you're saying that you don't have a need to prevent >>>> that, but only a need to detect it (e.g. via something like >>>> the ssl-observatory) then that seems to require a bigger >>>> change vs.5280. I've not looked at the text just now, but >>>> as I recall it, NC is designed for prevention and not for >>>> detection. >>> >>> The desired outcome here is: >>> >>> * Clients that process NCs have protection >>> * Clients that do not process NCs do not reject valid certs >>> >>> There are two issues here, false positives (reject a valid cert) and >>> false negatives (accept a bogus cert). Since the number of false >>> negatives has been negligible to date the false positives concern is >>> considerably greater than the false negatives. It is unacceptable for >>> a legacy client to reject a legitimate cert. >>> >>> >>>> Defining a new typically non-critical NC-like extension >>>> for detection would seem like the right thing to do. (And >>>> I'd imagine the putative new extension could have simpler >>>> syntax and more precise semantics for what is a now-real >>>> use-case:-) >>> >>> That may be something that we would want to look at in addition. But >>> 2012 is not 2010. We now have an active attacker and a very short time >>> horizon. There is deployed code that can be used to provide a degree >>> of protection now. >>> >>> >>>> So, another question: why is not a new non-critical NC-like >>>> extension not better here? The ssl-observatory approach would >>>> work just as well with that. >>> >>> If nobody had implemented the old NC system that would make sense. But >>> there are code paths we can and will use now. >>> >>> Why not change the SHALL on the legacy NC scheme to a SHOULD so that >>> we can start using it now and then have a discussion on new proposals >>> for NC like things? >>> >>> > > > From SChokhani@cygnacom.com Sun Apr 8 17:58:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C1621F84E7 for ; Sun, 8 Apr 2012 17:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM2hLRODBTnS for ; Sun, 8 Apr 2012 17:58:32 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id D6D3321F84E2 for ; Sun, 8 Apr 2012 17:58:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,391,1330923600"; d="scan'208";a="4646564" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 08 Apr 2012 20:58:29 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sun, 8 Apr 2012 20:58:28 -0400 From: Santosh Chokhani To: Tom Gindin Date: Sun, 8 Apr 2012 20:58:26 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0V6Pt6k+9jRgkJTVSmwWulK0dbTAAAq0uw Message-ID: References: from "Stephen Kent" at Apr 5, 12 01:54:50 pm <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 00:58:33 -0000 Tom, I am not an expert on X.400. So, I would not comment on it. But, 5280 is clear (I just elided over parts of the sentence David Cooper c= ited) that you need not understand and process a name constraint for a name= form that does not appear in the certificate subject name or subject alt n= ame. -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com]=20 Sent: Sunday, April 08, 2012 8:37 PM To: Santosh Chokhani Cc: mrex@sap.com; pkix@ietf.org Subject: RE: [pkix] Proposal: Change the Criticality Requirement of Name The description of the processing of X.400 name constraints is not = clear. There's one quite clear statement that CA's SHOULD NOT set them, an= d a less clear one that RP's are permitted to follow your second point (the= last sentence of page 40, quoted in Dave Cooper's earlier message).=20 That permission is sufficiently unclear that you described it as "against t= he RFC", and I hedged on whether it's conformant. If we don't think it's o= bvious, even though Dave Cooper does, how many implementors will? The actual processing of X.400 name constraints is almost unspecifi= ed in both RFC 5280 and X.509-2008. This is far more of a weakness for X.5= 09 than for RFC 5280, which at least makes it clear that it doesn't advocat= e such name constraints. The issue I'm bringing up is that an RP may recog= nize an X.400 name form while not knowing how to fully implement name const= raints for it. IMHO would be much easier to implement meaningful name cons= traints for Registered ID or EDIPartyName than for X400Address. It would a= lso be simpler to implement constraints for the PI Other-Name. Tom Gindin From: Santosh Chokhani To: Tom Gindin/Watson/IBM@IBMUS, "mrex@sap.com" ,=20 Cc: "pkix@ietf.org" Date: 04/06/2012 10:53 AM Subject: RE: [pkix] Proposal: Change the Criticality Requirement of= =20 Name Tom, In my reading 5280 is reasonably clear. It could always be made clearer. I would consider the following implementations secure: 1. If the name constraint is critical and you do not recognize one or more= name forms, reject the certificate. 2. If the name constraint is critical and you do not recognize one or more= name forms, accept the certificate if none of the unrecognized name forms = appear in the certification path, else reject the certificate. (this is aga= inst the RFC, but I see no harm) 3, If the name constraint is non-critical and you do not recognize one or = more name forms, accept the certificate. I agree that there is some ambiguity in terms of application behavior if yo= u assume that application behavior must be the same regardless of criticali= ty if an extension is recognized. This is due to inability to process all = name forms. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Tom= Gindin Sent: Thursday, April 05, 2012 9:31 PM To: mrex@sap.com Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Martin: Actually, the way in which name constraints are most clearly unders= pecified is their handling of x400Address. Implementers MUST be able to pr= ocess one of the GeneralName forms, and SHOULD be able to process four more= . Three of the remaining four forms are explicitly excluded from this spec= ification, but there's no reference to how x400Address should be processed = (if anyone still uses it) although there's a SHOULD NOT for the CA putting = in a name constraint of that form. I think that an RP is conformant if it simply rejects any certifica= te whose subject Alt Name has a member of type x400Address, if either permi= tted_subtrees or excluded_subtrees have any member of type x400Address duri= ng the processing of section 6.1.3 B and C. I have no idea whether it's in= tended that having permitted_subtrees contain organization-name but not tel= etex-organization-name means that names with teletex-organization-name (an = Extension attribute) should be banned. I suspect that it is, and I wonder = how many RP's enforce anything like that. In your examples, you'd have to restrict the name forms to ones cov= ered by permitted subtrees. Otherwise, CA's could put in a single excluded= subtree of each name form, covering entities which no longer exist or an I= P which can't be routed. Those are constraints, but they protect very litt= le. Tom Gindin P.S. - The opinions above are mine, and not necessarily those of my employe= r. From: Martin Rex To: kent@bbn.com (Stephen Kent),=20 Cc: pkix@ietf.org Date: 04/05/2012 08:04 PM Subject: Re: [pkix] Proposal: Change the Criticality Requirement of= =20 Name Sent by: pkix-bounces@ietf.org Stephen Kent wrote: >=20 > > > >Correct, name constraints as "envisioned" by rfc5280 are unusable, > >in case that you find yourself unable to ignore that invalid MUST. >=20 > nonsense. name constraints can be used in any PKI where there there > are clear lines of authority for issuing certs relative to a name=20 > space. The fact that the public TTP trust model, at the top, does=20 > not meet that criterion, is merely an indication of a collision > between a business model and technology. To me it appears that name constraints might be underspecified. >From how I understand the design of X.509, subject Name and=20 subjectAltNames are alternative unique representations of the name of the subject. So in order to use name constraints securely, all name forms present in a cert would have to be subject to constraints, and all unconstrained name forms would have to be unconditionally ignored, otherwise the constraints could be evaded. looking at this example structure (using "aaaa" instead of "com" to avoid collisions with mapped DNS space) well-known trust anchor | | CN=3Dpremium subCA, O=3DpubTC, C=3DY public subCA / \ / \ / \ CN=3Dorg-CA, OU=3DFoo, O=3DpubTC, C=3DY CN=3Dorg-CA, OU=3DBar, O=3Dpub= TC, C=3DY organizational subCA FOO organizational subCA BAR with name constraint on with name constraint on dNSName SAN "foo.aaaa" dnsName SAN "bar.aaaa" What is lacking in this example is name constraints on the subject name (DirectoryName). Without it, certain certificate processing, based on an unconstrained name forms, can evade the name constraints. e.g. what about the Bar org-CA issuing a CRL-signer cert (non-CA cert) with a subject DName of the Foo org-CA and using it to fabricate CRLs (with an AIA extension in the CRL, distinguishing the "forged" CRL signer cert from the real Foo org-CA cert by including and AuthKeyID and AIA CRL extensions (plus the IssuingDP CRL extension that RPs expect) ? Such a concoction would fulfil the "CRL Signer cert must validate under the same trust anchor" requirement. And PKIX software that is bold enough to perform forward path discovery based on AIA for the CRL signer might be tricked to accept CRLs forged by org-CA Bar during validation of certs issued by org-CA Foo, I assume. Another problem arises from the fact that there may exist SANs (such as KRB5PrincipalName http://tools.ietf.org/html/rfc4556#page-16) or the MS-UPN SAN for which name constraints have either not been defined or not been published, so that support for name constraints for such names is fairly unlikely exist in the installed base, yet the only reason to put alternate subject names into certs is to use them (and exclusively) for authentication. -Martin _______________________________________________ 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 SChokhani@cygnacom.com Sun Apr 8 18:09:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7C721F853B for ; Sun, 8 Apr 2012 18:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTG8hTMhPCVa for ; Sun, 8 Apr 2012 18:09:56 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 054F621F84C8 for ; Sun, 8 Apr 2012 18:09:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,391,1330923600"; d="scan'208";a="4646595" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 08 Apr 2012 21:09:55 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sun, 8 Apr 2012 21:09:55 -0400 From: Santosh Chokhani To: Stefan Santesson , Kyle Hamilton , Phillip Hallam-Baker Date: Sun, 8 Apr 2012 21:09:53 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0V1lkfVUKiXtVWQ/i38zIfVJ24ywAFZkaA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 01:09:57 -0000 Stefan, Your logic can be applied to any of the certificate extensions identified a= s critical in 5280. I do not think we write the standards so that they mee= t insecure implementations. In my opinion PKIX standards are for secure interoperability. What you say= exposes some of the clients. The harm it does is CAs will point to the RFC and mark the extension non cr= itical and the RP software (browser) vendors will not have any reason or in= centive to implement name constraints. This will expose the consumers and = businesses. It is best for the CAs make their own determination and work with RP in CA = browser forum, We should not dilute the security of a security standard just because the l= argest market capitalization company in the history of human race has not i= mplemented a long standing standard correctly. -----Original Message----- From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Sunday, April 08, 2012 6:24 PM To: Santosh Chokhani; Kyle Hamilton; Phillip Hallam-Baker Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Santosh, Not proposing making it non-critical. Relaxing the SHALL requirement to a S= HOULD would be appropriate. The reason is what I recently posted. I see no cons with a SHALL requiremen= t. Neither from a security nor from an interop perspective. Relaxing SHALL to SHOULD: - Does not affect the way RPs process and enforce the extension (regardless= of criticality). - RPs can protect their interests by correctly implementing the extension - CAs can protect their interests by setting the extension critical. - No harm is done to any defenseless third party. What do you think is missing? What, if anything, is your reasons for defending a SHALL requirement. /Stefan On 12-04-08 11:53 PM, "Santosh Chokhani" wrote: >Stefan, > >What is your reason for making it non critical? > >-----Original Message----- >From: Stefan Santesson [mailto:stefan@aaa-sec.com] >Sent: Sunday, April 08, 2012 4:47 PM >To: Santosh Chokhani; Kyle Hamilton; Phillip Hallam-Baker >Cc: IETF PKIX >Subject: Re: [pkix] Proposal: Change the Criticality Requirement of=20 >Name > >Santosh, > >I have considered that. Neither of these facts are in my mind any good=20 >reason for requiring criticality. > >/Stefan > >On 12-04-08 9:09 PM, "Santosh Chokhani" wrote: > >>Stefan, >> >>Consider the following facts: >> >>1. X.509 does not require any of the certificate extensions to be=20 >>critical. >> >>2. 5280 is a profile of X.509 as the very first sentence of 5280=20 >>abstract says. >> >>-----Original Message----- >>From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf=20 >>Of Stefan Santesson >>Sent: Saturday, April 07, 2012 8:11 PM >>To: Kyle Hamilton; Phillip Hallam-Baker >>Cc: IETF PKIX >>Subject: Re: [pkix] Proposal: Change the Criticality Requirement of=20 >>Name >> >>Being away for some days, it was quite a read before anyone cared to=20 >>look in the X.509 spec :) >> >>I regret the flaming in this thread, enough said about that. >> >>I believe PKIX made a mistake requiring CAs to mark this extension=20 >>critical, while X.509 allows it to be non-critical. >> >>The requirement does not affect client behavior (thoroughly examined=20 >>in this thread). It just imposes policy on the CA that actually should=20 >>be up to the CA to decide. A CA that concludes that criticality is=20 >>important, can always set it critical. >> >>IOS as well as OS X are clearly not compliant with RFC 5280, but that=20 >>is not a good argument to require criticality. >> >>/Stefan >> >> >>On 12-04-07 10:53 PM, "Kyle Hamilton" wrote: >> >>>Nope. X.509/2008 page 33, section 8.4.2.2: >>>[...] >>>This extension may, at the option of the certificate issuer, be=20 >>>either critical or non-critical . It is recommended that it be=20 >>>flagged critical, otherwise a certificate user may not check that=20 >>>subsequent certificates in a certification path are located in the=20 >>>name space intended by the issuing CA. >>>[...] >>> >>>The criticality mandate is all PKIX. >>> >>>-Kyle H >>> >>>On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker=20 >>> >>>wrote: >>>> Isn't it an X509v3 requirement in any case? >>>> >>>> On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley >>>>wrote: >>>>> Ryan: >>>>> >>>>>> While Apple's OS X (desktop) implementation will not choke if=20 >>>>>>Name Constraints is marked critical, it does not support=20 >>>>>>processing name constraints and will not enforce them - critical=20 >>>>>>or not. It does not quite implement all of RFC 2459, let alone=20 >>>>>>3280 or 5280, nor does >>>>>>2459 require that it fail processing if it does not process a=20 >>>>>>critical extension (although 5280 does). >>>>> >>>>> RFC 2459 says: >>>>> >>>>> ... A >>>>> certificate using system MUST reject the certificate if it=20 >>>>>encounters >>>>> a critical extension it does not recognize; however, a non-critical >>>>> extension may be ignored if it is not recognized. ... >>>>> >>>>> So, this is not a concept that was added in RFC 3280 or 5280. >>>>> >>>>> Russ >>>>> _______________________________________________ >>>>> pkix mailing list >>>>> pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>>> >>>> >>>> -- >>>> Website: http://hallambaker.com/ >>>> _______________________________________________ >>>> 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 paul.hoffman@vpnc.org Sun Apr 8 18:50:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EFA21F8584 for ; Sun, 8 Apr 2012 18:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR5HBt+Eg5Qj for ; Sun, 8 Apr 2012 18:50:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 038B021F8582 for ; Sun, 8 Apr 2012 18:50:50 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q391ohPj020058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Apr 2012 18:50:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sun, 8 Apr 2012 18:50:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stefan Santesson X-Mailer: Apple Mail (2.1257) Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 01:50:51 -0000 On Apr 8, 2012, at 5:46 PM, Stefan Santesson wrote: > On 12-04-09 2:18 AM, "Paul Hoffman" wrote: >=20 >> Because it would break clients that check the MUST from 5280. >=20 > Exactly how would that happen in practice? >=20 > An RP will only see if the extension has criticality or not. Correct. > To break anything the RP client would have to reject the cert just = because > it finds a NC with non-critical flag. Correct. > This is not a behavior caused by any existing RFC 5280 requirement. If the RP only accepts certificates that it thinks fully conforms to = 5280, and the RP sees a cert in the chain that does not fully conform to = 5280, it is reasonable for the RP to say "that's a bad cert, it doesn't = go in my chain" and thus fails to find a good chain. This is not = required by 5280, but it certainly makes sense for picky RPs. > Even if this would be the case. Isn't it up to the CA to decide what = RP > clients they need to interoperate with? Absolutely, and that's exactly what I said to Phill. --Paul Hoffman From piyush@identicate.com Sun Apr 8 18:50:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5337B21F85BB for ; Sun, 8 Apr 2012 18:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=1.950, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i5k0lglCCMn for ; Sun, 8 Apr 2012 18:50:56 -0700 (PDT) Received: from col0-omc3-s13.col0.hotmail.com (col0-omc3-s13.col0.hotmail.com [65.55.34.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9C521F85B6 for ; Sun, 8 Apr 2012 18:50:56 -0700 (PDT) Received: from COL119-W18 ([65.55.34.136]) by col0-omc3-s13.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 8 Apr 2012 18:50:56 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_228de53a-7fd2-48c7-b4f3-e65086552040_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , , Date: Sun, 8 Apr 2012 18:50:55 -0700 Importance: Normal In-Reply-To: References: <3259A94A-01CC-487F-BA80-C18AB55ED3FF@vpnc.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 09 Apr 2012 01:50:56.0013 (UTC) FILETIME=[342BBBD0:01CD15F3] Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 01:50:57 -0000 --_228de53a-7fd2-48c7-b4f3-e65086552040_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Date: Mon=2C 9 Apr 2012 02:46:23 +0200 > From: stefan@aaa-sec.com > To: paul.hoffman@vpnc.org=3B hallam@gmail.com > CC: pkix@ietf.org > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name >=20 > Paul=2C >=20 > On 12-04-09 2:18 AM=2C "Paul Hoffman" wrote: >=20 > >Because it would break clients that check the MUST from 5280. >=20 > Exactly how would that happen in practice? >=20 > An RP will only see if the extension has criticality or not. > To break anything the RP client would have to reject the cert just becaus= e > it finds a NC with non-critical flag. > This is not a behavior caused by any existing RFC 5280 requirement. Existing requirement is that NC must be marked critical. Believe it or not=2C there are implementations out there which check if a c= ertificate complies with the profile or not=2C and reject them upfront in = case of failure. >=20 > Even if this would be the case. Isn't it up to the CA to decide what RP > clients they need to interoperate with? Sure. And they are free to mark NC as non critical. But they won't be able = to claim compliance with 5280 and will need to explain their reason to brea= k compliance to their customers. The fact is that most people who are using PKI don't understand most things= about PKI. They put their trust in the standards and as long as an impleme= ntation claims compliance to the standard they are happy to adopt it. When = you start changing standards to accommodate insecure implementations you se= t a wrong precedence. A while ago I came across a big PKI deployment where applications were not = doing revocation checking because every cert that was issued was mapped to = an active directory user. The customer was convinced (rightfully so)=2C tha= t revocation checking was not required because they could achieve the same = outcome by removing the user from active directory.=20 Does it mean that we should make revocation checking optional in 5280? The point is that you will always find implementations/business cases where= breaking compliance to a standard makes sense. But in those cases=2C the e= ntities who make this decision should be able to justify/explain it instead= of saying that they were just following the standard. >=20 > /Stefan >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_228de53a-7fd2-48c7-b4f3-e65086552040_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B Date: Mon=2C 9 Ap= r 2012 02:46:23 +0200
>=3B From: stefan@aaa-sec.com
>=3B To: paul= .hoffman@vpnc.org=3B hallam@gmail.com
>=3B CC: pkix@ietf.org
>=3B= Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name>=3B
>=3B Paul=2C
>=3B
>=3B On 12-04-09 2:18 AM=2C "Pa= ul Hoffman" <=3Bpaul.hoffman@vpnc.org>=3B wrote:
>=3B
>=3B &= gt=3BBecause it would break clients that check the MUST from 5280.
>= =3B
>=3B Exactly how would that happen in practice?
>=3B
>= =3B An RP will only see if the extension has criticality or not.
>=3B = To break anything the RP client would have to reject the cert just because<= br>>=3B it finds a NC with non-critical flag.
>=3B This is not a beh= avior caused by any existing RFC 5280 requirement.

Existing requirem= ent is that NC must be marked critical.
Believe it or not=2C there are i= mplementations out there which check if a certificate complies with the pro= file or not=2C and reject =3B them upfront in case of failure.

&= gt=3B
>=3B Even if this would be the case. Isn't it up to the CA to d= ecide what RP
>=3B clients they need to interoperate with?

Sure= . And they are free to mark NC as non critical. But they won't be able to c= laim compliance with 5280 and will need to explain their reason to break co= mpliance to their customers.
The fact is that most people who are using = PKI don't understand most things about PKI. They put their trust in the sta= ndards and as long as an implementation claims compliance to the standard t= hey are happy to adopt it. When you start changing standards to accommodate= insecure implementations you set a wrong precedence.

A while ago I = came across a big PKI deployment where applications were not doing revocati= on checking because every cert that was issued was mapped to an active dire= ctory user. The customer was convinced (rightfully so)=2C that revocation c= hecking was not required because they could achieve the same outcome by rem= oving the user from active directory.
Does it mean that we should make = revocation checking optional in 5280?

The point is that you will alw= ays find implementations/business cases where breaking compliance to a stan= dard makes sense. But in those cases=2C the entities who make this decision= should be able to justify/explain it instead of saying that they were just= following the standard.
>=3B
>=3B /Stefan
>=3B
>=3B =
>=3B _______________________________________________
>=3B pkix m= ailing list
>=3B pkix@ietf.org
>=3B https://www.ietf.org/mailman/= listinfo/pkix
= --_228de53a-7fd2-48c7-b4f3-e65086552040_-- From ynir@checkpoint.com Mon Apr 9 00:42:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D78521F8622 for ; Mon, 9 Apr 2012 00:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAtPbNVIDcrK for ; Mon, 9 Apr 2012 00:42:05 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C0B5921F858F for ; Mon, 9 Apr 2012 00:42:04 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q397fZRu005795; Mon, 9 Apr 2012 10:41:47 +0300 X-CheckPoint: {4F82A011-2-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 9 Apr 2012 10:41:32 +0300 From: Yoav Nir To: Piyush Jain Date: Mon, 9 Apr 2012 10:41:24 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0WJC3Gb8W1D8kxQde7Q2OGVXKKAA== Message-ID: References: <3259A94A-01CC-487F-BA80-C18AB55ED3FF@vpnc.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_AA24FEEA75744FAEBF4B7E363C2D7384checkpointcom_" MIME-Version: 1.0 Cc: "stefan@aaa-sec.com" , "paul.hoffman@vpnc.org" , "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 07:42:06 -0000 --_000_AA24FEEA75744FAEBF4B7E363C2D7384checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 9, 2012, at 4:50 AM, Piyush Jain wrote: Existing requirement is that NC must be marked critical. Believe it or not, there are implementations out there which check if a cer= tificate complies with the profile or not, and reject them upfront in case= of failure. Can you name them? > Even if this would be the case. Isn't it up to the CA to decide what RP > clients they need to interoperate with? Sure. And they are free to mark NC as non critical. But they won't be able = to claim compliance with 5280 and will need to explain their reason to brea= k compliance to their customers. The fact is that most people who are using PKI don't understand most things= about PKI. They put their trust in the standards and as long as an impleme= ntation claims compliance to the standard they are happy to adopt it. When = you start changing standards to accommodate insecure implementations you se= t a wrong precedence. A while ago I came across a big PKI deployment where applications were not = doing revocation checking because every cert that was issued was mapped to = an active directory user. The customer was convinced (rightfully so), that = revocation checking was not required because they could achieve the same ou= tcome by removing the user from active directory. You could, but often certificates expire or get lost or compromised before = the EE gets removed from the directory, so revocation makes sense in that c= ase as well. Does it mean that we should make revocation checking optional in 5280? 5280 is a profile for using PKI on the Internet. If there's a valid reason = to make revocation checking optional on the Internet, then yes. The point is that you will always find implementations/business cases where= breaking compliance to a standard makes sense. But in those cases, the ent= ities who make this decision should be able to justify/explain it instead o= f saying that they were just following the standard. Maybe we need more than one profile. --_000_AA24FEEA75744FAEBF4B7E363C2D7384checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =
On Apr 9, 2012, at 4:50 AM, Piyush Jain wrote:



Existing requirement is that NC must be marked critical.=
Believe it or not, there are implementations out there which check if a= certificate complies with the profile or not, and reject  them upfron= t in case of failure.

Can you name them?

> Even if this would be the case. Isn't it up to the CA= to decide what RP
> clients they need to interoperate with?

S= ure. And they are free to mark NC as non critical. But they won't be able t= o claim compliance with 5280 and will need to explain their reason to break= compliance to their customers.
The fact is that most people who are usi= ng PKI don't understand most things about PKI. They put their trust in the = standards and as long as an implementation claims compliance to the standar= d they are happy to adopt it. When you start changing standards to accommod= ate insecure implementations you set a wrong precedence.

A while ago= I came across a big PKI deployment where applications were not doing revoc= ation checking because every cert that was issued was mapped to an active d= irectory user. The customer was convinced (rightfully so), that revocation = checking was not required because they could achieve the same outcome by re= moving the user from active directory. 

You could, but often certificates expire or get lost or compromised before= the EE gets removed from the directory, so revocation makes sense in that = case as well.

Does it mean that we should make revocation checking optional in 5280?

5280 is a profile for= using PKI on the Internet. If there's a valid reason to make revocation ch= ecking optional on the Internet, then yes.

The point is that you will always fin= d implementations/business cases where breaking compliance to a standard ma= kes sense. But in those cases, the entities who make this decision should b= e able to justify/explain it instead of saying that they were just followin= g the standard.

May= be we need more than one profile.

= --_000_AA24FEEA75744FAEBF4B7E363C2D7384checkpointcom_-- From SChokhani@cygnacom.com Mon Apr 9 08:07:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C3921F8705 for ; Mon, 9 Apr 2012 08:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf+Qdl+CWMfn for ; Mon, 9 Apr 2012 08:07:42 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 40FE521F8703 for ; Mon, 9 Apr 2012 08:07:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,393,1330923600"; d="scan'208,217";a="725786" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 09 Apr 2012 11:07:41 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 9 Apr 2012 11:07:41 -0400 From: Santosh Chokhani To: "pkix@ietf.org" Date: Mon, 9 Apr 2012 11:07:39 -0400 Thread-Topic: Fully Qualified Domain Name (FQDN) in DN and Name Constraints Thread-Index: Ac0WYoETgHN8tbE7T9mfW+iaRPIC0g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF0F60C128scygexch7cygnac_" MIME-Version: 1.0 Subject: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 15:07:43 -0000 --_000_B83745DA469B7847811819C5005244AF0F60C128scygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This relates to the name constraints discussion going on in another thread. Does anyone know how the browsers handle a Server certificate if subject al= ternative name is absent and the DN (specifically Common Name) contains the= FQDN? Related to this does anyone know what the browsers do with this name form i= f the certification path has URL or DNS Names constrained? Do, they enforc= e the applicable constraints on them. I did not find language in 5280 that deal with this. I may have missed som= ething. Santosh Chokhani CygnaCom Solutions --_000_B83745DA469B7847811819C5005244AF0F60C128scygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This relates to the name c= onstraints discussion going on in another thread.

 

Does anyone know how the brow= sers handle a Server certificate if subject alternative name is absent and = the DN (specifically Common Name) contains the FQDN?

<= p class=3DMsoNormal> 

Related to this does anyon= e know what the browsers do with this name form if the certification path h= as URL or DNS Names constrained?  Do, they enforce the applicable cons= traints on them.

 

I did not find language in 5280 that deal with this.  I m= ay have missed something.

 =

 

Santosh = Chokhani
CygnaCom Solutions

= --_000_B83745DA469B7847811819C5005244AF0F60C128scygexch7cygnac_-- From anders.rundgren@telia.com Mon Apr 9 08:21:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD3921F85A1 for ; Mon, 9 Apr 2012 08:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4VGUDzE3j3J for ; Mon, 9 Apr 2012 08:21:46 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id C7D1B21F85A0 for ; Mon, 9 Apr 2012 08:21:45 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E00A8D686; Mon, 9 Apr 2012 17:21:38 +0200 Message-ID: <4F82FE7F.1040805@telia.com> Date: Mon, 09 Apr 2012 17:21:35 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Santosh Chokhani References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 15:21:47 -0000 On 2012-04-09 17:07, Santosh Chokhani wrote: > This relates to the name constraints discussion going on in another thread. > > > > Does anyone know how the browsers handle a Server certificate if subject > alternative name is absent and the DN (specifically Common Name) contains the FQDN? That works fine with all major browsers. > Related to this does anyone know what the browsers do with this name form if > the certification path has URL or DNS Names constrained? Do, they enforce > the applicable constraints on them. I guess few of us has ever seen a certificate with name constraints. I haven't at least so I can unfortunately not help you on this one. Thanx Anders > > > > I did not find language in 5280 that deal with this. I may have missed something. > > > > > > Santosh Chokhani > CygnaCom Solutions > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From ryan-pkix@sleevi.com Mon Apr 9 08:22:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFB321F8746 for ; Mon, 9 Apr 2012 08:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnlWxP0i9d1x for ; Mon, 9 Apr 2012 08:22:45 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id D008921F8745 for ; Mon, 9 Apr 2012 08:22:45 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 738C1508085; Mon, 9 Apr 2012 08:22:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= sleevi.com; b=LunL1xbbxkliozAMF7cmXJpTPmx2LkKlL/3Aj32cQk4uK2z1FE 9Ma8QPjICaFH660ATm1g0szKqg7g3kNU/FyifRMsAktSdQJCvtA4FJ8l5Z+eNM9h 1zAlpch/eER28bVP0LrQ3ceXp24v2rdi/jCSlaqlnzJUsi9M4TimHQVEc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=yAmzUPeww6r6DbQQBC4vur3foSA=; b=NCIabl9Hv1ozuNRUM daC2N5GRqfgb/1oS/OqisvjuONJw+JR0SlEaj5Ah2TGM0VL/Tm53cpaJZo87WtAN mbPjvCLgXsYOwHpxKeXbK3JKys1HqpffTZD7MyZ22oE/MLse11FIAGklua6vZalK gElBI7aiJq5UOoOIU9CaP7Dxz0= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id 7CB32508084; Mon, 9 Apr 2012 08:22:44 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Mon, 9 Apr 2012 08:22:45 -0700 Message-ID: <0aad5b1eaee485b5e01ce12c6a9be53d.squirrel@webmail.dreamhost.com> In-Reply-To: References: Date: Mon, 9 Apr 2012 08:22:45 -0700 From: "Ryan Sleevi" To: "Santosh Chokhani" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pkix@ietf.org" Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-pkix@sleevi.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 15:22:46 -0000 > This relates to the name constraints discussion going on in another > thread. > > Does anyone know how the browsers handle a Server certificate if subje= ct > alternative name is absent and the DN (specifically Common Name) conta= ins > the FQDN? > > Related to this does anyone know what the browsers do with this name f= orm > if the certification path has URL or DNS Names constrained? Do, they > enforce the applicable constraints on them. > > I did not find language in 5280 that deal with this. I may have misse= d > something. > > > Santosh Chokhani > CygnaCom Solutions NSS, used by both Mozilla Firefox (all platforms) and Google Chrome/Chromium (Linux) constrains the CN-ID if the CN-ID appears to have a FQDN and dNSNames are constrained. The applicable bug number that implemented this behaviour is https://bugzilla.mozilla.org/show_bug.cgi?id=3D394919 From pritikin@cisco.com Mon Apr 9 09:46:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BB121F878E for ; Mon, 9 Apr 2012 09:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PL5UH9izhHvz for ; Mon, 9 Apr 2012 09:46:19 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFED21F8779 for ; Mon, 9 Apr 2012 09:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=3388; q=dns/txt; s=iport; t=1333989979; x=1335199579; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=M2z9hLXLgD0qI+f6jwJsT1pNlyWFTQSDAQTCtbWr/aU=; b=kn5hr+FCAdNOAGtdrJz4m+jAmbjPcnNR3VlUCeeYDjyXnwg34XRAyceU xkjnlUo0So8ddXcgfRzqcYlGtwiAu3LUfyfv9Sj4IVzEcFI9x2ifxzoVE SoTXEvWzCc8T7bEU5+d93vHXG1bdd6HBfQ5+GmHDGDOPprgbiPqptKvmn Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4GACkRg0+rRDoG/2dsb2JhbABDgym2BIEHggkBAQEDAQEBAQ8BJzQLBQsLGC4hBjAGEyKHXgMGBAyeZJYkDYFrii2FSmMEiFqNEoERhGGFR4MUgWmDBg X-IronPort-AV: E=Sophos;i="4.75,393,1330905600"; d="scan'208";a="36593468" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 09 Apr 2012 16:46:19 +0000 Received: from [10.21.0.54] ([10.21.0.54]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q39GkIQw008094; Mon, 9 Apr 2012 16:46:18 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Max Pritikin In-Reply-To: Date: Mon, 9 Apr 2012 10:46:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stefan Santesson X-Mailer: Apple Mail (2.1257) Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:46:20 -0000 +1 (Well stated Stefan) This is my position as well: The CAs should make this decision based on = their own policy. PKIX documents should, as does the X.509 document, = recommend the more secure option. Any client that ignores a critical extension's contents should be = publicly hounded as having a security vulnerability.=20 - max On Apr 7, 2012, at 6:11 PM, Stefan Santesson wrote: > Being away for some days, it was quite a read before anyone cared to = look > in the X.509 spec :) >=20 > I regret the flaming in this thread, enough said about that. >=20 > I believe PKIX made a mistake requiring CAs to mark this extension > critical, while X.509 allows it to be non-critical. >=20 > The requirement does not affect client behavior (thoroughly examined = in > this thread). It just imposes policy on the CA that actually should be = up > to the CA to decide. A CA that concludes that criticality is = important, > can always set it critical. >=20 > IOS as well as OS X are clearly not compliant with RFC 5280, but that = is > not a good argument to require criticality. >=20 > /Stefan >=20 >=20 > On 12-04-07 10:53 PM, "Kyle Hamilton" wrote: >=20 >> Nope. X.509/2008 page 33, section 8.4.2.2: >> [...] >> This extension may, at the option of the certificate issuer, be = either >> critical or non-critical . It is recommended that it be >> flagged critical, otherwise a certificate user may not check that >> subsequent certificates in a certification path are located >> in the name space intended by the issuing CA. >> [...] >>=20 >> The criticality mandate is all PKIX. >>=20 >> -Kyle H >>=20 >> On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker = >> wrote: >>> Isn't it an X509v3 requirement in any case? >>>=20 >>> On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley >>> wrote: >>>> Ryan: >>>>=20 >>>>> While Apple's OS X (desktop) implementation will not choke if Name >>>>> Constraints is marked critical, it does not support processing = name >>>>> constraints and will not enforce them - critical or not. It does = not >>>>> quite >>>>> implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 >>>>> require >>>>> that it fail processing if it does not process a critical = extension >>>>> (although 5280 does). >>>>=20 >>>> RFC 2459 says: >>>>=20 >>>> ... A >>>> certificate using system MUST reject the certificate if it = encounters >>>> a critical extension it does not recognize; however, a = non-critical >>>> extension may be ignored if it is not recognized. ... >>>>=20 >>>> So, this is not a concept that was added in RFC 3280 or 5280. >>>>=20 >>>> Russ >>>> _______________________________________________ >>>> pkix mailing list >>>> pkix@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pkix >>>=20 >>>=20 >>>=20 >>> -- >>> Website: http://hallambaker.com/ >>> _______________________________________________ >>> 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 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From housley@vigilsec.com Mon Apr 9 12:04:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2759021F87E6 for ; Mon, 9 Apr 2012 12:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK9m9Ww0Bd+H for ; Mon, 9 Apr 2012 12:04:31 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6183921F87AE for ; Mon, 9 Apr 2012 12:04:31 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E26389A472B; Mon, 9 Apr 2012 15:04:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id GBHV5mzU4AHK; Mon, 9 Apr 2012 15:04:07 -0400 (EDT) Received: from [192.168.2.101] (pool-96-255-13-167.washdc.fios.verizon.net [96.255.13.167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 3E3789A472A; Mon, 9 Apr 2012 15:04:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Mon, 9 Apr 2012 15:04:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stefan Santesson X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 19:04:32 -0000 Stefan: >> I believe PKIX made a mistake requiring CAs to mark this extension >> critical, while X.509 allows it to be non-critical. This was discussed at length prior to the publication of RFC 2459, which = says: Restrictions are defined in terms of permitted or excluded name subtrees. Any name matching a restriction in the excludedSubtrees field is invalid regardless of information appearing in the permittedSubtrees. This extension MUST be critical. The thinking at the time was that certificates should be rejected when = client does not recognize the name constraints extension. I have not = seen any discussion in this thread that changes my mind on this topic. Russ= From stefan@aaa-sec.com Mon Apr 9 13:05:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583F121F87DC for ; Mon, 9 Apr 2012 13:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxXyaoEyXGZI for ; Mon, 9 Apr 2012 13:05:24 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id AF45B21F87D5 for ; Mon, 9 Apr 2012 13:05:24 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id ABB691E1EB68 for ; Mon, 9 Apr 2012 22:05:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YorpjT37lqON for ; Mon, 9 Apr 2012 22:05:22 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 5B4D11E1EB2E for ; Mon, 9 Apr 2012 22:05:22 +0200 (CEST) Received: (qmail 37556 invoked from network); 9 Apr 2012 20:05:22 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.2]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Apr 2012 20:05:22 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 09 Apr 2012 22:01:57 +0200 From: Stefan Santesson To: Russ Housley Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 20:05:25 -0000 Russ, At the time of creating RFC 2459, I would probably been on the side of votes for mandating criticality. After spending my past 9 years in development, trying to get these things in practical use, my perspective has tend to gravitate more towards pragmatism. Unfortunately, today there is quite a gap between theoretical PKI and PKI in practice. A successful implementor need not only to be skilled in the theory, but also in the parts where common deployment deviate from the standards. This has caused many PKI deployment efforts to adapt a "trial and error" approach to PKI. You simply tweak your deployment until it passes the diverse clients and servers that need to use it. At my years at Microsoft it was quite an experience to discover how many implementations out there that got broken every time we corrected a non-conformant feature in the PKI stack of the Windows OS. I believe the industry is best served if we, where it can be done responsibly, try to at least reduce the gap between PKI theory and practice, fully aware that it never will be fully closed. On the issue at hand, I simply can't see that the matter of criticality for NC is anything more than a policy decision by the CA. Further, a policy decision that in no way puts standards compliant clients at risk. Fully respecting that others might disagree. Just my 2 cents. /Stefan On 12-04-09 9:04 PM, "Russ Housley" wrote: > >Stefan: > >>> I believe PKIX made a mistake requiring CAs to mark this extension >>> critical, while X.509 allows it to be non-critical. > >This was discussed at length prior to the publication of RFC 2459, which >says: > > Restrictions are defined in terms of permitted or excluded name > subtrees. Any name matching a restriction in the excludedSubtrees > field is invalid regardless of information appearing in the > permittedSubtrees. This extension MUST be critical. > >The thinking at the time was that certificates should be rejected when >client does not recognize the name constraints extension. I have not >seen any discussion in this thread that changes my mind on this topic. > >Russ From SChokhani@cygnacom.com Mon Apr 9 14:02:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887EA21F87E8 for ; Mon, 9 Apr 2012 14:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKuUuU5oOpi7 for ; Mon, 9 Apr 2012 14:02:47 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id C170721F87DE for ; Mon, 9 Apr 2012 14:02:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,395,1330923600"; d="scan'208";a="4656050" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 09 Apr 2012 17:02:43 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 9 Apr 2012 17:02:42 -0400 From: Santosh Chokhani To: Stefan Santesson , Russ Housley Date: Mon, 9 Apr 2012 17:02:42 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0WjCDB8EmNNa3+QRycyb8xe+Uw+gAB1gGA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 21:02:48 -0000 Stefan, The very much the length of this debate and disagreement and rationale you = provide is the reason in itself that the standard should not change. With this debate we know the exposure and producers and consumers can come = to agreement in an appropriate forum how to transition to secure implementa= tion. If the standard said this extension can be NC, folks would be happy to prod= uce certificates with NC and some browsers will not implement name constrai= nts processing. It is important that we get where the RP enforce the CA defined constraints= and making security critical extensions NC in a security standard is not t= he way to get their attention. It is a way to tell folks that this is not = important for security. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ste= fan Santesson Sent: Monday, April 09, 2012 4:02 PM To: Russ Housley Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Russ, At the time of creating RFC 2459, I would probably been on the side of vote= s for mandating criticality. After spending my past 9 years in development, trying to get these things i= n practical use, my perspective has tend to gravitate more towards pragmati= sm. Unfortunately, today there is quite a gap between theoretical PKI and PKI i= n practice. A successful implementor need not only to be skilled in the theory, but als= o in the parts where common deployment deviate from the standards. This has caused many PKI deployment efforts to adapt a "trial and error" approach to PKI. You simply tweak your deployment until it passes the diverse clients and se= rvers that need to use it. At my years at Microsoft it was quite an experience to discover how many im= plementations out there that got broken every time we corrected a non-confo= rmant feature in the PKI stack of the Windows OS. I believe the industry is best served if we, where it can be done responsib= ly, try to at least reduce the gap between PKI theory and practice, fully a= ware that it never will be fully closed. On the issue at hand, I simply can't see that the matter of criticality for= NC is anything more than a policy decision by the CA. Further, a policy decision that in no way puts standards compliant clients = at risk. Fully respecting that others might disagree. Just my 2 cents. /Stefan On 12-04-09 9:04 PM, "Russ Housley" wrote: > >Stefan: > >>> I believe PKIX made a mistake requiring CAs to mark this extension=20 >>> critical, while X.509 allows it to be non-critical. > >This was discussed at length prior to the publication of RFC 2459,=20 >which >says: > > Restrictions are defined in terms of permitted or excluded name > subtrees. Any name matching a restriction in the excludedSubtrees > field is invalid regardless of information appearing in the > permittedSubtrees. This extension MUST be critical. > >The thinking at the time was that certificates should be rejected when=20 >client does not recognize the name constraints extension. I have not=20 >seen any discussion in this thread that changes my mind on this topic. > >Russ _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From dev+ietf@seantek.com Mon Apr 9 14:46:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650A921F87B0 for ; Mon, 9 Apr 2012 14:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKTvAEFtCMgz for ; Mon, 9 Apr 2012 14:46:01 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 681B721F87A9 for ; Mon, 9 Apr 2012 14:46:01 -0700 (PDT) Received: from [192.168.123.7] (unknown [76.89.180.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D9C2F22E259 for ; Mon, 9 Apr 2012 17:45:54 -0400 (EDT) Message-ID: <4F835890.4060506@seantek.com> Date: Mon, 09 Apr 2012 14:45:52 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 21:46:02 -0000 "When all is said and done, much more is said than done." -Dave Cutler As Ryan Sleevi pointed out, Apple's tpPolicy code is open source, governed by the Apple Public Source License 2.0. Would we really be having this argument over a standards body mailing list (which now stretches to 138 messages), if someone just fixed Apple's code? Any one of a number of commenters could use their Prodigious Corporate Resources(tm) to fix the problem, and post a fix to Apple. It seriously would not take more than 2 weeks of a senior engineer's time. That will accomplish your long-range business and security objectives much better than fiddling with the criticality bit. As to any installed base argument that might crop up, Apple users are pretty good about getting updates in a timely fashion. See for iOS statistics. -Sean From anders.rundgren@telia.com Mon Apr 9 15:00:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C3221F87FF for ; Mon, 9 Apr 2012 15:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyzRzIy540Ls for ; Mon, 9 Apr 2012 15:00:40 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 822C021F87FC for ; Mon, 9 Apr 2012 15:00:39 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E00AA6531 for pkix@ietf.org; Tue, 10 Apr 2012 00:00:37 +0200 Message-ID: <4F835C04.3040707@telia.com> Date: Tue, 10 Apr 2012 00:00:36 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "pkix@ietf.org" References: <4F8356FE.7040208@w3.org> In-Reply-To: <4F8356FE.7040208@w3.org> X-Enigmail-Version: 1.4 X-Forwarded-Message-Id: <4F8356FE.7040208@w3.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Fwd: W3C launches Web Cryptography Working Group X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 22:00:40 -0000 -------- Original Message -------- Subject: W3C launches Web Cryptography Working Group Resent-Date: Mon, 09 Apr 2012 21:38:16 +0000 Resent-From: public-identity@w3.org Date: Mon, 09 Apr 2012 23:39:10 +0200 From: Harry Halpin To: public-identity@w3.org Everyone - thanks for all the feedback and work since the Workshop, we're finally launching: W3C launched today a new Web Cryptography Working Group, whose mission is to define an API that lets developers implement secure application protocols on the level of Web applications, including message confidentiality and authentication services, by exposing trusted cryptographic primitives from the browser. Web application developers will no longer have to create their own or use untrusted third-party libraries for cryptographic primitives. This will improve security on the Web. Some of the chartered use cases for this API include: http://www.w3.org/2012/webcrypto/ http://www.w3.org/2011/11/webcryptography-charter * The ability to select credentials and sign statements can be necessary to perform high-value transactions such as those involved in finance, corporate security, and identity-related claims about personal data. * The provisioning and use of keys within Web applications can be used for scenarios such as increasing the security of user authentication and determining whether a particular device is authenticated for particular services. * The ability to check source integrity before executing Javascript code previously stored in local storage. Learn more about the Security Activity. http://www.w3.org/Security/Activity From ron.ogle@technicolor.com Mon Apr 9 14:00:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663B921F8803 for ; Mon, 9 Apr 2012 14:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdVfqw1ugvRW for ; Mon, 9 Apr 2012 14:00:42 -0700 (PDT) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with ESMTP id 936DC21F8720 for ; Mon, 9 Apr 2012 14:00:17 -0700 (PDT) Received: from INDYSEDGE01.am.thmulti.com ([157.254.234.137]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKT4NN4HB0Z5dbLAV1/J1wT/n/TV+VwvcP@postini.com; Mon, 09 Apr 2012 14:00:42 PDT Received: from INDYSMAILHT03.am.thmulti.com (157.254.96.147) by INDYSEDGE01.am.thmulti.com (157.254.234.136) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 9 Apr 2012 16:59:23 -0400 Received: from INDYSMAILMB04.am.thmulti.com ([169.254.2.79]) by INDYSMAILHT03.am.thmulti.com ([157.254.96.147]) with mapi; Mon, 9 Apr 2012 16:59:37 -0400 From: Ogle Ron To: Stefan Santesson , Russ Housley Date: Mon, 9 Apr 2012 16:59:37 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0Wk60eHEbqTGmOSu+277AOvwQAZA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 09 Apr 2012 16:37:39 -0700 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 21:18:29 -0000 I do not normally add my .02 to these types of discussions; however, this time I will. I run a set of Certificate Authorities that have easily generated 100M+ certs for Cable Modems, DSL Gateways, and other consumer electronics products. Some of these PKIs run as subordinate to CableLabs and Excentis (Euro version of CableLabs) Root CAs. We try to run as close to PKIX RFCs as possible; however, we will deviate when necessary (seldom). From my perspective, NC is a business decision not a technical problem with a specification. I know that some on this list view this as a security issue, and they are trying to save the RP from themselves and the CA owners that they use. Maybe the best decision for those who see this as a security issue is to put in a note or caveat to the RFC that explains why this extension is important. However, the RFC has to reflect that this extension is a business decision by using "SHOULD" or "MAY" instead of "MUST" for the critical flag. The CA owners and RPs have to determine what is best for them, and how much security they need to do the job. Use education instead of the stick for this extension and the critical flag. FYI, if I do something with one of my subordinate CAs, CableLabs/Excentis will revoke me. It is a business decision that doesn't rely upon a certificate extension. The same can be done with any other subordinate under other roots. If the Enterprise CA is providing invalid certs, then the Root CA owner can revoke the subordinate. Of course, this too would be a business decision, but it is a very strong dis-incentive. BTW, it would not be a bad idea for Mitre, NSA, or NIST to provide guidance to us mere mortals on how CA owners can be evaluated for levels of assurance/trust. Right now the CA Root providers see this as simple commercial offerings instead of necessarily a security structure to provide commerce. As such they may not take the appropriate actions to provide a high level of assurance (but then again not everyone needs or wants a high level of assurance). I would really like to see these super smart demi-gods come up with a way for us mortals to see which Root providers can be evaluated at a specific level. Then us poor security worker bees can tell our IT brethren to remove certain CA Roots from our infrastructure because they don't make the grade. (I think that you'll see the market rapidly change when Roots are dropped.) Ron Ogle My thoughts are my own, and do not necessarily reflect those of my organization for whom I am employed. On 4/9/12 16:01 , "Stefan Santesson" wrote: >Russ, > >At the time of creating RFC 2459, I would probably been on the side of >votes for mandating criticality. > >After spending my past 9 years in development, trying to get these things >in practical use, my perspective has tend to gravitate more towards >pragmatism. >Unfortunately, today there is quite a gap between theoretical PKI and PKI >in practice. >A successful implementor need not only to be skilled in the theory, but >also in the parts where common deployment deviate from the standards. > >This has caused many PKI deployment efforts to adapt a "trial and error" >approach to PKI. >You simply tweak your deployment until it passes the diverse clients and >servers that need to use it. > >At my years at Microsoft it was quite an experience to discover how many >implementations out there that got broken every time we corrected a >non-conformant feature in the PKI stack of the Windows OS. > >I believe the industry is best served if we, where it can be done >responsibly, try to at least reduce the gap between PKI theory and >practice, fully aware that it never will be fully closed. > >On the issue at hand, I simply can't see that the matter of criticality >for NC is anything more than a policy decision by the CA. >Further, a policy decision that in no way puts standards compliant clients >at risk. >Fully respecting that others might disagree. > >Just my 2 cents. > >/Stefan > > >On 12-04-09 9:04 PM, "Russ Housley" wrote: > >> >>Stefan: >> >>>> I believe PKIX made a mistake requiring CAs to mark this extension >>>> critical, while X.509 allows it to be non-critical. >> >>This was discussed at length prior to the publication of RFC 2459, which >>says: >> >> Restrictions are defined in terms of permitted or excluded name >> subtrees. Any name matching a restriction in the excludedSubtrees >> field is invalid regardless of information appearing in the >> permittedSubtrees. This extension MUST be critical. >> >>The thinking at the time was that certificates should be rejected when >>client does not recognize the name constraints extension. I have not >>seen any discussion in this thread that changes my mind on this topic. >> >>Russ > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From James.H.Manger@team.telstra.com Mon Apr 9 16:56:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B4E21F87F4 for ; Mon, 9 Apr 2012 16:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sopjRAtd4sHJ for ; Mon, 9 Apr 2012 16:56:05 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 52A0921F87F3 for ; Mon, 9 Apr 2012 16:56:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,396,1330866000"; d="scan'208";a="68390933" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 10 Apr 2012 09:56:03 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6675"; a="6182245" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcani.tcif.telstra.com.au with ESMTP; 10 Apr 2012 09:56:04 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Tue, 10 Apr 2012 09:56:03 +1000 From: "Manger, James H" To: Santosh Chokhani , IETF PKIX Date: Tue, 10 Apr 2012 09:56:01 +1000 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0WjCDB8EmNNa3+QRycyb8xe+Uw+gAB1gGAAAVrhAA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 23:56:06 -0000 Santosh, > If the standard said this extension can be NC (non-critical), > folks would be happy to produce certificates with NC and some > browsers will not implement name constraints processing. > > It is important that we get where the RP enforce the CA defined > constraints and making security critical extensions NC in a > security standard is not the way to get their attention. > It is a way to tell folks that this is not important for security. At the moment, there is little incentive for an implementation (such as Saf= ari) to implement name constraints as there are almost no certificates usin= g them. A browser is equally secure with or without support. If name constraints can be non-critical, certificates using them can appear= far more easily and there will be an explicit security difference between = browsers that do or do not implement those constraints. That will provide a= tangible incentive for software (such as Safari) to implement name constra= ints. Otherwise it doesn't protect its users from a threat that other brows= ers do, which will look very bad if (or when) the threat becomes an attack. I am in favour of removing the PKIX requirement that name constraints be ma= rked critical. -- James Manger From kent@bbn.com Mon Apr 9 18:35:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4253621F86AA for ; Mon, 9 Apr 2012 18:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.5 X-Spam-Level: X-Spam-Status: No, score=-106.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5p82aXTdYzC for ; Mon, 9 Apr 2012 18:35:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id AFAA121F8562 for ; Mon, 9 Apr 2012 18:35:36 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57555 helo=[172.31.27.154]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHPzJ-0009FY-Bs; Mon, 09 Apr 2012 21:35:17 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201204052139.q35Ld3QW010708@fs4113.wdf.sap.corp> References: <201204052139.q35Ld3QW010708@fs4113.wdf.sap.corp> Date: Mon, 9 Apr 2012 20:57:55 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 01:35:37 -0000 At 11:39 PM +0200 4/5/12, Martin Rex wrote: >Stephen Kent wrote: >> >> It occurs to me that we might be able to make this even more concise >> and tighten the scope. The current text says that these certs don >> contain a basic constraints extension with the CA flag set to true. >> Do they contain a basic constraints extension at all? > >Unfortunately, this differs from the "existing practise" in the >installed base, where the majority of self-signed TLS server certs >in use carries the "Basic Constraints:cA=TRUE" attribute. a self-signed CA cert is already acceptable under X.509 and 280, and thus is not the subject of this text. Steve From kent@bbn.com Mon Apr 9 18:59:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6415911E8085 for ; Mon, 9 Apr 2012 18:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-3dgzgBbVQw for ; Mon, 9 Apr 2012 18:59:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DC32D11E8073 for ; Mon, 9 Apr 2012 18:59:36 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57555 helo=[172.31.27.154]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHPzT-0009FY-QA; Mon, 09 Apr 2012 21:35:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> References: <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> Date: Mon, 9 Apr 2012 21:14:16 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 01:59:37 -0000 At 2:04 AM +0200 4/6/12, Martin Rex wrote: >Stephen Kent wrote: >> >> > >> >Correct, name constraints as "envisioned" by rfc5280 are unusable, >> >in case that you find yourself unable to ignore that invalid MUST. >> >> nonsense. name constraints can be used in any PKI where there there >> are clear lines of authority for issuing certs relative to a name >> space. The fact that the public TTP trust model, at the top, does >> not meet that criterion, is merely an indication of a collision >> between a business model and technology. > > >To me it appears that name constraints might be underspecified. >From how I understand the design of X.509, subject Name and subjectAltNames >are alternative unique representations of the name of the subject. >So in order to use name constraints securely, all name forms present >in a cert would have to be subject to constraints, and all unconstrained >name forms would have to be unconditionally ignored, otherwise the >constraints could be evaded. Not necessarily. In a specific context only certain name forms may be relevant. The presence of other name forms may be harmless and thus they need not be constrained. no need to go through your example. I agree that not all name forms will ever be covered by name constraints, and if these name forms are of concern, then custom RP software would be required. Steve From kent@bbn.com Mon Apr 9 18:59:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110ED11E8073 for ; Mon, 9 Apr 2012 18:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.537 X-Spam-Level: X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhAgLwSkX6DK for ; Mon, 9 Apr 2012 18:59:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 17C3211E8074 for ; Mon, 9 Apr 2012 18:59:37 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57555 helo=[172.31.27.154]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHPzP-0009FY-5I; Mon, 09 Apr 2012 21:35:23 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201204052040.q35Ked7i007422@fs4113.wdf.sap.corp> References: <201204052040.q35Ked7i007422@fs4113.wdf.sap.corp> Date: Mon, 9 Apr 2012 21:01:26 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 01:59:38 -0000 At 10:40 PM +0200 4/5/12, Martin Rex wrote: >Stephen Kent wrote: >> >> At 8:47 PM -0400 4/4/12, Santosh Chokhani wrote: >> >This is quite silly conversation. RP should NOT reject certificate >> >because the criticality flag was not per the standard. >> >> I think the technically correct statement replaces "should not" with >> "need not." > >The behaviour standardized by rfc5280 is equivalent to SHOULD NOT: > > rfc5280 section 6.1 Basic Path Validation, 2nd paragaph: > > http://tools.ietf.org/html/rfc5280#section-6.1 > > While the certificate and CRL profiles specified in Sections 4 and 5 > of this document specify values for certificate and CRL fields and > extensions that are considered to be appropriate for the Internet > PKI, the algorithm presented in this section is not limited to > accepting certificates and CRLs that conform to these profiles. > Therefore, the algorithm only includes checks to verify that the > certification path is valid according to X.509 and does not include > checks to verify that the certificates and CRLs conform to this > profile. While the algorithm could be extended to include checks for > conformance to the profiles in Sections 4 and 5, this profile > RECOMMENDS against including such checks. > > >-Martin yes, and here is an example of where I think we got it wrong. If RPs checked for CAs violating 5280, it would have provided feedback to those CAs and that might have reduced the non-compliant behavior that we see. The RPKI specs require RPs to verify the syntactic constraints imposed on CAs, in an effort to avoid this faiulure mode. We'll see if we have better luck this time. Steve From ynir@checkpoint.com Mon Apr 9 21:38:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B33011E80A4 for ; Mon, 9 Apr 2012 21:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA6IateAOCZv for ; Mon, 9 Apr 2012 21:38:16 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 369F811E8074 for ; Mon, 9 Apr 2012 21:38:15 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3A4cBVr016950; Tue, 10 Apr 2012 07:38:13 +0300 X-CheckPoint: {4F83C689-0-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 10 Apr 2012 07:38:10 +0300 From: Yoav Nir To: "Manger, James H" Date: Tue, 10 Apr 2012 07:38:11 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0W07spe69IquFPQtyhual1UUWvaA== Message-ID: <5A757FAC-D552-45B3-A1FE-BE3FFF60FD38@checkpoint.com> References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 04:38:18 -0000 Hi James, On Apr 10, 2012, at 2:56 AM, Manger, James H wrote: > At the moment, there is little incentive for an implementation (such as S= afari) to implement name constraints as there are almost no certificates us= ing them. A browser is equally secure with or without support. >=20 > If name constraints can be non-critical, certificates using them can appe= ar far more easily and there will be an explicit security difference betwee= n browsers that do or do not implement those constraints. That will provide= a tangible incentive for software (such as Safari) to implement name const= raints. Otherwise it doesn't protect its users from a threat that other bro= wsers do, which will look very bad if (or when) the threat becomes an attac= k. +1 > I am in favour of removing the PKIX requirement that name constraints be = marked critical. I am not in favor of revving 5280. All the arguments for mandatory critical= ity are about generic relying parties. All the examples people give against= requiring criticality are from the commercial CA / browser use case. I th= ink we need another profile, one that is not aimed at the "Internet" like 5= 280, but specifically for browsers and CAs on the world wide web. It doesn't have to be a 150-page behemoth like 5280, either. More like Abstract This document specifies a profile for web browsers and CAs 1. Introduction [RFC5280] specifies a profile for PKI on the Internet. This document spec= ifies=20 a profile for web browsers and CAs. It inherits all the requirements from= =20 RFC 5280, with the exceptions listed in the following sections. 2. Name Constraints RFC 5280 requires name constraints to be marked critical. Under this pro= file this extension MAY be critical. Discussion: =85 Yoav= From anders.rundgren@telia.com Tue Apr 10 00:30:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FC021F8697 for ; Tue, 10 Apr 2012 00:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDMcOCVSOwdp for ; Tue, 10 Apr 2012 00:30:06 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 278C421F8690 for ; Tue, 10 Apr 2012 00:30:05 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E00AB9FCF for pkix@ietf.org; Tue, 10 Apr 2012 09:30:04 +0200 Message-ID: <4F83E178.6070506@telia.com> Date: Tue, 10 Apr 2012 09:30:00 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 07:30:06 -0000 Interesting discussion. Since it is mainly about deficiencies in a few named vendors' PKI SW and nobody from that camp is responding, this is essentially an SDO market adaptation issue. IMO security is a "journey" were all bits and pieces are moving in an uncoordinated fashion. Therefore it seems that offering software vendors an upgrade path would be the pragmatic solution. That "non-critical" extensions like OCSP URLs in reality must be regarded as critical also makes it [sort of] logical allowing non-critical name constraints. Anders From ynir@checkpoint.com Tue Apr 10 00:54:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0537421F8779 for ; Tue, 10 Apr 2012 00:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdjVVxRaIqtR for ; Tue, 10 Apr 2012 00:54:18 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2766721F876C for ; Tue, 10 Apr 2012 00:54:17 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3A7sCAd021648; Tue, 10 Apr 2012 10:54:16 +0300 X-CheckPoint: {4F83F477-1-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 10 Apr 2012 10:53:50 +0300 From: Yoav Nir To: Anders Rundgren Date: Tue, 10 Apr 2012 10:53:49 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0W7xBo1rYiq//tTqe/8RCCJyitww== Message-ID: <0429A6A6-9DF5-4F73-82C1-7DEE5FC5698D@checkpoint.com> References: <201204060004.q3604Bnt018984@fs4113.wdf.sap.corp> <4F83E178.6070506@telia.com> In-Reply-To: <4F83E178.6070506@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 07:54:19 -0000 On Apr 10, 2012, at 10:30 AM, Anders Rundgren wrote: > Interesting discussion. Since it is mainly about deficiencies in a > few named vendors' PKI SW and nobody from that camp is responding, > this is essentially an SDO market adaptation issue. The named vendor is known for its secrecy. > IMO security is a "journey" were all bits and pieces are moving > in an uncoordinated fashion. Therefore it seems that offering > software vendors an upgrade path would be the pragmatic solution. >=20 > That "non-critical" extensions like OCSP URLs in reality must > be regarded as critical also makes it [sort of] logical allowing > non-critical name constraints. The thing is, "critical" at best means "mandatory to implement", but vendor= s can also implement it as "recognize and ignore". We shouldn't try to prevent CAs from reflecting their name constraints to s= upporting RPs, which we will if we require them to exclude non-supporting R= Ps. The name constraints have been in the standards for over 15 years. Some bro= wsers didn't implement their enforcement, because they weren't "in the fiel= d". CAs didn't put them "in the field" because some browsers would barf on = a non-supported critical extension (and rightly so). It's great that Firefo= x did implement this, but without 99% success rate, the CAs won't deploy, b= ut I guess we need non-criticality to get adoption going. Yoav= From Peter.Sylvester@edelweb.fr Tue Apr 10 00:58:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB6B21F8796 for ; Tue, 10 Apr 2012 00:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD+yp6098fjq for ; Tue, 10 Apr 2012 00:58:14 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7A521F877E for ; Tue, 10 Apr 2012 00:58:14 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 574AB7EE5 for ; Tue, 10 Apr 2012 09:58:13 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 459B27BAED1 for ; Tue, 10 Apr 2012 09:56:57 +0200 (CEST) Received: from [192.168.2.42] (p5DE4966E.dip.t-dialin.net [93.228.150.110]) by smtps.on-x.com (Postfix) with ESMTPSA id 883B3236370 for ; Tue, 10 Apr 2012 03:54:00 -0400 (EDT) Message-ID: <4F83E812.1080301@edelweb.fr> Date: Tue, 10 Apr 2012 09:58:10 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 07:58:15 -0000 Hi, Can someone describe how in sight of rfc 6125 one can effectively construct name constraints that allow to only have services maiul, web, etc to *.example.com, fallback to common name included. C=NN; O="white rabbit"; cn="www.example.com" Thanks. From eabalea@gmail.com Tue Apr 10 01:05:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8D421F87C1 for ; Tue, 10 Apr 2012 01:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UMZcgDim7Z2 for ; Tue, 10 Apr 2012 01:05:02 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C362421F877E for ; Tue, 10 Apr 2012 01:05:01 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2446421ggm.31 for ; Tue, 10 Apr 2012 01:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=pmDqoR/Sc8NGjCP4EnWjbitbCRY1Gn7lEoZqX3h0L2Y=; b=WAWIrCgv5tMlwImt74IyC1A+iWwBKO+AyR80Eyq09Fu78sqVHdp/Qp6GNhs0a3DKp/ Nz9guTNEdsBs/YB4vESu2/x5oI/XW38ktQrOzzXPGROJWzWqzyh1sboaQCcxmcn6wB7R pu8VlXyCHAuc7ZvXmcAG+eTTKCABzRb/VCd27HOCGpUsIuE03bNb6/wpJ1GZFFZl3O+l l6bUHNVmvoq7Tzl4J2uiLIBfX+WZLLLKbVZMA8zHfAUqaRjS6Nl2C/CugqOD/4aU9W6x gOHKmQjy2B2o7aIm1CGKjw/06avWuRActZ7IllYcvCEhp+xuvoCixEM0tz78DdngA0SY lqGA== MIME-Version: 1.0 Received: by 10.236.144.134 with SMTP id n6mr8477511yhj.45.1334045101255; Tue, 10 Apr 2012 01:05:01 -0700 (PDT) Received: by 10.236.76.199 with HTTP; Tue, 10 Apr 2012 01:05:00 -0700 (PDT) Received: by 10.236.76.199 with HTTP; Tue, 10 Apr 2012 01:05:00 -0700 (PDT) In-Reply-To: References: <0aad5b1eaee485b5e01ce12c6a9be53d.squirrel@webmail.dreamhost.com> Date: Tue, 10 Apr 2012 10:05:00 +0200 Message-ID: From: Erwann Abalea To: "pkix@ietf.org" Content-Type: multipart/alternative; boundary=20cf303dd2765feaba04bd4e948e Subject: [pkix] Fwd: Re: Fully Qualified Domain Name (FQDN) in DN and Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 08:05:03 -0000 --20cf303dd2765feaba04bd4e948e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ---------- Message transf=C3=A9r=C3=A9 ---------- De : "Erwann Abalea" Date : 9 avr. 2012 18:00 Objet : Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints =C3=80 : Only when you use libpkix. I played with NC yesterday, critical and non critical, constrained with dnsname. An SSL certificate containing a bad CN is not detected. The same certificate with the fqdn placed in the SAN is detected and rejected. Firefox 3.6.8. --=20 Erwann. Le 9 avr. 2012 17:22, "Ryan Sleevi" a =C3=A9crit : > > > This relates to the name constraints discussion going on in another > > thread. > > > > Does anyone know how the browsers handle a Server certificate if subject > > alternative name is absent and the DN (specifically Common Name) contains > > the FQDN? > > > > Related to this does anyone know what the browsers do with this name form > > if the certification path has URL or DNS Names constrained? Do, they > > enforce the applicable constraints on them. > > > > I did not find language in 5280 that deal with this. I may have misse= d > > something. > > > > > > Santosh Chokhani > > CygnaCom Solutions > > NSS, used by both Mozilla Firefox (all platforms) and Google > Chrome/Chromium (Linux) constrains the CN-ID if the CN-ID appears to have > a FQDN and dNSNames are constrained. The applicable bug number that > implemented this behaviour is > https://bugzilla.mozilla.org/show_bug.cgi?id=3D394919 > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --20cf303dd2765feaba04bd4e948e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


---------- Message transf=C3=A9r=C3=A9 ----------
De=C2=A0: "Erwann Abalea" <eabalea@gmail.com>
Date=C2=A0: 9 avr. 2012 18:00
Objet=C2=A0: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name C= onstraints
=C3=80=C2=A0: <ryan-pkix@sleevi.= com>

Only when you use libpkix.
I played with NC yesterday, critical and non critical, constrained with dns= name. An SSL certificate containing a bad CN is not detected. The same cert= ificate with the fqdn placed in the SAN is detected and rejected.
Firefox 3.6.8.

--
Erwann.

Le 9 avr. 2012 17:22, "Ryan Sleevi" <ryan-pkix@sleevi.com> a =C3=A9crit=C2=A0:

>
> > =C2=A0This relates to the name constraints discussion going on in= another
> > =C2=A0thread.
> >
> > =C2=A0Does anyone know how the browsers handle a Server certifica= te if subject
> > =C2=A0alternative name is absent and the DN (specifically Common = Name) contains
> > =C2=A0the FQDN?
> >
> > =C2=A0Related to this does anyone know what the browsers do with = this name form
> > =C2=A0if the certification path has URL or DNS Names constrained?= =C2=A0Do, they
> > =C2=A0enforce the applicable constraints on them.
> >
> > =C2=A0I did not find language in 5280 that deal with this. =C2=A0= I may have missed
> > =C2=A0something.
> >
> >
> > =C2=A0Santosh Chokhani
> > =C2=A0CygnaCom Solutions
>
> NSS, used by both Mozilla Firefox (all platforms) and Google
> Chrome/Chromium (Linux) constrains the CN-ID if the CN-ID appears to h= ave
> a FQDN and dNSNames are constrained. The applicable bug number that > implemented this behaviour is
> http= s://bugzilla.mozilla.org/show_bug.cgi?id=3D394919
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.iet= f.org/mailman/listinfo/pkix

--20cf303dd2765feaba04bd4e948e-- From anders.rundgren@telia.com Tue Apr 10 01:52:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E4721F866C for ; Tue, 10 Apr 2012 01:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSAEzYEDvBDG for ; Tue, 10 Apr 2012 01:52:38 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 07F8821F872E for ; Tue, 10 Apr 2012 01:52:37 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E00AC717B; Tue, 10 Apr 2012 10:52:36 +0200 Message-ID: <4F83F4D1.7030806@telia.com> Date: Tue, 10 Apr 2012 10:52:33 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tomas Gustavsson References: <4F718771.6060906@ieca.com> <4F719B3D.10101@telia.com> <4F7AFEF8.7050406@telia.com> <2B4C275D-3278-4A0F-B231-D7384AEE9489@cisco.com> <4F7D5ABC.8080400@telia.com> <4F7D5E3B.8010708@primekey.se> In-Reply-To: <4F7D5E3B.8010708@primekey.se> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 08:52:42 -0000 On 2012-04-05 10:56, Tomas Gustavsson wrote: > On 04/05/2012 10:41 AM, Anders Rundgren wrote: >> On 2012-04-04 20:08, Max Pritikin wrote: >>> >>> On Apr 3, 2012, at 7:45 AM, Anders Rundgren wrote: >>> >>>> On 2012-04-03 01:48, Max Pritikin wrote: >>>>> >>>>> Comments inline, >>>>> >>>>> On Mar 27, 2012, at 4:49 AM, Anders Rundgren wrote: >>>>> >>>>>> Continuing this thread... >>>>>> >>>>>> From the abstract I would be interested in hearing what >>>>>> >>>>>> "simple Public Key Infrastructure clients" >>>>>> >>>>>> actually refer to. >>>>> >>>>> The first paragraph of the introduction notes that: "EST is designed to be easily implemented by clients and servers using common "off the shelf" PKI, HTTP, and TLS components". This also relates to the use of the "simple" messages defined in CMC. >>>> >>>> That's one way of expressing it. I'm a hands-on guy so I am rather >>>> thinking about how well it fits things like this: >>>> >>>> http://www.pcworld.com/businesscenter/article/252584/ibm_cio_discusses_big_blues_byod_strategy.html >>>> >>>> IMO EST doesn't address this market without adding non-standard >>>> "bootstrap" steps like Cisco's AnyConnect. I find AnyConnect pretty >>>> quirky and (undocumented...) compared to Apple's bootstrap profile scheme. >>>> >>>> It seems that you actually must be a device/OS vendor in order to implement >>>> things the way Apple do since no "mere mortals" can get under the hood or >>>> dump arbitrary junk in SYSTEM32 like we did during the Windows days. >>> >>> A general purpose bootstrapping system that works for a variety of solutions >>> ranging from Anyconnect products to the Iphone is a great idea. I'd happily >>> provide input on such a working group. EST within pkix is not the proper >>> venue for those ideas though. >> >> PKIX is indeed the wrong place for creating a new mainstream enrollment system >> since all bootstrapping systems I have seen are based on XML. >> >> Unfortunately none of "The big three" are interested in standardization efforts >> regarding enrollment; they rather have, or are in the process of creating such >> things on their own. Given the lack of interest among SDOs, I think this is >> the only reasonable decision. >> >> In addition, I can hardly imagine Cisco and Checkpoint cooperating on VPM BYOD enrollment >> so those who (like me) actually have to deploy stuff at customer sites probably gain >> most by one of the big three coming out as winner although it will take a while. > > That's really painting a dark future. Those big ones have generally done > a lot to make things harder for us techies, and indeed things are very > hard today, much harder than it would have needed to be if they had > cooperated in something like IETF. Hi Tomas, The problem is that there was never any money in strong authentication software for consumers which is the reason why the market leader in desktop OSes never bothered much about it. In addition, it is (as we have seen on this very list), not particularly easy discussing what such solutions should possibly do. PIN-protected credentials which is a standard feature for banks were considered as a "strange" requirement by all but me. Anyway, the new "Super Providers" Apple and Google do not only produce devices (or OSes for devices), they are also heavily engaged in services which means that they (in contrast to the 100 000 banks around the globe), not only have the vehicles but also the *motives* needed for establishing strong authentication solutions for consumers. I think this is much more important than fixing the SSL PKI since even if you login to "badbank.com" (through a mistake or through an active attack), with a client-certificate, "badbank.com" will not be able to reuse that login at "goodbank.com". If the IETF is interested in participating in this space, I think they need to come up with a plan, and that pretty soon as well! Anders > > Cheers, > Tomas > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From rob.stradling@comodo.com Tue Apr 10 02:09:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E1421F85E3 for ; Tue, 10 Apr 2012 02:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-UuX96HEOn0 for ; Tue, 10 Apr 2012 02:09:00 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 664A521F85DF for ; Tue, 10 Apr 2012 02:09:00 -0700 (PDT) Received: (qmail 19533 invoked from network); 10 Apr 2012 09:08:59 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Apr 2012 09:08:59 -0000 Received: (qmail 13832 invoked by uid 1000); 10 Apr 2012 09:08:58 -0000 Received: from nigel.brad.office.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 (CAMELLIA256-SHA encrypted) ESMTPSA; Tue, 10 Apr 2012 10:08:58 +0100 Message-ID: <4F83F8AA.9080904@comodo.com> Date: Tue, 10 Apr 2012 10:08:58 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: Yoav Nir References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> <5A757FAC-D552-45B3-A1FE-BE3FFF60FD38@checkpoint.com> In-Reply-To: <5A757FAC-D552-45B3-A1FE-BE3FFF60FD38@checkpoint.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 09:09:01 -0000 On 10/04/12 05:38, Yoav Nir wrote: > Hi James, > > On Apr 10, 2012, at 2:56 AM, Manger, James H wrote: > >> At the moment, there is little incentive for an implementation (such as Safari) to implement name constraints as there are almost no certificates using them. A browser is equally secure with or without support. >> >> If name constraints can be non-critical, certificates using them can appear far more easily and there will be an explicit security difference between browsers that do or do not implement those constraints. That will provide a tangible incentive for software (such as Safari) to implement name constraints. Otherwise it doesn't protect its users from a threat that other browsers do, which will look very bad if (or when) the threat becomes an attack. > > +1 > >> I am in favour of removing the PKIX requirement that name constraints be marked critical. > > I am not in favor of revving 5280. All the arguments for mandatory criticality are about generic relying parties. All the examples people give against requiring criticality are from the commercial CA / browser use case. I think we need another profile, one that is not aimed at the "Internet" like 5280, but specifically for browsers and CAs on the world wide web. > > It doesn't have to be a 150-page behemoth like 5280, either. More like > > Abstract > This document specifies a profile for web browsers and CAs > > 1. Introduction > [RFC5280] specifies a profile for PKI on the Internet. This document specifies > a profile for web browsers and CAs. It inherits all the requirements from > RFC 5280, with the exceptions listed in the following sections. Hi Yoav. Such a document already exists, so I don't think we need another new doc. http://www.cabforum.org/Baseline_Requirements_V1.pdf See Appendix B. The Name Constraints extension is not mentioned, which means that "All other fields and extensions MUST be set in accordance to RFC 5280" applies. > 2. Name Constraints > RFC 5280 requires name constraints to be marked critical. Under this profile > this extension MAY be critical. I intend to propose (on the CABForum list) updating the Baseline Requirements to allow NC to be non-critical. > Discussion: … > > > Yoav > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From tgindin@us.ibm.com Tue Apr 10 05:26:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D6521F8582 for ; Tue, 10 Apr 2012 05:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qm+rVdt6huPR for ; Tue, 10 Apr 2012 05:26:40 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by ietfa.amsl.com (Postfix) with ESMTP id 03FA021F854E for ; Tue, 10 Apr 2012 05:26:39 -0700 (PDT) Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Apr 2012 08:26:37 -0400 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 10 Apr 2012 08:26:34 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 50E8038C805C for ; Tue, 10 Apr 2012 08:26:33 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3ACQXVV3113140 for ; Tue, 10 Apr 2012 08:26:33 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3AHvO2k006612 for ; Tue, 10 Apr 2012 13:57:25 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3AHvOvG006604; Tue, 10 Apr 2012 13:57:24 -0400 In-Reply-To: References: To: Peter Gutmann MIME-Version: 1.0 X-KeepSent: 39FA0AC1:87E77C41-852579DB:0050C83D; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Tue, 10 Apr 2012 08:26:31 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/10/2012 08:26:31, Serialize complete at 04/10/2012 08:26:31 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12041012-1976-0000-0000-00000C356818 Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:26:40 -0000 AFAIK, no large organization uses unicorns. The good news arising from this part of the thread is that it's been clarified that it constitutes 5280-compliant RP processing to implement X.400 Name Constraints, like those for Registered ID or EDIPartyName, by rejecting any EE certificate with a SubjectAltName member of that form coming from a chain with a subtree of that form. As a practical matter, I expect most such RP's to do exactly that. That should remove one minor deterrent to the adoption of Name Constraints by RP's. Tom Gindin From: Peter Gutmann To: SChokhani@cygnacom.com, Tom Gindin/Watson/IBM@IBMUS, Cc: pkix@ietf.org Date: 04/09/2012 06:07 AM Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Tom Gindin writes: >The actual processing of X.400 name constraints is almost unspecified in both >RFC 5280 and X.509-2008. This is far more of a weakness for X.509 than for >RFC 5280, which at least makes it clear that it doesn't advocate such name >constraints. The issue I'm bringing up is that an RP may recognize an X.400 >name form while not knowing how to fully implement name constraints for it. How many implementations properly handle X.400 names. Not even name constraints, but just basic X.400 names [0]? Worrying about X.400 name constraints being underspecified is a bit like worrying about unicorn constraints being underspecified. Peter. [0] Yes, I know, the USG still uses X.400. I'm looking for stuff in our reality, not the USG's parallel universe. From david.cooper@nist.gov Tue Apr 10 05:39:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFF221F85C0 for ; Tue, 10 Apr 2012 05:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.602 X-Spam-Level: X-Spam-Status: No, score=-5.602 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8fgHWqqvlLo for ; Tue, 10 Apr 2012 05:39:11 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id E894021F85B9 for ; Tue, 10 Apr 2012 05:39:10 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q3ACcxla006673 for ; Tue, 10 Apr 2012 08:38:59 -0400 Message-ID: <4F8429E3.70000@nist.gov> Date: Tue, 10 Apr 2012 08:38:59 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 CC: "pkix@ietf.org" References: <201204052139.q35Ld3QW010708@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:39:12 -0000 If that is not the subject of this text then what is? I thought the subject of the text was self-signed certificates that are used to convey public keys that are not intended to be used to begin certification paths. On 04/09/2012 08:57 PM, Stephen Kent wrote: > At 11:39 PM +0200 4/5/12, Martin Rex wrote: >> Stephen Kent wrote: >>> It occurs to me that we might be able to make this even more concise >>> and tighten the scope. The current text says that these certs don >>> contain a basic constraints extension with the CA flag set to true. >>> Do they contain a basic constraints extension at all? >> Unfortunately, this differs from the "existing practise" in the >> installed base, where the majority of self-signed TLS server certs >> in use carries the "Basic Constraints:cA=TRUE" attribute. > a self-signed CA cert is already acceptable under X.509 and 280, and > thus is not > the subject of this text. > > Steve On 11/13/2011 09:36 PM, Sean Turner wrote: > Tim, > > You're right there's no such thing as an EE self-signed cert according > to RFC 5280. The point is for RFC 5280 to be updated to say that there > are such things as EE self-signed certs, which reflects reality (e.g., > dane). > > spt > > On 11/14/11 9:55 AM, Miller, Timothy J. wrote: >> Um, maybe I missed something but there's no such thing as an end-entity >> self-signed certificate. Since constraints can't be enforced every >> self-signed cert is potentially a CA, and should be treated as such. >> >> -- T >> >> On 11/13/11 7:18 PM, "Sean Turner" wrote: >> >>> So maybe I'm being simple minded but this is pretty much what I was >>> asking for. >>> >>> spt >>> >>> On 9/28/11 12:16 AM, Kemp, David P. wrote: >>>> Change 1 - on page 12 replace: >>>> "X.509 v3 also includes an extension that identifies the subject of a >>>> certificate as being either a CA or an end entity, reducing the >>>> reliance on out-of-band information demanded in PEM. >>>> >>>> with: >>>> X.509 v3 also includes two extensions that identify ... >>>> >>>> >>>> Change 2 - on page 12-13 replace: >>>> "This specification covers two classes of certificates: CA >>>> certificates and end entity certificates. CA certificates may be >>>> further divided into three classes: cross-certificates, self-issued >>>> certificates, and self-signed certificates. Cross-certificates are >>>> CA certificates in which the issuer and subject are different >>>> entities. Cross-certificates describe a trust relationship between >>>> the two CAs. Self-issued certificates are CA certificates in which >>>> the issuer and subject are the same entity. Self-issued certificates >>>> are generated to support changes in policy or operations. Self- >>>> signed certificates are self-issued certificates where the digital >>>> signature may be verified by the public key bound into the >>>> certificate. Self-signed certificates are used to convey a public >>>> key for use to begin certification paths. End entity certificates >>>> are issued to subjects that are not authorized to issue certificates." >>>> >>>> with: >>>> >>>> "This specification covers two classes of certificates: CA >>>> certificates and end entity certificates. CA and EE certificates may be >>>> further divided into three classes: CA-issued certificates, self-issued >>>> certificates, and self-signed certificates. Cross-certificates are >>>> CA certificates in which the issuer and subject are different >>>> entities. Cross-certificates describe a trust relationship between >>>> the two CAs. Self-issued certificates are certificates in which >>>> the issuer and subject are the same entity. Self-issued certificates >>>> are generated to support changes in policy or operations. Self- >>>> signed certificates are self-issued certificates where the digital >>>> signature may be verified by the public key bound into the >>>> certificate. Self-signed CA certificates are used to convey a public >>>> key for use to begin certification paths. End entity certificates >>>> are issued to subjects that are not authorized to issue certificates. >>>> Self-signed end entity certificates are used to convey a public key >>>> and other information directly to relying parties without using >>>> a PKI." >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>>> Paul Hoffman >>>> Sent: Tuesday, September 27, 2011 9:55 AM >>>> To: PKIX >>>> Subject: [pkix] End-entity self-signed certs (was: Re: AD Review >>>> ofdraft-ietf-pkix-rfc5280-clarifications-03.txt) >>>> >>>>> On Aug 22, 2011, at 5:52 AM, Sean Turner wrote: >>>>> >>>>>> I think the -03 version is just about ready to go. That is I have no >>>> comments on the existing text though I expect getting it through the >>>> IESG will be interesting (Apps ADs love to discuss about anything to do >>>> with characters strings/sets). But, I think this draft needs to also >>>> address the issue of self-signed EE certificates. I know at least the >>>> DANE WG had a lengthy discussion about self-signed EE certificates, I >>>> see that Max's EST draft also includes them, and they're used in the >>>> wild. I want to see text included that addresses them. >>>> This thread started there, but then sidetracked on more "improvements" >>>> on trust anchors that are express as certificates. Could we please have >>>> two threads? >>>> >>>> --Paul Hoffman >>>> >>>> From DPKemp@missi.ncsc.mil Tue Apr 10 05:39:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E5D21F85C2 for ; Tue, 10 Apr 2012 05:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEtWL5d+xQGC for ; Tue, 10 Apr 2012 05:39:53 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 12DA721F85B9 for ; Tue, 10 Apr 2012 05:39:52 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q3ACdpbM048397 for ; Tue, 10 Apr 2012 08:39:51 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 08:39:51 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 10 Apr 2012 08:39:51 -0400 Message-ID: In-Reply-To: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0UiVGBmrQszxZXSRucZaemwzH1egChrkmQ References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 10 Apr 2012 12:39:51.0895 (UTC) FILETIME=[062D9670:01CD1717] Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:39:54 -0000 It's a question of how to do Engineering. Approach 1: write a spec that describes what you want to achieve, implement the spec as closely as possible given the current operating environment and constraints, note AND EXPECT deviations from the spec, and update implementations as the environment changes. Approach 2: write a spec that achieves what is possible given current operating environment and constraints. As the environment changes, update the spec to add back in capabilities that were previously desired but omitted. I'm not an HTML expert, but does not HTML 4 specify a complete feature set that at one time was not implemented by all browsers? And individual HTML documents can be checked for "strict" or "transitional" compliance? As browser implementations improve, is it not possible to write more and more HTML documents that pass "strict" compliance checking WITHOUT updating the HTML 4 spec itself? My engineering toolbox includes tools like "lint". C compilers may be written to accept non-standard code, but the specification of the C language itself does not continue to evolve based on the current capabilities of compilers and coders. Should the PKIX spec be written like the HTML and C specs (one version that may not be completely adhered to in practice), or should today's version of PKIX be limited to the current state of applications and updated as the application environment changes? My vote is for Approach 1. Dave -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com]=20 > CAs have good=20 > justification for weighting "operate without inconveniencing casual=20 > users" more highly than "secure" in that situation. But it does not=20 > change the specification of the correct way to achieve both=20 > interoperability and security. I disagree. The E in IETF in engineering. A spec that considers only the "secure" and not the "operate without inconveniencing casual users" is bad engineering. Engineering has to consider the operating environment and constraints of those who need to follow the spec. From stefan@aaa-sec.com Tue Apr 10 05:52:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6712721F85CD for ; Tue, 10 Apr 2012 05:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1R8FvhdBaEE for ; Tue, 10 Apr 2012 05:52:40 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5FF21F848B for ; Tue, 10 Apr 2012 05:52:36 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 169631E28F71 for ; Tue, 10 Apr 2012 14:52:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id S5yrfTsXWQGe for ; Tue, 10 Apr 2012 14:52:34 +0200 (CEST) Received: from s329.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id BD71B1E29195 for ; Tue, 10 Apr 2012 14:52:34 +0200 (CEST) Received: (qmail 91165 invoked from network); 10 Apr 2012 12:52:34 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.2]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s329.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Apr 2012 12:52:34 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 10 Apr 2012 14:52:31 +0200 From: Stefan Santesson To: Yoav Nir , "Manger, James H" Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: <5A757FAC-D552-45B3-A1FE-BE3FFF60FD38@checkpoint.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:52:42 -0000 Yoav, On 12-04-10 6:38 AM, "Yoav Nir" wrote: >It doesn't have to be a 150-page behemoth like 5280, either. More like > >Abstract > This document specifies a profile for web browsers and CAs > >1. Introduction > [RFC5280] specifies a profile for PKI on the Internet. This document >specifies > a profile for web browsers and CAs. It inherits all the requirements >from > RFC 5280, with the exceptions listed in the following sections. > >2. Name Constraints > RFC 5280 requires name constraints to be marked critical. Under this >profile > this extension MAY be critical. > Discussion: =8A > It would have to be another profile of X.509. It can't be a profile of RFC 5280 as it isn't compliant with RFC 5280. Since web browsers are an Internet application, I would much rather have a web profile being a profile of RFC 5280. Such a profile AFAIK has already been defined by the cab-forum. /Stefan From hallam@gmail.com Tue Apr 10 05:58:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EBF21F852E for ; Tue, 10 Apr 2012 05:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OI+lQusEJXS4 for ; Tue, 10 Apr 2012 05:58:53 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3099521F852C for ; Tue, 10 Apr 2012 05:58:53 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8190338obb.31 for ; Tue, 10 Apr 2012 05:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s0Bm+C/PBXTEYp+qdvsOCXGb8cXdZmg3z2MzDBK64Zw=; b=wJOjGQ550o2O0O1x0piz5NYUN1yRY14KfVJbkKrYlXO5PTMiGKAMD0RVjKqMLk8M47 RpND/sXFO9VL/C25ehlTEm7DRoiO36fCe9dpx6gMLmyGb2jkkP9LxcgAd8k7YsE7Lqwd g0+oy3mECCHE4i6c0IERXTiIJi3ti5e+z/C0swdPa4jeJCRHjIFxzp64V+6Pac4+HwuR SWv99rScMjmrYXw2T/gvq9o60J2b8h7X4eDLeMwVfeYZJPMpyaWVdQdKwI1t8yotudQF VaTmpy/ZXSE8bNzHlamVYHhJbPy/cXgEvHYNGwkghCDSn5ymua/4d7O5mmyHyfKLgqhV 8Ddg== MIME-Version: 1.0 Received: by 10.60.28.33 with SMTP id y1mr15733932oeg.62.1334062732852; Tue, 10 Apr 2012 05:58:52 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Tue, 10 Apr 2012 05:58:52 -0700 (PDT) Date: Tue, 10 Apr 2012 08:58:52 -0400 Message-ID: From: Phillip Hallam-Baker To: Max Pritikin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stefan Santesson , IETF PKIX Subject: [pkix] Proposal: Change the Compatibility Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 12:58:54 -0000 The only reason that we are having this discussion is that the flag is misnamed. Criticality is ambiguous and has misled some people into thinking it means 'important'. Which it does not. Is the subject key an important field (yes) is it marked critical (nope). If the flag had been called 'Compatibility' instead we would have avoided this whole debate (and many others). All that was being suggested is to change the criticality flag requirement of the NC extension. But to prevent future confusion I suggest we rename the flag in 5280bis as well. On Mon, Apr 9, 2012 at 12:46 PM, Max Pritikin wrote: > +1 (Well stated Stefan) > > This is my position as well: The CAs should make this decision based on t= heir own policy. PKIX documents should, as does the X.509 document, recomme= nd the more secure option. > > Any client that ignores a critical extension's contents should be publicl= y hounded as having a security vulnerability. > > - max > > On Apr 7, 2012, at 6:11 PM, Stefan Santesson wrote: > >> Being away for some days, it was quite a read before anyone cared to loo= k >> in the X.509 spec :) >> >> I regret the flaming in this thread, enough said about that. >> >> I believe PKIX made a mistake requiring CAs to mark this extension >> critical, while X.509 allows it to be non-critical. >> >> The requirement does not affect client behavior (thoroughly examined in >> this thread). It just imposes policy on the CA that actually should be u= p >> to the CA to decide. A CA that concludes that criticality is important, >> can always set it critical. >> >> IOS as well as OS X are clearly not compliant with RFC 5280, but that is >> not a good argument to require criticality. >> >> /Stefan >> >> >> On 12-04-07 10:53 PM, "Kyle Hamilton" wrote: >> >>> Nope. =A0X.509/2008 page 33, section 8.4.2.2: >>> [...] >>> This extension may, at the option of the certificate issuer, be either >>> critical or non-critical . It is recommended that it be >>> flagged critical, otherwise a certificate user may not check that >>> subsequent certificates in a certification path are located >>> in the name space intended by the issuing CA. >>> [...] >>> >>> The criticality mandate is all PKIX. >>> >>> -Kyle H >>> >>> On Sat, Apr 7, 2012 at 12:39 PM, Phillip Hallam-Baker >>> wrote: >>>> Isn't it an X509v3 requirement in any case? >>>> >>>> On Sat, Apr 7, 2012 at 3:30 PM, Russ Housley >>>> wrote: >>>>> Ryan: >>>>> >>>>>> While Apple's OS X (desktop) implementation will not choke if Name >>>>>> Constraints is marked critical, it does not support processing name >>>>>> constraints and will not enforce them - critical or not. It does not >>>>>> quite >>>>>> implement all of RFC 2459, let alone 3280 or 5280, nor does 2459 >>>>>> require >>>>>> that it fail processing if it does not process a critical extension >>>>>> (although 5280 does). >>>>> >>>>> RFC 2459 says: >>>>> >>>>> =A0... =A0A >>>>> =A0certificate using system MUST reject the certificate if it encount= ers >>>>> =A0a critical extension it does not recognize; however, a non-critica= l >>>>> =A0extension may be ignored if it is not recognized. =A0... >>>>> >>>>> So, this is not a concept that was added in RFC 3280 or 5280. >>>>> >>>>> Russ >>>>> _______________________________________________ >>>>> pkix mailing list >>>>> pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix >>>> >>>> >>>> >>>> -- >>>> Website: http://hallambaker.com/ >>>> _______________________________________________ >>>> 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 > --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Apr 10 06:11:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EB221F8628 for ; Tue, 10 Apr 2012 06:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXksxLhcWVaz for ; Tue, 10 Apr 2012 06:11:00 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A00921F85D0 for ; Tue, 10 Apr 2012 06:10:59 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8204595obb.31 for ; Tue, 10 Apr 2012 06:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zRqYN7SHVJVqtOsFQuAVX9/qtJS6/GlXquvpST7lQoc=; b=v9TF2O2A9IGJx5S2nDzUtNpXOOIu+PRlljBBGMQuz8URg8+ADhYNssekHcSMqfj/+N aTp85M6c9pXTKUvdInBa+2u76GVy0aeXFypfqgeJAk5gGl5aN0rfzdQcOFUZnFSyONpO j0+X96JByzGX03+xeZAq3Z4MGg7DbQk/Ekv4n6pxSCWp3YXtEaDlDxYmeXVURGWbb8Us gVy6MKPlbshsSsJRCywM9hv8EoTMdqyFyagiWRuQcAoj5tyDuu88433bCPEGFr9XJDuG YKixZzZ+bBCYCRA+NIblXUtHiuhX7hK4DxkbKMb1KZuBQBAsZhpgZJOi+0+l+Bj7Z1aw WRCg== MIME-Version: 1.0 Received: by 10.60.3.99 with SMTP id b3mr15676461oeb.72.1334063459680; Tue, 10 Apr 2012 06:10:59 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Tue, 10 Apr 2012 06:10:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 09:10:59 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stefan Santesson , IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:11:01 -0000 For someone who was accusing me earlier of not understanding PKI, this is quite a statement. It is not even gramatical, I can't parse it. What you seem to be saying is that having this debate is a good thing because all those troublesome implementers and users will go somewhere else to solve their problems in future. On Mon, Apr 9, 2012 at 5:02 PM, Santosh Chokhani w= rote: > Stefan, > > The very much the length of this debate and disagreement and rationale yo= u provide is the reason in itself that the standard should not change. > > With this debate we know the exposure and producers and consumers can com= e to agreement in an appropriate forum how to transition to secure implemen= tation. > > If the standard said this extension can be NC, folks would be happy to pr= oduce certificates with NC and some browsers will not implement name constr= aints processing. > > It is important that we get where the RP enforce the CA defined constrain= ts and making security critical extensions NC in a security standard is not= the way to get their attention. =A0It is a way to tell folks that this is = not important for security. > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of S= tefan Santesson > Sent: Monday, April 09, 2012 4:02 PM > To: Russ Housley > Cc: IETF PKIX > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > > Russ, > > At the time of creating RFC 2459, I would probably been on the side of vo= tes for mandating criticality. > > After spending my past 9 years in development, trying to get these things= in practical use, my perspective has tend to gravitate more towards pragma= tism. > Unfortunately, today there is quite a gap between theoretical PKI and PKI= in practice. > A successful implementor need not only to be skilled in the theory, but a= lso in the parts where common deployment deviate from the standards. > > This has caused many PKI deployment efforts to adapt a "trial and error" > approach to PKI. > You simply tweak your deployment until it passes the diverse clients and = servers that need to use it. > > At my years at Microsoft it was quite an experience to discover how many = implementations out there that got broken every time we corrected a non-con= formant feature in the PKI stack of the Windows OS. > > I believe the industry is best served if we, where it can be done respons= ibly, try to at least reduce the gap between PKI theory and practice, fully= aware that it never will be fully closed. > > On the issue at hand, I simply can't see that the matter of criticality f= or NC is anything more than a policy decision by the CA. > Further, a policy decision that in no way puts standards compliant client= s at risk. > Fully respecting that others might disagree. > > Just my 2 cents. > > /Stefan > > > On 12-04-09 9:04 PM, "Russ Housley" wrote: > >> >>Stefan: >> >>>> I believe PKIX made a mistake requiring CAs to mark this extension >>>> critical, while X.509 allows it to be non-critical. >> >>This was discussed at length prior to the publication of RFC 2459, >>which >>says: >> >> =A0 Restrictions are defined in terms of permitted or excluded name >> =A0 subtrees. =A0Any name matching a restriction in the excludedSubtrees >> =A0 field is invalid regardless of information appearing in the >> =A0 permittedSubtrees. =A0This extension MUST be critical. >> >>The thinking at the time was that certificates should be rejected when >>client does not recognize the name constraints extension. =A0I have not >>seen any discussion in this thread that changes my mind on this topic. >> >>Russ > > > _______________________________________________ > 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 --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Apr 10 06:13:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E16D21F863C for ; Tue, 10 Apr 2012 06:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dev0vKW3WC+U for ; Tue, 10 Apr 2012 06:13:30 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFF021F8638 for ; Tue, 10 Apr 2012 06:13:30 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2563013ghb.31 for ; Tue, 10 Apr 2012 06:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7iS4Q/xwHh+jqsgcQtLNc7ZS4pyB6991+/UfqWducMs=; b=z5aatZgUFDp/JyhxuQ3Yyq9TvaH34Vr1q+BSlJlfVAlLsT2VLhrSjQGZk9MzyQlTMF BpH+Y47uOBcuwDz6fsJbNdGgRr7k9uXOApjrnd9IRugpjawfRhUM109A/FGHITzUVHeu VAxpYDBkJH71PvFQxvTb598jI46j/DmYq26aa5In6FcygBGHE8AqG//IlvKRxE6yZiJ6 NWcT2dyJU4c7NRruDD8MX+J6B7HdtDWWj4tAtu/96TYzVzhC2xg7COSxx5DCEhDBP8+X +fT06/hpgX2pbeDKUo+JQBxkhlCzvm9OZYzLm3cV7nktr9kG55Ns5y87HkKbHQLpmofb Llsg== MIME-Version: 1.0 Received: by 10.60.28.33 with SMTP id y1mr15816890oeg.62.1334063609952; Tue, 10 Apr 2012 06:13:29 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Tue, 10 Apr 2012 06:13:29 -0700 (PDT) In-Reply-To: <4F835890.4060506@seantek.com> References: <4F835890.4060506@seantek.com> Date: Tue, 10 Apr 2012 09:13:29 -0400 Message-ID: From: Phillip Hallam-Baker To: Sean Leonard Content-Type: text/plain; charset=ISO-8859-1 Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:13:31 -0000 Fixing Apple's code is one thing, getting them to distribute is another, getting users to upgrade yet another. Apple is not even patching their known virus vulnerability in Snow Leopard, there are still Power PC users who have no support at all. We can't wait ten years before using this technology. I have seen no good argument for continuing to attempt PKIX compliance here. On Mon, Apr 9, 2012 at 5:45 PM, Sean Leonard wrote: > "When all is said and done, much more is said than done." > -Dave Cutler > > As Ryan Sleevi pointed out, Apple's tpPolicy code is open source, governed > by the Apple Public Source License 2.0. Would we really be having this > argument over a standards body mailing list (which now stretches to 138 > messages), if someone just fixed Apple's code? Any one of a number of > commenters could use their Prodigious Corporate Resources(tm) to fix the > problem, and post a fix to Apple. It seriously would not take more than 2 > weeks of a senior engineer's time. That will accomplish your long-range > business and security objectives much better than fiddling with the > criticality bit. > > As to any installed base argument that might crop up, Apple users are pretty > good about getting updates in a timely fashion. See > > for iOS statistics. > > -Sean > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ From hallam@gmail.com Tue Apr 10 06:26:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F7821F853C for ; Tue, 10 Apr 2012 06:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFu7EVT4kPhF for ; Tue, 10 Apr 2012 06:26:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2675821F84A6 for ; Tue, 10 Apr 2012 06:26:50 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8222976obb.31 for ; Tue, 10 Apr 2012 06:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=B773QmmKS22yE5BK8rw4fBW8Bm4jRVJFwoc4xIX+Iqo=; b=HpAFJ26KNOnfYR77LYikHlXOh/1ZzwfcTCsmXQIQu/hGsOXh5g79YqQ8mbQjwaR0r8 K1iIt4R9OF6J1zbAJGeYivVACWAmCM3WafAxFtQAE10NrIQSB+3rXhNnrELg80av3qGM f8VHPK+WIRug55RcdIkZI+9KR/BaJDvCrxTIij5Lb2zdAPRCCFv+9QG7Xdz5fBVd7yGD utpk3TJn9T4N3vTNzxC7IrR5ZfqaXSHHKrfaNpCG6cowjB/hCud3q/1/CfkXy0OSRcXY gyivATO3XXoIqvj67KKQVcZKZ66UhfYVUsyJPAjRzsQvEbZoqQWp1qV7bsTuIHlgFYJE UdAg== MIME-Version: 1.0 Received: by 10.182.48.66 with SMTP id j2mr15778459obn.72.1334064409747; Tue, 10 Apr 2012 06:26:49 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Tue, 10 Apr 2012 06:26:49 -0700 (PDT) In-Reply-To: References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> Date: Tue, 10 Apr 2012 09:26:49 -0400 Message-ID: From: Phillip Hallam-Baker To: "Kemp, David P." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:26:52 -0000 But what is the basis for making the decisions in the furst place? If the decisions are based on a bunch of consultants working out how to fleece DoD out of the maximum amount of moolah, then the industry that has real customers is going to go elsewhere. That is the downside of the COTS strategy, it creates economic incentives for folk to muck up the standards process. There is already a consensus to make this change on the Mozilla list. I would be astonished if anyone opposed making the change in CABForum. So even under the present situation where those are two separate communities, the de facto standard is going to change. At this point this group has already backed the industry into a position where it has lost de facto standards making capability. The question now is whether it also loses control of the de jure specification. On Tue, Apr 10, 2012 at 8:39 AM, Kemp, David P. wro= te: > It's a question of how to do Engineering. > > Approach 1: write a spec that describes what you want to achieve, > implement the spec as closely as possible given the current operating > environment and constraints, note AND EXPECT deviations from the spec, > and update implementations as the environment changes. > > Approach 2: write a spec that achieves what is possible given current > operating environment and constraints. =A0As the environment changes, > update the spec to add back in capabilities that were previously desired > but omitted. > > I'm not an HTML expert, but does not HTML 4 specify a complete feature > set that at one time was not implemented by all browsers? =A0And > individual HTML documents can be checked for "strict" or "transitional" > compliance? =A0As browser implementations improve, is it not possible to > write more and more HTML documents that pass "strict" compliance > checking WITHOUT updating the HTML 4 spec itself? > > My engineering toolbox includes tools like "lint". =A0C compilers may be > written to accept non-standard code, but the specification of the C > language itself does not continue to evolve based on the current > capabilities of compilers and coders. > > Should the PKIX spec be written like the HTML and C specs (one version > that may not be completely adhered to in practice), or should today's > version of PKIX be limited to the current state of applications and > updated as the application environment changes? > > My vote is for Approach 1. > > Dave > > > > -----Original Message----- > From: Yoav Nir [mailto:ynir@checkpoint.com] > >> CAs have good >> justification for weighting "operate without inconveniencing casual >> users" more highly than "secure" in that situation. =A0But it does not >> change the specification of the correct way to achieve both >> interoperability and security. > > I disagree. The E in IETF in engineering. A spec that considers only the > "secure" and not the "operate without inconveniencing casual users" is > bad engineering. Engineering has to consider the operating environment > and constraints of those who need to follow the spec. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From SChokhani@cygnacom.com Tue Apr 10 06:34:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3473E21F84F7 for ; Tue, 10 Apr 2012 06:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3wF5BqKvRyl for ; Tue, 10 Apr 2012 06:34:23 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 88AE421F84EF for ; Tue, 10 Apr 2012 06:34:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="733030" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 10 Apr 2012 09:34:08 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 10 Apr 2012 09:34:08 -0400 From: Santosh Chokhani To: "Manger, James H" , IETF PKIX Date: Tue, 10 Apr 2012 09:34:07 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0WjCDB8EmNNa3+QRycyb8xe+Uw+gAB1gGAAAVrhAAAHTxiUA== Message-ID: References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:34:24 -0000 James, It is hard to determine what would motivate a given vendor. You may very w= ell be right. But, the way to achieve this is for the CAs to determine how= to bring the "certificate consuming" software vendors in compliance. The = standard should preserve security. CA vendors can give grace period or browser vendors can use existing or new= UI to let the human use decide if they want to override the browser decisi= on until browsers have the capability to process the extension. -----Original Message----- From: Manger, James H [mailto:James.H.Manger@team.telstra.com]=20 Sent: Monday, April 09, 2012 7:56 PM To: Santosh Chokhani; IETF PKIX Subject: RE: [pkix] Proposal: Change the Criticality Requirement of Name Santosh, > If the standard said this extension can be NC (non-critical), folks=20 > would be happy to produce certificates with NC and some browsers will=20 > not implement name constraints processing. > > It is important that we get where the RP enforce the CA defined=20 > constraints and making security critical extensions NC in a security=20 > standard is not the way to get their attention. > It is a way to tell folks that this is not important for security. At the moment, there is little incentive for an implementation (such as Saf= ari) to implement name constraints as there are almost no certificates usin= g them. A browser is equally secure with or without support. If name constraints can be non-critical, certificates using them can appear= far more easily and there will be an explicit security difference between = browsers that do or do not implement those constraints. That will provide a= tangible incentive for software (such as Safari) to implement name constra= ints. Otherwise it doesn't protect its users from a threat that other brows= ers do, which will look very bad if (or when) the threat becomes an attack. I am in favour of removing the PKIX requirement that name constraints be ma= rked critical. -- James Manger From anders.rundgren@telia.com Tue Apr 10 06:43:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3498C21F8595 for ; Tue, 10 Apr 2012 06:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Uxoh5Iku-tQ for ; Tue, 10 Apr 2012 06:43:32 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1D69521F8585 for ; Tue, 10 Apr 2012 06:43:31 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E00AF1C15; Tue, 10 Apr 2012 15:43:29 +0200 Message-ID: <4F8438FE.5070001@telia.com> Date: Tue, 10 Apr 2012 15:43:26 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:43:33 -0000 I think you are absolutely right Phil. Breaking a gazillion clients out there is not how you gain momentum. Best Anders PS It is nice [for once] not being the only "bad guy" in PKIX :-) DS On 2012-04-10 15:26, Phillip Hallam-Baker wrote: > But what is the basis for making the decisions in the furst place? > > If the decisions are based on a bunch of consultants working out how > to fleece DoD out of the maximum amount of moolah, then the industry > that has real customers is going to go elsewhere. That is the downside > of the COTS strategy, it creates economic incentives for folk to muck > up the standards process. > > There is already a consensus to make this change on the Mozilla list. > I would be astonished if anyone opposed making the change in CABForum. > So even under the present situation where those are two separate > communities, the de facto standard is going to change. > > > At this point this group has already backed the industry into a > position where it has lost de facto standards making capability. The > question now is whether it also loses control of the de jure > specification. > > > > > On Tue, Apr 10, 2012 at 8:39 AM, Kemp, David P. wrote: >> It's a question of how to do Engineering. >> >> Approach 1: write a spec that describes what you want to achieve, >> implement the spec as closely as possible given the current operating >> environment and constraints, note AND EXPECT deviations from the spec, >> and update implementations as the environment changes. >> >> Approach 2: write a spec that achieves what is possible given current >> operating environment and constraints. As the environment changes, >> update the spec to add back in capabilities that were previously desired >> but omitted. >> >> I'm not an HTML expert, but does not HTML 4 specify a complete feature >> set that at one time was not implemented by all browsers? And >> individual HTML documents can be checked for "strict" or "transitional" >> compliance? As browser implementations improve, is it not possible to >> write more and more HTML documents that pass "strict" compliance >> checking WITHOUT updating the HTML 4 spec itself? >> >> My engineering toolbox includes tools like "lint". C compilers may be >> written to accept non-standard code, but the specification of the C >> language itself does not continue to evolve based on the current >> capabilities of compilers and coders. >> >> Should the PKIX spec be written like the HTML and C specs (one version >> that may not be completely adhered to in practice), or should today's >> version of PKIX be limited to the current state of applications and >> updated as the application environment changes? >> >> My vote is for Approach 1. >> >> Dave >> >> >> >> -----Original Message----- >> From: Yoav Nir [mailto:ynir@checkpoint.com] >> >>> CAs have good >>> justification for weighting "operate without inconveniencing casual >>> users" more highly than "secure" in that situation. But it does not >>> change the specification of the correct way to achieve both >>> interoperability and security. >> >> I disagree. The E in IETF in engineering. A spec that considers only the >> "secure" and not the "operate without inconveniencing casual users" is >> bad engineering. Engineering has to consider the operating environment >> and constraints of those who need to follow the spec. >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > From hallam@gmail.com Tue Apr 10 06:44:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8722E21F8595 for ; Tue, 10 Apr 2012 06:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Coz0+d4Iyt3h for ; Tue, 10 Apr 2012 06:44:44 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE69421F8585 for ; Tue, 10 Apr 2012 06:44:44 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2585605ggm.31 for ; Tue, 10 Apr 2012 06:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Q1xOKClnObwYf6gru8mJSxQmENPjkLU1TThfPsLkxK8=; b=SE0iD0o5S9TMHcnwFzaMxqEBKAiueqG+vvj+rZHfGn+/u9O5lUPV0HwtVI0KdAtMjK lIppTfRDE1sHn4lddWOdcu2vNi5WbaBKgsPWop6+sP9k9CBqi99pdFhca4qWQ/KQugUU CH6KxnN1fHqv5qi8ncWtv8FDqOc8UQvYH8iWrswb41LPlAXPVpW99MhektIEzLfkqSeQ SD+REAZhB2gxYR5QkIOI7CK/HSef6MeZqI3PKT0X0L3wS7Fw9faZpmrCxv1FGRxVq7sp j0/ndQ1f3SG4DmvU+scPI3YP4JcWVT21kt14AaDLfViEluNT2asb15LjjilJnYwzHrQL jOzA== MIME-Version: 1.0 Received: by 10.60.36.100 with SMTP id p4mr16053622oej.42.1334065484235; Tue, 10 Apr 2012 06:44:44 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Tue, 10 Apr 2012 06:44:44 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 10 Apr 2012 09:44:44 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:44:45 -0000 What incentive is there for the CAs to act as you suggest? The only way that such a threat can be made is through joint action by the CAs which is impossible to agree in this forum as there isn't even a membership. In fact the only place that there could be such an agreement is in CABForum. Since Apple is a very large vendor, I can't see how we can credibly threaten them with a big stick. What you are suggesting essentially amounts to 'brick every iPhone'. Instead I think that the new security forum should have a brand like the WiFi brand that is awarded on completion of compliance tests for 'good security' and make the criteria reasonable so that Apple wants to achieve that brand just like they did with WiFi and so on. On Tue, Apr 10, 2012 at 9:34 AM, Santosh Chokhani wrote: > James, > > It is hard to determine what would motivate a given vendor. =A0You may ve= ry well be right. =A0But, the way to achieve this is for the CAs to determi= ne how to bring the "certificate consuming" software vendors in compliance.= =A0The standard should preserve security. > > CA vendors can give grace period or browser vendors can use existing or n= ew UI to let the human use decide if they want to override the browser deci= sion until browsers have the capability to process the extension. > > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Monday, April 09, 2012 7:56 PM > To: Santosh Chokhani; IETF PKIX > Subject: RE: [pkix] Proposal: Change the Criticality Requirement of Name > > Santosh, > >> If the standard said this extension can be NC (non-critical), folks >> would be happy to produce certificates with NC and some browsers will >> not implement name constraints processing. >> >> It is important that we get where the RP enforce the CA defined >> constraints and making security critical extensions NC in a security >> standard is not the way to get their attention. >> It is a way to tell folks that this is not important for security. > > At the moment, there is little incentive for an implementation (such as S= afari) to implement name constraints as there are almost no certificates us= ing them. A browser is equally secure with or without support. > > If name constraints can be non-critical, certificates using them can appe= ar far more easily and there will be an explicit security difference betwee= n browsers that do or do not implement those constraints. That will provide= a tangible incentive for software (such as Safari) to implement name const= raints. Otherwise it doesn't protect its users from a threat that other bro= wsers do, which will look very bad if (or when) the threat becomes an attac= k. > > I am in favour of removing the PKIX requirement that name constraints be = marked critical. > > -- > James Manger > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From SChokhani@cygnacom.com Tue Apr 10 06:56:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF1F11E80CA for ; Tue, 10 Apr 2012 06:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9yOIw+dhRps for ; Tue, 10 Apr 2012 06:56:05 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3E04A11E80C9 for ; Tue, 10 Apr 2012 06:56:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="733249" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 10 Apr 2012 09:56:04 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 10 Apr 2012 09:56:04 -0400 From: Santosh Chokhani To: Phillip Hallam-Baker Date: Tue, 10 Apr 2012 09:56:03 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0XIBbTza5sSclZRzymU/V7bnzGxwAAVDnw Message-ID: References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 13:56:06 -0000 PHB, All I am saying that 5280 is as much a security standard and it should not = equivocate about the need to enforce name constraints, especially in light = of 2010-11 happenings. CABF may be the right place to sort out how to get to the secure, end state= that 5280 represents. -----Original Message----- From: Phillip Hallam-Baker [mailto:hallam@gmail.com]=20 Sent: Tuesday, April 10, 2012 9:45 AM To: Santosh Chokhani Cc: Manger, James H; IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name What incentive is there for the CAs to act as you suggest? The only way that such a threat can be made is through joint action by the = CAs which is impossible to agree in this forum as there isn't even a member= ship. In fact the only place that there could be such an agreement is in CA= BForum. Since Apple is a very large vendor, I can't see how we can credibly threate= n them with a big stick. What you are suggesting essentially amounts to 'br= ick every iPhone'. Instead I think that the new security forum should have a brand like the Wi= Fi brand that is awarded on completion of compliance tests for 'good securi= ty' and make the criteria reasonable so that Apple wants to achieve that br= and just like they did with WiFi and so on. On Tue, Apr 10, 2012 at 9:34 AM, Santosh Chokhani = wrote: > James, > > It is hard to determine what would motivate a given vendor. =A0You may ve= ry well be right. =A0But, the way to achieve this is for the CAs to determi= ne how to bring the "certificate consuming" software vendors in compliance.= =A0The standard should preserve security. > > CA vendors can give grace period or browser vendors can use existing or n= ew UI to let the human use decide if they want to override the browser deci= sion until browsers have the capability to process the extension. > > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Monday, April 09, 2012 7:56 PM > To: Santosh Chokhani; IETF PKIX > Subject: RE: [pkix] Proposal: Change the Criticality Requirement of=20 > Name > > Santosh, > >> If the standard said this extension can be NC (non-critical), folks=20 >> would be happy to produce certificates with NC and some browsers will=20 >> not implement name constraints processing. >> >> It is important that we get where the RP enforce the CA defined=20 >> constraints and making security critical extensions NC in a security=20 >> standard is not the way to get their attention. >> It is a way to tell folks that this is not important for security. > > At the moment, there is little incentive for an implementation (such as S= afari) to implement name constraints as there are almost no certificates us= ing them. A browser is equally secure with or without support. > > If name constraints can be non-critical, certificates using them can appe= ar far more easily and there will be an explicit security difference betwee= n browsers that do or do not implement those constraints. That will provide= a tangible incentive for software (such as Safari) to implement name const= raints. Otherwise it doesn't protect its users from a threat that other bro= wsers do, which will look very bad if (or when) the threat becomes an attac= k. > > I am in favour of removing the PKIX requirement that name constraints be = marked critical. > > -- > James Manger > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ From hallam@gmail.com Tue Apr 10 07:06:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A9711E80D9 for ; Tue, 10 Apr 2012 07:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp+vh+s9PGfm for ; Tue, 10 Apr 2012 07:06:05 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFAE911E80D6 for ; Tue, 10 Apr 2012 07:06:03 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so8270331obb.31 for ; Tue, 10 Apr 2012 07:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=r3kHjYhQqqresT+GQ1R+mpGnkNbE5sQ6om0+wLLVJHk=; b=IKpUfmGFtRutLw4OuWbWtJp9FbUht+cwuduS83YS6TnzAk9eO34yEUFtEnDgjW22ih O+thz74BPzV8PNzhAbIzin1mcYHS5WHLDZXxplJzrGZGDW9ovZHv51k8SkNaOqHB2WT2 rdU1Y50ZgnJoh8TO7uUmsCkfu6mNbQOfWZmN/4J0XFvi+E3JjReGBfsaGGHEic4COUiY TgrSMZtCFAknHzuU9mU0jkbgwLeZ3sVX3o32YJ9FqDkhiooCGCLJMxnTfmm6exPpi3oU nIK8FEk0JVLt68Wbp35AYZAdfJIVhJ50M4Kdw7CRmfKOEljk9liIWZmq6E934lDBV/AZ bTKQ== MIME-Version: 1.0 Received: by 10.182.74.42 with SMTP id q10mr16297974obv.52.1334066763335; Tue, 10 Apr 2012 07:06:03 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Tue, 10 Apr 2012 07:06:03 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 10 Apr 2012 10:06:03 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:06:12 -0000 Seems to me like you want to make a decision on grounds that we find to be arbitrary and capricious and then hold a gun that is liable to backfire on us to Apple's head in order to force their compliance. On Tue, Apr 10, 2012 at 9:56 AM, Santosh Chokhani wrote: > PHB, > > All I am saying that 5280 is as much a security standard and it should no= t equivocate about the need to enforce name constraints, especially in ligh= t of 2010-11 happenings. > > CABF may be the right place to sort out how to get to the secure, end sta= te that 5280 represents. > > -----Original Message----- > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > Sent: Tuesday, April 10, 2012 9:45 AM > To: Santosh Chokhani > Cc: Manger, James H; IETF PKIX > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > > What incentive is there for the CAs to act as you suggest? > > The only way that such a threat can be made is through joint action by th= e CAs which is impossible to agree in this forum as there isn't even a memb= ership. In fact the only place that there could be such an agreement is in = CABForum. > > Since Apple is a very large vendor, I can't see how we can credibly threa= ten them with a big stick. What you are suggesting essentially amounts to '= brick every iPhone'. > > > Instead I think that the new security forum should have a brand like the = WiFi brand that is awarded on completion of compliance tests for 'good secu= rity' and make the criteria reasonable so that Apple wants to achieve that = brand just like they did with WiFi and so on. > > > On Tue, Apr 10, 2012 at 9:34 AM, Santosh Chokhani wrote: >> James, >> >> It is hard to determine what would motivate a given vendor. =A0You may v= ery well be right. =A0But, the way to achieve this is for the CAs to determ= ine how to bring the "certificate consuming" software vendors in compliance= . =A0The standard should preserve security. >> >> CA vendors can give grace period or browser vendors can use existing or = new UI to let the human use decide if they want to override the browser dec= ision until browsers have the capability to process the extension. >> >> -----Original Message----- >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] >> Sent: Monday, April 09, 2012 7:56 PM >> To: Santosh Chokhani; IETF PKIX >> Subject: RE: [pkix] Proposal: Change the Criticality Requirement of >> Name >> >> Santosh, >> >>> If the standard said this extension can be NC (non-critical), folks >>> would be happy to produce certificates with NC and some browsers will >>> not implement name constraints processing. >>> >>> It is important that we get where the RP enforce the CA defined >>> constraints and making security critical extensions NC in a security >>> standard is not the way to get their attention. >>> It is a way to tell folks that this is not important for security. >> >> At the moment, there is little incentive for an implementation (such as = Safari) to implement name constraints as there are almost no certificates u= sing them. A browser is equally secure with or without support. >> >> If name constraints can be non-critical, certificates using them can app= ear far more easily and there will be an explicit security difference betwe= en browsers that do or do not implement those constraints. That will provid= e a tangible incentive for software (such as Safari) to implement name cons= traints. Otherwise it doesn't protect its users from a threat that other br= owsers do, which will look very bad if (or when) the threat becomes an atta= ck. >> >> I am in favour of removing the PKIX requirement that name constraints be= marked critical. >> >> -- >> James Manger >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > > -- > Website: http://hallambaker.com/ --=20 Website: http://hallambaker.com/ From SChokhani@cygnacom.com Tue Apr 10 07:11:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016CD21F856F for ; Tue, 10 Apr 2012 07:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxbmIOfpM19G for ; Tue, 10 Apr 2012 07:11:48 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id AFCF011E80CB for ; Tue, 10 Apr 2012 07:11:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="4663172" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 10 Apr 2012 10:11:35 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 10 Apr 2012 10:11:35 -0400 From: Santosh Chokhani To: Phillip Hallam-Baker Date: Tue, 10 Apr 2012 10:11:33 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0XIxFbG7JCJREARHe4ERpb+mEMbQAAJsSw Message-ID: References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:11:49 -0000 PHB, No. I am saying that the decision made for 2459 and that has stood to date= is a sound one and should remain so. If implementations need to catch up, appropriate producers and consumers ca= n negotiate the transition plan. -----Original Message----- From: Phillip Hallam-Baker [mailto:hallam@gmail.com]=20 Sent: Tuesday, April 10, 2012 10:06 AM To: Santosh Chokhani Cc: Manger, James H; IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Seems to me like you want to make a decision on grounds that we find to be = arbitrary and capricious and then hold a gun that is liable to backfire on = us to Apple's head in order to force their compliance. On Tue, Apr 10, 2012 at 9:56 AM, Santosh Chokhani = wrote: > PHB, > > All I am saying that 5280 is as much a security standard and it should no= t equivocate about the need to enforce name constraints, especially in ligh= t of 2010-11 happenings. > > CABF may be the right place to sort out how to get to the secure, end sta= te that 5280 represents. > > -----Original Message----- > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > Sent: Tuesday, April 10, 2012 9:45 AM > To: Santosh Chokhani > Cc: Manger, James H; IETF PKIX > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of=20 > Name > > What incentive is there for the CAs to act as you suggest? > > The only way that such a threat can be made is through joint action by th= e CAs which is impossible to agree in this forum as there isn't even a memb= ership. In fact the only place that there could be such an agreement is in = CABForum. > > Since Apple is a very large vendor, I can't see how we can credibly threa= ten them with a big stick. What you are suggesting essentially amounts to '= brick every iPhone'. > > > Instead I think that the new security forum should have a brand like the = WiFi brand that is awarded on completion of compliance tests for 'good secu= rity' and make the criteria reasonable so that Apple wants to achieve that = brand just like they did with WiFi and so on. > > > On Tue, Apr 10, 2012 at 9:34 AM, Santosh Chokhani wrote: >> James, >> >> It is hard to determine what would motivate a given vendor. =A0You may v= ery well be right. =A0But, the way to achieve this is for the CAs to determ= ine how to bring the "certificate consuming" software vendors in compliance= . =A0The standard should preserve security. >> >> CA vendors can give grace period or browser vendors can use existing or = new UI to let the human use decide if they want to override the browser dec= ision until browsers have the capability to process the extension. >> >> -----Original Message----- >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] >> Sent: Monday, April 09, 2012 7:56 PM >> To: Santosh Chokhani; IETF PKIX >> Subject: RE: [pkix] Proposal: Change the Criticality Requirement of=20 >> Name >> >> Santosh, >> >>> If the standard said this extension can be NC (non-critical), folks=20 >>> would be happy to produce certificates with NC and some browsers=20 >>> will not implement name constraints processing. >>> >>> It is important that we get where the RP enforce the CA defined=20 >>> constraints and making security critical extensions NC in a security=20 >>> standard is not the way to get their attention. >>> It is a way to tell folks that this is not important for security. >> >> At the moment, there is little incentive for an implementation (such as = Safari) to implement name constraints as there are almost no certificates u= sing them. A browser is equally secure with or without support. >> >> If name constraints can be non-critical, certificates using them can app= ear far more easily and there will be an explicit security difference betwe= en browsers that do or do not implement those constraints. That will provid= e a tangible incentive for software (such as Safari) to implement name cons= traints. Otherwise it doesn't protect its users from a threat that other br= owsers do, which will look very bad if (or when) the threat becomes an atta= ck. >> >> I am in favour of removing the PKIX requirement that name constraints be= marked critical. >> >> -- >> James Manger >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > > -- > Website: http://hallambaker.com/ -- Website: http://hallambaker.com/ From tgindin@us.ibm.com Tue Apr 10 07:24:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFE321F8682 for ; Tue, 10 Apr 2012 07:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.239 X-Spam-Level: X-Spam-Status: No, score=-10.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWvoDqJnXf0d for ; Tue, 10 Apr 2012 07:24:29 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by ietfa.amsl.com (Postfix) with ESMTP id B061021F8681 for ; Tue, 10 Apr 2012 07:24:28 -0700 (PDT) Received: from /spool/local by e4.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Apr 2012 10:24:23 -0400 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e4.ny.us.ibm.com (192.168.1.104) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 10 Apr 2012 10:24:07 -0400 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 6774938C8059 for ; Tue, 10 Apr 2012 10:24:06 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3AEO5IM273220 for ; Tue, 10 Apr 2012 10:24:05 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3AENHIP010112 for ; Tue, 10 Apr 2012 10:23:17 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3AEMVM0003739; Tue, 10 Apr 2012 10:22:31 -0400 In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> To: Santosh Chokhani MIME-Version: 1.0 X-KeepSent: 71F07927:D3A74F0A-852579DC:004D4436; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Tue, 10 Apr 2012 10:22:30 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/10/2012 10:22:30, Serialize complete at 04/10/2012 10:22:30 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12041014-3534-0000-0000-0000075C33AD Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:24:35 -0000 Santosh: Under the defined syntax, CA's have three choices for intermediate certificates in this area. In ascending order of security, they are "no constraints", "non-critical constraints", "critical constraints". It appears to me that the effect of banning the middle option has been, at least in the commercial world, to drive most CA's to the less secure option rather than to the more secure one. Do you have evidence that many commercial CA's are using critical name constraints except under government influence? I don't, but others may have had better experiences. Tom Gindin From: Santosh Chokhani To: "Manger, James H" , IETF PKIX , Date: 04/10/2012 09:36 AM Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Sent by: pkix-bounces@ietf.org James, It is hard to determine what would motivate a given vendor. You may very well be right. But, the way to achieve this is for the CAs to determine how to bring the "certificate consuming" software vendors in compliance. The standard should preserve security. CA vendors can give grace period or browser vendors can use existing or new UI to let the human use decide if they want to override the browser decision until browsers have the capability to process the extension. -----Original Message----- From: Manger, James H [mailto:James.H.Manger@team.telstra.com] Sent: Monday, April 09, 2012 7:56 PM To: Santosh Chokhani; IETF PKIX Subject: RE: [pkix] Proposal: Change the Criticality Requirement of Name Santosh, > If the standard said this extension can be NC (non-critical), folks > would be happy to produce certificates with NC and some browsers will > not implement name constraints processing. > > It is important that we get where the RP enforce the CA defined > constraints and making security critical extensions NC in a security > standard is not the way to get their attention. > It is a way to tell folks that this is not important for security. At the moment, there is little incentive for an implementation (such as Safari) to implement name constraints as there are almost no certificates using them. A browser is equally secure with or without support. If name constraints can be non-critical, certificates using them can appear far more easily and there will be an explicit security difference between browsers that do or do not implement those constraints. That will provide a tangible incentive for software (such as Safari) to implement name constraints. Otherwise it doesn't protect its users from a threat that other browsers do, which will look very bad if (or when) the threat becomes an attack. I am in favour of removing the PKIX requirement that name constraints be marked critical. -- James Manger _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From stefan@aaa-sec.com Tue Apr 10 07:31:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E4711E80E4 for ; Tue, 10 Apr 2012 07:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYnbaYcYdJgJ for ; Tue, 10 Apr 2012 07:31:24 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id D92D511E80E6 for ; Tue, 10 Apr 2012 07:31:23 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id F32AA1E294AC for ; Tue, 10 Apr 2012 16:30:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id h0siwtx8zVLb for ; Tue, 10 Apr 2012 16:30:57 +0200 (CEST) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 533711E294AD for ; Tue, 10 Apr 2012 16:30:57 +0200 (CEST) Received: (qmail 37146 invoked from network); 10 Apr 2012 14:30:57 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.2]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Apr 2012 14:30:57 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 10 Apr 2012 16:30:31 +0200 From: Stefan Santesson To: Santosh Chokhani , Phillip Hallam-Baker Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:31:25 -0000 Protocol security is not about denying implementers the option to run in insecure modes. One typical example is the TLS ciphesuite TLS_NULL_WITH_NULL_NULL A secure protocol is a protocol that gives the level of security one is entitled to expect, given a selected policy and configuration. Denying CAs to set NC non critical is equal to denying CAs to set their own policy. /Stefan On 12-04-10 4:11 PM, "Santosh Chokhani" wrote: >PHB, > >No. I am saying that the decision made for 2459 and that has stood to >date is a sound one and should remain so. > >If implementations need to catch up, appropriate producers and consumers >can negotiate the transition plan. > >-----Original Message----- >From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >Sent: Tuesday, April 10, 2012 10:06 AM >To: Santosh Chokhani >Cc: Manger, James H; IETF PKIX >Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > >Seems to me like you want to make a decision on grounds that we find to >be arbitrary and capricious and then hold a gun that is liable to >backfire on us to Apple's head in order to force their compliance. > > >On Tue, Apr 10, 2012 at 9:56 AM, Santosh Chokhani > wrote: >> PHB, >> >> All I am saying that 5280 is as much a security standard and it should >>not equivocate about the need to enforce name constraints, especially in >>light of 2010-11 happenings. >> >> CABF may be the right place to sort out how to get to the secure, end >>state that 5280 represents. >> >> -----Original Message----- >> From: Phillip Hallam-Baker [mailto:hallam@gmail.com] >> Sent: Tuesday, April 10, 2012 9:45 AM >> To: Santosh Chokhani >> Cc: Manger, James H; IETF PKIX >> Subject: Re: [pkix] Proposal: Change the Criticality Requirement of >> Name >> >> What incentive is there for the CAs to act as you suggest? >> >> The only way that such a threat can be made is through joint action by >>the CAs which is impossible to agree in this forum as there isn't even a >>membership. In fact the only place that there could be such an agreement >>is in CABForum. >> >> Since Apple is a very large vendor, I can't see how we can credibly >>threaten them with a big stick. What you are suggesting essentially >>amounts to 'brick every iPhone'. >> >> >> Instead I think that the new security forum should have a brand like >>the WiFi brand that is awarded on completion of compliance tests for >>'good security' and make the criteria reasonable so that Apple wants to >>achieve that brand just like they did with WiFi and so on. >> >> >> On Tue, Apr 10, 2012 at 9:34 AM, Santosh Chokhani >> wrote: >>> James, >>> >>> It is hard to determine what would motivate a given vendor. You may >>>very well be right. But, the way to achieve this is for the CAs to >>>determine how to bring the "certificate consuming" software vendors in >>>compliance. The standard should preserve security. >>> >>> CA vendors can give grace period or browser vendors can use existing >>>or new UI to let the human use decide if they want to override the >>>browser decision until browsers have the capability to process the >>>extension. >>> >>> -----Original Message----- >>> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] >>> Sent: Monday, April 09, 2012 7:56 PM >>> To: Santosh Chokhani; IETF PKIX >>> Subject: RE: [pkix] Proposal: Change the Criticality Requirement of >>> Name >>> >>> Santosh, >>> >>>> If the standard said this extension can be NC (non-critical), folks >>>> would be happy to produce certificates with NC and some browsers >>>> will not implement name constraints processing. >>>> >>>> It is important that we get where the RP enforce the CA defined >>>> constraints and making security critical extensions NC in a security >>>> standard is not the way to get their attention. >>>> It is a way to tell folks that this is not important for security. >>> >>> At the moment, there is little incentive for an implementation (such >>>as Safari) to implement name constraints as there are almost no >>>certificates using them. A browser is equally secure with or without >>>support. >>> >>> If name constraints can be non-critical, certificates using them can >>>appear far more easily and there will be an explicit security >>>difference between browsers that do or do not implement those >>>constraints. That will provide a tangible incentive for software (such >>>as Safari) to implement name constraints. Otherwise it doesn't protect >>>its users from a threat that other browsers do, which will look very >>>bad if (or when) the threat becomes an attack. >>> >>> I am in favour of removing the PKIX requirement that name constraints >>>be marked critical. >>> >>> -- >>> James Manger >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> >> >> >> -- >> Website: http://hallambaker.com/ > > > >-- >Website: http://hallambaker.com/ >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From SChokhani@cygnacom.com Tue Apr 10 07:31:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DBD21F85B9 for ; Tue, 10 Apr 2012 07:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tGQ3W6hACdZ for ; Tue, 10 Apr 2012 07:31:59 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 14AFC21F8582 for ; Tue, 10 Apr 2012 07:31:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,399,1330923600"; d="scan'208";a="733623" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 10 Apr 2012 10:31:58 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 10 Apr 2012 10:31:58 -0400 From: Santosh Chokhani To: Tom Gindin Date: Tue, 10 Apr 2012 10:31:56 -0400 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0XJY7WDGGQV+fhQvqVLZEhy9S1WwAAJOrw Message-ID: References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:31:59 -0000 Tom, I know commercial Bridge CAs that issue certificates with and get certifica= te with name constraints being critical. -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com]=20 Sent: Tuesday, April 10, 2012 10:23 AM To: Santosh Chokhani Cc: Manger, James H; IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Santosh: Under the defined syntax, CA's have three choices for intermediate = certificates in this area. In ascending order of security, they are "no co= nstraints", "non-critical constraints", "critical constraints". It appears= to me that the effect of banning the middle option has been, at least in t= he commercial world, to drive most CA's to the less secure option rather th= an to the more secure one. Do you have evidence that many commercial CA's are using critical n= ame constraints except under government influence? I don't, but others may= have had better experiences. Tom Gindin From: Santosh Chokhani To: "Manger, James H" , IETF PKIX=20 ,=20 Date: 04/10/2012 09:36 AM Subject: Re: [pkix] Proposal: Change the Criticality Requirement of= =20 Name Sent by: pkix-bounces@ietf.org James, It is hard to determine what would motivate a given vendor. You may very w= ell be right. But, the way to achieve this is for the CAs to determine how= to bring the "certificate consuming" software vendors in compliance.=20 The standard should preserve security. CA vendors can give grace period or browser vendors can use existing or new= UI to let the human use decide if they want to override the browser decisi= on until browsers have the capability to process the extension. -----Original Message----- From: Manger, James H [mailto:James.H.Manger@team.telstra.com] Sent: Monday, April 09, 2012 7:56 PM To: Santosh Chokhani; IETF PKIX Subject: RE: [pkix] Proposal: Change the Criticality Requirement of Name Santosh, > If the standard said this extension can be NC (non-critical), folks=20 > would be happy to produce certificates with NC and some browsers will=20 > not implement name constraints processing. > > It is important that we get where the RP enforce the CA defined=20 > constraints and making security critical extensions NC in a security=20 > standard is not the way to get their attention. > It is a way to tell folks that this is not important for security. At the moment, there is little incentive for an implementation (such as Safari) to implement name constraints as there are almost no certificates u= sing them. A browser is equally secure with or without support. If name constraints can be non-critical, certificates using them can appear= far more easily and there will be an explicit security difference between = browsers that do or do not implement those constraints. That will provide a= tangible incentive for software (such as Safari) to implement name constra= ints. Otherwise it doesn't protect its users from a threat that other brows= ers do, which will look very bad if (or when) the threat becomes an attack. I am in favour of removing the PKIX requirement that name constraints be ma= rked critical. -- James Manger _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From paul.hoffman@vpnc.org Tue Apr 10 07:35:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B9B21F8680 for ; Tue, 10 Apr 2012 07:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft-Rw7vDXmBt for ; Tue, 10 Apr 2012 07:35:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFA321F8672 for ; Tue, 10 Apr 2012 07:35:49 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3AEZbmM082817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Apr 2012 07:35:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Paul Hoffman In-Reply-To: <4F83F8AA.9080904@comodo.com> Date: Tue, 10 Apr 2012 07:35:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <95CB7F13-AF4C-456F-AC16-CD70C5F577B6@vpnc.org> References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> <5A757FAC-D552-45B3-A1FE-BE3FFF60FD38@checkpoint.com> <4F83F8AA.9080904@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.1257) Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:35:50 -0000 On Apr 10, 2012, at 2:08 AM, Rob Stradling wrote: > Hi Yoav. Such a document already exists, so I don't think we need = another new doc. >=20 > http://www.cabforum.org/Baseline_Requirements_V1.pdf >=20 > See Appendix B. >=20 > The Name Constraints extension is not mentioned, which means that "All = other fields and extensions MUST be set in accordance to RFC 5280" = applies. >=20 >> 2. Name Constraints >> RFC 5280 requires name constraints to be marked critical. Under = this profile >> this extension MAY be critical. >=20 > I intend to propose (on the CABForum list) updating the Baseline = Requirements to allow NC to be non-critical. Great! Can we stop this thread then? If the people who need this change = already have a way to get it, there is no need to have the discussion = here. --Paul Hoffman From rob.stradling@comodo.com Tue Apr 10 07:41:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD8A21F84FC for ; Tue, 10 Apr 2012 07:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMsEbeVOQLyU for ; Tue, 10 Apr 2012 07:41:32 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 86E7221F8699 for ; Tue, 10 Apr 2012 07:41:31 -0700 (PDT) Received: (qmail 21428 invoked from network); 10 Apr 2012 14:41:30 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Apr 2012 14:41:30 -0000 Received: (qmail 13541 invoked by uid 1000); 10 Apr 2012 14:41:29 -0000 Received: from nigel.brad.office.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 (CAMELLIA256-SHA encrypted) ESMTPSA; Tue, 10 Apr 2012 15:41:29 +0100 Message-ID: <4F844699.2030907@comodo.com> Date: Tue, 10 Apr 2012 15:41:29 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: Paul Hoffman References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> <5A757FAC-D552-45B3-A1FE-BE3FFF60FD38@checkpoint.com> <4F83F8AA.9080904@comodo.com> <95CB7F13-AF4C-456F-AC16-CD70C5F577B6@vpnc.org> In-Reply-To: <95CB7F13-AF4C-456F-AC16-CD70C5F577B6@vpnc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:41:32 -0000 Hi Paul. I'm guessing you meant to "To:" the list rather than me. I tried to stop this thread 6 days ago! ;-) On 10/04/12 15:35, Paul Hoffman wrote: > On Apr 10, 2012, at 2:08 AM, Rob Stradling wrote: > >> Hi Yoav. Such a document already exists, so I don't think we need another new doc. >> >> http://www.cabforum.org/Baseline_Requirements_V1.pdf >> >> See Appendix B. >> >> The Name Constraints extension is not mentioned, which means that "All other fields and extensions MUST be set in accordance to RFC 5280" applies. >> >>> 2. Name Constraints >>> RFC 5280 requires name constraints to be marked critical. Under this profile >>> this extension MAY be critical. >> >> I intend to propose (on the CABForum list) updating the Baseline Requirements to allow NC to be non-critical. > > > Great! Can we stop this thread then? If the people who need this change already have a way to get it, there is no need to have the discussion here. > > --Paul Hoffman > > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From stefan@aaa-sec.com Tue Apr 10 07:49:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7868321F86B2 for ; Tue, 10 Apr 2012 07:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VelaG4+MLNfY for ; Tue, 10 Apr 2012 07:49:13 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id DB74421F869F for ; Tue, 10 Apr 2012 07:49:12 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id D21AA1E26C5E for ; Tue, 10 Apr 2012 16:49:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mqhTh8LtxBio for ; Tue, 10 Apr 2012 16:49:11 +0200 (CEST) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 883821E26A7E for ; Tue, 10 Apr 2012 16:49:11 +0200 (CEST) Received: (qmail 42560 invoked from network); 10 Apr 2012 14:49:11 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.2]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Apr 2012 14:49:11 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 10 Apr 2012 16:48:36 +0200 From: Stefan Santesson To: Paul Hoffman , Rob Stradling Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: <95CB7F13-AF4C-456F-AC16-CD70C5F577B6@vpnc.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:49:13 -0000 Why should we stop the thread? 1) Because all has been said? 2) Because since CABFORUM decides to deviate from PKIX, there are no reasons for PKIX to relax the requirement? /Stefan On 12-04-10 4:35 PM, "Paul Hoffman" wrote: >On Apr 10, 2012, at 2:08 AM, Rob Stradling wrote: > >> Hi Yoav. Such a document already exists, so I don't think we need >>another new doc. >> >> http://www.cabforum.org/Baseline_Requirements_V1.pdf >> >> See Appendix B. >> >> The Name Constraints extension is not mentioned, which means that "All >>other fields and extensions MUST be set in accordance to RFC 5280" >>applies. >> >>> 2. Name Constraints >>> RFC 5280 requires name constraints to be marked critical. Under >>>this profile >>> this extension MAY be critical. >> >> I intend to propose (on the CABForum list) updating the Baseline >>Requirements to allow NC to be non-critical. > > >Great! Can we stop this thread then? If the people who need this change >already have a way to get it, there is no need to have the discussion >here. > >--Paul Hoffman > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From paul.hoffman@vpnc.org Tue Apr 10 07:53:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBA421F86D1 for ; Tue, 10 Apr 2012 07:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+zwzPQ1BZtd for ; Tue, 10 Apr 2012 07:53:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7323C21F86D0 for ; Tue, 10 Apr 2012 07:53:22 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3AErFXL083443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Apr 2012 07:53:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F844699.2030907@comodo.com> Date: Tue, 10 Apr 2012 07:53:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5933FF98-9971-46F2-9FA8-209A584A0B70@vpnc.org> References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> <5A757FAC-D552-45B3-A1FE-BE3FFF60FD38@checkpoint.com> <4F83F8AA.9080904@comodo.com> <95CB7F13-AF4C-456F-AC16-CD70C5F577B6@vpnc.org> <4F844699.2030907@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.1257) Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:53:24 -0000 On Apr 10, 2012, at 7:41 AM, Rob Stradling wrote: > Hi Paul. I'm guessing you meant to "To:" the list rather than me. I = tried to stop this thread 6 days ago! ;-) Someone else from your company seems pretty intent on keeping the thread = going; maybe you two could talk. :-) --Paul Hoffman From paul.hoffman@vpnc.org Tue Apr 10 07:53:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8161421F86DB for ; Tue, 10 Apr 2012 07:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtVcopDRG3Lr for ; Tue, 10 Apr 2012 07:53:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D6B3B21F86D9 for ; Tue, 10 Apr 2012 07:53:51 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3AErFXM083443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Apr 2012 07:53:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 10 Apr 2012 07:53:47 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Stefan Santesson X-Mailer: Apple Mail (2.1257) Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:53:52 -0000 On Apr 10, 2012, at 7:48 AM, Stefan Santesson wrote: > Why should we stop the thread? > > 1) Because all has been said? > 2) Because since CABFORUM decides to deviate from PKIX, there are no > reasons for PKIX to relax the requirement? Yes and yes. --Paul Hoffman From DPKemp@missi.ncsc.mil Tue Apr 10 07:56:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2342721F86D9 for ; Tue, 10 Apr 2012 07:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smV5G5NLt5lK for ; Tue, 10 Apr 2012 07:56:00 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0998A21F86CB for ; Tue, 10 Apr 2012 07:55:59 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q3AEtxp9051259 for ; Tue, 10 Apr 2012 10:55:59 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 10:55:59 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 10 Apr 2012 10:55:16 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0XHZgjP3wvux2fQIO3vHD6JiUfUwABrPnQ References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 10 Apr 2012 14:55:59.0104 (UTC) FILETIME=[0A36C800:01CD172A] Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:56:01 -0000 CAB Forum deciding to recommend what works best in today's application = environment is a GOOD thing. PKIX recommending what works best in a fully-capable application = environment is also a good thing. There is no conflict, and no "loss of = control" (whatever that means) in having two specs that differ in = specifics because they differ in target environments. As for the basis for making a decision in the first place, I haven't = heard any assertion that marking the extension critical isn't = appropriate when the majority of Internet applications (and all = "significant" applications) support the extension. The only argument = for marking it non-critical is based on a lack of application support, = which can be expected to change over time. If you regard PKIX as analogous to the HTML 4.01 strict DTD, and a = CABForum profile as analogous to the HTML 4.01 Transitional DTD, why = would you view differences in the two profiles as a conflict? -----Original Message----- From: Phillip Hallam-Baker [mailto:hallam@gmail.com]=20 Sent: Tuesday, April 10, 2012 9:27 AM To: Kemp, David P. Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name But what is the basis for making the decisions in the furst place? If the decisions are based on a bunch of consultants working out how to = fleece DoD out of the maximum amount of moolah, then the industry that = has real customers is going to go elsewhere. That is the downside of the = COTS strategy, it creates economic incentives for folk to muck up the = standards process. There is already a consensus to make this change on the Mozilla list. I would be astonished if anyone opposed making the change in CABForum. So even under the present situation where those are two separate = communities, the de facto standard is going to change. At this point this group has already backed the industry into a position = where it has lost de facto standards making capability. The question now = is whether it also loses control of the de jure specification. On Tue, Apr 10, 2012 at 8:39 AM, Kemp, David P. = wrote: > It's a question of how to do Engineering. > > Approach 1: write a spec that describes what you want to achieve,=20 > implement the spec as closely as possible given the current operating=20 > environment and constraints, note AND EXPECT deviations from the spec, = > and update implementations as the environment changes. > > Approach 2: write a spec that achieves what is possible given current=20 > operating environment and constraints. =A0As the environment changes,=20 > update the spec to add back in capabilities that were previously=20 > desired but omitted. > > I'm not an HTML expert, but does not HTML 4 specify a complete feature = > set that at one time was not implemented by all browsers? =A0And=20 > individual HTML documents can be checked for "strict" or = "transitional" > compliance? =A0As browser implementations improve, is it not possible = to=20 > write more and more HTML documents that pass "strict" compliance=20 > checking WITHOUT updating the HTML 4 spec itself? > > My engineering toolbox includes tools like "lint". =A0C compilers may = be=20 > written to accept non-standard code, but the specification of the C=20 > language itself does not continue to evolve based on the current=20 > capabilities of compilers and coders. > > Should the PKIX spec be written like the HTML and C specs (one version = > that may not be completely adhered to in practice), or should today's=20 > version of PKIX be limited to the current state of applications and=20 > updated as the application environment changes? > > My vote is for Approach 1. > > Dave > > > > -----Original Message----- > From: Yoav Nir [mailto:ynir@checkpoint.com] > >> CAs have good >> justification for weighting "operate without inconveniencing casual=20 >> users" more highly than "secure" in that situation. =A0But it does = not=20 >> change the specification of the correct way to achieve both=20 >> interoperability and security. > > I disagree. The E in IETF in engineering. A spec that considers only=20 > the "secure" and not the "operate without inconveniencing casual=20 > users" is bad engineering. Engineering has to consider the operating=20 > environment and constraints of those who need to follow the spec. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ From hallam@gmail.com Tue Apr 10 08:12:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0795621F857A for ; Tue, 10 Apr 2012 08:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4+O5m-UeF9C for ; Tue, 10 Apr 2012 08:12:33 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5E911E80EF for ; Tue, 10 Apr 2012 08:12:33 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2657866yhk.31 for ; Tue, 10 Apr 2012 08:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AlHHWl8YkTyr1Q1nblFDOKkyNUIij1kaD81kx8l9mw0=; b=Ugl8O4/Hbop8BTe0veYt8yo9Gy7dQRCS2PL8qyDWXbBW89Q/2ONS6hJ/9+rwyubCCN 9GdzV7Bc21SCeyjUBUe6U6ACB1tk3XyUfJG/zRanGrk9H+WVj9iMRoyq8E3CmUZEutEp i6EsMTJfppNaNZmphOvd1bjEwhZjMyaUkV5QhrzeqxVE5s57SFomiWu0ASa4WeGStGrf ruvziniF2J3yESHf18hQ/CwinvcldKQBV2d+fxNM12uP5/idDEDG3R49atdWfY/6ftXU eDJjDA+YGiLSsTOwYHjciBndWD+cYlKSD51AxMBvqMT83yaIcaSO6rewo8bdh7ekHsyG HXhw== MIME-Version: 1.0 Received: by 10.60.36.100 with SMTP id p4mr16513260oej.42.1334070752722; Tue, 10 Apr 2012 08:12:32 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Tue, 10 Apr 2012 08:12:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Apr 2012 11:12:32 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: Stefan Santesson , IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:12:34 -0000 The reason that I re-raised the issue was that I saw that a schism was about to open in the PKI world and thought that we should either have a clean break or none at all. I don't think it is a good idea for the WG to walk blindly into a divorce. What Paul proposes is essentially a trial separation. There are marriages that have been saved by a trial separation. But you should not go into one unless you are at least considering the option of a divorce. Keeping quiet is clearly the best way to protect the institution. But that has never been a priority of mine. I am only interested in what I believe will make the Internet safer. And note that I said 'safer' not more secure. I know that I have a history of doing this. I worked with Tim to turn W3C into a standards organization after the arrangement with IETF became untenable then I was involved in the OASIS work and APWG and CABForum. I don't worry about protecting institutions because they are rather easier to establish than you might imagine. If you are prepared to risk a divorce over a MUST vs a SHOULD on a single bit then its probably best for all concerned if we admit that the marriage is probably over anyway. On Tue, Apr 10, 2012 at 10:53 AM, Paul Hoffman wrote: > On Apr 10, 2012, at 7:48 AM, Stefan Santesson wrote: > >> Why should we stop the thread? >> >> 1) Because all has been said? >> 2) Because since CABFORUM decides to deviate from PKIX, there are no >> reasons for PKIX to relax the requirement? > > > Yes and yes. > > --Paul Hoffman > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Website: http://hallambaker.com/ From rob.stradling@comodo.com Tue Apr 10 08:16:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808C021F84DD for ; Tue, 10 Apr 2012 08:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbA5Cxnq6cae for ; Tue, 10 Apr 2012 08:16:37 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 94AF321F8440 for ; Tue, 10 Apr 2012 08:16:36 -0700 (PDT) Received: (qmail 4129 invoked from network); 10 Apr 2012 15:16:33 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Apr 2012 15:16:33 -0000 Received: (qmail 31590 invoked by uid 1000); 10 Apr 2012 15:16:33 -0000 Received: from nigel.brad.office.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 (CAMELLIA256-SHA encrypted) ESMTPSA; Tue, 10 Apr 2012 16:16:33 +0100 Message-ID: <4F844ED0.20705@comodo.com> Date: Tue, 10 Apr 2012 16:16:32 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: Paul Hoffman References: <255B9BB34FB7D647A506DC292726F6E114F0498F31@WSMSG3153V.srv.dir.telstra.com> <5A757FAC-D552-45B3-A1FE-BE3FFF60FD38@checkpoint.com> <4F83F8AA.9080904@comodo.com> <95CB7F13-AF4C-456F-AC16-CD70C5F577B6@vpnc.org> <4F844699.2030907@comodo.com> <5933FF98-9971-46F2-9FA8-209A584A0B70@vpnc.org> In-Reply-To: <5933FF98-9971-46F2-9FA8-209A584A0B70@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:16:37 -0000 On 10/04/12 15:53, Paul Hoffman wrote: > On Apr 10, 2012, at 7:41 AM, Rob Stradling wrote: > >> Hi Paul. I'm guessing you meant to "To:" the list rather than me. I tried to stop this thread 6 days ago! ;-) > > Someone else from your company seems pretty intent on keeping the thread going; maybe you two could talk. :-) Let me rephrase: I tried to stop the original thread 6 days ago, after my question had been answered and the consensus against my proposal was clear. But since then, it has morphed into umpteen sub-threads all sharing the same Subject line. > --Paul Hoffman -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From hallam@gmail.com Tue Apr 10 08:18:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E8E11E80D9 for ; Tue, 10 Apr 2012 08:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEjh2yw7-AKo for ; Tue, 10 Apr 2012 08:18:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19AC011E80DF for ; Tue, 10 Apr 2012 08:18:35 -0700 (PDT) Received: by yenm5 with SMTP id m5so2669465yen.31 for ; Tue, 10 Apr 2012 08:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tWYsIEDX1XDrA1rQaUtEkcvw6qFF/39fc+xihr91h0E=; b=oUr9lU0Ofe/+qdus3NVoAuExX6NAeaklSpGPAkjs9svy6KrudZ6PPYhmADSVWxnE8Z fKZjz6iTYzUDexBX/gp1BtnPal+fZYMT0s0u69C5jkd7hMWIagcWuWtnUi+ejCKjZqlM MK90v4uDxZ9gdcIdPKvRlKDSGjKuGMespOQ1Tj1SeoT8x65XlbEoaIkG7/1+nRorM+X0 VOlNBafT4Vn3EmXKAXrdJ+SWdRSo1ag3s9DLYsdZYbXsT/y2+XwDiU57CgATmlNYxhGW suc/4LLBqZQZEWafvTZ/hqZI2vHXhNeoqnJmM9N7U44vH6ednnuZ7nXxo4DZwAFdhvN9 /a9A== MIME-Version: 1.0 Received: by 10.60.28.33 with SMTP id y1mr16476189oeg.62.1334071114603; Tue, 10 Apr 2012 08:18:34 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Tue, 10 Apr 2012 08:18:34 -0700 (PDT) In-Reply-To: References: <1142A026-E7ED-44F9-9339-F6ED6E3D4008@checkpoint.com> Date: Tue, 10 Apr 2012 11:18:34 -0400 Message-ID: From: Phillip Hallam-Baker To: "Kemp, David P." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:18:38 -0000 I disagree for the following reasons: 1) If every client processes NCs then the critical flag is irrelevant 2) If 'most' clients process NCs and some do not then it is still for the CA to decide whether safety of Internet users is best achieved by marking it critical or not. Once CABForum is forced into a position where it is overriding one part of the spec, a precedent has been set and it will override others. The result will be two specifications of which the PKIX profile is the less recognized. On Tue, Apr 10, 2012 at 10:55 AM, Kemp, David P. wr= ote: > CAB Forum deciding to recommend what works best in today's application en= vironment is a GOOD thing. > > PKIX recommending what works best in a fully-capable application environm= ent is also a good thing. =A0There is no conflict, and no "loss of control"= (whatever that means) in having two specs that differ in specifics because= they differ in target environments. > > As for the basis for making a decision in the first place, I haven't hear= d any assertion that marking the extension critical isn't appropriate when = the majority of Internet applications (and all "significant" applications) = support the extension. =A0The only argument for marking it non-critical is = based on a lack of application support, which can be expected to change ove= r time. > > If you regard PKIX as analogous to the HTML 4.01 strict DTD, and a CABFor= um profile as analogous to the HTML 4.01 Transitional DTD, why would you vi= ew differences in the two profiles as a conflict? > > > > -----Original Message----- > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > Sent: Tuesday, April 10, 2012 9:27 AM > To: Kemp, David P. > Cc: pkix@ietf.org > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name > > But what is the basis for making the decisions in the furst place? > > If the decisions are based on a bunch of consultants working out how to f= leece DoD out of the maximum amount of moolah, then the industry that has r= eal customers is going to go elsewhere. That is the downside of the COTS st= rategy, it creates economic incentives for folk to muck up the standards pr= ocess. > > There is already a consensus to make this change on the Mozilla list. > I would be astonished if anyone opposed making the change in CABForum. > So even under the present situation where those are two separate communit= ies, the de facto standard is going to change. > > > At this point this group has already backed the industry into a position = where it has lost de facto standards making capability. The question now is= whether it also loses control of the de jure specification. > > > > > On Tue, Apr 10, 2012 at 8:39 AM, Kemp, David P. w= rote: >> It's a question of how to do Engineering. >> >> Approach 1: write a spec that describes what you want to achieve, >> implement the spec as closely as possible given the current operating >> environment and constraints, note AND EXPECT deviations from the spec, >> and update implementations as the environment changes. >> >> Approach 2: write a spec that achieves what is possible given current >> operating environment and constraints. =A0As the environment changes, >> update the spec to add back in capabilities that were previously >> desired but omitted. >> >> I'm not an HTML expert, but does not HTML 4 specify a complete feature >> set that at one time was not implemented by all browsers? =A0And >> individual HTML documents can be checked for "strict" or "transitional" >> compliance? =A0As browser implementations improve, is it not possible to >> write more and more HTML documents that pass "strict" compliance >> checking WITHOUT updating the HTML 4 spec itself? >> >> My engineering toolbox includes tools like "lint". =A0C compilers may be >> written to accept non-standard code, but the specification of the C >> language itself does not continue to evolve based on the current >> capabilities of compilers and coders. >> >> Should the PKIX spec be written like the HTML and C specs (one version >> that may not be completely adhered to in practice), or should today's >> version of PKIX be limited to the current state of applications and >> updated as the application environment changes? >> >> My vote is for Approach 1. >> >> Dave >> >> >> >> -----Original Message----- >> From: Yoav Nir [mailto:ynir@checkpoint.com] >> >>> CAs have good >>> justification for weighting "operate without inconveniencing casual >>> users" more highly than "secure" in that situation. =A0But it does not >>> change the specification of the correct way to achieve both >>> interoperability and security. >> >> I disagree. The E in IETF in engineering. A spec that considers only >> the "secure" and not the "operate without inconveniencing casual >> users" is bad engineering. Engineering has to consider the operating >> environment and constraints of those who need to follow the spec. >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From wjhns1@hardakers.net Tue Apr 10 08:22:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0783B11E80DF for ; Tue, 10 Apr 2012 08:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAj5KoK-mVbb for ; Tue, 10 Apr 2012 08:22:18 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D6911E80CD for ; Tue, 10 Apr 2012 08:22:17 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 40EA56A7; Tue, 10 Apr 2012 08:22:17 -0700 (PDT) From: Wes Hardaker To: Paul Hoffman References: <1E3BEE27-9EF6-4C84-BFCB-9FA8350B33BD@vpnc.org> <87E63D05-473A-4866-811E-A31F653EB07C@vpnc.org> <987765D8-D527-4FB9-B19F-1800CCA7242D@vpnc.org> Date: Tue, 10 Apr 2012 08:22:16 -0700 In-Reply-To: <987765D8-D527-4FB9-B19F-1800CCA7242D@vpnc.org> (Paul Hoffman's message of "Thu, 5 Apr 2012 12:57:01 -0700") Message-ID: <0lbomzvcgn.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:22:19 -0000 >>>>> On Thu, 5 Apr 2012 12:57:01 -0700, Paul Hoffman said: PH> Fully disagree. While it is clear to me that both X.509 and PKIX PH> totally muffed the definition of "self-signed" by also requiring the PH> cA bit, we have to life with that (and similar muffage). If the term is "muffed" then replace it. You're unlikely to fix it. In particular, the majority of the under-educated geeks in the world that are throwing the "self-signed" term around use it in one context in their head: "A certificate with a public key and the whole ball of wax was signed by the corresponding private key". 90% of the people using the term have *no* notion that a cA component even exists. So... if you're going to try and "clarify what self-signed actually means" then you'll only succeed in re-educating the original 10% that already understood it. The other 90%, that never read the RFC and probably learned everything through word of mouth or badly-assumed context, will not be corrected and the term will continue to be misused. How about use a new term instead, if it needs to be discussed in 5280bis (which it certainly does). Let self-signed be the parent term and have a (new) special-case term for the other special-case sub-categories you wish to define. [Others have already hinted at doing something close to this, so I'm just generically expressing my opinion about the fact that we can't fix the world's terminology usage at this point. It's *way* too in-use to recall the bad usage at this point.] -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From stefan@aaa-sec.com Tue Apr 10 08:27:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7D311E80EA for ; Tue, 10 Apr 2012 08:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZPXkTWs28Gx for ; Tue, 10 Apr 2012 08:27:15 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 7E73111E80FB for ; Tue, 10 Apr 2012 08:27:10 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 359671E1446D for ; Tue, 10 Apr 2012 17:27:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vGYAJiNYHSx9 for ; Tue, 10 Apr 2012 17:27:08 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id EFD0E1E108C1 for ; Tue, 10 Apr 2012 17:27:08 +0200 (CEST) Received: (qmail 4617 invoked from network); 10 Apr 2012 15:27:07 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.2]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Apr 2012 15:27:07 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 10 Apr 2012 17:26:44 +0200 From: Stefan Santesson To: Paul Hoffman Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:27:15 -0000 Paul, Please enlighten me more on your reasoning. Why is it better to have the world's largest implementation of public internet PKI non-conformant to the PKIX profile? /Stefan On 12-04-10 4:53 PM, "Paul Hoffman" wrote: >On Apr 10, 2012, at 7:48 AM, Stefan Santesson wrote: > >> Why should we stop the thread? >> >> 1) Because all has been said? >> 2) Because since CABFORUM decides to deviate from PKIX, there are no >> reasons for PKIX to relax the requirement? > > >Yes and yes. > >--Paul Hoffman > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From paul.hoffman@vpnc.org Tue Apr 10 08:28:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36E511E8103 for ; Tue, 10 Apr 2012 08:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnSeOP2TR2at for ; Tue, 10 Apr 2012 08:28:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 06CDF11E80EF for ; Tue, 10 Apr 2012 08:28:12 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3AFSAcV085026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Apr 2012 08:28:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 10 Apr 2012 08:28:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <621B895B-D120-4DBF-BA77-F4EE58A8AB03@vpnc.org> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1257) Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:28:13 -0000 On Apr 10, 2012, at 8:12 AM, Phillip Hallam-Baker wrote: > The reason that I re-raised the issue was that I saw that a schism was > about to open in the PKI world and thought that we should either have > a clean break or none at all. It is not "about to open": CABForum opened it long ago. > I don't think it is a good idea for the WG to walk blindly into a > divorce. What Paul proposes is essentially a trial separation. Once again: please don't put words (in this case, analogies) into my = mouth. CABForum has already proposed a profile, and the market can = decide whether or not it is a good one. Rob says that the CABForum will = consider a change to its profile, which seems good too. Lots of other = groups have also proposed profiles, and their markets decide as well. > There > are marriages that have been saved by a trial separation. But you > should not go into one unless you are at least considering the option > of a divorce. I do not consider the PKI-using world as a polyamory relationship. --Paul Hoffman From ynir@checkpoint.com Tue Apr 10 08:41:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0251B21F84E2 for ; Tue, 10 Apr 2012 08:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu6X7KGP+UaN for ; Tue, 10 Apr 2012 08:41:03 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 28A7111E80B8 for ; Tue, 10 Apr 2012 08:41:02 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3AFem0X000747; Tue, 10 Apr 2012 18:40:48 +0300 X-CheckPoint: {4F8461CF-2-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 10 Apr 2012 18:40:47 +0300 From: Yoav Nir To: Phillip Hallam-Baker Date: Tue, 10 Apr 2012 18:40:44 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0XMEvhhIZGdudWTNWMz2PONetnlQ== Message-ID: <15C88201-DE1B-46E8-92EC-188EAF2B986A@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 119e1bc6bf49c0493f3ae1a0136de7eb9646bb8106 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stefan Santesson , Paul Hoffman , IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:41:05 -0000 Interesting analogy. Or should I say metaphor. http://xkcd.com/762/ The current profile suggested by CABForum is a sub-profile of 5280. Every r= equirement there is allowed by 5280. What is being proposed here is a devia= tion from 5280, so essentially it's another profile. The CABForum has so fa= r not done this, and I would not like there to be such an overlap in what t= he two organizations do. Doing that leads to turf wars on the one hand, and= the "is this ours or theirs" question (such as is raised whenever somebody= brings anything new to websec) I would much rather that a new profile (if needed) be done in the IETF in c= ooperation with CABForum, rather than in competition. Yoav On Apr 10, 2012, at 6:12 PM, Phillip Hallam-Baker wrote: > The reason that I re-raised the issue was that I saw that a schism was > about to open in the PKI world and thought that we should either have > a clean break or none at all. >=20 > I don't think it is a good idea for the WG to walk blindly into a > divorce. What Paul proposes is essentially a trial separation. There > are marriages that have been saved by a trial separation. But you > should not go into one unless you are at least considering the option > of a divorce. >=20 >=20 > Keeping quiet is clearly the best way to protect the institution. But > that has never been a priority of mine. I am only interested in what I > believe will make the Internet safer. And note that I said 'safer' not > more secure. >=20 > I know that I have a history of doing this. I worked with Tim to turn > W3C into a standards organization after the arrangement with IETF > became untenable then I was involved in the OASIS work and APWG and > CABForum. I don't worry about protecting institutions because they are > rather easier to establish than you might imagine. >=20 >=20 > If you are prepared to risk a divorce over a MUST vs a SHOULD on a > single bit then its probably best for all concerned if we admit that > the marriage is probably over anyway. >=20 > On Tue, Apr 10, 2012 at 10:53 AM, Paul Hoffman wr= ote: >> On Apr 10, 2012, at 7:48 AM, Stefan Santesson wrote: >>=20 >>> Why should we stop the thread? >>>=20 >>> 1) Because all has been said? >>> 2) Because since CABFORUM decides to deviate from PKIX, there are no >>> reasons for PKIX to relax the requirement? >>=20 >>=20 >> Yes and yes. >>=20 >> --Paul Hoffman >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 > Scanned by Check Point Total Security Gateway. From ynir@checkpoint.com Tue Apr 10 08:42:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0955E21F850D for ; Tue, 10 Apr 2012 08:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7Q6cMEnz8yb for ; Tue, 10 Apr 2012 08:42:25 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 25DC621F850C for ; Tue, 10 Apr 2012 08:42:24 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3AFgLPP001108; Tue, 10 Apr 2012 18:42:21 +0300 X-CheckPoint: {4F84622C-1-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 10 Apr 2012 18:42:20 +0300 From: Yoav Nir To: Stefan Santesson Date: Tue, 10 Apr 2012 18:42:19 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0XMINmrFDIWSOVT+aJBKvf4y4JtA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 113e41f54a7629b256566abfaa212fe0d3dd8c2553 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:42:26 -0000 I agree. It would be another profile. We can make the document short, and e= xclude all the explanations of X509 that 5280 includes by saying that this = profile is the same as 5280 except for these few differences. On Apr 10, 2012, at 3:52 PM, Stefan Santesson wrote: > Yoav, >=20 > On 12-04-10 6:38 AM, "Yoav Nir" wrote: >=20 >> It doesn't have to be a 150-page behemoth like 5280, either. More like >>=20 >> Abstract >> This document specifies a profile for web browsers and CAs >>=20 >> 1. Introduction >> [RFC5280] specifies a profile for PKI on the Internet. This document >> specifies >> a profile for web browsers and CAs. It inherits all the requirements >> from >> RFC 5280, with the exceptions listed in the following sections. >>=20 >> 2. Name Constraints >> RFC 5280 requires name constraints to be marked critical. Under this >> profile >> this extension MAY be critical. >> Discussion: =8A >>=20 >=20 >=20 > It would have to be another profile of X.509. > It can't be a profile of RFC 5280 as it isn't compliant with RFC 5280. >=20 > Since web browsers are an Internet application, I would much rather have = a > web profile being a profile of RFC 5280. > Such a profile AFAIK has already been defined by the cab-forum. >=20 > /Stefan >=20 >=20 From paul.hoffman@vpnc.org Tue Apr 10 08:59:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC23321F859B for ; Tue, 10 Apr 2012 08:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dflmDW0dZQ7p for ; Tue, 10 Apr 2012 08:59:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BCCBC21F859A for ; Tue, 10 Apr 2012 08:59:00 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3AFwufm086096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Apr 2012 08:58:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 10 Apr 2012 08:58:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7210A729-787E-4006-A89C-97A233BD6A04@vpnc.org> References: To: Stefan Santesson X-Mailer: Apple Mail (2.1257) Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:59:01 -0000 On Apr 10, 2012, at 8:26 AM, Stefan Santesson wrote: > Please enlighten me more on your reasoning. > Why is it better to have the world's largest implementation of public > internet PKI non-conformant to the PKIX profile? Because they believe that it works for their business model. Their = business model evolves over time, sometimes in ways that add to the PKIX = spec, other times in ways that subtract from it. They should be free to = move with the needs of their users. Different implementations need different things from PKIX at different = times. If they want to diverge, there are no Internet Police to stop = them: that's a good thing. --Paul Hoffman From stefan@aaa-sec.com Tue Apr 10 09:14:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B300911E80CB for ; Tue, 10 Apr 2012 09:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ko4XPHyK58aa for ; Tue, 10 Apr 2012 09:14:39 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 273BB11E80F2 for ; Tue, 10 Apr 2012 09:14:38 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 0DFB51E2532C for ; Tue, 10 Apr 2012 18:14:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7_HDlczuIKy6 for ; Tue, 10 Apr 2012 18:14:36 +0200 (CEST) Received: from s329.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id BE7A81E25EF4 for ; Tue, 10 Apr 2012 18:14:36 +0200 (CEST) Received: (qmail 74446 invoked from network); 10 Apr 2012 16:14:36 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.2]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s329.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Apr 2012 16:14:36 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 10 Apr 2012 18:13:55 +0200 From: Stefan Santesson To: Paul Hoffman Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: <7210A729-787E-4006-A89C-97A233BD6A04@vpnc.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:14:39 -0000 Thank you Paul, Then at least I know that we fundamentally disagree. To me RFC 5280 (being the only Internet X.509 profile) should be usable for all legitimate business models for internet PKI. If there is a legitimate business model that does not fit within the base technical profile of RFC 5280, our profile is to narrow. If the business model fails to fit within RFC 5280, because it's security model is broken, then it is not a legitimate business model. I believe CABForum has a legitimate business model, and it appears that you agree. I simply can't understand why you want to ban it from RFC 5280. /Stefan On 12-04-10 5:58 PM, "Paul Hoffman" wrote: >On Apr 10, 2012, at 8:26 AM, Stefan Santesson wrote: > >> Please enlighten me more on your reasoning. >> Why is it better to have the world's largest implementation of public >> internet PKI non-conformant to the PKIX profile? > > >Because they believe that it works for their business model. Their >business model evolves over time, sometimes in ways that add to the PKIX >spec, other times in ways that subtract from it. They should be free to >move with the needs of their users. > >Different implementations need different things from PKIX at different >times. If they want to diverge, there are no Internet Police to stop >them: that's a good thing. > >--Paul Hoffman > From stephen.farrell@cs.tcd.ie Tue Apr 10 09:23:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E1411E8102 for ; Tue, 10 Apr 2012 09:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lH88OBQOUGoe for ; Tue, 10 Apr 2012 09:23:39 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id D628011E80F3 for ; Tue, 10 Apr 2012 09:23:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4D19D171479; Tue, 10 Apr 2012 17:23:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334075017; bh=gTPk5JY5z19OuF gMjfyrJfL8Wmdls2BhR5ul9vxJJCE=; b=qWSLYS25dNBKIfSGbao1emXAhkZSB8 FJHk9FLVb/Ma4LviEr1cwRsYgV14Gh4zHYAiVG3liBmhPvJfAl8KnjTPwzde3s0P q5dB9iJDb0DfFUGm+XL+zbuXb93zMGKo5ZjJab4pFwr1DNrajwrFrpizNpqeaAeI XT90dHkC3Lriv4Xdb7VwojQnfGWXHeTKP0CI33f7bRzDOxpb/LNPwhmNHO2RZOvJ kA6gUhdBRq33rNoRBD1y4Xmm1SnrWcv9Yxy3+bEkIwPuFFA/lhfhK2XaIJaDU1CZ bCVZHFZjMuEY3Aac+4I7VLuQ6Duv0aIy3yv9gg2RNykmr2gnt0BCeDZw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 5-gTTsNAH4aH; Tue, 10 Apr 2012 17:23:37 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 023B7171472; Tue, 10 Apr 2012 17:23:36 +0100 (IST) Message-ID: <4F845E89.6090001@cs.tcd.ie> Date: Tue, 10 Apr 2012 17:23:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF PKIX , Paul Hoffman Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:23:45 -0000 Stefan, On 04/10/2012 05:13 PM, Stefan Santesson wrote: > I simply can't understand why you want to ban it from RFC 5280. I didn't hear anyone try "ban" anything. There is a trade off here. If the one implementation for which we're told this is a problem gets fixed then do we tweak RFCs again? That'd seem like an odd way to do stuff. OTOH, starting to use NC would be a good thing. There are arguments for the change to be made and there are arguments for the status quo. Speaking as a co-author of 5280, so far, I'm not convinced by the argument to change the 5280 rule. S. > > /Stefan > > > On 12-04-10 5:58 PM, "Paul Hoffman" wrote: > >> On Apr 10, 2012, at 8:26 AM, Stefan Santesson wrote: >> >>> Please enlighten me more on your reasoning. >>> Why is it better to have the world's largest implementation of public >>> internet PKI non-conformant to the PKIX profile? >> >> >> Because they believe that it works for their business model. Their >> business model evolves over time, sometimes in ways that add to the PKIX >> spec, other times in ways that subtract from it. They should be free to >> move with the needs of their users. >> >> Different implementations need different things from PKIX at different >> times. If they want to diverge, there are no Internet Police to stop >> them: that's a good thing. >> >> --Paul Hoffman >> > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From DPKemp@missi.ncsc.mil Tue Apr 10 09:31:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564A911E8106 for ; Tue, 10 Apr 2012 09:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtUWZ4tc+x+Z for ; Tue, 10 Apr 2012 09:31:22 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6E07811E80BE for ; Tue, 10 Apr 2012 09:31:22 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q3AGVKKR053263 for ; Tue, 10 Apr 2012 12:31:20 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 12:31:20 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 10 Apr 2012 12:31:12 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0XLm97G42a+K82RDG2B6f2fCeUQQABD9MA References: From: "Kemp, David P." To: "IETF PKIX" X-OriginalArrivalTime: 10 Apr 2012 16:31:20.0823 (UTC) FILETIME=[5C9FD070:01CD1737] Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:31:23 -0000 For the same reason that in 1999, the world's largest collection of browsers was non-conformant to the HTML 4.01 strict profile. >From W3C: * The HTML 4.01 Strict DTD includes all elements and attributes that have not been deprecated or do not appear in frameset documents. * The HTML 4.01 Transitional DTD includes everything in the strict DTD plus deprecated elements and attributes. This approach seems like a perfect analogy (or metaphor: +1 for xkcd references :-). There is no divorce or trial separation between the two HTML DTDs; they are partners that were designed together to address legacy applications and modern applications. My question is "if the purpose of PKIX is to define the transitional profile, then who is responsible for defining the strict profile?" Dave -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Tuesday, April 10, 2012 11:27 AM To: Paul Hoffman Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name Paul, Please enlighten me more on your reasoning. Why is it better to have the world's largest implementation of public internet PKI non-conformant to the PKIX profile? /Stefan On 12-04-10 4:53 PM, "Paul Hoffman" wrote: >On Apr 10, 2012, at 7:48 AM, Stefan Santesson wrote: > >> Why should we stop the thread? >>=20 >> 1) Because all has been said? >> 2) Because since CABFORUM decides to deviate from PKIX, there are no=20 >> reasons for PKIX to relax the requirement? > > >Yes and yes. > >--Paul Hoffman > >_______________________________________________ >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 paul.hoffman@vpnc.org Tue Apr 10 09:39:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D117C11E8126 for ; Tue, 10 Apr 2012 09:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dp1J+M0HKyIA for ; Tue, 10 Apr 2012 09:39:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 48F8B11E80F3 for ; Tue, 10 Apr 2012 09:39:45 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3AGdfAN087410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Apr 2012 09:39:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 10 Apr 2012 09:39:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <48CF6FE3-E73B-4AC7-A1BD-DD84A964E9B2@vpnc.org> References: To: Stefan Santesson X-Mailer: Apple Mail (2.1257) Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:39:45 -0000 On Apr 10, 2012, at 9:13 AM, Stefan Santesson wrote: > Thank you Paul, >=20 > Then at least I know that we fundamentally disagree. >=20 > To me RFC 5280 (being the only Internet X.509 profile) should be = usable > for all legitimate business models for internet PKI. > If there is a legitimate business model that does not fit within the = base > technical profile of RFC 5280, our profile is to narrow. >=20 > If the business model fails to fit within RFC 5280, because it's = security > model is broken, then it is not a legitimate business model. >=20 > I believe CABForum has a legitimate business model, and it appears = that > you agree. > I simply can't understand why you want to ban it from RFC 5280. The trust model for the CAs in the CABForum is quite different than the = security assumptions made by other CAs who use PKIX. The CABForum trust = model ("you will trust every CA in your root pile to issue certs for any = domain name") works pretty well for the typical web browser model, but = does not work well for other models that have historically been = supported by PKIX. CAs, and CA groups like the CABForum, should be encouraged to make = profiles to PKIX as they see fit. Publicly-facing CAs should be = encouraged to make their profiles public, as the CABForum did. --Paul Hoffman From stefan@aaa-sec.com Tue Apr 10 09:47:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D554611E80FC for ; Tue, 10 Apr 2012 09:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3tA8hHErEZS for ; Tue, 10 Apr 2012 09:47:35 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id A319F11E80F3 for ; Tue, 10 Apr 2012 09:47:28 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 6BC4D1E1064A for ; Tue, 10 Apr 2012 18:47:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AI4RfldZ948a for ; Tue, 10 Apr 2012 18:47:27 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 16C591E149EC for ; Tue, 10 Apr 2012 18:47:27 +0200 (CEST) Received: (qmail 34687 invoked from network); 10 Apr 2012 16:47:24 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.2]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Apr 2012 16:47:24 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 10 Apr 2012 18:47:13 +0200 From: Stefan Santesson To: Stephen Farrell Message-ID: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name In-Reply-To: <4F845E89.6090001@cs.tcd.ie> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF PKIX , Paul Hoffman Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:47:37 -0000 On 12-04-10 6:23 PM, "Stephen Farrell" wrote: > >Stefan, > >On 04/10/2012 05:13 PM, Stefan Santesson wrote: >> I simply can't understand why you want to ban it from RFC 5280. > >I didn't hear anyone try "ban" anything. Wrong word, I'm sorry. I meant to say, I can't see any reason why this legitimate business need would not be allowed under 5280. > >There is a trade off here. If the one implementation for >which we're told this is a problem gets fixed then do we tweak >RFCs again? That'd seem like an odd way to do stuff. Actually yes, I would hope this group would have the courage to change things when it is the right thing to do. In particular when the spec turns out to be to narrow to meet legitimate needs. I do not advocate changing things that would break the security model, introducing vulnerabilities or breaking backwards compatibility. > >OTOH, starting to use NC would be a good thing. Agreed. > >There are arguments for the change to be made and there are >arguments for the status quo. Agreed. > >Speaking as a co-author of 5280, so far, I'm not convinced >by the argument to change the 5280 rule. I am. However I like to view it as "allowing more" because we found legitimate scenarios where it is reasonable to do so. /Stefan > >S. > >> >> /Stefan >> >> >> On 12-04-10 5:58 PM, "Paul Hoffman" wrote: >> >>> On Apr 10, 2012, at 8:26 AM, Stefan Santesson wrote: >>> >>>> Please enlighten me more on your reasoning. >>>> Why is it better to have the world's largest implementation of public >>>> internet PKI non-conformant to the PKIX profile? >>> >>> >>> Because they believe that it works for their business model. Their >>> business model evolves over time, sometimes in ways that add to the >>>PKIX >>> spec, other times in ways that subtract from it. They should be free to >>> move with the needs of their users. >>> >>> Different implementations need different things from PKIX at different >>> times. If they want to diverge, there are no Internet Police to stop >>> them: that's a good thing. >>> >>> --Paul Hoffman >>> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> From mrex@sap.com Tue Apr 10 12:44:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8773711E8139 for ; Tue, 10 Apr 2012 12:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.08 X-Spam-Level: X-Spam-Status: No, score=-10.08 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taFomd6p6cXI for ; Tue, 10 Apr 2012 12:44:16 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id CD2EC11E80DF for ; Tue, 10 Apr 2012 12:44:15 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3AJi9J3000204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Apr 2012 21:44:10 +0200 (MEST) From: Martin Rex Message-Id: <201204101944.q3AJi9Ue026845@fs4113.wdf.sap.corp> To: piyush@identicate.com (Piyush Jain) Date: Tue, 10 Apr 2012 21:44:09 +0200 (MEST) In-Reply-To: from "Piyush Jain" at Apr 8, 12 06:50:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: stefan@aaa-sec.com, paul.hoffman@vpnc.org, pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:44:17 -0000 Piyush Jain wrote: > > > > > An RP will only see if the extension has criticality or not. > > To break anything the RP client would have to reject the cert just because > > it finds a NC with non-critical flag. > > This is not a behavior caused by any existing RFC 5280 requirement. > > Existing requirement is that NC must be marked critical. > Believe it or not, there are implementations out there which check > if a certificate complies with the profile or not, and reject > them upfront in case of failure. But you should realize that such behaviour is significantly less compliant to rfc5280 that not implementing name constraints for anything besided directory names. Checking whether a name constraints is marked critical is something that rfc5280 explicitly recommends _against_. Since following rfc5280 means less code then performing such a check, adding such a check requires a really good rationale. The logic to check name constraints of the various name forms, on the other hand, requires huge amounts of non-trivial extra code. Therefore every implementation option that requires >10 lines of code is considered a true implementor option in PKIX, something that the "minimum requirements RP" must be expected to not support. By defining the concept of a "minimum requirements RP", PKIX has effectively watered down all non-trivial-to-implement SHOULDs to MAYs. -Martin From tmiller@mitre.org Tue Apr 10 12:45:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8813911E8140 for ; Tue, 10 Apr 2012 12:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkxc1lZhWA0G for ; Tue, 10 Apr 2012 12:45:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0671411E80DF for ; Tue, 10 Apr 2012 12:45:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B771521B066E; Tue, 10 Apr 2012 15:45:04 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9FD6121B040C; Tue, 10 Apr 2012 15:45:04 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.233]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.01.0339.001; Tue, 10 Apr 2012 15:45:04 -0400 From: "Miller, Timothy J." To: Tom Gindin , Santosh Chokhani Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: AQHNEPPvquDEc5XKr0iEIGU8AH05gZaICg8AgAUfg4CAABWQgIAAA7CAgACzvICAAA6cAIAABD0AgAASSACAACJKAIAA9dKAgAATYgCAAMPIgIAAAneAgAAUuACAADc3gIACqGEAgAAml4CAABAPgIAAEPkAgAAwbICAAOSUgIAADYQAgAAGSQA= Date: Tue, 10 Apr 2012 19:45:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.51.112] Content-Type: text/plain; charset="us-ascii" Content-ID: <8EA6E00CEC9FA841B8889532E52C43EA@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:45:07 -0000 So what NC would a commercial CA vendor assert, given that most public CAs do not use namespace-specific Issuers? (IOW, Verisign issues to any DNS name. Is Verisign champing at the bit to create a *.edu Issuer? What prevents them from doing so now?) -- T On 4/10/12 9:22 AM, "Tom Gindin" wrote: > Santosh: > > Under the defined syntax, CA's have three choices for >intermediate=20 >certificates in this area. In ascending order of security, they are "no >constraints", "non-critical constraints", "critical constraints". It >appears to me that the effect of banning the middle option has been, at >least in the commercial world, to drive most CA's to the less secure >option rather than to the more secure one. > Do you have evidence that many commercial CA's are using critical >name constraints except under government influence? I don't, but others >may have had better experiences. > >Tom Gindin > > > > >From: Santosh Chokhani >To: "Manger, James H" , IETF PKIX >,=20 >Date: 04/10/2012 09:36 AM >Subject: Re: [pkix] Proposal: Change the Criticality Requirement >of=20 >Name >Sent by: pkix-bounces@ietf.org > > > >James, > >It is hard to determine what would motivate a given vendor. You may very >well be right. But, the way to achieve this is for the CAs to determine >how to bring the "certificate consuming" software vendors in compliance. >The standard should preserve security. > >CA vendors can give grace period or browser vendors can use existing or >new UI to let the human use decide if they want to override the browser >decision until browsers have the capability to process the extension. > >-----Original Message----- >From: Manger, James H [mailto:James.H.Manger@team.telstra.com] >Sent: Monday, April 09, 2012 7:56 PM >To: Santosh Chokhani; IETF PKIX >Subject: RE: [pkix] Proposal: Change the Criticality Requirement of Name > >Santosh, > >> If the standard said this extension can be NC (non-critical), folks >> would be happy to produce certificates with NC and some browsers will >> not implement name constraints processing. >> >> It is important that we get where the RP enforce the CA defined >> constraints and making security critical extensions NC in a security >> standard is not the way to get their attention. >> It is a way to tell folks that this is not important for security. > >At the moment, there is little incentive for an implementation (such as >Safari) to implement name constraints as there are almost no certificates >using them. A browser is equally secure with or without support. > >If name constraints can be non-critical, certificates using them can >appear far more easily and there will be an explicit security difference >between browsers that do or do not implement those constraints. That will >provide a tangible incentive for software (such as Safari) to implement >name constraints. Otherwise it doesn't protect its users from a threat >that other browsers do, which will look very bad if (or when) the threat >becomes an attack. > >I am in favour of removing the PKIX requirement that name constraints be >marked critical. > >-- >James Manger >_______________________________________________ >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 ynir@checkpoint.com Tue Apr 10 12:56:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B9C21F84B8 for ; Tue, 10 Apr 2012 12:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.567 X-Spam-Level: X-Spam-Status: No, score=-10.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXcMRuA5R+No for ; Tue, 10 Apr 2012 12:56:50 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D5FBD21F8474 for ; Tue, 10 Apr 2012 12:56:49 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3AJudPk018782; Tue, 10 Apr 2012 22:56:39 +0300 X-CheckPoint: {4F849DC3-0-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 10 Apr 2012 22:56:37 +0300 From: Yoav Nir To: "Miller, Timothy J." Date: Tue, 10 Apr 2012 22:56:37 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0XVAk68ITv5y/qT8Wns4utJr38zg== Message-ID: <6867F7B7-0D96-4A4F-A9DD-1713864CF8AA@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11e3a5434a8885eed7198016b9669291ebdaf95d88 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 19:56:51 -0000 On Apr 10, 2012, at 10:45 PM, Miller, Timothy J. wrote: > So what NC would a commercial CA vendor assert, given that most public CA= s > do not use namespace-specific Issuers? (IOW, Verisign issues to any DNS > name. Is Verisign champing at the bit to create a *.edu Issuer? What > prevents them from doing so now?) They're not chomping at the bit to create a *.edu issuer, but they may want= to sell my company a *.checkpoint.com CA certificate (for more than the wi= ldcard cost), so that we can issue certificates for supportcenter.checkpoin= t.com, wiki.checkpoint.com, sslvpn.checkpoint.com and opengrok.source.check= point.com, while still not allowing us to sell you a gateway with a certifi= cate for cpgateway.mitre.org, and have that certificate chain all the way t= o Verisign. They would also not like us to take that certificate and use it in our TLS = proxy to sign on-the-fly certificates for gmail, facebook, Amazon and other= s. What prevents them from doing it now, is that not having a NC extension wil= l allow us to do both of these things, while adding a critical one will cau= se iOS clients to fail. Yoav= From mrex@sap.com Tue Apr 10 13:17:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AD111E80DF for ; Tue, 10 Apr 2012 13:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.09 X-Spam-Level: X-Spam-Status: No, score=-10.09 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hPeCf4XE47d for ; Tue, 10 Apr 2012 13:17:34 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4742011E80F4 for ; Tue, 10 Apr 2012 13:17:34 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3AKHPL6003152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Apr 2012 22:17:25 +0200 (MEST) From: Martin Rex Message-Id: <201204102017.q3AKHPv6029023@fs4113.wdf.sap.corp> To: kent@bbn.com (Stephen Kent) Date: Tue, 10 Apr 2012 22:17:25 +0200 (MEST) In-Reply-To: from "Stephen Kent" at Apr 9, 12 08:57:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:17:35 -0000 Stephen Kent wrote: > >Martin Rex wrote: >> >>Stephen Kent wrote: >>> >>> It occurs to me that we might be able to make this even more concise >>> and tighten the scope. The current text says that these certs don >>> contain a basic constraints extension with the CA flag set to true. >>> Do they contain a basic constraints extension at all? >> >>Unfortunately, this differs from the "existing practise" in the >>installed base, where the majority of self-signed TLS server certs >>in use carries the "Basic Constraints:cA=TRUE" attribute. > >a self-signed CA cert is already acceptable under X.509 and 280, and >thus is not the subject of this text. We're talking past each other. The text we're discussing is _exactly_ about self-signed EE certs used by communication peers, what they should look like and how they should be processed _in_the_future_. Since X.509 and PKIX were previously silent about this mode of operation, you will find all possible solutions in the installed base: X.509v1, X.509v3 non-CA and X.509v3 CA certs, and the probability for each solution is related to default behaviour/default configuration of the software that was used to create these certs. With X.509v1, CA and non-CA certs can only be distinguished by meta-knowledge. Self-signed X.509v3 certs used by communication peers of the currently installed base can also only be distinguished by meta-knowledge, because the attributes in the certificates that distinguish CA from non-CA uses very often do not reflect conscious intent of the admin / cert creator, but rather an implementation decision of the software creator or software distributor trying to obtain wire-level interop. -Martin From mrex@sap.com Tue Apr 10 17:19:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14BE11E8143 for ; Tue, 10 Apr 2012 17:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.957 X-Spam-Level: X-Spam-Status: No, score=-8.957 tagged_above=-999 required=5 tests=[AWL=-1.008, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_STOP=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ob0+mJVvJqfB for ; Tue, 10 Apr 2012 17:19:24 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C65B911E8081 for ; Tue, 10 Apr 2012 17:19:23 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3B0JCWB020619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Apr 2012 02:19:12 +0200 (MEST) From: Martin Rex Message-Id: <201204110019.q3B0JB3L012814@fs4113.wdf.sap.corp> To: SChokhani@cygnacom.com (Santosh Chokhani) Date: Wed, 11 Apr 2012 02:19:11 +0200 (MEST) In-Reply-To: from "Santosh Chokhani" at Apr 8, 12 09:09:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: stefan@aaa-sec.com, pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 00:19:24 -0000 Santosh Chokhani wrote: > > Your logic can be applied to any of the certificate extensions identified > as critical in 5280. Correct! See the discussion of what *additional* impact the criticality flag has on an extension, and why there might be reasons (for the entity deciding about the trade-off) not to flag an extension as critical. http://tools.ietf.org/html/rfc3647#section-3.3.1 That document (rfc3647) lists _you_ as one of the authors, so I'm kind of confused (to put it mildly) to see you argue 100% the opposite today. > > In my opinion PKIX standards are for secure interoperability. > What you say exposes some of the clients. You got it all backwards. Because of the current requirement, the situation that we're faced it that _everyone_ is exposed, and it is not possible to allow mitigation for the subset of clients that implements that optional protocol feature. Not protecting anyone at all is definitely worse than not protecting only those that do not fully implement this feature. > > The harm it does is CAs will point to the RFC and mark the extension > non critical and the RP software (browser) vendors will not have any > reason or incentive to implement name constraints. > This will expose the consumers and businesses. > > It is best for the CAs make their own determination and work with RP in CA browser forum, > > We should not dilute the security of a security standard just because > the largest market capitalization company in the history of human race > has not implemented a long standing standard correctly. While I personally try to avoid stuff from Apple as much as I possibly can, criticising them for rejecting certs signed by CAs with certs containing a name constraints extensions is a terribly BAD idea. They're actually *MORE* compliant than many other implementations that simply ignore name constraints extensions, independent of their criticality. I don't know whether OpenSSL 0.9.8x will reject name constraints that are marked critical, but comparing crypto/x509v3/v4_ncons.c from 0.9.8r and 1.0.0d, it don't see the matching of name constraints in 0.9.8r. Pretty much 100% of all our *NEW* Linux systems that I run (and those in use in our company) use OpenSSL 0.9.8x, and a signficant number of SLES-9 system still use OpenSSL 0.9.7x. Erwann Abalea wrote: > > OpenSSL 1.0.0 does enforce nameConstraints. mod_ssl, when using older > versions of OpenSSL, rejects a certificate containing a critical > nameConstraints extension. The majority of Linux installations is on 0.9.8x or earlier, and the original discussion was about name constraints primarily for servers(!) (e.g. DNSName) rather than client certs. Is the mod_ssl check really about the **own** server cert (where such a check would be silly and only hurting the consumer), or about the peer certificate (where that check is just marginally interesting for the current discussion). What wget/curl do when doing server endpoint identification would be more relevant to the discussion. And I repeat my complaint that only looking at 5 top-most vendors is missing the point, because it will miss several hundred million TLS usage scenarios. -Martin From kent@bbn.com Wed Apr 11 00:55:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5D311E8122 for ; Wed, 11 Apr 2012 00:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.015 X-Spam-Level: X-Spam-Status: No, score=-106.015 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyeHNDSxGShF for ; Wed, 11 Apr 2012 00:55:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BFB5511E8121 for ; Wed, 11 Apr 2012 00:55:30 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:52325 helo=[172.31.27.154]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHsOV-000CTf-0k; Wed, 11 Apr 2012 03:55:12 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <201204102017.q3AKHPv6029023@fs4113.wdf.sap.corp> References: <201204102017.q3AKHPv6029023@fs4113.wdf.sap.corp> Date: Tue, 10 Apr 2012 21:03:21 -0400 To: mrex@sap.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: pkix@ietf.org Subject: Re: [pkix] 5280 clarifications X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 07:55:31 -0000 >... > >We're talking past each other. > >The text we're discussing is _exactly_ about self-signed EE certs used by >communication peers, what they should look like and how they should be >processed _in_the_future_. self-signed certs that contain the basic constraint extension and are marked as CA certs are not what prompted this discussion. Hence my comment that they are not the focus of the next text. >. > >With X.509v1, CA and non-CA certs can only be distinguished by meta-knowledge. v1 certs were superceded by v3 certs, so v1 certs are definitely not relevant to this discussion. Steve From anders.rundgren@telia.com Wed Apr 11 04:38:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8D811E80AD for ; Wed, 11 Apr 2012 04:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kFmaqmC9lFx for ; Wed, 11 Apr 2012 04:38:41 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id D938611E808F for ; Wed, 11 Apr 2012 04:38:40 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E00B59A76 for pkix@ietf.org; Wed, 11 Apr 2012 13:38:39 +0200 Message-ID: <4F856D3A.1060103@telia.com> Date: Wed, 11 Apr 2012 13:38:34 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "pkix@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 11:38:45 -0000 Dear All, It seems that there's no end to the amount of time and energy available for addressing various short-comings of the SSL PKI. This is of course very good. What's a little bit less understandable is why the interest in making client-side PKI more useful is close to zero. It is true that there isn't any money to make on the software and protocols. However, the availability of usable PKI clients will pay itself through indirect means (more CAs, more services and less security breaches). >From a security point of view it is important to realize that even if the SSL PKI or DNS get corrupted, a client-PKI-based login to "badbank.com" won't give "badbank.com" any access to "goodbank.com". Using static passwords (the current "standard"), all bets are off, not to mention how well shared passwords work... The current PKI enrollment solutions (maybe with Apple's iPhone scheme as a notable exception) are close to useless for consumers. The SSL credential selection GUIs are also based on ideas that only PKI geeks can possibly appreciate. Many service providers feel it would be downright embarrassing offering such a clunky interface to their users. The majority of issuers of consumer-PKI have therefore developed their own client-side PKI software which address things like GUI, PINs, X-platform, etc. IMHO, fixing a little bit here and there in a completely uncoordinated fashion will never return an interoperable and useful foundation for consumer-PKI. Comments? Anders From tmiller@mitre.org Wed Apr 11 05:42:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DD321F8597 for ; Wed, 11 Apr 2012 05:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.271 X-Spam-Level: X-Spam-Status: No, score=-6.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKA9KBTNSRQs for ; Wed, 11 Apr 2012 05:42:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A586321F8598 for ; Wed, 11 Apr 2012 05:42:23 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 810BD21B0B88; Wed, 11 Apr 2012 08:42:20 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6E45321B00BB; Wed, 11 Apr 2012 08:42:20 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.227]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0283.003; Wed, 11 Apr 2012 08:42:20 -0400 From: "Miller, Timothy J." To: Yoav Nir Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: AQHNEPPvquDEc5XKr0iEIGU8AH05gZaICg8AgAUfg4CAABWQgIAAA7CAgACzvICAAA6cAIAABD0AgAASSACAACJKAIAA9dKAgAATYgCAAMPIgIAAAneAgAAUuACAADc3gIACqGEAgAAml4CAABAPgIAAEPkAgAAwbICAAOSUgIAADYQAgAAGSQCAAFcRgIAAxS8A Date: Wed, 11 Apr 2012 12:42:19 +0000 Message-ID: In-Reply-To: <6867F7B7-0D96-4A4F-A9DD-1713864CF8AA@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.31.51.95] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 12:42:25 -0000 On 4/10/12 2:56 PM, "Yoav Nir" wrote: >What prevents them from doing it now, is that not having a NC extension >will allow us to do both of these things, while adding a critical one >will cause iOS clients to fail. We keep coming back to "Beat up on via your support agreements." -- T From tgindin@us.ibm.com Wed Apr 11 06:50:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4C11E8167 for ; Wed, 11 Apr 2012 06:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-96SLFNN7N2 for ; Wed, 11 Apr 2012 06:50:35 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id A622811E8160 for ; Wed, 11 Apr 2012 06:50:35 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 11 Apr 2012 09:50:34 -0400 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 11 Apr 2012 09:49:33 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 579526E806F for ; Wed, 11 Apr 2012 09:49:32 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3BDnWfV316538 for ; Wed, 11 Apr 2012 09:49:32 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3BDnRBa002278 for ; Wed, 11 Apr 2012 09:49:31 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3BDnFb2001123; Wed, 11 Apr 2012 09:49:16 -0400 In-Reply-To: References: To: "Miller, Timothy J." MIME-Version: 1.0 X-KeepSent: 62AE9AC5:1100FE07-852579DD:00027ACB; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Wed, 11 Apr 2012 09:49:15 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/11/2012 09:49:15, Serialize complete at 04/11/2012 09:49:15 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12041113-9360-0000-0000-000005527BDE Cc: IETF PKIX Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:50:37 -0000 I don't expect root certificates, or the sort of intermediates that Entrust or Verisign create for brands, to contain any PermittedSubtree name constraints with the possible exception of Country. I would like to see commercial CA's issue intermediates to other organizations with name constraints for that organization. Tom Gindin From: "Miller, Timothy J." To: Tom Gindin/Watson/IBM@IBMUS, Santosh Chokhani , Cc: IETF PKIX Date: 04/10/2012 03:46 PM Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name So what NC would a commercial CA vendor assert, given that most public CAs do not use namespace-specific Issuers? (IOW, Verisign issues to any DNS name. Is Verisign champing at the bit to create a *.edu Issuer? What prevents them from doing so now?) -- T On 4/10/12 9:22 AM, "Tom Gindin" wrote: > Santosh: > > Under the defined syntax, CA's have three choices for >intermediate >certificates in this area. In ascending order of security, they are "no >constraints", "non-critical constraints", "critical constraints". It >appears to me that the effect of banning the middle option has been, at >least in the commercial world, to drive most CA's to the less secure >option rather than to the more secure one. > Do you have evidence that many commercial CA's are using critical >name constraints except under government influence? I don't, but others >may have had better experiences. > >Tom Gindin > > > > >From: Santosh Chokhani >To: "Manger, James H" , IETF PKIX >, >Date: 04/10/2012 09:36 AM >Subject: Re: [pkix] Proposal: Change the Criticality Requirement >of >Name >Sent by: pkix-bounces@ietf.org > > > >James, > >It is hard to determine what would motivate a given vendor. You may very >well be right. But, the way to achieve this is for the CAs to determine >how to bring the "certificate consuming" software vendors in compliance. >The standard should preserve security. > >CA vendors can give grace period or browser vendors can use existing or >new UI to let the human use decide if they want to override the browser >decision until browsers have the capability to process the extension. > >-----Original Message----- >From: Manger, James H [mailto:James.H.Manger@team.telstra.com] >Sent: Monday, April 09, 2012 7:56 PM >To: Santosh Chokhani; IETF PKIX >Subject: RE: [pkix] Proposal: Change the Criticality Requirement of Name > >Santosh, > >> If the standard said this extension can be NC (non-critical), folks >> would be happy to produce certificates with NC and some browsers will >> not implement name constraints processing. >> >> It is important that we get where the RP enforce the CA defined >> constraints and making security critical extensions NC in a security >> standard is not the way to get their attention. >> It is a way to tell folks that this is not important for security. > >At the moment, there is little incentive for an implementation (such as >Safari) to implement name constraints as there are almost no certificates >using them. A browser is equally secure with or without support. > >If name constraints can be non-critical, certificates using them can >appear far more easily and there will be an explicit security difference >between browsers that do or do not implement those constraints. That will >provide a tangible incentive for software (such as Safari) to implement >name constraints. Otherwise it doesn't protect its users from a threat >that other browsers do, which will look very bad if (or when) the threat >becomes an attack. > >I am in favour of removing the PKIX requirement that name constraints be >marked critical. > >-- >James Manger >_______________________________________________ >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 paul.hoffman@vpnc.org Wed Apr 11 10:28:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5B411E808D for ; Wed, 11 Apr 2012 10:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3+AU8inT39i for ; Wed, 11 Apr 2012 10:28:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AA11C11E8089 for ; Wed, 11 Apr 2012 10:28:20 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3BHSGSM037665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 11 Apr 2012 10:28:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Apr 2012 10:28:16 -0700 Message-Id: To: IETF PKIX Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and name/policy constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:28:21 -0000 This proposal is an alternative to the people who want the "MUST mark as = critical" to be a "SHOULD". So far, those proposals have not given CAs = enough guidance about when the "SHOULD" is and is not important. = Instead, we can look at this as clarification of what the current "MUST" = means. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D In describing the Name Constraints and Policy Contraints extensions, RFC = 5280 says: Conforming CAs MUST mark this extension as critical In these cases, the "MUST" language from RFC 2119 is based on a = potential for causing harm, not the need for interoperability. This = interpretation can be seen by looking in Section 6.1 of RFC 5280, which = says: While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. The Name Constraints and Policy Contraints extensions do not need to be = marked critical if a relying party has no restrictions on the names or = policies of end entity certificates issued under a particular trust = anchor. For example, if such a trust anchor issues a CA certificate with = the Name Constraints extension that limits that CA's ability to issue = certificates, and if the Name Constraints extension in that CA's = certificate is not marked critical, and if the CA issues an end entity = certificate whose name is outside the set of ones it is allowed to issue = for, and if the relying party does not understand the Name Constraints = extension, the relying party is no worse off because it would have = accepted that end entity certificate issued directly by the trust = anchor. Given this rationale, the statement "Conforming CAs MUST mark this = extension as critical" is interpreted as "Conforming CAs MUST mark this = extension as critical when there is a potential for harm in relying = parties that do not understand the extension", not universally. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Thoughts? --Paul Hoffman= From jmdesp@free.fr Wed Apr 11 11:10:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BD811E80C2 for ; Wed, 11 Apr 2012 11:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqLPyBLqVipe for ; Wed, 11 Apr 2012 11:10:42 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by ietfa.amsl.com (Postfix) with ESMTP id 4417811E8098 for ; Wed, 11 Apr 2012 11:10:40 -0700 (PDT) Received: from [172.30.24.38] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) (Authenticated sender: jmdesp) by smtp4-g21.free.fr (Postfix) with ESMTPA id 0D2E54C81A7; Wed, 11 Apr 2012 20:10:33 +0200 (CEST) Message-ID: <4F85C917.9010108@free.fr> Date: Wed, 11 Apr 2012 20:10:31 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120307 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: Erwann Abalea , "pkix@ietf.org" References: <201204021713.q32HDZBe022605@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 18:10:43 -0000 Erwann Abalea a écrit : > For example the deltaCRLIndicator extension, which also MUST be set > critical. You probably know why it is dangerous for a RP to receive a > CRL with such an extension non critical. Following your logic, the CA > defines what is secure and what isn't, so this extension could be set > non critical. Is that right? > [...] > Can your argumentation be applied to every extension defined in the > recommendation and the PKIX profiles? The basis of his argumentation is indeed that all extensions aren't created equal, and "name constraint" and "deltaCRLIndicator" are a perfect example of that. With deltaCRLIndicator, a proper deltaCRL issued by the CA *can* be used to abuse a client that doesn't properly handle it. Because the deltaCRL won't contain all revoked certificate so any client that accept it must absolutely take under account the fact it's a delta CRL to handle it properly. With name constraints, a certificate properly issued by the CA *can't* be used to abuse a client that doesn't properly handle it. An uncompromised CA will only issue certificates that respect the applicable name constraints, so the name constraint is there only as a double-check, and is not a basic requirement without which the certificate simply couldn't be properly used. Still, a rogue CA that issues a cert with a bad name will have to handle the fact most client will properly reject that certificate, which will certainly very fast rise an alert against that CA. From jmdesp@free.fr Wed Apr 11 11:33:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A13911E80BA for ; Wed, 11 Apr 2012 11:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYcbntC2wDhp for ; Wed, 11 Apr 2012 11:33:58 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by ietfa.amsl.com (Postfix) with ESMTP id 68FFE11E80B3 for ; Wed, 11 Apr 2012 11:33:56 -0700 (PDT) Received: from [172.30.24.38] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) (Authenticated sender: jmdesp) by smtp4-g21.free.fr (Postfix) with ESMTPA id 0D3464C80E7; Wed, 11 Apr 2012 20:33:50 +0200 (CEST) Message-ID: <4F85CE8C.2010302@free.fr> Date: Wed, 11 Apr 2012 20:33:48 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120307 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: mrex@sap.com, "pkix@ietf.org" References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> In-Reply-To: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 18:33:59 -0000 Martin Rex a écrit : > A subCA cert with name constraints that is > marked non-critical SHOULD be accepted by RPs per rfc-5280. My understanding is that this ought more be "MUST be accepted" and not SHOULD : 4.2. Certificate Extensions [...] A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. [...] I understand some people may defend this does not explicitly say what you MUST/SHOULD do with a non-critical extension that you expect to be critical but isn't, and that whilst the Certification Path Validation in 6 ignores the critically of extension, you are allowed to complement it with further verification. By the way, there is an incorrect text in 4.2.1.10 : [...] If a name constraints extension that is marked as critical imposes constraints on a particular name form, and an instance of that name form appears in the subject field or subjectAltName extension of a subsequent certificate, then the application MUST either process the constraint or reject the certificate. [...] if an application encounters a critical name constraints extension that specifies other values for minimum or maximum for a name form that appears in a subsequent certificate, the application MUST either process these fields or reject the certificate. This, twice, can be interpreted as meaning the extension could be ignored if not marked critical. This of course directly contradicts 4.2. From ynir@checkpoint.com Wed Apr 11 12:25:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD6511E8098 for ; Wed, 11 Apr 2012 12:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgSs-gaakGHi for ; Wed, 11 Apr 2012 12:25:07 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 62BA711E808D for ; Wed, 11 Apr 2012 12:25:07 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3BJP5De008150; Wed, 11 Apr 2012 22:25:05 +0300 X-CheckPoint: {4F85E7CF-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 11 Apr 2012 22:25:06 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 11 Apr 2012 22:25:02 +0300 From: Yoav Nir To: Paul Hoffman Date: Wed, 11 Apr 2012 22:25:02 +0300 Thread-Topic: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and name/policy constraints Thread-Index: Ac0YGMu8IGuR7B5eS3+mFv4aPggE0Q== Message-ID: <35C4242E-C528-4DD2-AC0F-131DB8A45079@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 110b55fe387b9dae213daefbb33686589eeded5d8a Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IETF PKIX Subject: Re: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and name/policy constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:25:08 -0000 I think MUST means MUST. The thing that means "MUST unless it's safe not to= do it" is called SHOULD. At least that is my understanding of RFC 2119. A CA that issues a sub-CA certificate with non-critical name constraints do= es not conform to RFC 5280. That may not be a bad thing, but I don't think = we can clarify that fact away. On Apr 11, 2012, at 8:28 PM, Paul Hoffman wrote: > This proposal is an alternative to the people who want the "MUST mark as = critical" to be a "SHOULD". So far, those proposals have not given CAs enou= gh guidance about when the "SHOULD" is and is not important. Instead, we ca= n look at this as clarification of what the current "MUST" means. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > In describing the Name Constraints and Policy Contraints extensions, RFC = 5280 says: > Conforming CAs MUST mark this extension as > critical > In these cases, the "MUST" language from RFC 2119 is based on a potential= for causing harm, not the need for interoperability. This interpretation c= an be seen by looking in Section 6.1 of RFC 5280, which says: > While the algorithm could be extended to include checks for > conformance to the profiles in Sections 4 and 5, this profile > RECOMMENDS against including such checks. >=20 > The Name Constraints and Policy Contraints extensions do not need to be m= arked critical if a relying party has no restrictions on the names or polic= ies of end entity certificates issued under a particular trust anchor. For = example, if such a trust anchor issues a CA certificate with the Name Const= raints extension that limits that CA's ability to issue certificates, and i= f the Name Constraints extension in that CA's certificate is not marked cri= tical, and if the CA issues an end entity certificate whose name is outside= the set of ones it is allowed to issue for, and if the relying party does = not understand the Name Constraints extension, the relying party is no wors= e off because it would have accepted that end entity certificate issued dir= ectly by the trust anchor. >=20 > Given this rationale, the statement "Conforming CAs MUST mark this extens= ion as critical" is interpreted as "Conforming CAs MUST mark this extension= as critical when there is a potential for harm in relying parties that do = not understand the extension", not universally. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Thoughts? >=20 > --Paul Hoffman > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 > Scanned by Check Point Total Security Gateway. From swilson@lockstep.com.au Wed Apr 11 13:01:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC3721F84D0 for ; Wed, 11 Apr 2012 13:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEMqyubFvPhd for ; Wed, 11 Apr 2012 13:01:25 -0700 (PDT) Received: from smtp162.iad.emailsrvr.com (smtp162.iad.emailsrvr.com [207.97.245.162]) by ietfa.amsl.com (Postfix) with ESMTP id 44AA621F84CF for ; Wed, 11 Apr 2012 13:01:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp56.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 929D43D8495 for ; Wed, 11 Apr 2012 16:01:24 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp56.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id CFA203D8478 for ; Wed, 11 Apr 2012 16:01:23 -0400 (EDT) Message-ID: <4F85E303.3090700@lockstep.com.au> Date: Thu, 12 Apr 2012 06:01:07 +1000 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "pkix@ietf.org" References: <4F856D3A.1060103@telia.com> In-Reply-To: <4F856D3A.1060103@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 20:01:29 -0000 My comment is that client side certificate management needs fixing as much as client side car maintenance. Why do it? PKI is the classic case of a technology that appalls in the rough but is indispensible when embedded. My list of successful client side PKI deployment includes EMV DDA chip cards, the health cards of Austria, Taiwan, Thailand, Malaysia, France and others, the Estonia government services card, CAC, PIV and Skype. See http://lockstep.com.au/blog/2011/01/16/embedded-pki-on-the-cards.html General purpose, naked, personal digital certificates are of historical interest only! PKI should not be about creating a vertically integrated identity certificate management process. It should be about taking existing relationships and instantiating them in special purpose digital certificates congruent with those relationships. See http://lockstep.com.au/library/pki/relationship_certificates.html Cheers, Steve Wilson Lockstep http://lockstep.com.au/library/pki On 11/04/2012 9:38 PM, Anders Rundgren wrote: > Dear All, > > It seems that there's no end to the amount of time and energy available for > addressing various short-comings of the SSL PKI. This is of course very good. > > What's a little bit less understandable is why the interest in making client-side PKI > more useful is close to zero. It is true that there isn't any money to make on the > software and protocols. However, the availability of usable PKI clients will pay itself > through indirect means (more CAs, more services and less security breaches). > > > From a security point of view it is important to realize that even if the SSL PKI or DNS > get corrupted, a client-PKI-based login to "badbank.com" won't give "badbank.com" > any access to "goodbank.com". Using static passwords (the current "standard"), > all bets are off, not to mention how well shared passwords work... > > The current PKI enrollment solutions (maybe with Apple's iPhone scheme as a > notable exception) are close to useless for consumers. > > The SSL credential selection GUIs are also based on ideas that only PKI geeks > can possibly appreciate. Many service providers feel it would be downright > embarrassing offering such a clunky interface to their users. > > The majority of issuers of consumer-PKI have therefore developed their own > client-side PKI software which address things like GUI, PINs, X-platform, etc. > > IMHO, fixing a little bit here and there in a completely uncoordinated fashion > will never return an interoperable and useful foundation for consumer-PKI. > > Comments? > > Anders > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > From ron.ogle@technicolor.com Wed Apr 11 13:15:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77EF21F850B for ; Wed, 11 Apr 2012 13:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLbZCri9Xydx for ; Wed, 11 Apr 2012 13:15:48 -0700 (PDT) Received: from psmtp.com (na3sys009aog137.obsmtp.com [74.125.149.18]) by ietfa.amsl.com (Postfix) with ESMTP id D932421F8507 for ; Wed, 11 Apr 2012 13:15:46 -0700 (PDT) Received: from INDYSEDGE01.am.thmulti.com ([157.254.234.137]) (using TLSv1) by na3sys009aob137.postini.com ([74.125.148.12]) with SMTP ID DSNKT4XmcUNT9+FC/UMDe65BzIPzaQ4MsJk1@postini.com; Wed, 11 Apr 2012 13:15:47 PDT Received: from INDYSMAILHT01.am.thmulti.com (157.254.98.93) by INDYSEDGE01.am.thmulti.com (157.254.234.136) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 11 Apr 2012 16:13:20 -0400 Received: from INDYSMAILMB04.am.thmulti.com ([169.254.2.79]) by INDYSMAILHT01.am.thmulti.com ([157.254.98.93]) with mapi; Wed, 11 Apr 2012 16:13:22 -0400 From: Ogle Ron To: "swilson@lockstep.com.au" , "pkix@ietf.org" Date: Wed, 11 Apr 2012 16:13:21 -0400 Thread-Topic: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI Thread-Index: Ac0YH4spBWP+gQHDQaG1o4bi8NgXWA== Message-ID: In-Reply-To: <4F85E303.3090700@lockstep.com.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 20:15:48 -0000 I agree. Anyone using a Cable Modem and many DSL services are using a PKI implementation today in the background. I know that we are heavily relying upon PKI for our consumer electronics products that are being produced today. Of course, you won't see our CA certs in any browser or OS implementations. I'd say that there are more certs created and installed in embedded systems than in use for any other reason. We don't need or want Name Constraints to be marked critical to provide security in our PKI. Ron Ogle On 4/11/12 16:01 , "Stephen Wilson" wrote: > >My comment is that client side certificate management needs fixing as >much as client side car maintenance. Why do it? > >PKI is the classic case of a technology that appalls in the rough but is >indispensible when embedded. My list of successful client side PKI >deployment includes EMV DDA chip cards, the health cards of Austria, >Taiwan, Thailand, Malaysia, France and others, the Estonia government >services card, CAC, PIV and Skype. > >See http://lockstep.com.au/blog/2011/01/16/embedded-pki-on-the-cards.html > >General purpose, naked, personal digital certificates are of historical >interest only! PKI should not be about creating a vertically integrated >identity certificate management process. It should be about taking >existing relationships and instantiating them in special purpose digital >certificates congruent with those relationships. > >See http://lockstep.com.au/library/pki/relationship_certificates.html > >Cheers, > >Steve Wilson >Lockstep >http://lockstep.com.au/library/pki From david.cooper@nist.gov Wed Apr 11 13:52:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38DC11E80B8 for ; Wed, 11 Apr 2012 13:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2VIB85UFP3b for ; Wed, 11 Apr 2012 13:52:52 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id E851D11E8075 for ; Wed, 11 Apr 2012 13:52:48 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q3BKqa4j029343; Wed, 11 Apr 2012 16:52:36 -0400 Message-ID: <4F85EF14.8050302@nist.gov> Date: Wed, 11 Apr 2012 16:52:36 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: Jean-Marc Desperrier References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> <4F85CE8C.2010302@free.fr> In-Reply-To: <4F85CE8C.2010302@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 20:52:52 -0000 On 04/11/2012 02:10 PM, Jean-Marc Desperrier wrote: > An uncompromised CA will only issue certificates that respect the > applicable name constraints, so the name constraint is there only as a > double-check, and is not a basic requirement without which the > certificate simply couldn't be properly used. As I noted previously (http://www.ietf.org/mail-archive/web/pkix/current/msg30778.html) this is not true. Not all PKIs are hierarchies. In some cases a nameConstraints extension is simply intended to restrict the set of certificates accepted by the issuer's relying parties, and it is does not represent a restriction on the set of certificates that the subject CA may legitimately issue. On 04/11/2012 02:33 PM, Jean-Marc Desperrier wrote: > By the way, there is an incorrect text in 4.2.1.10 : > [...] If a name constraints extension that is marked as critical > imposes constraints on a particular name form, and an instance of > that name form appears in the subject field or subjectAltName > extension of a subsequent certificate, then the application MUST > either process the constraint or reject the certificate. > [...] if an application encounters a critical name > constraints extension that specifies other values for minimum or > maximum for a name form that appears in a subsequent certificate, the > application MUST either process these fields or reject the > certificate. > > This, twice, can be interpreted as meaning the extension could be > ignored if not marked critical. This of course directly contradicts 4.2. This text is not incorrect. It is merely silent on how to process a nameConstraints extension is not marked as critical. This was intentional, since (for some reason) we were unable to come to consensus on the proper behavior of a client encountering a non-critical nameConstraints extension where the client was capable of processing some of the name forms in the extension, but not all of them. From paul.hoffman@vpnc.org Wed Apr 11 14:26:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C2A21F84C9 for ; Wed, 11 Apr 2012 14:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7QCVO5S8gRK for ; Wed, 11 Apr 2012 14:26:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 28B0721F848F for ; Wed, 11 Apr 2012 14:26:06 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3BLPtBh044593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Apr 2012 14:25:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <35C4242E-C528-4DD2-AC0F-131DB8A45079@checkpoint.com> Date: Wed, 11 Apr 2012 14:25:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8BBB1F7D-CB0D-44C6-8817-43DFE590650B@vpnc.org> References: <35C4242E-C528-4DD2-AC0F-131DB8A45079@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1257) Cc: IETF PKIX Subject: Re: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and name/policy constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 21:26:06 -0000 On Apr 11, 2012, at 12:25 PM, Yoav Nir wrote: > I think MUST means MUST. The thing that means "MUST unless it's safe = not to do it" is called SHOULD. At least that is my understanding of RFC = 2119. Direct quote from RFC 2119: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. > A CA that issues a sub-CA certificate with non-critical name = constraints does not conform to RFC 5280. One purpose of draft-ietf-pkix-rfc5280-clarifications it to clarify RFC = 5280; my proposal is for such a clarification, given the confusion. --Paul Hoffman From stephen.farrell@cs.tcd.ie Wed Apr 11 15:47:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAE121F8475 for ; Wed, 11 Apr 2012 15:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE5HYTmBdaLb for ; Wed, 11 Apr 2012 15:47:15 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7D721F8474 for ; Wed, 11 Apr 2012 15:47:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E752517147D; Wed, 11 Apr 2012 23:47:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1334184430; bh=iOAGjOU+1sOSYD LzYBzR09SHUK+8eeKG/qYevhSrtSo=; b=smW1SPgD34tbLnuAj2q1Izt6adz04d 9O6j9j7j6rdNVD5PZ8IHhe1nQaOoUmYXBLeZfKUV08vLzKFu+DgSyCixaSl9cbI6 5/r/joT7QUJD1nGDow13rYkRd3dUppmKub6RpH2PuPBvfCMOS8apFLE6hXXrGcP9 Rb5ykn6Q0N1rCeTLwnzD3Jh863mC1/CcvShtBZM3gxrViARn4Iqa1564vWxcpYp4 aAQKaXWziD2hNglofar3rGnKRBGUnABQduoVC8PGYy+l4IDQRf5qpmaPqMdFQNNl UGfJeu9x5revuCK2BNOgEyjWgAzXtFGqV7nA14FRrqUFSnOJ+g4stNjA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id J-wcPi-lrHwv; Wed, 11 Apr 2012 23:47:10 +0100 (IST) Received: from [10.87.48.3] (unknown [86.44.64.139]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4F78517147B; Wed, 11 Apr 2012 23:47:09 +0100 (IST) Message-ID: <4F8609EC.3010501@cs.tcd.ie> Date: Wed, 11 Apr 2012 23:47:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "David A. Cooper" References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> <4F85CE8C.2010302@free.fr> <4F85EF14.8050302@nist.gov> In-Reply-To: <4F85EF14.8050302@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 22:47:16 -0000 So I like Paul's idea but think David is right that its not quite right as stated. I've no problem with 2119 purity either, so how about taking Paul's approach but naming names (sort of) and saying that NC MUST be critical except in the current public CA/web browser model, where NC SHOULD be critical on the basis that some implementations still need to catch up (with RFC 2459;-) and explain that that's ok because it does improve matters for some and is no worse than the status-quo for those RP's not supporting NC. With a wordsmithed version of the above I'd find that ok. Personally, I think that might be better as a separate document updating 5280 and not necessarily from the PKIX WG, so's we can obsolete that without side-effect once NC is supported widely enough, but I won't quibble about where it gets documented. The point that 5280's assertion that NC MUST be critical is a harm-reduction measure and not for interop was well-made too btw. S. On 04/11/2012 09:52 PM, David A. Cooper wrote: > On 04/11/2012 02:10 PM, Jean-Marc Desperrier wrote: >> An uncompromised CA will only issue certificates that respect the >> applicable name constraints, so the name constraint is there only as a >> double-check, and is not a basic requirement without which the >> certificate simply couldn't be properly used. > > As I noted previously > (http://www.ietf.org/mail-archive/web/pkix/current/msg30778.html) this > is not true. Not all PKIs are hierarchies. In some cases a > nameConstraints extension is simply intended to restrict the set of > certificates accepted by the issuer's relying parties, and it is does > not represent a restriction on the set of certificates that the subject > CA may legitimately issue. > > > On 04/11/2012 02:33 PM, Jean-Marc Desperrier wrote: >> By the way, there is an incorrect text in 4.2.1.10 : >> [...] If a name constraints extension that is marked as critical >> imposes constraints on a particular name form, and an instance of >> that name form appears in the subject field or subjectAltName >> extension of a subsequent certificate, then the application MUST >> either process the constraint or reject the certificate. >> [...] if an application encounters a critical name >> constraints extension that specifies other values for minimum or >> maximum for a name form that appears in a subsequent certificate, the >> application MUST either process these fields or reject the >> certificate. >> >> This, twice, can be interpreted as meaning the extension could be >> ignored if not marked critical. This of course directly contradicts 4.2. > > This text is not incorrect. It is merely silent on how to process a > nameConstraints extension is not marked as critical. This was > intentional, since (for some reason) we were unable to come to consensus > on the proper behavior of a client encountering a non-critical > nameConstraints extension where the client was capable of processing > some of the name forms in the extension, but not all of them. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From stefan@aaa-sec.com Wed Apr 11 16:10:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A18B11E80EA for ; Wed, 11 Apr 2012 16:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKMW367tkZAv for ; Wed, 11 Apr 2012 16:10:04 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.110]) by ietfa.amsl.com (Postfix) with ESMTP id 6A05D11E80D9 for ; Wed, 11 Apr 2012 16:09:59 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id CC3BE1E2A754 for ; Thu, 12 Apr 2012 01:09:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9ZSKHKGuP4Pp for ; Thu, 12 Apr 2012 01:09:57 +0200 (CEST) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 796231E2B9C3 for ; Thu, 12 Apr 2012 01:09:57 +0200 (CEST) Received: (qmail 83331 invoked from network); 11 Apr 2012 23:09:57 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.2]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Apr 2012 23:09:57 -0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 12 Apr 2012 01:09:53 +0200 From: Stefan Santesson To: Paul Hoffman , IETF PKIX Message-ID: Thread-Topic: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and name/policy constraints In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and name/policy constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 23:10:05 -0000 Interesting idea Paul, I think this text might be a bit confusing though. Isn't what you intend to say the following: In cases where the CA need to enforce that relying parties rejects certificates issued outside of a set NC, the CA MUST mark this extension as critical. In cases where the CA need to declare a limited name space without enforcing any particular behavior on non-conformant relaying parties that do not implement the NC extension, the CA MAY mark this extension as non-critical. /Stefan On 12-04-11 7:28 PM, "Paul Hoffman" wrote: >This proposal is an alternative to the people who want the "MUST mark as >critical" to be a "SHOULD". So far, those proposals have not given CAs >enough guidance about when the "SHOULD" is and is not important. Instead, >we can look at this as clarification of what the current "MUST" means. > >=========================== > >In describing the Name Constraints and Policy Contraints extensions, RFC >5280 says: > Conforming CAs MUST mark this extension as > critical >In these cases, the "MUST" language from RFC 2119 is based on a potential >for causing harm, not the need for interoperability. This interpretation >can be seen by looking in Section 6.1 of RFC 5280, which says: > While the algorithm could be extended to include checks for > conformance to the profiles in Sections 4 and 5, this profile > RECOMMENDS against including such checks. > >The Name Constraints and Policy Contraints extensions do not need to be >marked critical if a relying party has no restrictions on the names or >policies of end entity certificates issued under a particular trust >anchor. For example, if such a trust anchor issues a CA certificate with >the Name Constraints extension that limits that CA's ability to issue >certificates, and if the Name Constraints extension in that CA's >certificate is not marked critical, and if the CA issues an end entity >certificate whose name is outside the set of ones it is allowed to issue >for, and if the relying party does not understand the Name Constraints >extension, the relying party is no worse off because it would have >accepted that end entity certificate issued directly by the trust anchor. > >Given this rationale, the statement "Conforming CAs MUST mark this >extension as critical" is interpreted as "Conforming CAs MUST mark this >extension as critical when there is a potential for harm in relying >parties that do not understand the extension", not universally. > >=========================== > >Thoughts? > >--Paul Hoffman >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From paul.hoffman@vpnc.org Wed Apr 11 16:34:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525A611E809D for ; Wed, 11 Apr 2012 16:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8ezwun8io7o for ; Wed, 11 Apr 2012 16:34:07 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BD24921F84B4 for ; Wed, 11 Apr 2012 16:34:07 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3BNY1pP048190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Apr 2012 16:34:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Wed, 11 Apr 2012 16:34:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4B7FDE14-5E2E-45B8-AD50-4ACD24557338@vpnc.org> References: To: Stefan Santesson X-Mailer: Apple Mail (2.1257) Cc: IETF PKIX Subject: Re: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and name/policy constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 23:34:08 -0000 On Apr 11, 2012, at 4:09 PM, Stefan Santesson wrote: > I think this text might be a bit confusing though. Could be; RFC 2119 "MUST" can mean one of three things, and we are using = the least common one here. > Isn't what you intend to say the following: >=20 > In cases where the CA need to enforce that relying parties rejects > certificates issued outside of a set NC, the CA MUST mark this = extension > as critical. No, not at all. A CA never needs to enforce anything on an RP. A CA = might want to reduce its liability by constraining CAs under it, and if = that CA believes that some RPs only trust the CA for some names or = policies, the CA needs to alert the RP that sub-CAs have more = constraints. That's probably not less confusing. :-) > In cases where the CA need to declare a limited name space without > enforcing any particular behavior on non-conformant relaying parties = that > do not implement the NC extension, the CA MAY mark this extension as > non-critical. The CA MAY do whatever it wants for marking anyway, given that we say = that RPs SHOULD NOT check conformance. So I don't think we need to = change the rule, only clarify it. --Paul Hoffman From mrex@sap.com Wed Apr 11 16:37:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C46A21F84BD for ; Wed, 11 Apr 2012 16:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.07 X-Spam-Level: X-Spam-Status: No, score=-10.07 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CWToT4Zqp4S for ; Wed, 11 Apr 2012 16:37:08 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB1621F84B9 for ; Wed, 11 Apr 2012 16:37:07 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3BNaxNF024980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Apr 2012 01:36:59 +0200 (MEST) From: Martin Rex Message-Id: <201204112336.q3BNax3N001149@fs4113.wdf.sap.corp> To: stefan@aaa-sec.com (Stefan Santesson) Date: Thu, 12 Apr 2012 01:36:59 +0200 (MEST) In-Reply-To: from "Stefan Santesson" at Apr 12, 12 01:09:53 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org, paul.hoffman@vpnc.org Subject: Re: [pkix] Proposed addition to X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 23:37:09 -0000 Stefan Santesson wrote: > > Interesting idea Paul, > > I think this text might be a bit confusing though. > > Isn't what you intend to say the following: > > In cases where the CA need to enforce that relying parties rejects > certificates issued outside of a set NC, the CA MUST mark this extension > as critical. > > In cases where the CA need to declare a limited name space without > enforcing any particular behavior on non-conformant relaying parties that > do not implement the NC extension, the CA MAY mark this extension as > non-critical. As I previously said, not implementing NC for SubjectAltNames is 100% rfc5280 conformant. It is called "minimal requirements RP". Most Non-conforming RPs will simply ignore critical NC constraints. The "MAY mark this extension as non-critical" is only to take care of rfc5280-conforming "minimal requirements RPs", which do not implement the optional NC processing of SubjectAltNames, and reject the cert due to NC being marked critical, in full conformance with rfc5280 -Martin From kent@bbn.com Wed Apr 11 19:04:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABED611E8127 for ; Wed, 11 Apr 2012 19:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.51 X-Spam-Level: X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 902yFpK34rTV for ; Wed, 11 Apr 2012 19:04:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 370F611E811E for ; Wed, 11 Apr 2012 19:04:25 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37796 helo=[10.5.32.50]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SI9OJ-0009SG-AM for pkix@ietf.org; Wed, 11 Apr 2012 22:04:07 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 11 Apr 2012 22:03:05 -0400 To: pkix@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [pkix] 2875bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 02:04:26 -0000 Folks, As noted in the PKIX meeting minutes from Paris, Jim Schaad has updated RFC 2875 in support of alg agility, with a focus on parameterizing use of hash algs. 2875 is a PKIX RFC, so it makes sense for this update to be a WG doc. As noted in the meeting minutes, Sean has offered to sponsor the doc if PKIX choose to not adopt it. Please comment on the list if you want PKIX to adopt the doc. The default will be that Sean will deal with it directly. This call for adoption will end in two weeks, on 4/25. Steve From ynir@checkpoint.com Wed Apr 11 21:36:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F8D21F84B8 for ; Wed, 11 Apr 2012 21:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.57 X-Spam-Level: X-Spam-Status: No, score=-10.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az2BpmPHi-bP for ; Wed, 11 Apr 2012 21:36:54 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 74E5A21F84B5 for ; Wed, 11 Apr 2012 21:36:53 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3C4aptd032590; Thu, 12 Apr 2012 07:36:51 +0300 X-CheckPoint: {4F86691B-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 12 Apr 2012 07:36:51 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 12 Apr 2012 07:36:47 +0300 From: Yoav Nir To: Paul Hoffman Date: Thu, 12 Apr 2012 07:36:49 +0300 Thread-Topic: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and name/policy constraints Thread-Index: Ac0YZd7Ke8il1LtsQZK7UreKQdG53Q== Message-ID: References: <35C4242E-C528-4DD2-AC0F-131DB8A45079@checkpoint.com> <8BBB1F7D-CB0D-44C6-8817-43DFE590650B@vpnc.org> In-Reply-To: <8BBB1F7D-CB0D-44C6-8817-43DFE590650B@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 115635a6be7ff86a14783076bee2696b624a08dbed Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IETF PKIX Subject: Re: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and name/policy constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 04:36:54 -0000 On Apr 12, 2012, at 12:25 AM, Paul Hoffman wrote: > On Apr 11, 2012, at 12:25 PM, Yoav Nir wrote: >=20 >> I think MUST means MUST. The thing that means "MUST unless it's safe not= to do it" is called SHOULD. At least that is my understanding of RFC 2119. >=20 > Direct quote from RFC 2119: >=20 > 6. Guidance in the use of these Imperatives >=20 > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. That's guidance. I think the authors of RFC 5280 and its predecessors did n= ot follow that guidance, but that's because I don't think a non-critical na= me constraints (NCNC?) causes harm. Once it's there, MUST still means MUST. >=20 >> A CA that issues a sub-CA certificate with non-critical name constraints= does not conform to RFC 5280. >=20 > One purpose of draft-ietf-pkix-rfc5280-clarifications it to clarify RFC 5= 280; my proposal is for such a clarification, given the confusion. The confusion is about what RFC 5280 should say, not about what it does say= . Yoav= From ynir@checkpoint.com Wed Apr 11 21:41:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E3111E80CF for ; Wed, 11 Apr 2012 21:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxJa9AmrrCn7 for ; Wed, 11 Apr 2012 21:41:03 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E15C211E80CB for ; Wed, 11 Apr 2012 21:41:02 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3C4ew8o000590; Thu, 12 Apr 2012 07:40:58 +0300 X-CheckPoint: {4F866A13-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 12 Apr 2012 07:40:58 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 12 Apr 2012 07:40:56 +0300 From: Yoav Nir To: Stephen Farrell Date: Thu, 12 Apr 2012 07:40:58 +0300 Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0YZnN8FgNFzRecRkSjTFSOhjs3Xw== Message-ID: <7B0CAB6F-665E-4ACC-824D-6CD79983DD0E@checkpoint.com> References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> <4F85CE8C.2010302@free.fr> <4F85EF14.8050302@nist.gov> <4F8609EC.3010501@cs.tcd.ie> In-Reply-To: <4F8609EC.3010501@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11a88e0e6b52c50d1a5864b41c4bf2fbac36c3ac93 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "pkix@ietf.org" Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 04:41:04 -0000 On Apr 12, 2012, at 1:47 AM, Stephen Farrell wrote: >=20 > So I like Paul's idea but think David is right that its not quite > right as stated. I've no problem with 2119 purity either, so how > about taking Paul's approach but naming names (sort of) and saying > that NC MUST be critical except in the current public CA/web > browser model, where NC SHOULD be critical on the basis that > some implementations still need to catch up (with RFC 2459;-) and > explain that that's ok because it does improve matters for some > and is no worse than the status-quo for those RP's not supporting > NC. As Martin said, implementations don't have to catch up. They can remain wit= hout support for name constraints forever. Besides, if all implementations = do catch up, then criticality ceases to be an issue at all. Any implementat= ion that recognizes the extension MUST process it regardless of criticality= . Yoav= From anders.rundgren@telia.com Wed Apr 11 22:58:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E264521F85C5 for ; Wed, 11 Apr 2012 22:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd8TfOi56HPt for ; Wed, 11 Apr 2012 22:58:33 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id D09F821F85BD for ; Wed, 11 Apr 2012 22:58:32 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB81D00857ED5; Thu, 12 Apr 2012 07:58:31 +0200 Message-ID: <4F866EFF.3020207@telia.com> Date: Thu, 12 Apr 2012 07:58:23 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "pkix@ietf.org" References: <4F856D3A.1060103@telia.com> <4F85E303.3090700@lockstep.com.au> In-Reply-To: <4F85E303.3090700@lockstep.com.au> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 05:58:37 -0000 On 2012-04-11 22:01, Stephen Wilson wrote: > > My comment is that client side certificate management needs fixing as > much as client side car maintenance. Why do it? CONDENSED RATIONALE Currently people login to various services on the Internet; often several times per day. In the majority of cases they use a userid/password combination for login. Quite a bunch of these users (including myself) try to reduce the awkwardness of this system by reusing passwords at different sites. When you pay for stuff on the Internet you typically use non-secure(d) credit-card credentials. PROPOSAL A consumer-oriented on-line enrollment system would IMHO be the single most efficient measure for enabling us to slowly but surely move away from static passwords and payment systems that were designed in another time and for another purpose. If somebody has a better suggestion, I encourage you to present it. -- Anders Rundgren > > PKI is the classic case of a technology that appalls in the rough but is > indispensible when embedded. My list of successful client side PKI > deployment includes EMV DDA chip cards, the health cards of Austria, > Taiwan, Thailand, Malaysia, France and others, the Estonia government > services card, CAC, PIV and Skype. > > See http://lockstep.com.au/blog/2011/01/16/embedded-pki-on-the-cards.html > > General purpose, naked, personal digital certificates are of historical > interest only! PKI should not be about creating a vertically integrated > identity certificate management process. It should be about taking > existing relationships and instantiating them in special purpose digital > certificates congruent with those relationships. > > See http://lockstep.com.au/library/pki/relationship_certificates.html > > Cheers, > > Steve Wilson > Lockstep > http://lockstep.com.au/library/pki > > > > > On 11/04/2012 9:38 PM, Anders Rundgren wrote: >> Dear All, >> >> It seems that there's no end to the amount of time and energy available for >> addressing various short-comings of the SSL PKI. This is of course very good. >> >> What's a little bit less understandable is why the interest in making client-side PKI >> more useful is close to zero. It is true that there isn't any money to make on the >> software and protocols. However, the availability of usable PKI clients will pay itself >> through indirect means (more CAs, more services and less security breaches). >> >>> From a security point of view it is important to realize that even if the SSL PKI or DNS >> get corrupted, a client-PKI-based login to "badbank.com" won't give "badbank.com" >> any access to "goodbank.com". Using static passwords (the current "standard"), >> all bets are off, not to mention how well shared passwords work... >> >> The current PKI enrollment solutions (maybe with Apple's iPhone scheme as a >> notable exception) are close to useless for consumers. >> >> The SSL credential selection GUIs are also based on ideas that only PKI geeks >> can possibly appreciate. Many service providers feel it would be downright >> embarrassing offering such a clunky interface to their users. >> >> The majority of issuers of consumer-PKI have therefore developed their own >> client-side PKI software which address things like GUI, PINs, X-platform, etc. >> >> IMHO, fixing a little bit here and there in a completely uncoordinated fashion >> will never return an interoperable and useful foundation for consumer-PKI. >> >> Comments? >> >> Anders >> >> >> >> >> _______________________________________________ >> 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 jmdesp@free.fr Thu Apr 12 00:08:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A04611E8089 for ; Thu, 12 Apr 2012 00:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG09beAkYCBW for ; Thu, 12 Apr 2012 00:08:17 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by ietfa.amsl.com (Postfix) with ESMTP id A453211E809F for ; Thu, 12 Apr 2012 00:08:14 -0700 (PDT) Received: from [172.30.24.38] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) (Authenticated sender: jmdesp) by smtp4-g21.free.fr (Postfix) with ESMTPA id C58314C80E6; Thu, 12 Apr 2012 09:08:07 +0200 (CEST) Message-ID: <4F867F55.8080809@free.fr> Date: Thu, 12 Apr 2012 09:08:05 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120307 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: Santosh Chokhani , "pkix@ietf.org" References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> <0DFEAD5C-C1DB-48FA-81FA-A523464ABA9C@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 07:08:17 -0000 Santosh Chokhani a écrit : > The RFC does not require you to reject a certificate because name > constraint was marked non critical. However it's quite ambiguous about it, which is a bad idea. If you consider it properly, they are some case where it would actually help to reject any certificate with the non-critical extension, because it would guarantee security problems can immediately be seen. For example, it would be best to reject crl with a non critical "Delta CRL Indicator" because that means one produced by error would be directly identified as invalid, instead of being perfectly usable until it falls into the hand of someone who doesn't implement the extension and where it's a security failure. OTOH treating a certificate containing a non-critical "Name Constraints" as invalid would impair compatibility with no real gain. At the end, the conclusion is : - The difference between the two actually is that "Delta CRL Indicator" has a good reason to be critical and "Name Constraints" doesn't So in a ideal world : - Extension that don't have a really good reason to be critical should be changed to non critical, including "Name Constraints" - Software should reject as invalid certificates containing extension required to be critical that aren't, because there's a real security risk in having issued one and that risk ought to be identified as soon as possible From swilson@lockstep.com.au Thu Apr 12 03:14:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50D121F856C for ; Thu, 12 Apr 2012 03:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvKEMxdb4XBu for ; Thu, 12 Apr 2012 03:13:57 -0700 (PDT) Received: from smtp152.iad.emailsrvr.com (smtp152.iad.emailsrvr.com [207.97.245.152]) by ietfa.amsl.com (Postfix) with ESMTP id B6DA321F8593 for ; Thu, 12 Apr 2012 03:13:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp35.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 472912C81FC for ; Thu, 12 Apr 2012 06:13:57 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp35.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id 82F6F2C823A for ; Thu, 12 Apr 2012 06:13:56 -0400 (EDT) Message-ID: <4F86AADC.10906@lockstep.com.au> Date: Thu, 12 Apr 2012 20:13:48 +1000 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "pkix@ietf.org" References: <4F856D3A.1060103@telia.com> <4F85E303.3090700@lockstep.com.au> <4F866EFF.3020207@telia.com> In-Reply-To: <4F866EFF.3020207@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 10:14:01 -0000 Anders, But that's not any sort of PKI challenge is it? It's even less a PKIX specific issue. Rather you've stated a broad federated identity vision. And on federated identity, I have to say that the dream of a one-size-fits-all identity (or identification/enrolment as you frame it) is impractical. Of late I have been thinking and publishing about digital identity through an ecological lens. I have concluded that the diversity of identities we see today is a result of natural selection. If a single all-purpose identity was beneficial (nett nett), then I reckon natural selection would have delivered it already, maybe commercially. Especially commercially! But no, even in countries with national identity systems, these things are NOT used universally in commerce. Instead, everywhere in the world has siloed banking identities, health IDs, employee IDs, and all manner of customer reference numbers. This is because identification protocols (which are just one element in risk management) have to be precisely matched to local environmental conditions. It's the first rule of risk management: understand your own business and adopt risk management ploys that are suited to your circumstances. Risk management orthodoxy works against universality. Thus there is no universal identification protocol that delivers knowledge of the customer suitable for all conceivable applications. See also http://lockstep.com.au/library/identity_authentication/an-ecological-theory-of-digit.html and http://lockstep.com.au/blog/federated-identity Cheers, Steve Wilson Lockstep. On 12/04/2012 3:58 PM, Anders Rundgren wrote: > On 2012-04-11 22:01, Stephen Wilson wrote: >> My comment is that client side certificate management needs fixing as >> much as client side car maintenance. Why do it? > CONDENSED RATIONALE > > Currently people login to various services on the Internet; often several times > per day. In the majority of cases they use a userid/password combination for login. > Quite a bunch of these users (including myself) try to reduce the awkwardness of > this system by reusing passwords at different sites. > > When you pay for stuff on the Internet you typically use non-secure(d) credit-card > credentials. > > PROPOSAL > > A consumer-oriented on-line enrollment system would IMHO be the single most efficient > measure for enabling us to slowly but surely move away from static passwords and payment > systems that were designed in another time and for another purpose. > > > If somebody has a better suggestion, I encourage you to present it. > > -- Anders Rundgren > > > >> PKI is the classic case of a technology that appalls in the rough but is >> indispensible when embedded. My list of successful client side PKI >> deployment includes EMV DDA chip cards, the health cards of Austria, >> Taiwan, Thailand, Malaysia, France and others, the Estonia government >> services card, CAC, PIV and Skype. >> >> See http://lockstep.com.au/blog/2011/01/16/embedded-pki-on-the-cards.html >> >> General purpose, naked, personal digital certificates are of historical >> interest only! PKI should not be about creating a vertically integrated >> identity certificate management process. It should be about taking >> existing relationships and instantiating them in special purpose digital >> certificates congruent with those relationships. >> >> See http://lockstep.com.au/library/pki/relationship_certificates.html >> >> Cheers, >> >> Steve Wilson >> Lockstep >> http://lockstep.com.au/library/pki >> >> >> >> >> On 11/04/2012 9:38 PM, Anders Rundgren wrote: >>> Dear All, >>> >>> It seems that there's no end to the amount of time and energy available for >>> addressing various short-comings of the SSL PKI. This is of course very good. >>> >>> What's a little bit less understandable is why the interest in making client-side PKI >>> more useful is close to zero. It is true that there isn't any money to make on the >>> software and protocols. However, the availability of usable PKI clients will pay itself >>> through indirect means (more CAs, more services and less security breaches). >>> >>>> From a security point of view it is important to realize that even if the SSL PKI or DNS >>> get corrupted, a client-PKI-based login to "badbank.com" won't give "badbank.com" >>> any access to "goodbank.com". Using static passwords (the current "standard"), >>> all bets are off, not to mention how well shared passwords work... >>> >>> The current PKI enrollment solutions (maybe with Apple's iPhone scheme as a >>> notable exception) are close to useless for consumers. >>> >>> The SSL credential selection GUIs are also based on ideas that only PKI geeks >>> can possibly appreciate. Many service providers feel it would be downright >>> embarrassing offering such a clunky interface to their users. >>> >>> The majority of issuers of consumer-PKI have therefore developed their own >>> client-side PKI software which address things like GUI, PINs, X-platform, etc. >>> >>> IMHO, fixing a little bit here and there in a completely uncoordinated fashion >>> will never return an interoperable and useful foundation for consumer-PKI. >>> >>> Comments? >>> >>> Anders >>> >>> >>> >>> >>> _______________________________________________ >>> 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 anders.rundgren@telia.com Thu Apr 12 03:48:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FB621F8629 for ; Thu, 12 Apr 2012 03:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WToMzoi+cEil for ; Thu, 12 Apr 2012 03:48:28 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id DCDDB21F8646 for ; Thu, 12 Apr 2012 03:48:27 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E00BC74ED; Thu, 12 Apr 2012 12:48:26 +0200 Message-ID: <4F86B2F3.7090406@telia.com> Date: Thu, 12 Apr 2012 12:48:19 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "pkix@ietf.org" References: <4F856D3A.1060103@telia.com> <4F85E303.3090700@lockstep.com.au> <4F866EFF.3020207@telia.com> <4F86AADC.10906@lockstep.com.au> In-Reply-To: <4F86AADC.10906@lockstep.com.au> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 10:48:32 -0000 On 2012-04-12 12:13, Stephen Wilson wrote: > > Anders, > > But that's not any sort of PKI challenge is it? It's even less a PKIX > specific issue. Rather you've stated a broad federated identity vision. Stephen, I guess you have interpreted enrollment as some kind of sign-up procedure? This is of course a part of enrollment on the web but that's the beauty of the web; you can sign-up for anything. What's missing (IMO...) is a way to enroll that instead of providing you with yet another usersid/password combination, equips you with an X.509 certificate and matching private key. The universality of issued credentials is completely out-of-scope for this proposal, anything else would be silly. If providers believe that passwords are more suited to their risk management concepts they should of course continue with passwords. This proposal is about offering a useful alternative. The level of identity verification applied during enrollment is also out-of-scope since this is fairly technology independent. I agree that this is not a PKIX issue but that has more to do with IETF legacy (IETF do not make browser standards) than with the actual question. Do you think that Facebook should purchase and securely distribute 500 000 000 smart cards in order to improve their login solution? Anders > > And on federated identity, I have to say that the dream of a > one-size-fits-all identity (or identification/enrolment as you frame it) > is impractical. Of late I have been thinking and publishing about > digital identity through an ecological lens. I have concluded that the > diversity of identities we see today is a result of natural selection. > If a single all-purpose identity was beneficial (nett nett), then I > reckon natural selection would have delivered it already, maybe > commercially. Especially commercially! But no, even in countries with > national identity systems, these things are NOT used universally in > commerce. Instead, everywhere in the world has siloed banking > identities, health IDs, employee IDs, and all manner of customer > reference numbers. This is because identification protocols (which are > just one element in risk management) have to be precisely matched to > local environmental conditions. It's the first rule of risk management: > understand your own business and adopt risk management ploys that are > suited to your circumstances. Risk management orthodoxy works against > universality. Thus there is no universal identification protocol that > delivers knowledge of the customer suitable for all conceivable > applications. > > See also > http://lockstep.com.au/library/identity_authentication/an-ecological-theory-of-digit.html > > and > http://lockstep.com.au/blog/federated-identity > > Cheers, > > Steve Wilson > Lockstep. > > > > > On 12/04/2012 3:58 PM, Anders Rundgren wrote: >> On 2012-04-11 22:01, Stephen Wilson wrote: >>> My comment is that client side certificate management needs fixing as >>> much as client side car maintenance. Why do it? >> CONDENSED RATIONALE >> >> Currently people login to various services on the Internet; often several times >> per day. In the majority of cases they use a userid/password combination for login. >> Quite a bunch of these users (including myself) try to reduce the awkwardness of >> this system by reusing passwords at different sites. >> >> When you pay for stuff on the Internet you typically use non-secure(d) credit-card >> credentials. >> >> PROPOSAL >> >> A consumer-oriented on-line enrollment system would IMHO be the single most efficient >> measure for enabling us to slowly but surely move away from static passwords and payment >> systems that were designed in another time and for another purpose. >> >> >> If somebody has a better suggestion, I encourage you to present it. >> >> -- Anders Rundgren >> >> >> >>> PKI is the classic case of a technology that appalls in the rough but is >>> indispensible when embedded. My list of successful client side PKI >>> deployment includes EMV DDA chip cards, the health cards of Austria, >>> Taiwan, Thailand, Malaysia, France and others, the Estonia government >>> services card, CAC, PIV and Skype. >>> >>> See http://lockstep.com.au/blog/2011/01/16/embedded-pki-on-the-cards.html >>> >>> General purpose, naked, personal digital certificates are of historical >>> interest only! PKI should not be about creating a vertically integrated >>> identity certificate management process. It should be about taking >>> existing relationships and instantiating them in special purpose digital >>> certificates congruent with those relationships. >>> >>> See http://lockstep.com.au/library/pki/relationship_certificates.html >>> >>> Cheers, >>> >>> Steve Wilson >>> Lockstep >>> http://lockstep.com.au/library/pki >>> >>> >>> >>> >>> On 11/04/2012 9:38 PM, Anders Rundgren wrote: >>>> Dear All, >>>> >>>> It seems that there's no end to the amount of time and energy available for >>>> addressing various short-comings of the SSL PKI. This is of course very good. >>>> >>>> What's a little bit less understandable is why the interest in making client-side PKI >>>> more useful is close to zero. It is true that there isn't any money to make on the >>>> software and protocols. However, the availability of usable PKI clients will pay itself >>>> through indirect means (more CAs, more services and less security breaches). >>>> >>>>> From a security point of view it is important to realize that even if the SSL PKI or DNS >>>> get corrupted, a client-PKI-based login to "badbank.com" won't give "badbank.com" >>>> any access to "goodbank.com". Using static passwords (the current "standard"), >>>> all bets are off, not to mention how well shared passwords work... >>>> >>>> The current PKI enrollment solutions (maybe with Apple's iPhone scheme as a >>>> notable exception) are close to useless for consumers. >>>> >>>> The SSL credential selection GUIs are also based on ideas that only PKI geeks >>>> can possibly appreciate. Many service providers feel it would be downright >>>> embarrassing offering such a clunky interface to their users. >>>> >>>> The majority of issuers of consumer-PKI have therefore developed their own >>>> client-side PKI software which address things like GUI, PINs, X-platform, etc. >>>> >>>> IMHO, fixing a little bit here and there in a completely uncoordinated fashion >>>> will never return an interoperable and useful foundation for consumer-PKI. >>>> >>>> Comments? >>>> >>>> Anders >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 DPKemp@missi.ncsc.mil Thu Apr 12 05:52:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B470521F85D2 for ; Thu, 12 Apr 2012 05:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iki8yzjkCAMj for ; Thu, 12 Apr 2012 05:52:53 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1650221F85C2 for ; Thu, 12 Apr 2012 05:52:52 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q3CCqpEg082247 for ; Thu, 12 Apr 2012 08:52:52 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 08:52:51 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 12 Apr 2012 08:52:39 -0400 Message-ID: In-Reply-To: <4F867F55.8080809@free.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Proposal: Change the Criticality Requirement of Name Thread-Index: Ac0YexTeL2to/3VvSRGM4l+M0UOrpQAKebXQ References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp><0DFEAD5C-C1DB-48FA-81FA-A523464ABA9C@checkpoint.com> <4F867F55.8080809@free.fr> From: "Kemp, David P." To: X-OriginalArrivalTime: 12 Apr 2012 12:52:51.0918 (UTC) FILETIME=[2BEF26E0:01CD18AB] Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 12:52:53 -0000 That depends on who decides whether a reason is good. PKI does not exist for the benefit of CA operators or subscribers (in this case, server operators), it exists for the benefit of relying parties. When I go to my bank web site, it is in my interest (not the bank's directly, much less the CA's) to ensure that the site is what it claims to be. If security was a priority for me, I would do my banking on a device that warned me if something was fishy over a device that provided no such warning. Name constraints provides the warning if the device supports it, but not if the device doesn't support the extension and the extension is non-critical. Delta CRLs can be misused to trick RPs without any mistakes by a CA. Forged names require a CA to 1) make a mistake, 2) deliberately issue a forged name, or 3) be induced to do so by an attacker. But that difference isn't sufficient to claim that one extension has a "good" reason to be critical and the other does not. In both cases the RP is fooled and can suffer harm if the extension is non-critical, and the harm could be prevented by making the extension critical. This discussion is whether interoperability is more important than security, which in many cases it is. But that doesn't mean that avoiding security failures that could harm the RP is not a "good" reason. I like Stephen Farrell's suggestion to be explicit about the reason for making NC NC - it is an exception made for applications with significant market share that do not yet support it, and the security of the Internet would be improved when those applications are fixed and the exception is no longer needed for interoperability. Dave -----Original Message----- From: Jean-Marc Desperrier > > At the end, the conclusion is : > - The difference between the two actually is that "Delta CRL Indicator"=20 > has a good reason to be critical and "Name Constraints" doesn't From piyush@identicate.com Thu Apr 12 07:00:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378D121F85F4 for ; Thu, 12 Apr 2012 07:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOBCMTveS6qH for ; Thu, 12 Apr 2012 07:00:07 -0700 (PDT) Received: from col0-omc1-s4.col0.hotmail.com (col0-omc1-s4.col0.hotmail.com [65.55.34.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9F38D21F85E4 for ; Thu, 12 Apr 2012 07:00:05 -0700 (PDT) Received: from COL119-W48 ([65.55.34.7]) by col0-omc1-s4.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 07:00:05 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_655e05b8-e376-4698-8fda-1f49d006b2f5_" X-Originating-IP: [75.25.128.241] From: Piyush Jain To: , Date: Thu, 12 Apr 2012 07:00:04 -0700 Importance: Normal In-Reply-To: <7B0CAB6F-665E-4ACC-824D-6CD79983DD0E@checkpoint.com> References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp>, <4F85CE8C.2010302@free.fr> <4F85EF14.8050302@nist.gov>, <4F8609EC.3010501@cs.tcd.ie>, <7B0CAB6F-665E-4ACC-824D-6CD79983DD0E@checkpoint.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Apr 2012 14:00:05.0135 (UTC) FILETIME=[8FEB39F0:01CD18B4] Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 14:00:08 -0000 --_655e05b8-e376-4698-8fda-1f49d006b2f5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > From: ynir@checkpoint.com > To: stephen.farrell@cs.tcd.ie > Date: Thu=2C 12 Apr 2012 07:40:58 +0300 > CC: pkix@ietf.org > Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name >=20 >=20 > On Apr 12=2C 2012=2C at 1:47 AM=2C Stephen Farrell wrote: >=20 > >=20 > > So I like Paul's idea but think David is right that its not quite > > right as stated. I've no problem with 2119 purity either=2C so how > > about taking Paul's approach but naming names (sort of) and saying > > that NC MUST be critical except in the current public CA/web > > browser model=2C where NC SHOULD be critical on the basis that > > some implementations still need to catch up (with RFC 2459=3B-) and > > explain that that's ok because it does improve matters for some > > and is no worse than the status-quo for those RP's not supporting > > NC. >=20 > As Martin said=2C implementations don't have to catch up. They can remain= without support for name constraints forever.=20 To be compliant implementations must process Name Constraints. Off course t= hey don't have to catch up if compliance is not important to them.>Besides= =2C if all implementations do catch up=2C then criticality ceases to be an = issue at all. Until then=2C they are vulnerable if the understand criticali= ty and don't recognize name constraints=2C which is true of most non compli= ant implementations. >Any implementation that recognizes the extension MUST process it regardles= s of criticality. and compliant implementations MUST recognize (and process) name constraint.= =20 >=20 > Yoav > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --_655e05b8-e376-4698-8fda-1f49d006b2f5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B From: ynir@checkp= oint.com
>=3B To: stephen.farrell@cs.tcd.ie
>=3B Date: Thu=2C 12 = Apr 2012 07:40:58 +0300
>=3B CC: pkix@ietf.org
>=3B Subject: Re: = [pkix] Proposal: Change the Criticality Requirement of Name
>=3B
&= gt=3B
>=3B On Apr 12=2C 2012=2C at 1:47 AM=2C Stephen Farrell wrote:<= br>>=3B
>=3B >=3B
>=3B >=3B So I like Paul's idea but thi= nk David is right that its not quite
>=3B >=3B right as stated. I've= no problem with 2119 purity either=2C so how
>=3B >=3B about taking= Paul's approach but naming names (sort of) and saying
>=3B >=3B tha= t NC MUST be critical except in the current public CA/web
>=3B >=3B = browser model=2C where NC SHOULD be critical on the basis that
>=3B &g= t=3B some implementations still need to catch up (with RFC 2459=3B-) and>=3B >=3B explain that that's ok because it does improve matters for s= ome
>=3B >=3B and is no worse than the status-quo for those RP's not= supporting
>=3B >=3B NC.
>=3B
>=3B As Martin said=2C imp= lementations don't have to catch up. =3BThey can remain without support for name constraints forever.<= span style=3D"font-size: 10pt=3B "> =3B

To be compliant implementations must process Name Constraints. Off course = they don't have to catch up if compliance is not important to them.
>=3BBesides=2C if all implemen= tations do catch up=2C then criticality ceases to be an issue at all. = =3B
Until then=2C they are vulnerable if the understand criticali= ty and don't recognize name constraints=2C which is true of most non compli= ant implementations.

>=3BAny implementation that= recognizes the extension MUST process it regardless of criticality.
<= div>
and compliant implementations MUST recognize (and proces= s) name constraint. =3B

>=3B
>=3B Yoav=
>=3B _______________________________________________
>=3B pkix m= ailing list
>=3B pkix@ietf.org
>=3B https://www.ietf.org/mailman/= listinfo/pkix
= --_655e05b8-e376-4698-8fda-1f49d006b2f5_-- From housley@vigilsec.com Thu Apr 12 10:55:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B978421F85B5 for ; Thu, 12 Apr 2012 10:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4hiVUfAF-uj for ; Thu, 12 Apr 2012 10:55:54 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 25FC421F85B4 for ; Thu, 12 Apr 2012 10:55:54 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id A8F8AF2C067 for ; Thu, 12 Apr 2012 13:56:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id R+NfP200If8O for ; Thu, 12 Apr 2012 13:55:33 -0400 (EDT) Received: from [192.168.2.101] (pool-96-255-13-167.washdc.fios.verizon.net [96.255.13.167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E911BF24035 for ; Thu, 12 Apr 2012 13:56:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Russ Housley In-Reply-To: Date: Thu, 12 Apr 2012 13:55:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IETF PKIX X-Mailer: Apple Mail (2.1084) Subject: Re: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and name/policy constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 17:55:54 -0000 > This proposal is an alternative to the people who want the "MUST mark = as critical" to be a "SHOULD". So far, those proposals have not given = CAs enough guidance about when the "SHOULD" is and is not important. = Instead, we can look at this as clarification of what the current "MUST" = means. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > In describing the Name Constraints and Policy Contraints extensions, = RFC 5280 says: > Conforming CAs MUST mark this extension as > critical > In these cases, the "MUST" language from RFC 2119 is based on a = potential for causing harm, not the need for interoperability. This = interpretation can be seen by looking in Section 6.1 of RFC 5280, which = says: > While the algorithm could be extended to include checks for > conformance to the profiles in Sections 4 and 5, this profile > RECOMMENDS against including such checks. >=20 > The Name Constraints and Policy Contraints extensions do not need to = be marked critical if a relying party has no restrictions on the names = or policies of end entity certificates issued under a particular trust = anchor. For example, if such a trust anchor issues a CA certificate with = the Name Constraints extension that limits that CA's ability to issue = certificates, and if the Name Constraints extension in that CA's = certificate is not marked critical, and if the CA issues an end entity = certificate whose name is outside the set of ones it is allowed to issue = for, and if the relying party does not understand the Name Constraints = extension, the relying party is no worse off because it would have = accepted that end entity certificate issued directly by the trust = anchor. >=20 > Given this rationale, the statement "Conforming CAs MUST mark this = extension as critical" is interpreted as "Conforming CAs MUST mark this = extension as critical when there is a potential for harm in relying = parties that do not understand the extension", not universally. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Thoughts? I am still unconvinced that this is desirable. Russ= From david.cooper@nist.gov Thu Apr 12 11:50:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEF721F85B9 for ; Thu, 12 Apr 2012 11:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vS3XMZwYP-Z for ; Thu, 12 Apr 2012 11:50:55 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB2B21F85F4 for ; Thu, 12 Apr 2012 11:50:54 -0700 (PDT) Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q3CIogj7017498; Thu, 12 Apr 2012 14:50:43 -0400 Message-ID: <4F872402.80409@nist.gov> Date: Thu, 12 Apr 2012 14:50:42 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120318 Thunderbird/11.0 MIME-Version: 1.0 To: Paul Hoffman References: <4B7FDE14-5E2E-45B8-AD50-4ACD24557338@vpnc.org> In-Reply-To: <4B7FDE14-5E2E-45B8-AD50-4ACD24557338@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: IETF PKIX Subject: Re: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and As name/policy constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 18:50:56 -0000 Paul, As I noted in my previous messages, it is a mistake to only think about public roots, hierarchical PKIs, and sub-CAs. The example that I used was the DoD Root CA. DoD has a policy of only accepting (as a relying party) certificates issued at the Medium Hardware and High assurance levels. It reflects this policy in its cross-certificate to the Federal Bridge CA by including a critical policyConstraints extension. The Federal Bridge CA is not a sub-CA of the DoD Root and the inclusion of the constraints extension by DoD is not to notify DoD relying parties that the Federal PKI is not supposed to be issuing certificates at lower assurance levels. The constraints extension is enforcing on DoD relying parties that they may only accept the subset of Federal PKI-issued certificates that have been issued at an assurance level acceptable to DoD. This is very different from a hierarchical PKI, in which a CA may procedurally limit what certificates a sub-CA may issue. In this case it would likely be a sign of an error if a sub-CA issued a certificate that did not satisfy a constraint (policyConstraints or nameConstraints) specified in a cross-certificate issued to the sub-CA. In the non-hierarchical case, failure to process a constraints extension will lead to the relying party accepting certificates that it should not be accepting. In the hierarchical case, failure to process a constraints extension will only lead to the relying party accepting certificates that it should not be accepting if a sub-CA issued a certificate that it shouldn't have issued (and the bad certificate does not satisfy the constraint). Dave On 04/11/2012 07:34 PM, Paul Hoffman wrote: > On Apr 11, 2012, at 4:09 PM, Stefan Santesson wrote: >> Isn't what you intend to say the following: >> >> In cases where the CA need to enforce that relying parties rejects >> certificates issued outside of a set NC, the CA MUST mark this extension >> as critical. > No, not at all. A CA never needs to enforce anything on an RP. A CA might want to reduce its liability by constraining CAs under it, and if that CA believes that some RPs only trust the CA for some names or policies, the CA needs to alert the RP that sub-CAs have more constraints. From mrex@sap.com Thu Apr 12 12:05:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EA921F85D1 for ; Thu, 12 Apr 2012 12:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.777 X-Spam-Level: X-Spam-Status: No, score=-9.777 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlJUf74Y63P7 for ; Thu, 12 Apr 2012 12:05:46 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id ABA4921F858E for ; Thu, 12 Apr 2012 12:05:45 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3CJ5KrD002518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Apr 2012 21:05:20 +0200 (MEST) From: Martin Rex Message-Id: <201204121905.q3CJ5JVR007067@fs4113.wdf.sap.corp> To: SChokhani@cygnacom.com (Santosh Chokhani) Date: Thu, 12 Apr 2012 21:05:19 +0200 (MEST) In-Reply-To: from "Santosh Chokhani" at Apr 9, 12 11:07:39 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:05:46 -0000 Santosh Chokhani wrote: > > This relates to the name constraints discussion going on in another thread. > > Does anyone know how the browsers handle a Server certificate if subject > alternative name is absent and the DN (specifically Common Name) > contains the FQDN? > > Related to this does anyone know what the browsers do with this name > form if the certification path has URL or DNS Names constrained? > Do, they enforce the applicable constraints on them. > > I did not find language in 5280 that deal with this. > I may have missed something. You did not miss it, that is currently undefined. NameConstraints processing happens entirely within the certificate path validation algorithm of the PKIX module (rfc5280, section 6.1), whereas server endpoint identification is something completely unrelated, that is performed by the application on top of TLS (such as rfc2818 or rfc6125). These two operations are conceptually unrelated, and the application does its server endpoint identification based only on the Server certificate and typically ignorant of any other certs in the server's certification path and potentially at a different time. E.g. basic certificate path validation might be performed by TLS itself when processing the respective Certificate handshake message and before using the crypto keys, whereas (Server) endpoint identification and certificate revocation checking might be performed after the TLS handshake has successfully completed. The issue of name constraints and its interaction with CN-ID matching by TLS clients doing server endpoint identification was discussed on the certid (-> rfc6125) mailing list in mid of 2010, but I'm not aware of any changes of PKIX processing rules for name constraints so far. -Martin Btw. just today a customer message floated by from a customer that was trying to use a server cert from a PKI with name constraints in the CA cert above the leaf cert. Those name constraints were marked critical an therefore the server cert rejected by our PKI software. The size of the name constraints was "impressive" and some of the contents confusing. Among it, an otherName MS-UPN constraint (both permitted and excluded subtree) -- but I'm not aware of a public specificiation for this SAN and its name constraints processing). The contents were: permitted: 1x MS-UPN, value "" 1x rfc822name, value "something@somedomain.dir" 5x DNSName, values like ".somedomain.dir" 37x directoryName 5x URI, values exactly same as DNSName values excluded: 1x MS-UPN, value "." 8x DNSName, values like ".root.somedomain.dir" 8x URI, values exactly same as DNSName values Processing such a large list of name constraints probably burns more CPU cycles than processing the 1024-bit sha1WithRSA signature verification with that cert... What confused me: - is an name constraint URI with a value ".somedomain.dir" correct, doesn't that need to start with a schema? - the rfc822name looks like _completely_ hardwired for certs issued by that subCA - the server cert that the customer was trying to install did not contain a DNSName SAN, but only a hostname in CN of the subject name (i.e. unconstrained). A CA software that is capable of creating a TLS Server certificate with the id-kp-serverAuth and a CA-cert with DNSName name constraints ought not issue a TLS Server cert without the hostname in a DNSName SAN... From SChokhani@cygnacom.com Thu Apr 12 12:11:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A42321F86B6 for ; Thu, 12 Apr 2012 12:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsqRQsYJoHtr for ; Thu, 12 Apr 2012 12:11:52 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id AE47821F86A7 for ; Thu, 12 Apr 2012 12:11:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,411,1330923600"; d="scan'208";a="4691452" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 12 Apr 2012 15:11:52 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 12 Apr 2012 15:11:51 -0400 From: Santosh Chokhani To: "mrex@sap.com" Date: Thu, 12 Apr 2012 15:11:50 -0400 Thread-Topic: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints Thread-Index: Ac0Y30nh/39rh9fGQyKEnJsHwjxbDwAALufg Message-ID: References: from "Santosh Chokhani" at Apr 9, 12 11:07:39 am <201204121905.q3CJ5JVR007067@fs4113.wdf.sap.corp> In-Reply-To: <201204121905.q3CJ5JVR007067@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:11:53 -0000 Martin, May be you can send me the actual certificate chain and I can see what the = issues are. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Thursday, April 12, 2012 3:05 PM To: Santosh Chokhani Cc: pkix@ietf.org Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Const= raints Santosh Chokhani wrote: >=20 > This relates to the name constraints discussion going on in another threa= d. >=20 > Does anyone know how the browsers handle a Server certificate if=20 > subject alternative name is absent and the DN (specifically Common=20 > Name) contains the FQDN? >=20 > Related to this does anyone know what the browsers do with this name=20 > form if the certification path has URL or DNS Names constrained? > Do, they enforce the applicable constraints on them. >=20 > I did not find language in 5280 that deal with this. > I may have missed something. You did not miss it, that is currently undefined. NameConstraints processing happens entirely within the certificate path val= idation algorithm of the PKIX module (rfc5280, section 6.1), whereas server= endpoint identification is something completely unrelated, that is perform= ed by the application on top of TLS (such as rfc2818 or rfc6125). These two operations are conceptually unrelated, and the application does i= ts server endpoint identification based only on the Server certificate and = typically ignorant of any other certs in the server's certification path an= d potentially at a different time. E.g. basic certificate path validation might be performed by TLS itself whe= n processing the respective Certificate handshake message and before using = the crypto keys, whereas (Server) endpoint identification and certificate r= evocation checking might be performed after the TLS handshake has successfu= lly completed. The issue of name constraints and its interaction with CN-ID matching by TL= S clients doing server endpoint identification was discussed on the certid = (-> rfc6125) mailing list in mid of 2010, but I'm not aware of any changes= of PKIX processing rules for name constraints so far. -Martin Btw. just today a customer message floated by from a customer that was tryi= ng to use a server cert from a PKI with name constraints in the CA cert abo= ve the leaf cert. Those name constraints were marked critical an therefore= the server cert rejected by our PKI software. The size of the name constraints was "impressive" and some of the contents = confusing. Among it, an otherName MS-UPN constraint (both permitted and ex= cluded subtree) -- but I'm not aware of a public specificiation for this SA= N and its name constraints processing). The contents were: permitted: 1x MS-UPN, value "" 1x rfc822name, value "something@somedomain.dir" 5x DNSName, values like ".somedomain.dir" 37x directoryName 5x URI, values exactly same as DNSName values excluded: 1x MS-UPN, value "." 8x DNSName, values like ".root.somedomain.dir" 8x URI, values exactly same as DNSName values Processing such a large list of name constraints probably burns more CPU cy= cles than processing the 1024-bit sha1WithRSA signature verification with t= hat cert... What confused me: - is an name constraint URI with a value ".somedomain.dir" correct, doesn't that need to start with a schema? - the rfc822name looks like _completely_ hardwired for certs issued by that subCA - the server cert that the customer was trying to install did not contain a DNSName SAN, but only a hostname in CN of the subject name (i.e. unconstrained). A CA software that is capable of creating a TLS Server certificate with the= id-kp-serverAuth and a CA-cert with DNSName name constraints ought not iss= ue a TLS Server cert without the hostname in a DNSName SAN... From paul.hoffman@vpnc.org Thu Apr 12 13:23:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27B221F869D for ; Thu, 12 Apr 2012 13:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XprZx3nAz39X for ; Thu, 12 Apr 2012 13:23:39 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1499C21F86A7 for ; Thu, 12 Apr 2012 13:23:39 -0700 (PDT) Received: from [10.20.30.105] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3CKNaKe088425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Apr 2012 13:23:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F872402.80409@nist.gov> Date: Thu, 12 Apr 2012 13:23:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2EF86A31-CED9-4EE9-803B-81963328958F@vpnc.org> References: <4B7FDE14-5E2E-45B8-AD50-4ACD24557338@vpnc.org> <4F872402.80409@nist.gov> To: "David A. Cooper" X-Mailer: Apple Mail (2.1257) Cc: IETF PKIX Subject: Re: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and As name/policy constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 20:23:39 -0000 I'm not sure why this message was addressed to me, since I didn't say = anything below that indicates limiting our view to public roots and = hierarchical PKIs. Even in the US DoD CA case, the CA does not need to = enforce anything on an RP. I agree strongly with your last paragraph, = about what happens when those RP fail to process a constraints = extension, but that doesn't mean that the CA needs to enforce anything: = it is the systems that are RPs that need to enforce either understanding = the constraints or stopping validation when they see the critical bit on = something they don't understand. --Paul Hoffman On Apr 12, 2012, at 11:50 AM, David A. Cooper wrote: > Paul, >=20 > As I noted in my previous messages, it is a mistake to only think = about public roots, hierarchical PKIs, and sub-CAs. The example that I = used was the DoD Root CA. DoD has a policy of only accepting (as a = relying party) certificates issued at the Medium Hardware and High = assurance levels. It reflects this policy in its cross-certificate to = the Federal Bridge CA by including a critical policyConstraints = extension. The Federal Bridge CA is not a sub-CA of the DoD Root and = the inclusion of the constraints extension by DoD is not to notify DoD = relying parties that the Federal PKI is not supposed to be issuing = certificates at lower assurance levels. The constraints extension is = enforcing on DoD relying parties that they may only accept the subset of = Federal PKI-issued certificates that have been issued at an assurance = level acceptable to DoD. >=20 > This is very different from a hierarchical PKI, in which a CA may = procedurally limit what certificates a sub-CA may issue. In this case = it would likely be a sign of an error if a sub-CA issued a certificate = that did not satisfy a constraint (policyConstraints or nameConstraints) = specified in a cross-certificate issued to the sub-CA. >=20 > In the non-hierarchical case, failure to process a constraints = extension will lead to the relying party accepting certificates that it = should not be accepting. In the hierarchical case, failure to process a = constraints extension will only lead to the relying party accepting = certificates that it should not be accepting if a sub-CA issued a = certificate that it shouldn't have issued (and the bad certificate does = not satisfy the constraint). >=20 > Dave >=20 > On 04/11/2012 07:34 PM, Paul Hoffman wrote: >> On Apr 11, 2012, at 4:09 PM, Stefan Santesson wrote: >>> Isn't what you intend to say the following: >>>=20 >>> In cases where the CA need to enforce that relying parties rejects >>> certificates issued outside of a set NC, the CA MUST mark this = extension >>> as critical. >> No, not at all. A CA never needs to enforce anything on an RP. A CA = might want to reduce its liability by constraining CAs under it, and if = that CA believes that some RPs only trust the CA for some names or = policies, the CA needs to alert the RP that sub-CAs have more = constraints. From swilson@lockstep.com.au Thu Apr 12 14:16:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB32821F8762 for ; Thu, 12 Apr 2012 14:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xGiShHJ8jHf for ; Thu, 12 Apr 2012 14:16:24 -0700 (PDT) Received: from smtp172.iad.emailsrvr.com (smtp172.iad.emailsrvr.com [207.97.245.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEDD21F870E for ; Thu, 12 Apr 2012 14:16:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp57.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 8DD53F82FC; Thu, 12 Apr 2012 17:16:23 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp57.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id 90B63F8289; Thu, 12 Apr 2012 17:16:22 -0400 (EDT) Message-ID: <4F874603.8070204@lockstep.com.au> Date: Fri, 13 Apr 2012 07:15:47 +1000 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Anders Rundgren References: <4F856D3A.1060103@telia.com> <4F85E303.3090700@lockstep.com.au> <4F866EFF.3020207@telia.com> <4F86AADC.10906@lockstep.com.au> <4F86B2F3.7090406@telia.com> In-Reply-To: <4F86B2F3.7090406@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 21:16:29 -0000 I see. Sorry, I did read "enrolment" as meaning sign up. And I thought you were talking to the (overstated) issue of multiple credentials. So I agree with you. I wish that people got smartcards instead of anything else. And I wish that device manufacturers standardised on built-in smartcard readers, as they started to in 2003 after Microsoft put smartcard support into their software stack. a decade later, I can see a new wave of smartcard use now that NFC/wifi components can be co-opted to read/write contactless smartcards. In principle it's an easy matter for a PIV card to connect to any NFC enabled device. We could get read of the dreaded smartcard reader problem overnight. Instead of Facebook ... if banks said "the hell with online fraud and ID theft, and the hell with craziness like 3D Secure -- let's instead use EMV smartcards for Internet payments" ... we would see all those laptop and tablet manufacturers rush to reinstate card readers in their products. As an engineering exercise, it's nearly trivial. The decision to prioritise smartcard readers in computers is a product marketing question. We just need a killer app, like payments, to make the decision worthwhile. Cheers, Steve Wilson Lockstep http://lockstep.com.au/blog/smartcards On 12/04/2012 8:48 PM, Anders Rundgren wrote: > On 2012-04-12 12:13, Stephen Wilson wrote: >> Anders, >> >> But that's not any sort of PKI challenge is it? It's even less a PKIX >> specific issue. Rather you've stated a broad federated identity vision. > Stephen, > I guess you have interpreted enrollment as some kind of sign-up procedure? > > This is of course a part of enrollment on the web but that's the beauty of > the web; you can sign-up for anything. What's missing (IMO...) is a way to > enroll that instead of providing you with yet another usersid/password > combination, equips you with an X.509 certificate and matching private key. > > The universality of issued credentials is completely out-of-scope for > this proposal, anything else would be silly. If providers believe that > passwords are more suited to their risk management concepts they should > of course continue with passwords. This proposal is about offering a > useful alternative. > > The level of identity verification applied during enrollment is also > out-of-scope since this is fairly technology independent. > > I agree that this is not a PKIX issue but that has more to do with IETF > legacy (IETF do not make browser standards) than with the actual question. > > Do you think that Facebook should purchase and securely distribute 500 000 000 > smart cards in order to improve their login solution? > > Anders > > >> And on federated identity, I have to say that the dream of a >> one-size-fits-all identity (or identification/enrolment as you frame it) >> is impractical. Of late I have been thinking and publishing about >> digital identity through an ecological lens. I have concluded that the >> diversity of identities we see today is a result of natural selection. >> If a single all-purpose identity was beneficial (nett nett), then I >> reckon natural selection would have delivered it already, maybe >> commercially. Especially commercially! But no, even in countries with >> national identity systems, these things are NOT used universally in >> commerce. Instead, everywhere in the world has siloed banking >> identities, health IDs, employee IDs, and all manner of customer >> reference numbers. This is because identification protocols (which are >> just one element in risk management) have to be precisely matched to >> local environmental conditions. It's the first rule of risk management: >> understand your own business and adopt risk management ploys that are >> suited to your circumstances. Risk management orthodoxy works against >> universality. Thus there is no universal identification protocol that >> delivers knowledge of the customer suitable for all conceivable >> applications. >> >> See also >> http://lockstep.com.au/library/identity_authentication/an-ecological-theory-of-digit.html >> >> and >> http://lockstep.com.au/blog/federated-identity >> >> Cheers, >> >> Steve Wilson >> Lockstep. >> >> >> >> >> On 12/04/2012 3:58 PM, Anders Rundgren wrote: >>> On 2012-04-11 22:01, Stephen Wilson wrote: >>>> My comment is that client side certificate management needs fixing as >>>> much as client side car maintenance. Why do it? >>> CONDENSED RATIONALE >>> >>> Currently people login to various services on the Internet; often several times >>> per day. In the majority of cases they use a userid/password combination for login. >>> Quite a bunch of these users (including myself) try to reduce the awkwardness of >>> this system by reusing passwords at different sites. >>> >>> When you pay for stuff on the Internet you typically use non-secure(d) credit-card >>> credentials. >>> >>> PROPOSAL >>> >>> A consumer-oriented on-line enrollment system would IMHO be the single most efficient >>> measure for enabling us to slowly but surely move away from static passwords and payment >>> systems that were designed in another time and for another purpose. >>> >>> >>> If somebody has a better suggestion, I encourage you to present it. >>> >>> -- Anders Rundgren >>> >>> >>> >>>> PKI is the classic case of a technology that appalls in the rough but is >>>> indispensible when embedded. My list of successful client side PKI >>>> deployment includes EMV DDA chip cards, the health cards of Austria, >>>> Taiwan, Thailand, Malaysia, France and others, the Estonia government >>>> services card, CAC, PIV and Skype. >>>> >>>> See http://lockstep.com.au/blog/2011/01/16/embedded-pki-on-the-cards.html >>>> >>>> General purpose, naked, personal digital certificates are of historical >>>> interest only! PKI should not be about creating a vertically integrated >>>> identity certificate management process. It should be about taking >>>> existing relationships and instantiating them in special purpose digital >>>> certificates congruent with those relationships. >>>> >>>> See http://lockstep.com.au/library/pki/relationship_certificates.html >>>> >>>> Cheers, >>>> >>>> Steve Wilson >>>> Lockstep >>>> http://lockstep.com.au/library/pki >>>> >>>> >>>> >>>> >>>> On 11/04/2012 9:38 PM, Anders Rundgren wrote: >>>>> Dear All, >>>>> >>>>> It seems that there's no end to the amount of time and energy available for >>>>> addressing various short-comings of the SSL PKI. This is of course very good. >>>>> >>>>> What's a little bit less understandable is why the interest in making client-side PKI >>>>> more useful is close to zero. It is true that there isn't any money to make on the >>>>> software and protocols. However, the availability of usable PKI clients will pay itself >>>>> through indirect means (more CAs, more services and less security breaches). >>>>> >>>>>> From a security point of view it is important to realize that even if the SSL PKI or DNS >>>>> get corrupted, a client-PKI-based login to "badbank.com" won't give "badbank.com" >>>>> any access to "goodbank.com". Using static passwords (the current "standard"), >>>>> all bets are off, not to mention how well shared passwords work... >>>>> >>>>> The current PKI enrollment solutions (maybe with Apple's iPhone scheme as a >>>>> notable exception) are close to useless for consumers. >>>>> >>>>> The SSL credential selection GUIs are also based on ideas that only PKI geeks >>>>> can possibly appreciate. Many service providers feel it would be downright >>>>> embarrassing offering such a clunky interface to their users. >>>>> >>>>> The majority of issuers of consumer-PKI have therefore developed their own >>>>> client-side PKI software which address things like GUI, PINs, X-platform, etc. >>>>> >>>>> IMHO, fixing a little bit here and there in a completely uncoordinated fashion >>>>> will never return an interoperable and useful foundation for consumer-PKI. >>>>> >>>>> Comments? >>>>> >>>>> Anders >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 mrex@sap.com Thu Apr 12 17:32:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECD521F84F0 for ; Thu, 12 Apr 2012 17:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.184 X-Spam-Level: X-Spam-Status: No, score=-9.184 tagged_above=-999 required=5 tests=[AWL=-0.735, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6gcGm7HbnJ1 for ; Thu, 12 Apr 2012 17:32:26 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E9C2B21F84DE for ; Thu, 12 Apr 2012 17:32:25 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3D0WNEB029191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Apr 2012 02:32:23 +0200 (MEST) From: Martin Rex Message-Id: <201204130032.q3D0WLTZ025519@fs4113.wdf.sap.corp> To: SChokhani@cygnacom.com (Santosh Chokhani) Date: Fri, 13 Apr 2012 02:32:21 +0200 (MEST) In-Reply-To: from "Santosh Chokhani" at Apr 12, 12 03:11:50 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 00:32:27 -0000 Santosh Chokhani wrote: > >> The contents were: >> permitted: ... >> 5x DNSName, values like ".somedomain.dir" >> ... >> 5x URI, values exactly same as DNSName values > > May be you can send me the actual certificate chain and I can see > what the issues are. Re-scanning rfc5280 (where the syntax of GeneralName in the context of NameConstraints appears to be specified here): http://tools.ietf.org/html/rfc5280#section-4.2.1.10 it seems that the name constraints specified for URI are correct, but the NameConstraints specified for DNSName are invalid. Different to domain names in URI and rfc822Name Constraints, DNSName Constraints do not permit a leading dot. Cross-checking with the implementation of name constraints in openssl-1.0.0h/crypto/x509v3/v3_ncons.c, that code appears to be according to the spec and fail comparison with such a malformed DNSName NameConstraints -- in case there is a DNSName present in the End-Entity cert (which wasn't...). The openssl-1.0.0x codebase seems to include name constraints processing, plus a check of rfc822Name Constraints against an EMail= RDName of the subject name. It does not (currently) seem to contain a check for DNSName Constraints against CN=f.q.d.n. (neither rfc5280/PKIX nor X.509 specify such DName cross-checks). Passing that customers cert-chain to openssl (0.9.8j-fips) on our newest SLES-11sp1 machines, results in a confusing output: openssl verify -verbose -CAfile root.pem -untrusted pathcerts.pem -purpose sslserver server.cer server.cer: /DC=dir/DC=... error 34 at 1 depth lookup:unhandled critical extension OK What does this tell me? I would have expected either an error or an OK, but not both! apps/verify.c looks like this: i=X509_verify_cert(csc); X509_STORE_CTX_free(csc); ret=0; end: if (i > 0) { fprintf(stdout,"OK\n"); ret=1; } and the documentation for X509_verify_cert() says this: http://www.openssl.org/docs/crypto/X509_verify_cert.html RETURN VALUES If a complete chain can be built and validated this function returns 1 ... NOTES Applications rarely call this function directly but it is used by OpenSSL internally for certificate validation, in both the S/MIME and SSL/TLS code. which looks to me like OpenSSL-0.9.8x is (silently) ignoring critical name constraints. -Martin btw. I consider the context-sensitive syntax rule for the ASN.1 type GeneralName extremely confusing! From SChokhani@cygnacom.com Thu Apr 12 17:53:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B48F21F86A6 for ; Thu, 12 Apr 2012 17:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dzloGBAX6GX for ; Thu, 12 Apr 2012 17:53:08 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2C721F8594 for ; Thu, 12 Apr 2012 17:53:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,414,1330923600"; d="scan'208";a="4694477" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 12 Apr 2012 20:53:07 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 12 Apr 2012 20:53:07 -0400 From: Santosh Chokhani To: Stephen Kent , "pkix@ietf.org" Date: Thu, 12 Apr 2012 20:53:05 -0400 Thread-Topic: [pkix] 2875bis Thread-Index: Ac0YULHqtld4O3RuQfyjSUEMxNl5NAAo5JnQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] 2875bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 00:53:09 -0000 Steve, I support PKIX adopting this document as a work item since PoP is key part = of PKI management protocols. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ste= phen Kent Sent: Wednesday, April 11, 2012 10:03 PM To: pkix@ietf.org Subject: [pkix] 2875bis Folks, As noted in the PKIX meeting minutes from Paris, Jim Schaad has updated RFC= 2875 in support of alg agility, with a focus on parameterizing use of hash= algs. 2875 is a PKIX RFC, so it makes sense for this update to be a WG doc= . As noted in the meeting minutes, Sean has offered to sponsor the doc if PKI= X choose to not adopt it. Please comment on the list if you want PKIX to adopt the doc. The default w= ill be that Sean will deal with it directly. This call for adoption will end in two weeks, on 4/25. Steve _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From SChokhani@cygnacom.com Thu Apr 12 17:53:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8C121F8594 for ; Thu, 12 Apr 2012 17:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJzVlLzF-+cl for ; Thu, 12 Apr 2012 17:53:58 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8E86E21F86DB for ; Thu, 12 Apr 2012 17:53:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,414,1330923600"; d="scan'208";a="4694485" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 12 Apr 2012 20:53:58 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 12 Apr 2012 20:53:57 -0400 From: Santosh Chokhani To: "mrex@sap.com" Date: Thu, 12 Apr 2012 20:53:56 -0400 Thread-Topic: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints Thread-Index: Ac0Y30nh/39rh9fGQyKEnJsHwjxbDwAFnObQ Message-ID: References: from "Santosh Chokhani" at Apr 9, 12 11:07:39 am <201204121905.q3CJ5JVR007067@fs4113.wdf.sap.corp> In-Reply-To: <201204121905.q3CJ5JVR007067@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 00:53:59 -0000 Martin, I do not see either the rfc2818 or rfc6125 addressing name constraints appl= ication to DNS names appearing in CN of Subject field. Am I missing something? -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Thursday, April 12, 2012 3:05 PM To: Santosh Chokhani Cc: pkix@ietf.org Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Const= raints Santosh Chokhani wrote: >=20 > This relates to the name constraints discussion going on in another threa= d. >=20 > Does anyone know how the browsers handle a Server certificate if=20 > subject alternative name is absent and the DN (specifically Common=20 > Name) contains the FQDN? >=20 > Related to this does anyone know what the browsers do with this name=20 > form if the certification path has URL or DNS Names constrained? > Do, they enforce the applicable constraints on them. >=20 > I did not find language in 5280 that deal with this. > I may have missed something. You did not miss it, that is currently undefined. NameConstraints processing happens entirely within the certificate path val= idation algorithm of the PKIX module (rfc5280, section 6.1), whereas server= endpoint identification is something completely unrelated, that is perform= ed by the application on top of TLS (such as rfc2818 or rfc6125). These two operations are conceptually unrelated, and the application does i= ts server endpoint identification based only on the Server certificate and = typically ignorant of any other certs in the server's certification path an= d potentially at a different time. E.g. basic certificate path validation might be performed by TLS itself whe= n processing the respective Certificate handshake message and before using = the crypto keys, whereas (Server) endpoint identification and certificate r= evocation checking might be performed after the TLS handshake has successfu= lly completed. The issue of name constraints and its interaction with CN-ID matching by TL= S clients doing server endpoint identification was discussed on the certid = (-> rfc6125) mailing list in mid of 2010, but I'm not aware of any changes= of PKIX processing rules for name constraints so far. -Martin Btw. just today a customer message floated by from a customer that was tryi= ng to use a server cert from a PKI with name constraints in the CA cert abo= ve the leaf cert. Those name constraints were marked critical an therefore= the server cert rejected by our PKI software. The size of the name constraints was "impressive" and some of the contents = confusing. Among it, an otherName MS-UPN constraint (both permitted and ex= cluded subtree) -- but I'm not aware of a public specificiation for this SA= N and its name constraints processing). The contents were: permitted: 1x MS-UPN, value "" 1x rfc822name, value "something@somedomain.dir" 5x DNSName, values like ".somedomain.dir" 37x directoryName 5x URI, values exactly same as DNSName values excluded: 1x MS-UPN, value "." 8x DNSName, values like ".root.somedomain.dir" 8x URI, values exactly same as DNSName values Processing such a large list of name constraints probably burns more CPU cy= cles than processing the 1024-bit sha1WithRSA signature verification with t= hat cert... What confused me: - is an name constraint URI with a value ".somedomain.dir" correct, doesn't that need to start with a schema? - the rfc822name looks like _completely_ hardwired for certs issued by that subCA - the server cert that the customer was trying to install did not contain a DNSName SAN, but only a hostname in CN of the subject name (i.e. unconstrained). A CA software that is capable of creating a TLS Server certificate with the= id-kp-serverAuth and a CA-cert with DNSName name constraints ought not iss= ue a TLS Server cert without the hostname in a DNSName SAN... From mrex@sap.com Thu Apr 12 18:24:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A67421F8565 for ; Thu, 12 Apr 2012 18:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.065 X-Spam-Level: X-Spam-Status: No, score=-10.065 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaAx4lNW0Jkb for ; Thu, 12 Apr 2012 18:24:59 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id CE23921F8541 for ; Thu, 12 Apr 2012 18:24:58 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3D1Otia026072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Apr 2012 03:24:55 +0200 (MEST) From: Martin Rex Message-Id: <201204130124.q3D1Otvd028364@fs4113.wdf.sap.corp> To: SChokhani@cygnacom.com (Santosh Chokhani) Date: Fri, 13 Apr 2012 03:24:55 +0200 (MEST) In-Reply-To: from "Santosh Chokhani" at Apr 12, 12 08:53:56 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 01:24:59 -0000 Santosh Chokhani wrote: > > I do not see either the rfc2818 or rfc6125 addressing name constraints > application to DNS names appearing in CN of Subject field. > > Am I missing something? No. There is nothing in those document, and IMO it would be inappropriate to put it in those documents. NameConstraints are exclusively a PKIX-internal(!) thing. For an RP, NameConstraints processing is completely hidden inside the certificate path validation function of the PKIX module. One possible approach might be to add a new optional input parameter (k) to rfc-5280 6.1.1 so that the caller can identify the desired key purpose(s), and then extend the processing in rfc-5280 6.1.3 (c) for two conditions: - if the application caller supplied the id-kp-serverAuth as input, check whether the cert is allowed for id-kp-serverAuth should it be purpose-limited by an EKU extension, and if EKU id-kp-serverAuth is asserted, process DNSName constraints for every CN= Attributes in the subject DName. - if the application caller supplied the id-kp-emailProtection as input, check whether the cert is allowed for id-kp-emailProtection should it be purpose-limited by an EKU extension, and if EKU id-kp-emailProtection is asserted, process rfc822Name constraints for every pkcs9_emailAddress Attributes in the subject DName. -Martin From SChokhani@cygnacom.com Thu Apr 12 18:29:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ABC21F8726 for ; Thu, 12 Apr 2012 18:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kESuQbFCrJjI for ; Thu, 12 Apr 2012 18:29:50 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7907421F8722 for ; Thu, 12 Apr 2012 18:29:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,414,1330923600"; d="scan'208";a="755164" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 12 Apr 2012 21:29:50 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 12 Apr 2012 21:29:49 -0400 From: Santosh Chokhani To: "mrex@sap.com" Date: Thu, 12 Apr 2012 21:29:21 -0400 Thread-Topic: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Thread-Index: Ac0ZFD1O7wAKdUUURamdZ52dPDnqqAAAHDag Message-ID: References: from "Santosh Chokhani" at Apr 12, 12 08:53:56 pm <201204130124.q3D1Otvd028364@fs4113.wdf.sap.corp> In-Reply-To: <201204130124.q3D1Otvd028364@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 01:29:51 -0000 I was thinking something simpler: Just like RFC 5280 describes name constra= ints for RFC 822 names need to be enforced when they appear in DN, they nee= d to be enforced on DNS name when they appear in CN. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Thursday, April 12, 2012 9:25 PM To: Santosh Chokhani Cc: mrex@sap.com; pkix@ietf.org Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Santosh Chokhani wrote: >=20 > I do not see either the rfc2818 or rfc6125 addressing name constraints=20 > application to DNS names appearing in CN of Subject field. >=20 > Am I missing something? No. There is nothing in those document, and IMO it would be inappropriate = to put it in those documents. NameConstraints are exclusively a PKIX-internal(!) thing. For an RP, NameC= onstraints processing is completely hidden inside the certificate path vali= dation function of the PKIX module. One possible approach might be to add a new optional input parameter (k) to= rfc-5280 6.1.1 so that the caller can identify the desired key purpose(s)= , and then extend the processing in rfc-5280 6.1.3 (c) for two conditions: - if the application caller supplied the id-kp-serverAuth as input, check whether the cert is allowed for id-kp-serverAuth should it be purpose-limited by an EKU extension, and if EKU id-kp-serverAuth is asserted, process DNSName constraints for every CN=3D Attributes in the subject DName. - if the application caller supplied the id-kp-emailProtection as input, check whether the cert is allowed for id-kp-emailProtection should it be purpose-limited by an EKU extension, and if EKU id-kp-emailProtectio= n is asserted, process rfc822Name constraints for every pkcs9_emailAddres= s Attributes in the subject DName. -Martin From mrex@sap.com Thu Apr 12 18:45:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9497321F8712 for ; Thu, 12 Apr 2012 18:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.071 X-Spam-Level: X-Spam-Status: No, score=-10.071 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n0gIAMxfg4H for ; Thu, 12 Apr 2012 18:45:26 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DBD0D21F86FC for ; Thu, 12 Apr 2012 18:45:25 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3D1jMTq006537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Apr 2012 03:45:23 +0200 (MEST) From: Martin Rex Message-Id: <201204130145.q3D1jMk0029680@fs4113.wdf.sap.corp> To: SChokhani@cygnacom.com (Santosh Chokhani) Date: Fri, 13 Apr 2012 03:45:22 +0200 (MEST) In-Reply-To: from "Santosh Chokhani" at Apr 12, 12 09:29:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 01:45:26 -0000 Santosh Chokhani wrote: > > I was thinking something simpler: Just like RFC 5280 describes name > constraints for RFC 822 names need to be enforced when they appear in DN, > they need to be enforced on DNS name when they appear in CN. pkcs9-emailAddress is a fairly non-ambiguous attribute label, so applying rfc822Name constraints processing need not necessarily be limited to the emailProtection purpose. The situation with 2.5.4.cn(3) might be different, where applying DNSName constraints should probably be limited to purposes of id-kp-serverAuth. -Martin PS: I hadn't noticed the graf about pkcs9-emailAddress on rfc5280 page41 that appears mislocated because it is seperated from the description of the EMail constraints processing with the description of DNSName processing. Btw. limiting the constraints to situations where no subjectAltName is present seems _very_ wrong, because the application code looking at cert attributes and the PKIX code processing name constraints are _very_ often independently maintained! From SChokhani@cygnacom.com Thu Apr 12 19:03:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E7821F85FD for ; Thu, 12 Apr 2012 19:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWBRR-gL9MXR for ; Thu, 12 Apr 2012 19:03:00 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1420E21F8576 for ; Thu, 12 Apr 2012 19:02:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,414,1330923600"; d="scan'208";a="4694705" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 12 Apr 2012 22:02:55 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 12 Apr 2012 22:02:55 -0400 From: Santosh Chokhani To: "mrex@sap.com" Date: Thu, 12 Apr 2012 21:58:10 -0400 Thread-Topic: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Thread-Index: Ac0ZFxiSzfTihzUuRG2oFhdR69JS3QAAWW7w Message-ID: References: from "Santosh Chokhani" at Apr 12, 12 09:29:21 pm <201204130145.q3D1jMk0029680@fs4113.wdf.sap.corp> In-Reply-To: <201204130145.q3D1jMk0029680@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 02:03:01 -0000 Good points. I would like to apply name constraints to a field for appropriate name for= m if a relevant RFC says that the application can use value from that fiel= d as a application specific name. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Thursday, April 12, 2012 9:45 PM To: Santosh Chokhani Cc: mrex@sap.com; pkix@ietf.org Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Santosh Chokhani wrote: >=20 > I was thinking something simpler: Just like RFC 5280 describes name=20 > constraints for RFC 822 names need to be enforced when they appear in=20 > DN, they need to be enforced on DNS name when they appear in CN. pkcs9-emailAddress is a fairly non-ambiguous attribute label, so applying r= fc822Name constraints processing need not necessarily be limited to the ema= ilProtection purpose. The situation with 2.5.4.cn(3) might be different, where applying DNSName c= onstraints should probably be limited to purposes of id-kp-serverAuth. -Martin PS: I hadn't noticed the graf about pkcs9-emailAddress on rfc5280 page41 th= at appears mislocated because it is seperated from the description of the E= Mail constraints processing with the description of DNSName processing. Bt= w. limiting the constraints to situations where no subjectAltName is presen= t seems _very_ wrong, because the application code looking at cert attribut= es and the PKIX code processing name constraints are _very_ often independe= ntly maintained! From mrex@sap.com Thu Apr 12 20:42:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491E321F858D for ; Thu, 12 Apr 2012 20:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.177 X-Spam-Level: X-Spam-Status: No, score=-9.177 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeDm779S48dt for ; Thu, 12 Apr 2012 20:42:48 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id EEC4F21F85A2 for ; Thu, 12 Apr 2012 20:42:47 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3D3gi5X018926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Apr 2012 05:42:45 +0200 (MEST) From: Martin Rex Message-Id: <201204130342.q3D3girC006607@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Fri, 13 Apr 2012 05:42:44 +0200 (MEST) In-Reply-To: <201204130032.q3D0WLTZ025519@fs4113.wdf.sap.corp> from "Martin Rex" at Apr 13, 12 02:32:21 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 03:42:49 -0000 Having looked more closely at what apps/verify.c really does, it is shooting itself in the foot with respect to the "OK" output, because apps/verify.c insert a callback function that converts X509_V_ERR_UNHANDLED_CRITICAL_EXTENSION into "OK"... I'm sorry for spreading confusion to others (I am still confused myself). -Martin Martin Rex wrote: > > Passing that customers cert-chain to openssl (0.9.8j-fips) on our newest > SLES-11sp1 machines, results in a confusing output: > > openssl verify -verbose -CAfile root.pem -untrusted pathcerts.pem -purpose sslserver server.cer > server.cer: /DC=dir/DC=... > error 34 at 1 depth lookup:unhandled critical extension > OK > > What does this tell me? I would have expected either an error > or an OK, but not both! > > apps/verify.c looks like this: > i=X509_verify_cert(csc); > X509_STORE_CTX_free(csc); > > ret=0; > end: > if (i > 0) > { > fprintf(stdout,"OK\n"); > ret=1; > } > > and the documentation for X509_verify_cert() says this: > http://www.openssl.org/docs/crypto/X509_verify_cert.html > > RETURN VALUES > > If a complete chain can be built and validated this function returns 1 ... > > NOTES > > Applications rarely call this function directly but it is used by OpenSSL > internally for certificate validation, in both the S/MIME and SSL/TLS code. > > > which looks to me like OpenSSL-0.9.8x is (silently) ignoring critical > name constraints. > > > -Martin > > > btw. I consider the context-sensitive syntax rule for the > ASN.1 type GeneralName extremely confusing! > From anders.rundgren@telia.com Thu Apr 12 21:24:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392E321F8778 for ; Thu, 12 Apr 2012 21:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IfZF1TFTqe5 for ; Thu, 12 Apr 2012 21:24:12 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 2711121F8771 for ; Thu, 12 Apr 2012 21:24:11 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB81D008A5C12; Fri, 13 Apr 2012 06:24:07 +0200 Message-ID: <4F87AA5F.9060608@telia.com> Date: Fri, 13 Apr 2012 06:23:59 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: swilson@lockstep.com.au References: <4F856D3A.1060103@telia.com> <4F85E303.3090700@lockstep.com.au> <4F866EFF.3020207@telia.com> <4F86AADC.10906@lockstep.com.au> <4F86B2F3.7090406@telia.com> <4F874603.8070204@lockstep.com.au> In-Reply-To: <4F874603.8070204@lockstep.com.au> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 04:24:16 -0000 On 2012-04-12 23:15, Stephen Wilson wrote: > > I see. Sorry, I did read "enrolment" as meaning sign up. And I thought > you were talking to the (overstated) issue of multiple credentials. > > So I agree with you. I wish that people got smartcards instead of > anything else. And I wish that device manufacturers standardised on > built-in smartcard readers, as they started to in 2003 after Microsoft > put smartcard support into their software stack. a decade later, I can > see a new wave of smartcard use now that NFC/wifi components can be > co-opted to read/write contactless smartcards. In principle it's an > easy matter for a PIV card to connect to any NFC enabled device. We > could get read of the dreaded smartcard reader problem overnight. My perspective on this is slightly different. IMO this issue (as well as PKI...) is essentially "owned" by three major laggards: Governments, Banks, and Microsoft. Since the first two are numerous as well as geographically and culturally diverse it would be wrong giving them the blame. However, since they to some 90% have relied on a single client-OS vendor, the generally pitiful state of client-side PKI in consumer PCs is unilaterally due to Microsoft's limited of understanding of this market. Over the years I have met quite a bunch of Microsoft Program Managers and they all say the same thing: "There is no business case for consumer PKI". In some way this is also true since there is no paying customer out there. Due to that, the banks in the EU that actually use consumer PKI have been forced developing their own client-side software. I guess Stefan (PKIX co-char), never told that to his boss when he worked for Microsoft (in the US a subordinate typically gets fired if he/she criticizes company strategy). This has and still is the primary motivation behind my enrollment "crusade". However, it is also possible that the whole idea reviving traditional PCs is toast, it is really the mobile devices that are in the center these days. Here there won't be any EMV cards so you need an on-line enrollment system to provision virtual (running in embedded security HW), EMV, SIM, PIV etc etc. The smart card industry is desperately trying to get a piece of the cake: http://www.globalplatform.org/documents/Consumer_Centric_Model_White_PaperMar2012.pdf It is essentially Google and Apple that run this show nowadays. Since they also have the services, there is an entirely new motivation these days. Anyway, PKIX won't be there when it actually happens; that's for sure!!! Cheers, Anders > > Instead of Facebook ... if banks said "the hell with online fraud and ID > theft, and the hell with craziness like 3D Secure -- let's instead use > EMV smartcards for Internet payments" ... we would see all those laptop > and tablet manufacturers rush to reinstate card readers in their > products. As an engineering exercise, it's nearly trivial. The > decision to prioritise smartcard readers in computers is a product > marketing question. We just need a killer app, like payments, to make > the decision worthwhile. > > Cheers, > > Steve Wilson > Lockstep > http://lockstep.com.au/blog/smartcards > > > > > On 12/04/2012 8:48 PM, Anders Rundgren wrote: >> On 2012-04-12 12:13, Stephen Wilson wrote: >>> Anders, >>> >>> But that's not any sort of PKI challenge is it? It's even less a PKIX >>> specific issue. Rather you've stated a broad federated identity vision. >> Stephen, >> I guess you have interpreted enrollment as some kind of sign-up procedure? >> >> This is of course a part of enrollment on the web but that's the beauty of >> the web; you can sign-up for anything. What's missing (IMO...) is a way to >> enroll that instead of providing you with yet another usersid/password >> combination, equips you with an X.509 certificate and matching private key. >> >> The universality of issued credentials is completely out-of-scope for >> this proposal, anything else would be silly. If providers believe that >> passwords are more suited to their risk management concepts they should >> of course continue with passwords. This proposal is about offering a >> useful alternative. >> >> The level of identity verification applied during enrollment is also >> out-of-scope since this is fairly technology independent. >> >> I agree that this is not a PKIX issue but that has more to do with IETF >> legacy (IETF do not make browser standards) than with the actual question. >> >> Do you think that Facebook should purchase and securely distribute 500 000 000 >> smart cards in order to improve their login solution? >> >> Anders >> >> >>> And on federated identity, I have to say that the dream of a >>> one-size-fits-all identity (or identification/enrolment as you frame it) >>> is impractical. Of late I have been thinking and publishing about >>> digital identity through an ecological lens. I have concluded that the >>> diversity of identities we see today is a result of natural selection. >>> If a single all-purpose identity was beneficial (nett nett), then I >>> reckon natural selection would have delivered it already, maybe >>> commercially. Especially commercially! But no, even in countries with >>> national identity systems, these things are NOT used universally in >>> commerce. Instead, everywhere in the world has siloed banking >>> identities, health IDs, employee IDs, and all manner of customer >>> reference numbers. This is because identification protocols (which are >>> just one element in risk management) have to be precisely matched to >>> local environmental conditions. It's the first rule of risk management: >>> understand your own business and adopt risk management ploys that are >>> suited to your circumstances. Risk management orthodoxy works against >>> universality. Thus there is no universal identification protocol that >>> delivers knowledge of the customer suitable for all conceivable >>> applications. >>> >>> See also >>> http://lockstep.com.au/library/identity_authentication/an-ecological-theory-of-digit.html >>> >>> and >>> http://lockstep.com.au/blog/federated-identity >>> >>> Cheers, >>> >>> Steve Wilson >>> Lockstep. >>> >>> >>> >>> >>> On 12/04/2012 3:58 PM, Anders Rundgren wrote: >>>> On 2012-04-11 22:01, Stephen Wilson wrote: >>>>> My comment is that client side certificate management needs fixing as >>>>> much as client side car maintenance. Why do it? >>>> CONDENSED RATIONALE >>>> >>>> Currently people login to various services on the Internet; often several times >>>> per day. In the majority of cases they use a userid/password combination for login. >>>> Quite a bunch of these users (including myself) try to reduce the awkwardness of >>>> this system by reusing passwords at different sites. >>>> >>>> When you pay for stuff on the Internet you typically use non-secure(d) credit-card >>>> credentials. >>>> >>>> PROPOSAL >>>> >>>> A consumer-oriented on-line enrollment system would IMHO be the single most efficient >>>> measure for enabling us to slowly but surely move away from static passwords and payment >>>> systems that were designed in another time and for another purpose. >>>> >>>> >>>> If somebody has a better suggestion, I encourage you to present it. >>>> >>>> -- Anders Rundgren >>>> >>>> >>>> >>>>> PKI is the classic case of a technology that appalls in the rough but is >>>>> indispensible when embedded. My list of successful client side PKI >>>>> deployment includes EMV DDA chip cards, the health cards of Austria, >>>>> Taiwan, Thailand, Malaysia, France and others, the Estonia government >>>>> services card, CAC, PIV and Skype. >>>>> >>>>> See http://lockstep.com.au/blog/2011/01/16/embedded-pki-on-the-cards.html >>>>> >>>>> General purpose, naked, personal digital certificates are of historical >>>>> interest only! PKI should not be about creating a vertically integrated >>>>> identity certificate management process. It should be about taking >>>>> existing relationships and instantiating them in special purpose digital >>>>> certificates congruent with those relationships. >>>>> >>>>> See http://lockstep.com.au/library/pki/relationship_certificates.html >>>>> >>>>> Cheers, >>>>> >>>>> Steve Wilson >>>>> Lockstep >>>>> http://lockstep.com.au/library/pki >>>>> >>>>> >>>>> >>>>> >>>>> On 11/04/2012 9:38 PM, Anders Rundgren wrote: >>>>>> Dear All, >>>>>> >>>>>> It seems that there's no end to the amount of time and energy available for >>>>>> addressing various short-comings of the SSL PKI. This is of course very good. >>>>>> >>>>>> What's a little bit less understandable is why the interest in making client-side PKI >>>>>> more useful is close to zero. It is true that there isn't any money to make on the >>>>>> software and protocols. However, the availability of usable PKI clients will pay itself >>>>>> through indirect means (more CAs, more services and less security breaches). >>>>>> >>>>>>> From a security point of view it is important to realize that even if the SSL PKI or DNS >>>>>> get corrupted, a client-PKI-based login to "badbank.com" won't give "badbank.com" >>>>>> any access to "goodbank.com". Using static passwords (the current "standard"), >>>>>> all bets are off, not to mention how well shared passwords work... >>>>>> >>>>>> The current PKI enrollment solutions (maybe with Apple's iPhone scheme as a >>>>>> notable exception) are close to useless for consumers. >>>>>> >>>>>> The SSL credential selection GUIs are also based on ideas that only PKI geeks >>>>>> can possibly appreciate. Many service providers feel it would be downright >>>>>> embarrassing offering such a clunky interface to their users. >>>>>> >>>>>> The majority of issuers of consumer-PKI have therefore developed their own >>>>>> client-side PKI software which address things like GUI, PINs, X-platform, etc. >>>>>> >>>>>> IMHO, fixing a little bit here and there in a completely uncoordinated fashion >>>>>> will never return an interoperable and useful foundation for consumer-PKI. >>>>>> >>>>>> Comments? >>>>>> >>>>>> Anders >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 hallam@gmail.com Fri Apr 13 08:19:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E24521F8741 for ; Fri, 13 Apr 2012 08:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNyVdq4X0YWp for ; Fri, 13 Apr 2012 08:19:35 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5539F21F872F for ; Fri, 13 Apr 2012 08:19:35 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1895280yhk.31 for ; Fri, 13 Apr 2012 08:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nHQDXbkEplVmO2NLtRbVNM9nMlPCkvQM5njca29sHBo=; b=m3kzlLG5bRWgf3j+BK0apKwtA8SrfLG9EjW2DKdbmpsfWVVkzUXQ0icN2WjuFTI+tK bHAQOu6lkQjGtnBaTamYgGIuduDLNVXH38r9tjMofDUA82nfiKh4tSlEPaCi4BI10WgL 8dxUjuVs0j/BRT88Y8N7m5xT3ARIMckfJTlrzlkDM1qXydXv06ct4gxcxFatPtwW1+4h 91YlYYz31GVHRTpCaQhmrYrcCJ7S+bbnLEyEmXhWTXwExGkReJ9o+JeUNuSdMBtozggM NBNLwq01dYMQbihAJUAgYlh9zEMWPmrpNcCJtyrOFCYfokyW8URzUCExKwjh49m/KzxT oquA== MIME-Version: 1.0 Received: by 10.60.3.99 with SMTP id b3mr2555251oeb.72.1334330374806; Fri, 13 Apr 2012 08:19:34 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Fri, 13 Apr 2012 08:19:34 -0700 (PDT) In-Reply-To: References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> <0DFEAD5C-C1DB-48FA-81FA-A523464ABA9C@checkpoint.com> <4F867F55.8080809@free.fr> Date: Fri, 13 Apr 2012 11:19:34 -0400 Message-ID: From: Phillip Hallam-Baker To: "Kemp, David P." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Proposal: Change the Criticality Requirement of Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 15:19:36 -0000 I agree that users are best served by having secure devices. But in this particular case the rate of mis-issue incidents does not come anywhere close to justifying bricking the vast majority of mobile devices made thus far. I really can't see the justification for forcing the issue to a split between the commercial PKI world and the IETF. The CABForum BR guidelines are currently a profile of PKIX. If you continue to force the issue here they will end up as a profile of X.509v3. It is possible that there will be a re-combination at a later date, but do not count on that being inevitable. The critical mass of the cryptography industry has been in the commercial sector for 15 years now. This particular forum has given the younger engineers no real stake in or ability to influence a process that consists of them watching their ideas being trampled by folk making bogus appeals to their own authority. I can build a more secure Internet without you, Kent and Santosh but I really do need their help. On Thu, Apr 12, 2012 at 8:52 AM, Kemp, David P. wro= te: > That depends on who decides whether a reason is good. =A0PKI does not > exist for the benefit of CA operators or subscribers (in this case, > server operators), it exists for the benefit of relying parties. =A0When = II > go to my bank web site, it is in my interest (not the bank's directly, > much less the CA's) to ensure that the site is what it claims to be. > > If security was a priority for me, I would do my banking on a device > that warned me if something was fishy over a device that provided no > such warning. =A0Name constraints provides the warning if the device > supports it, but not if the device doesn't support the extension and the > extension is non-critical. > > Delta CRLs can be misused to trick RPs without any mistakes by a CA. > Forged names require a CA to 1) make a mistake, 2) deliberately issue a > forged name, or 3) be induced to do so by an attacker. =A0But that > difference isn't sufficient to claim that one extension has a "good" > reason to be critical and the other does not. =A0In both cases the RP is > fooled and can suffer harm if the extension is non-critical, and the > harm could be prevented by making the extension critical. > > This discussion is whether interoperability is more important than > security, which in many cases it is. =A0But that doesn't mean that > avoiding security failures that could harm the RP is not a "good" > reason. > > I like Stephen Farrell's suggestion to be explicit about the reason for > making NC NC - it is an exception made for applications with significant > market share that do not yet support it, and the security of the > Internet would be improved when those applications are fixed and the > exception is no longer needed for interoperability. > > Dave > > > -----Original Message----- > From: Jean-Marc Desperrier >> >> At the end, the conclusion is : >> =A0- The difference between the two actually is that "Delta CRL > Indicator" >> =A0 =A0has a good reason to be critical and "Name Constraints" doesn't > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From anders.rundgren@telia.com Sun Apr 15 07:09:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7BB21F87AD for ; Sun, 15 Apr 2012 07:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7EMRUBHVmEv for ; Sun, 15 Apr 2012 07:09:47 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 74D2A21F87A5 for ; Sun, 15 Apr 2012 07:09:47 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E00CB5390 for pkix@ietf.org; Sun, 15 Apr 2012 16:09:45 +0200 Message-ID: <4F8AD69E.5020404@telia.com> Date: Sun, 15 Apr 2012 16:09:34 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> <0DFEAD5C-C1DB-48FA-81FA-A523464ABA9C@checkpoint.com> <4F867F55.8080809@free.fr> In-Reply-To: <4F867F55.8080809@free.fr> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pkix] Voting on the Proposal: Change the Criticality Requirement of Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 14:09:48 -0000 It seems like a moderately good idea sending out yet another bunch of messages to convince "the other camp" that they are wrong because *nobody is actually wrong*; it is (as often) rather a matter of principles and priorities. Since "Rough Consensus" obviously isn't achievable, a formal voting procedure could be used instead for settling this somewhat heated issue. The proposal is here: http://www.ietf.org/mail-archive/web/pkix/current/msg30734.html If the proposal is taken it means that this would eventually become a PKIX standard, otherwise the CAB forum's specifications would be the (non-PKIX-endorsed) alternative. FWIW, I cast my vote here: I'm for the proposal. Regards, Anders Rundgren From ynir@checkpoint.com Sun Apr 15 07:16:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700A821F8621 for ; Sun, 15 Apr 2012 07:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97Iw2aouWOmn for ; Sun, 15 Apr 2012 07:16:58 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0FF21F85FC for ; Sun, 15 Apr 2012 07:16:58 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3FEGs6V017389; Sun, 15 Apr 2012 17:16:54 +0300 X-CheckPoint: {4F8AE55D-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 15 Apr 2012 17:16:55 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sun, 15 Apr 2012 17:16:52 +0300 From: Yoav Nir To: Anders Rundgren Date: Sun, 15 Apr 2012 17:16:54 +0300 Thread-Topic: [pkix] Voting on the Proposal: Change the Criticality Requirement of Name Constraints Thread-Index: Ac0bEmdefxmojb6WSBCf4BrXPk609w== Message-ID: References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> <0DFEAD5C-C1DB-48FA-81FA-A523464ABA9C@checkpoint.com> <4F867F55.8080809@free.fr> <4F8AD69E.5020404@telia.com> In-Reply-To: <4F8AD69E.5020404@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11cbb7b1de73ea5c2314d993e71428f71c6f66e4c3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "pkix@ietf.org" Subject: Re: [pkix] Voting on the Proposal: Change the Criticality Requirement of Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 14:16:59 -0000 On Apr 15, 2012, at 5:09 PM, Anders Rundgren wrote: > It seems like a moderately good idea sending out yet another bunch of mes= sages to > convince "the other camp" that they are wrong because *nobody is actually= wrong*; > it is (as often) rather a matter of principles and priorities. >=20 > Since "Rough Consensus" obviously isn't achievable, a formal voting proce= dure could > be used instead for settling this somewhat heated issue. >=20 > The proposal is here: >=20 > http://www.ietf.org/mail-archive/web/pkix/current/msg30734.html >=20 > If the proposal is taken it means that this would eventually become a PKI= X standard, > otherwise the CAB forum's specifications would be the (non-PKIX-endorsed)= alternative. >=20 > FWIW, I cast my vote here: I'm for the proposal. "We reject ... and voting, we believe in rough consensus and ..." Having said that, +1 Yoav= From paul.hoffman@vpnc.org Sun Apr 15 07:31:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7596A21F87A4 for ; Sun, 15 Apr 2012 07:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpwKLUIU8bPn for ; Sun, 15 Apr 2012 07:31:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E534F21F87AE for ; Sun, 15 Apr 2012 07:30:59 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3FEUwbf088820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 15 Apr 2012 07:30:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Paul Hoffman In-Reply-To: Date: Sun, 15 Apr 2012 07:31:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2BCDACD0-E40E-4529-B4EA-C2959DC109E6@vpnc.org> References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> <0DFEAD5C-C1DB-48FA-81FA-A523464ABA9C@checkpoint.com> <4F867F55.8080809@free.fr> <4F8AD69E.5020404@telia.com> To: IETF PKIX X-Mailer: Apple Mail (2.1257) Subject: Re: [pkix] Voting on the Proposal: Change the Criticality Requirement of Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 14:31:00 -0000 The proposal is poorly worded. Changing the word "MUST" to "SHOULD" = without saying what the exception to the "SHOULD" are causes worse = security and insufficient guidance to those who would benefit from = changing their CA software. Anders: instead of you taking on the role of WG Chair, maybe you could = do a wee bit of work, like writing a clearer proposal. Given that = clarity is not your strong point, it still would help get what you and = others want here. If there is a solid proposal for "SHOULD be marked critical except Xyz", = the WG chairs should consider a consensus call. None of this affects CABForum's ability to do whatever they want on the = topic. --Paul Hoffman From anders.rundgren@telia.com Sun Apr 15 08:56:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E4321F87A5 for ; Sun, 15 Apr 2012 08:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nET8V6wZVTfc for ; Sun, 15 Apr 2012 08:56:20 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 9715C21F8794 for ; Sun, 15 Apr 2012 08:56:20 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E00CBBDB5; Sun, 15 Apr 2012 17:56:17 +0200 Message-ID: <4F8AEF95.2010704@telia.com> Date: Sun, 15 Apr 2012 17:56:05 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> <0DFEAD5C-C1DB-48FA-81FA-A523464ABA9C@checkpoint.com> <4F867F55.8080809@free.fr> <4F8AD69E.5020404@telia.com> <2BCDACD0-E40E-4529-B4EA-C2959DC109E6@vpnc.org> In-Reply-To: <2BCDACD0-E40E-4529-B4EA-C2959DC109E6@vpnc.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Voting on the Proposal: Change the Criticality Requirement of Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 15:56:21 -0000 On 2012-04-15 16:31, Paul Hoffman wrote: > The proposal is poorly worded. Changing the word "MUST" to "SHOULD" without saying > what the exception to the "SHOULD" are causes worse security and insufficient guidance > to those who would benefit from changing their CA software. > > Anders: instead of you taking on the role of WG Chair, maybe you could do a wee > bit of work, like writing a clearer proposal. > Given that clarity is not your strong point, Thanx :-) > it still would help get what you and others want here. As Rob wrote, he proposed a compromise. When I make specifications they just have to be implementable. Here is a condensed version of what I would put in an RFC. If the NC criticality bit is set, and the application doesn't support NC extensions, a confirming application MUST reject the certificate. If an application implements support for NC extensions a confirming application MUST process NCs as described. If the application implements support for NC extensions but doesn't recognize one or more NC objects under processing, a confirming application MUST reject the certificate. If the NC criticality bit is not set and the application doesn't support NC extensions, a confirming application MAY silently ignore NC processing altogether. Trying to squeeze in more stuff in the non-critical case would IMHO only lead to "slimy" code and specifications. This part more or less remains in "vendor land". Anders > > If there is a solid proposal for "SHOULD be marked critical except Xyz", the WG chairs should consider a consensus call. > > None of this affects CABForum's ability to do whatever they want on the topic. > > --Paul Hoffman > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From era@x500.eu Sun Apr 15 09:02:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A1321F8693 for ; Sun, 15 Apr 2012 09:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OldWS2X-YSa for ; Sun, 15 Apr 2012 09:02:20 -0700 (PDT) Received: from mail01.dandomain.dk (mail01.dandomain.dk [194.150.112.201]) by ietfa.amsl.com (Postfix) with ESMTP id D03CA21F868A for ; Sun, 15 Apr 2012 09:02:19 -0700 (PDT) Received: from Morten ([109.59.216.62]) by mail01.dandomain.dk (DanDomain Mailserver) with ASMTP id ZUR31917; Sun, 15 Apr 2012 18:02:17 +0200 From: "Erik Andersen" To: "'Anders Rundgren'" , "'Paul Hoffman'" References: <201204042241.q34MfOSx022936@fs4113.wdf.sap.corp> <0DFEAD5C-C1DB-48FA-81FA-A523464ABA9C@checkpoint.com> <4F867F55.8080809@free.fr> <4F8AD69E.5020404@telia.com> <2BCDACD0-E40E-4529-B4EA-C2959DC109E6@vpnc.org> <4F8AEF95.2010704@telia.com> In-Reply-To: <4F8AEF95.2010704@telia.com> Date: Sun, 15 Apr 2012 18:02:10 +0200 Message-ID: <000901cd1b21$22c0bde0$684239a0$@eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0bIFYJVhjEU57zTUybSzIvTVBAAAAALGMQ Content-Language: da Cc: 'IETF PKIX' Subject: Re: [pkix] Voting on the Proposal: Change the Criticality Requirement of Name Constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 16:02:20 -0000 Sounds like an echo of X.509 Eri -----Oprindelig meddelelse----- Fra: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] P=E5 vegne af = Anders Rundgren Sendt: 15. april 2012 17:56 Til: Paul Hoffman Cc: IETF PKIX Emne: Re: [pkix] Voting on the Proposal: Change the Criticality = Requirement of Name Constraints On 2012-04-15 16:31, Paul Hoffman wrote: > The proposal is poorly worded. Changing the word "MUST" to "SHOULD"=20 > without saying what the exception to the "SHOULD" are causes worse=20 > security and insufficient guidance to those who would benefit from changing their CA software. >=20 > Anders: instead of you taking on the role of WG Chair, maybe you could = > do a wee bit of work, like writing a clearer proposal. > Given that clarity is not your strong point, Thanx :-) > it still would help get what you and others want here. As Rob wrote, he proposed a compromise. When I make specifications they = just have to be implementable. Here is a condensed version of what I would = put in an RFC. If the NC criticality bit is set, and the application doesn't support NC extensions, a confirming application MUST reject the certificate. If an application implements support for NC extensions a confirming application MUST process NCs as described. If the application = implements support for NC extensions but doesn't recognize one or more NC objects = under processing, a confirming application MUST reject the certificate. If the NC criticality bit is not set and the application doesn't support = NC extensions, a confirming application MAY silently ignore NC processing altogether. Trying to squeeze in more stuff in the non-critical case would IMHO only lead to "slimy" code and specifications. This part more or less remains = in "vendor land". Anders >=20 > If there is a solid proposal for "SHOULD be marked critical except = Xyz", the WG chairs should consider a consensus call. >=20 > None of this affects CABForum's ability to do whatever they want on = the topic. >=20 > --Paul Hoffman >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From tgindin@us.ibm.com Tue Apr 17 06:17:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5711E8074 for ; Tue, 17 Apr 2012 06:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.342 X-Spam-Level: X-Spam-Status: No, score=-10.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Op4e1NGVaRPs for ; Tue, 17 Apr 2012 06:17:51 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 159E421F85E1 for ; Tue, 17 Apr 2012 06:17:50 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 17 Apr 2012 09:17:49 -0400 Received: from d01dlp02.pok.ibm.com (9.56.224.85) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 17 Apr 2012 09:16:51 -0400 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id B07D06E804C for ; Tue, 17 Apr 2012 09:16:50 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3HDGoXY255206 for ; Tue, 17 Apr 2012 09:16:50 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3HDGoUb014561 for ; Tue, 17 Apr 2012 09:16:50 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3HDGoqn014557; Tue, 17 Apr 2012 09:16:50 -0400 In-Reply-To: <4F872402.80409@nist.gov> References: <4B7FDE14-5E2E-45B8-AD50-4ACD24557338@vpnc.org> <4F872402.80409@nist.gov> To: "David A. Cooper" MIME-Version: 1.0 X-KeepSent: 1FA58C25:FBEBDB38-852579E2:00755297; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Tue, 17 Apr 2012 09:16:49 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/17/2012 09:16:49, Serialize complete at 04/17/2012 09:16:49 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12041713-9360-0000-0000-0000057B94A2 Cc: IETF PKIX , Paul Hoffman Subject: Re: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and As name/policy constraints X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 13:17:55 -0000 That is certainly a strong reason for such a cross-certificate to use a critical name constraint. It doesn't mean that hierarchical certificates' name constraints need to be critical. Is there any generalizable advice which this case leads to? The narrowest I can think of is roughly "When a CA specifies a name constraint in a cross-certificate that is intended to exclude many of the certificates legitimately issued by the subject of that cross-certificate, that name constraint SHOULD be marked critical". Tom Gindin From: "David A. Cooper" To: Paul Hoffman , Cc: IETF PKIX Date: 04/12/2012 02:52 PM Subject: Re: [pkix] Proposed addition to draft-ietf-pkix-rfc5280-clarifications about criticality and As name/policy constraints Sent by: pkix-bounces@ietf.org Paul, As I noted in my previous messages, it is a mistake to only think about public roots, hierarchical PKIs, and sub-CAs. The example that I used was the DoD Root CA. DoD has a policy of only accepting (as a relying party) certificates issued at the Medium Hardware and High assurance levels. It reflects this policy in its cross-certificate to the Federal Bridge CA by including a critical policyConstraints extension. The Federal Bridge CA is not a sub-CA of the DoD Root and the inclusion of the constraints extension by DoD is not to notify DoD relying parties that the Federal PKI is not supposed to be issuing certificates at lower assurance levels. The constraints extension is enforcing on DoD relying parties that they may only accept the subset of Federal PKI-issued certificates that have been issued at an assurance level acceptable to DoD. This is very different from a hierarchical PKI, in which a CA may procedurally limit what certificates a sub-CA may issue. In this case it would likely be a sign of an error if a sub-CA issued a certificate that did not satisfy a constraint (policyConstraints or nameConstraints) specified in a cross-certificate issued to the sub-CA. In the non-hierarchical case, failure to process a constraints extension will lead to the relying party accepting certificates that it should not be accepting. In the hierarchical case, failure to process a constraints extension will only lead to the relying party accepting certificates that it should not be accepting if a sub-CA issued a certificate that it shouldn't have issued (and the bad certificate does not satisfy the constraint). Dave On 04/11/2012 07:34 PM, Paul Hoffman wrote: > On Apr 11, 2012, at 4:09 PM, Stefan Santesson wrote: >> Isn't what you intend to say the following: >> >> In cases where the CA need to enforce that relying parties rejects >> certificates issued outside of a set NC, the CA MUST mark this extension >> as critical. > No, not at all. A CA never needs to enforce anything on an RP. A CA might want to reduce its liability by constraining CAs under it, and if that CA believes that some RPs only trust the CA for some names or policies, the CA needs to alert the RP that sub-CAs have more constraints. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From kyanha@kyanha.net Tue Apr 17 14:43:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420F411E80BD for ; Tue, 17 Apr 2012 14:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.376 X-Spam-Level: * X-Spam-Status: No, score=1.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRJTNML1Ycdz for ; Tue, 17 Apr 2012 14:43:19 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8E58911E80B2 for ; Tue, 17 Apr 2012 14:43:19 -0700 (PDT) Received: by dady13 with SMTP id y13so12330783dad.27 for ; Tue, 17 Apr 2012 14:43:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type:x-gm-message-state; bh=MUnPpXAqRfhtMA8EvzcWrghrg54vreCT78rRFJCrqzs=; b=IY8+XSrvJMMKpFJc9MXTZeWyKr2XdrnIK9VPTdnqXLHy7SSKXUYQetJyjiUFIyaNab uJsN5Yjntufhb45En3VtoR59qlmWloZJi5wOlTNtElGfEwhBDh71SVflzxHUDB8jujAa BwWqGUPAr2X+nxY/jAzyd+1fNWd0I7ijjo091kj220W/0Eq9X48QGh4xRPGjV0a7PR0O eMOyWNZaY4gc9btIYtBE+WY/3Rz+IV3dtNBCETw8GdqFBqmNUmCbA4N7ChxEQ4xiUpj+ xpORCL+2GInM/hMv3hRn+MuMsP9Gn6cxciKqM5fpbAMxw1tCIw8cq9zWOjONMFIU+F1H glqw== Received: by 10.68.233.99 with SMTP id tv3mr795049pbc.8.1334698999049; Tue, 17 Apr 2012 14:43:19 -0700 (PDT) Received: from penango (user-64-9-237-162.googlewifi.com. [64.9.237.162]) by mx.google.com with ESMTPS id n8sm21750353pba.20.2012.04.17.14.43.17 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 14:43:18 -0700 (PDT) From: "Kyle Hamilton" To: "Anders Rundgren" Date: Tue, 17 Apr 2012 14:43:18 -0700 (Pacific Daylight Time) Message-ID: In-Reply-To: <4F856D3A.1060103@telia.com> References: <4F856D3A.1060103@telia.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.6eqh15hbmma278366dqf42 X-Gm-Message-State: ALoCoQnmnUNVzeI9naqHRdb/lXvPorWW04m9Y5mhxBbVGy/VcOxl74D8qAeJfIyhmGUzkoKdY18G Cc: "pkix@ietf.org" Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 21:43:20 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.6eqh15hbmma278366dqf42 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 DQpPbiBUaHUsIEFwciAxMiwgMjAxMiBhdCA5OjIzIFBNLCBBbmRlcnMgUnVuZGdyZW4gPGFuZGVy cy5ydW5kZ3JlbkB0ZWxpYS5jb20+IHdyb3RlOg0KPiBNeSBwZXJzcGVjdGl2ZSBvbiB0aGlzIGlz IHNsaWdodGx5IGRpZmZlcmVudC4goElNTyB0aGlzIGlzc3VlIChhcyB3ZWxsIGFzIFBLSS4uLikN Cj4gaXMgZXNzZW50aWFsbHkgIm93bmVkIiBieSB0aHJlZSBtYWpvciBsYWdnYXJkczogR292ZXJu bWVudHMsIEJhbmtzLCBhbmQgTWljcm9zb2Z0Lg0KDQpUaGlzIGlzc3VlIGlzICJvd25lZCIgYnkg SVNPLCB3aGljaCBtZWFucyB0aGF0IGl0J3Mgb24gdGhlIGdvdmVybm1lbnRzIHdobyBhcmUgcGFy dGljaXBhdGluZyBpbiBJU08uDQoNClRoZSBtb3N0IGltcG9ydGFudCBhc3BlY3Qgb2YgYW55IGFj Y2Vzcy1jb250cm9sIHN5c3RlbSAoZXNwZWNpYWxseSBmaW5hbmNpYWwpIGlzIGF1ZGl0YWJpbGl0 eSwgYW5kIHRoZSBJU08gc3RhbmRhcmRzIGRvbid0IGNhdXNlIGVub3VnaCBkYXRhIHRvIGJlIHRy YW5zbWl0dGVkIHRvIHRoZSBjcnlwdG9ncmFwaGljIGNvbnRhaW5lciBmb3IgdGhlIGNvbnRhaW5l ciB0byB3cml0ZSBpdHMgb3duIGF1ZGl0IGxvZ3MuICBQS0NTIzExIGV4cG9zZXMgSVNPIGZ1bmN0 aW9uYWxpdHksIHNvIGl0IGRvZXNuJ3QgaGF2ZSBhICJJJ20gc2VuZGluZyB5b3Ugc29tZXRoaW5n IHRoYXQgSSB3YW50IHlvdSB0byBkaWdlc3QgZm9yIG1lIiBjYWxsLiAgVGh1cywgd2UgaGF2ZSBu byBpZGVhIHRoYXQgdGhlIGRpZ2VzdHMgc3VibWl0dGVkIGFyZSBiZWluZyBjYWxjdWxhdGVkIGNv cnJlY3RseSwgYW5kIG5vIGlkZWEgd2hhdCB0aGUgZGlnZXN0cyB3ZSdyZSBzaWduaW5nIGFjdHVh bGx5IG1lYW4uDQoNCkluc3RlYWQsIHdlIGhhdmUgdG8gaW1wbGVtZW50IHRoZSBhdWRpdGluZyBz ZXJ2aWNlIGV4dGVybmFsbHksIHdoaWNoIG1lYW5zIHRoYXQgd2UgbXVzdCBiZSBhYmxlIHRvIHRy dXN0IHRoYXQgd2UgYXJlIHRoZSBzb2xlIGNvbnRyb2xsZXJzIG9mIHRoZSBjcnlwdG9ncmFwaGlj IGNvbnRhaW5lcnMgaW52b2x2ZWQuDQoNCj4gU2luY2UgdGhlIGZpcnN0IHR3byBhcmUgbnVtZXJv dXMgYXMgd2VsbCBhcyBnZW9ncmFwaGljYWxseSBhbmQgY3VsdHVyYWxseQ0KPiBkaXZlcnNlIGl0 IHdvdWxkIGJlIHdyb25nIGdpdmluZyB0aGVtIHRoZSBibGFtZS4goEhvd2V2ZXIsIHNpbmNlIHRo ZXkgdG8NCj4gc29tZSA5MCUgaGF2ZSByZWxpZWQgb24gYSBzaW5nbGUgY2xpZW50LU9TIHZlbmRv ciwgdGhlIGdlbmVyYWxseSBwaXRpZnVsDQo+IHN0YXRlIG9mIGNsaWVudC1zaWRlIFBLSSBpbiBj b25zdW1lciBQQ3MgaXMgdW5pbGF0ZXJhbGx5IGR1ZSB0byBNaWNyb3NvZnQncw0KPiBsaW1pdGVk IG9mIHVuZGVyc3RhbmRpbmcgb2YgdGhpcyBtYXJrZXQuIKBPdmVyIHRoZSB5ZWFycyBJIGhhdmUg bWV0IHF1aXRlDQo+IGEgYnVuY2ggb2YgTWljcm9zb2Z0IFByb2dyYW0gTWFuYWdlcnMgYW5kIHRo ZXkgYWxsIHNheSB0aGUgc2FtZSB0aGluZzoNCj4gIlRoZXJlIGlzIG5vIGJ1c2luZXNzIGNhc2Ug Zm9yIGNvbnN1bWVyIFBLSSIuIKBJbiBzb21lIHdheSB0aGlzIGlzIGFsc28NCj4gdHJ1ZSBzaW5j ZSB0aGVyZSBpcyBubyBwYXlpbmcgY3VzdG9tZXIgb3V0IHRoZXJlLg0KDQpBaCwgTWljcm9zb2Z0 IHNwcmVhZGluZyBsaWVzIGFnYWluLg0KDQpUaGVyZSBpcyBubyBidXNpbmVzcyBjYXNlIGZvciBk aXNjYXJkaW5nIEFwYWNoZSBodHRwZCdzIFNTTFZlcmlmeUNsaWVudCBvcHRpb25hbF9ub19jYSwg YnV0IGl0J3MgZGlzY2FyZGVkIGJ5IHRoZSB0ZWNobmljYWwgcGVvcGxlIGJlY2F1c2UgaXRzIGRv Y3VtZW50YXRpb24gc2F5cyB0aGF0ICJvcHRpb25hbF9ub19jYSBpcyBhY3R1YWxseSBhZ2FpbnN0 IHRoZSBpZGVhIG9mIGF1dGhlbnRpY2F0aW9uIi4gIEluc3RlYWQsIHdlIGVuZCB1cCB3aXRoIGFw cGxpY2F0aW9ucyB3aGljaCBoYW5kbGUgdGhlaXIgb3duIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBl cnJvciBmbG93cyBiZWNhdXNlIG9wdGlvbmFsX25vX2NhIGlzIGluIGZhY3QgdGhlIG9ubHkgd2F5 IHRvIHByZXNlbnQgYSBjdXN0b20gZXJyb3IgcGFnZSB3aGVuIHBlb3BsZSBpbmFkdmVydGVudGx5 IHRyeSB0byBsb2cgaW4gd2l0aCB0aGUgd3JvbmcgY2VydGlmaWNhdGUgb3IgYmVmb3JlIHRoZXkn dmUgZXZlciBiZWVuIGlzc3VlZCBhIGNlcnRpZmljYXRlIGZvciB0aGUgc2VydmljZSBpbiBxdWVz dGlvbi4NCg0KVGhlcmUgaXMgbm8gYnVzaW5lc3MgY2FzZSBmb3IgY29uc3VtZXIgWC41MDktYXMt dGllZC10by1YLjUwMC4gIFRoZXJlIGlzIGEgYnVzaW5lc3MgY2FzZSBmb3IgZW5yb2xsaW5nIHlv dXIgc2l0ZSdzIG93biBjcmVkZW50aWFscy4gIFRoZXJlIGlzIGEgYnVzaW5lc3MgY2FzZSBmb3Ig d2hpc3BlcmluZyB0byBhIGZyaWVuZC4gIChUaGUgcHJvYmxlbSBpcyB0aGF0IGF0dGVtcHRzIGxp a2UgdGhpcyB0byByZXB1cnBvc2UgWC41MDkgYXJlIG1hbGlnbmVkIGJ5IGUuZy4gRmlyZWZveC4p DQoNCj4gRHVlIHRvIHRoYXQsIHRoZSBiYW5rcyBpbiB0aGUgRVUgdGhhdCBhY3R1YWxseSB1c2Ug Y29uc3VtZXIgUEtJIGhhdmUgYmVlbg0KPiBmb3JjZWQgZGV2ZWxvcGluZyB0aGVpciBvd24gY2xp ZW50LXNpZGUgc29mdHdhcmUuIKBJIGd1ZXNzIFN0ZWZhbiAoUEtJWA0KPiBjby1jaGFyKSwgbmV2 ZXIgdG9sZCB0aGF0IHRvIGhpcyBib3NzIHdoZW4gaGUgd29ya2VkIGZvciBNaWNyb3NvZnQgKGlu IHRoZQ0KPiBVUyBhIHN1Ym9yZGluYXRlIHR5cGljYWxseSBnZXRzIGZpcmVkIGlmIGhlL3NoZSBj cml0aWNpemVzIGNvbXBhbnkgc3RyYXRlZ3kpLg0KDQouLi5zbyB3aHkgaGF2ZW4ndCB0aGV5IGdv dHRlbiB0b2dldGhlciB0byBmdW5kIHRoZSBkZXZlbG9wbWVudCBvZiBhIHVuaWZpZWQgaW50ZXJm YWNlPyAgV2h5IGhhdmVuJ3QgdGhleSBjb250cmlidXRlZCB0aGVpciBxdWFudHVtIGxlYXBzIGlu IGNsaWVudCBQS0kgcHJlc2VudGF0aW9uPyAgSG93IG11Y2ggb2YgdGhlIGJsYW1lIGxpa2VzIGlu IHRoZWlyIGRlc2lyZSB0byBoYXZlIGEgcHJvcHJpZXRhcnkgZWRnZT8NCg0KPiBUaGlzIGhhcyBh bmQgc3RpbGwgaXMgdGhlIHByaW1hcnkgbW90aXZhdGlvbiBiZWhpbmQgbXkgZW5yb2xsbWVudCAi Y3J1c2FkZSIuDQo+IEhvd2V2ZXIsIGl0IGlzIGFsc28gcG9zc2libGUgdGhhdCB0aGUgd2hvbGUg aWRlYSByZXZpdmluZyB0cmFkaXRpb25hbCBQQ3MgaXMNCj4gdG9hc3QsIGl0IGlzIHJlYWxseSB0 aGUgbW9iaWxlIGRldmljZXMgdGhhdCBhcmUgaW4gdGhlIGNlbnRlciB0aGVzZSBkYXlzLg0KDQpJ IGFtIG9mIHRoZSBvcGluaW9uIHRoYXQgImVucm9sbG1lbnQgaXMgY2hlYXAsIHZlcmlmaWNhdGlv biBpcyBleHBlbnNpdmUuIiAgT25jZSB0aGUgaWRlbnRpdHkgaXMgdmVyaWZpZWQsIHRoZXJlJ3Mg bm8gcmVhc29uIGF0IGFsbCB0byBhdm9pZCBlbnJvbGxpbmcgYWRkaXRpb25hbCBrZXlzIGFuZCBs aW5raW5nIHRoZW0gdG8gdGhlIHNhbWUgcmVjb3JkLCBhcyBsb25nIGFzIHlvdSBkZWZpbmUgdGhl IGVucm9sbG1lbnQgcHJvY2VzcyBhcyBtb3JlIHRoYW4ganVzdCB0aGUgYXBwbGljYXRpb24gb2Yg YSBzaW5nbGUga2V5IHBlci1wYXJ0eS4NCg0KV2hhdCdzIGhhcHBlbmVkIHRvIHRoaXMgcG9pbnQg aXMgdGhhdCBub2JvZHkncyBib3RoZXJlZCB0byBhdXRoZW50aWNhdGUgdGhlIGtleXN0b3JlIG9u IGVhY2ggaW5kaXZpZHVhbCBkZXZpY2UsIHNvIHRoZSBrZXlzdG9yZSBpdHNlbGYgY2FuJ3QgYXNz ZXJ0IHRoYXQgaXQgZ2VuZXJhdGVkIHRoZSBrZXkgd2l0aCBrbm93bGVkZ2Ugb2YgdGhlIHBvbGlj eSBnb3Zlcm5pbmcgc2FpZCBrZXkgZ2VuZXJhdGlvbi4gIElmIHRoZSBlbnJvbGxpbmcgY2VydGlm aWVyIGhhcyBldmlkZW5jZSB0aGF0IHRoZSBrZXkgd2FzIGdlbmVyYXRlZCBwcm9wZXJseSAtYW5k LSB0aGF0IGl0IHdhcyBzdWJtaXR0ZWQgYnkgdGhlIHByaW5jaXBhbCwgaXQgY2FuIHNlY3VyZWx5 IGVucm9sbCBhZGRpdGlvbmFsIGtleXMuDQoNClRoaXMgaXMgbm90IGltcG9zc2libGUuICBJdCBq dXN0IHJlcXVpcmVzIGV4YW1pbmluZyB0aGluZ3MgaW4gdGhlICJob3cgY2FuIEkgZ2V0IHBhc3Qg dGhpcyBwcm9ibGVtPyIgaW52ZW50aW5nIG1pbmRzZXQuDQoNCj4gSXQgaXMgZXNzZW50aWFsbHkg R29vZ2xlIGFuZCBBcHBsZSB0aGF0IHJ1biB0aGlzIHNob3cgbm93YWRheXMuIKBTaW5jZSB0aGV5 DQo+IGFsc28gaGF2ZSB0aGUgc2VydmljZXMsIHRoZXJlIGlzIGFuIGVudGlyZWx5IG5ldyBtb3Rp dmF0aW9uIHRoZXNlIGRheXMuDQo+DQo+IEFueXdheSwgUEtJWCB3b24ndCBiZSB0aGVyZSB3aGVu IGl0IGFjdHVhbGx5IGhhcHBlbnM7IHRoYXQncyBmb3Igc3VyZSEhIQ0KDQouLi51bmxlc3MgZXZl cnlvbmUgd2hvJ3MgdGVycmlmaWVkIG9mIGNoYW5naW5nIGFueXRoaW5nIGZvciBmZWFyIG9mIFZp b2xhdGluZyBUaGUgUHVyaXR5IE9mIFRoZSBEZXNpZ24gU3BlYyBpcyBzdW1tYXJpbHkgcmVtb3Zl ZCBmcm9tIHRoZSBvcmdhbml6YXRpb24sIGFueXdheS4gIFdlIG5lZWQgdG8gbWFrZSB0aGlzIHdv cmsuICBJdCdzIHVuYWNjZXB0YWJsZSB0aGF0IHdlIGdpdmUgZXhjdXNlcyBtdWNoIGxpa2UgInlv dSBkaWRuJ3QgY3JlYXRlIHRoaXMgc2lnbmF0dXJlIHVuZGVyIHRoZSBkYXJrIG9mIHRoZSBtb29u IHdpdGggdGhlIGJsb29kIG9mIGEgc2FjcmlmaWNlZCBjaGlja2VuIG9uIGEgcml0dWFsbHkgc2Fu Y3RpZmllZCBzaWx2ZXIgZGFnZ2VyIHdhc2hlZCBpbiB0aGUgdGVhcnMgb2YgYSB2aXJnaW4uLi4g c28gd2UncmUganVzdCBnb2luZyB0byBpbnRlcmZlcmUgd2l0aCBhbmQgcHJldmVudCB5b3UgZnJv bSBkb2luZyB0aGUgd29yayB5b3UgbmVlZCB0byBkby4iDQoNCkkgbWVhbiBubyBvZmZlbnNlLCBi dXQgdGhpcyByZWFsbHkgbmVlZHMgdG8gYmUgc2FpZC4gIFRoZSBQS0kgUHJpZXN0aG9vZCBpcyBs aWtlIHRoZSByaWdpZCBoaWVyYXJjaHkgb2YgVmF0aWNhbiBDYXRob2xpY2lzbSBtaXhlZCB3aXRo IHRoZSAib2ggR29kIHBsZWFzZSBsZXQgdGhpcyBiZSBzdWZmaWNpZW50IHRvIG5vdCBkbyB3aGF0 IEkgZmVhciBZb3Ugd2lsbCIgYW5kIGtvc2hlciBsYXdzIG9mIE9ydGhvZG94IEp1ZGFpc20gYW5k IHRoZSBibG9vZCBzYWNyaWZpY2UgY29uc2VjcmF0aW9uIG9mIEhhaXRpYW4gVm9kb3VuIGFsbCBy b2xsZWQgaW50byBvbmUgaG9ycmlibGUgYmxhc3BoZW15IG9mIHJvdGUgcml0dWFsIGZvciBhbGwg dGhlIHdyb25nIHJlYXNvbnMuICBDYW4ndCB3ZSBkZWZyb2NrIHRoZSBQS0kgUHJpZXN0cz8gIE9y IGFtIEkgc3R1Y2sgaW4gdGhlIGVzdGFibGlzaG1lbnQtcXVlc3Rpb25pbmcgc2hvZXMgb2YgTWFy dGluIEx1dGhlciAoZmF0aGVyIG9mIEx1dGhlcmFuaXNtIGFmdGVyIGhlIGRlbm91bmNlZCBWYXRp Y2FuIENhdGhvbGljaXNtIGFzIGNvcnJ1cHQpPw0KDQotS3lsZSBIDQo= --gmsm1.9.6eqh15hbmma278366dqf42 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINAjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGxjCCBa6g AwIBAgICCMUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNzE5MDFaFw0xMjA2MDUyMDMxMzFaMIHAMSAwHgYDVQQNExcyMDc2MDUtQzh5TUxvb3ll VE85NFFKeDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xIDAeBgkqhkiG9w0BCQEWEWt5YW5oYUBreWFuaGEubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5YylxEUtOSlqBT0sxqB7H0YUDx30ADzggTrSLA9n JVa0QCcIXhk04n7VUD5Augbc40rWhgmB8xl6N9pQ5qvAQZj8JmNej6LRlueN/et9MCjNN0euH0Ky zzKBSE5fxoUPYTTa6QBBurmKNR0navAKWBi8ITLRPi864zTay2oW1A1E1nt69SgJGn3PAv/LyKII WWMzu9YeJsRCd4u6vLHOsGHvr5rc7Dq4bXx8x+vyHgSuYccAnNu81lOC2Unea4TORMoULiwKOTRb pEy35H9Y7MW+SCTlaQiSLgxvYB260OuofHZgcS0wr/OnbGVAEUeBRYhfu3BaxNlZ6zY7mvs9NwID AQABo4IC+jCCAvYwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBThUNrymHVQVA3i/K/6BF4dnrmTqDAfBgNVHSMEGDAWgBSuVYNv 7DHKufcd+q9rMfPIHeOsuzAcBgNVHREEFTATgRFreWFuaGFAa3lhbmhhLm5ldDCCAUIGA1UdIASC ATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p bnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFM aW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9v Y3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDov L3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAjquLhQpUqqxo pg1hbv8zADjhTUY1Gxm1Ha/5Ntdjds7HZ54jOqD2fVwWRbqLAtq+rwHIaudvk13icftTedJlV01r +6VjmOZhSwOPPiYG/v81ABitv8bfyOkei/3BblORXOyzwuXHrbmMOgaEcCmQmqyTo1UJiNMy5Tw0 CvDt+KbSbGP2lQL8BAGyLhswuGePoReqw221KsX6sZJ4Eovk70SlNN19YiRAFYdWL+ggY5mMPn9S qXk8GGLaOyg3g2HnVr7Y4MLYfI0pheoRvoGxj8a4xofTz3u6OlGYE/3D5/uLQbw/rTz6GVVgUFPi GFSKZjzXwfEYJ3Kd1BMXCyfE6zGCAnwwggJ4AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAgjFMAkGBSsOAwIaBQCggb4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTIwNDE3MjE0MzE4WjAjBgkqhkiG9w0BCQQxFgQUJgEInk1uQocwN4r2FSDiOoet 3nEwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIIBABdRn2ZEBbAVTTZBKkEh3TMbBKPyi7QKdZpMZvoBEWQSHMIRE9ezZ4iz1F/xDrIw9id0RgYt oU6wH3YkBN3XLL4lefKco3GOWnGiPUkFCCe1Kvxcuw5azAo3Ik/UWLOUE5Falsws0gkbsoOirTq8 DOh2FQO6hf+qg7JQIVBhx+uLLlq1DjCOluiedT/aI8zBMeWAQ3fjdJhwvGcemZMN1f4flUe2kkvb 9txpPXxIQnhG9air3/o8QwkPh6PHBg0bN68sfDVolp9MLeSpUVIJsl9cHlkCV23hmTo4IwNYFx0z L9oA3/O/rHPNrY2mpC83P62L0HX+sFu2/1hgQk5Bie4AAAAAAAA= --gmsm1.9.6eqh15hbmma278366dqf42-- From bhill@paypal-inc.com Tue Apr 17 19:50:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD7821F857F for ; Tue, 17 Apr 2012 19:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.217 X-Spam-Level: X-Spam-Status: No, score=-8.217 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmr9yK6-jIT1 for ; Tue, 17 Apr 2012 19:50:24 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEE021F8582 for ; Tue, 17 Apr 2012 19:50:23 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:x-ems-proccessed: x-ems-stamp:Content-Type:Content-Transfer-Encoding: MIME-Version:X-CFilter; b=oajq76bzJCrTDtzGrzYODX8IAxTY0xJZVnYvnm38k8Y62tSNAS21YhtE pLR4l7zO+LUMePK4wMH6mjOO6cRNrPL2Tsm4mXIwMyzwYNp0Hwu+LNwDE tA8Jdy2lPUWCDRI; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=ppinc; t=1334717423; x=1366253423; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=dwkSg1PxgMgKtaMf2dgBd0LwGDRJzuCOes47FxwFUyc=; b=Cut0fRyZHQNp5irZQC4X3XCexjkbcDXSgsuJk+R39EZCjp/YQb7F5n2l 15tCiNXtC02uvEnPKKuFjSzli63I2tgafapQGp38C3rrG8gZLSORyyFDf H2c0f9UfCatGN9g; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.75,438,1330934400"; d="scan'208";a="7614723" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 17 Apr 2012 19:50:22 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-003.corp.ebay.com ([fe80::55d3:9d86:3fc8:dbf4%14]) with mapi id 14.01.0339.001; Tue, 17 Apr 2012 20:50:21 -0600 From: "Hill, Brad" To: "mrex@sap.com" Thread-Topic: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name Thread-Index: Ac0dDfHg32QdKAOsTPmrnvj/aThgZg== Date: Wed, 18 Apr 2012 02:50:20 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E09AFD4@DEN-EXDDA-S12.corp.ebay.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.241] x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: YdhvOKtvRfOCGSsl9bBJRQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "pkix@ietf.org" Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 02:50:29 -0000 Martin, Certificates issued according to the CABF BR 1.0 contain both a Subject CN= and a DNSName SAN. If the same host name is expressed in both Subject CN and a SAN of type DN= SName, and DNSName Constraints apply, what is the behavior if the Name Cons= traint is violated? Pass, because Subject CN matches and is not subject to the constraint? Fail, because the Subject CN is ignored when an appropriately-typed SAN is = present, and the SAN is subject to the NC? Thanks, Brad Hill > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Martin Rex > Sent: Thursday, April 12, 2012 5:32 PM > To: Santosh Chokhani > Cc: pkix@ietf.org > Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name >=20 > Santosh Chokhani wrote: > > > >> The contents were: > >> permitted: ... > >> 5x DNSName, values like ".somedomain.dir" > >> ... > >> 5x URI, values exactly same as DNSName values > > > > May be you can send me the actual certificate chain and I can see what > > the issues are. >=20 > Re-scanning rfc5280 (where the syntax of GeneralName in the context of > NameConstraints appears to be specified here): >=20 > http://tools.ietf.org/html/rfc5280#section-4.2.1.10 >=20 > it seems that the name constraints specified for URI are correct, but the > NameConstraints specified for DNSName are invalid. > Different to domain names in URI and rfc822Name Constraints, DNSName > Constraints do not permit a leading dot. >=20 > Cross-checking with the implementation of name constraints in openssl- > 1.0.0h/crypto/x509v3/v3_ncons.c, that code appears to be according to the > spec and fail comparison with such a malformed DNSName > NameConstraints -- in case there is a DNSName present in the End-Entity > cert (which wasn't...). >=20 > The openssl-1.0.0x codebase seems to include name constraints processing, > plus a check of rfc822Name Constraints against an EMail=3D RDName of the > subject name. It does not (currently) seem to contain a check for DNSName > Constraints against CN=3Df.q.d.n. > (neither rfc5280/PKIX nor X.509 specify such DName cross-checks). >=20 > Passing that customers cert-chain to openssl (0.9.8j-fips) on our newest > SLES-11sp1 machines, results in a confusing output: >=20 > openssl verify -verbose -CAfile root.pem -untrusted pathcerts.pem -purp= ose > sslserver server.cer > server.cer: /DC=3Ddir/DC=3D... > error 34 at 1 depth lookup:unhandled critical extension > OK >=20 > What does this tell me? I would have expected either an error or an OK, = but > not both! >=20 > apps/verify.c looks like this: > i=3DX509_verify_cert(csc); > X509_STORE_CTX_free(csc); >=20 > ret=3D0; > end: > if (i > 0) > { > fprintf(stdout,"OK\n"); > ret=3D1; > } >=20 > and the documentation for X509_verify_cert() says this: > http://www.openssl.org/docs/crypto/X509_verify_cert.html >=20 > RETURN VALUES >=20 > If a complete chain can be built and validated this function returns 1 = ... >=20 > NOTES >=20 > Applications rarely call this function directly but it is used by OpenS= SL > internally for certificate validation, in both the S/MIME and SSL/TLS c= ode. >=20 >=20 > which looks to me like OpenSSL-0.9.8x is (silently) ignoring critical nam= e > constraints. >=20 >=20 > -Martin >=20 >=20 > btw. I consider the context-sensitive syntax rule for the > ASN.1 type GeneralName extremely confusing! > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Tue Apr 17 20:23:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D47E11E80D7 for ; Tue, 17 Apr 2012 20:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.089 X-Spam-Level: X-Spam-Status: No, score=-10.089 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtxu2X1CtaNk for ; Tue, 17 Apr 2012 20:23:46 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4CC11E8075 for ; Tue, 17 Apr 2012 20:23:46 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3I3NdSh011650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2012 05:23:44 +0200 (MEST) From: Martin Rex Message-Id: <201204180323.q3I3NdOM000692@fs4113.wdf.sap.corp> To: bhill@paypal-inc.com (Hill Brad) Date: Wed, 18 Apr 2012 05:23:39 +0200 (MEST) In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E09AFD4@DEN-EXDDA-S12.corp.ebay.com> from "Hill, Brad" at Apr 18, 12 02:50:20 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Fully Qualified Domain Name (FQDN) in DN and Name X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 03:23:47 -0000 Hill, Brad wrote: > > Certificates issued according to the CABF BR 1.0 contain both > a Subject CN and a DNSName SAN. > > If the same host name is expressed in both Subject CN and a SAN of > type DNSName, and DNSName Constraints apply, what is the behavior > if the Name Constraint is violated? > > Pass, because Subject CN matches and is not subject to the constraint? > > Fail, because the Subject CN is ignored when an appropriately-typed > SAN is present, and the SAN is subject to the NC? That resulting behaviour is quite implementation-defined. (i.e. you'll have to test each and every App(!!) individually to find out). There seem to exist some (newer versions of certain) browsers that apply DNSName constraints to CN= when matching to CN= and cause a failure. OpenSSL 0.9.8x (and allegedly iOS 5) unconditionally abort when they encounter a Name constraints extension that is marked critical. While OpenSSL 1.0.0x can process name constraints, it will never apply DNSName constraints to the CN of a certificate's subject DName (this is not specified in rfc5280), and other than for pkcs9-EmailAddress, the certificate path validation function of a PKIX module regularly does not know about the usage scenario in which it is being called anyway -- blindly applying DNSName constraints on the CN= part of a subject DName seems like a bad idea. Applications that are independently maintained from its TLS-implementation might be looking exclusively at CN= and be completely ignorant about SANs. Potential candidates: curl/wget. Or Applications or TLS-using middleware might _always_ be looking at both, SAN and CN= (ours needs to, for backward compatibility, and not support NameConstraints or not apply DNS Name constraints to CN=. Adding support for matching to SANs does not break any usage scenarios in the installed base, but no longer matching CN= might, so unconditionally disabling such matching when sneaking out "feature updates" as part of a patch is not an option for a responsible software supplier. One could offer a configuration option for callers, so that consumers of the technology that want strict, and potentiall backwards-incompatible behaviour, can explicitly request it. Considering what crappy CA-Software is out there, that will boldly create certs with invalid DNSName constraints in it, and boldly issue TLS ServerCerts below such a CA without DNSName SANs it it, then this is really a minefield, where you hardly would want to ship backwards-incompatible changes into the installed base. -Martin From anders.rundgren@telia.com Tue Apr 17 23:31:38 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E784F21F85F2 for ; Tue, 17 Apr 2012 23:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qMZkGjXzOfS for ; Tue, 17 Apr 2012 23:31:38 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id B6B9721F85EF for ; Tue, 17 Apr 2012 23:31:37 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB98E00DE972C; Wed, 18 Apr 2012 08:31:34 +0200 Message-ID: <4F8E5FC2.2060106@telia.com> Date: Wed, 18 Apr 2012 08:31:30 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Kyle Hamilton References: <4F856D3A.1060103@telia.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 06:31:39 -0000 Hi Kyle, I'm not able to respond to your elaborate input because I'm working with a much more basic question which is "getting away from passwords". To have a chance of succeeding you need Vision, Ambition, Marketing, Competence, and Funding. Maybe you even need a portion of luck :-) One of the problems is that if you intend to create something of this kind you [presumably] need a requirement list. The naked truth is that getting such a thing is essentially impossible because the existing users of consumer PKI don't know which one of the gazillion security standards efforts are for "real", and therefore do not [actively] support any of them. A true standardization effort could have a slim chance if it was supported by NIST since banks and European governments lack the necessary "bandwidth". However, I have indeed talked to a bunch of NIST people and I believe they are not particularly interested in consumer authentication in spite of the fact that this nowadays includes the considerably "hotter" BYOD movement. Due to this, the fate of consumer PKI firmly resides in the hands of big vendors which are exclusively targeting mobile devices with embedded security hardware. The smart card concept never worked well as consumer solution in desktop PCs. IMO, there is actually a way ahead and that is "putting the cart before the horse" which means that instead of following the whims of the severely divided smart card community, you define a standard card and provide a *fixed* driver. Implementing a minute set of cryptographic operations is actually not rocket science while developing and distributing middleware for a huge number of ever-changing platforms takes forever and still you never know for sure if it is actually working! By making the driver a *platform vendor issue only*, things get much easier. PIV was a step in this direction but NIST didn't standardize the management functions since the card industry wanted to keep something to be unique with. Anders On 2012-04-17 23:43, Kyle Hamilton wrote: > > On Thu, Apr 12, 2012 at 9:23 PM, Anders Rundgren wrote: >> My perspective on this is slightly different. IMO this issue (as well as PKI...) >> is essentially "owned" by three major laggards: Governments, Banks, and Microsoft. > > This issue is "owned" by ISO, which means that it's on the governments who are participating in ISO. > > The most important aspect of any access-control system (especially financial) is auditability, and the ISO standards don't cause enough data to be transmitted to the cryptographic container for the container to write its own audit logs. PKCS#11 exposes ISO functionality, so it doesn't have a "I'm sending you something that I want you to digest for me" call. Thus, we have no idea that the digests submitted are being calculated correctly, and no idea what the digests we're signing actually mean. > > Instead, we have to implement the auditing service externally, which means that we must be able to trust that we are the sole controllers of the cryptographic containers involved. > >> Since the first two are numerous as well as geographically and culturally >> diverse it would be wrong giving them the blame. However, since they to >> some 90% have relied on a single client-OS vendor, the generally pitiful >> state of client-side PKI in consumer PCs is unilaterally due to Microsoft's >> limited of understanding of this market. Over the years I have met quite >> a bunch of Microsoft Program Managers and they all say the same thing: >> "There is no business case for consumer PKI". In some way this is also >> true since there is no paying customer out there. > > Ah, Microsoft spreading lies again. > > There is no business case for discarding Apache httpd's SSLVerifyClient optional_no_ca, but it's discarded by the technical people because its documentation says that "optional_no_ca is actually against the idea of authentication". Instead, we end up with applications which handle their own username and password error flows because optional_no_ca is in fact the only way to present a custom error page when people inadvertently try to log in with the wrong certificate or before they've ever been issued a certificate for the service in question. > > There is no business case for consumer X.509-as-tied-to-X.500. There is a business case for enrolling your site's own credentials. There is a business case for whispering to a friend. (The problem is that attempts like this to repurpose X.509 are maligned by e.g. Firefox.) > >> Due to that, the banks in the EU that actually use consumer PKI have been >> forced developing their own client-side software. I guess Stefan (PKIX >> co-char), never told that to his boss when he worked for Microsoft (in the >> US a subordinate typically gets fired if he/she criticizes company strategy). > > ...so why haven't they gotten together to fund the development of a unified interface? Why haven't they contributed their quantum leaps in client PKI presentation? How much of the blame likes in their desire to have a proprietary edge? > >> This has and still is the primary motivation behind my enrollment "crusade". >> However, it is also possible that the whole idea reviving traditional PCs is >> toast, it is really the mobile devices that are in the center these days. > > I am of the opinion that "enrollment is cheap, verification is expensive." Once the identity is verified, there's no reason at all to avoid enrolling additional keys and linking them to the same record, as long as you define the enrollment process as more than just the application of a single key per-party. > > What's happened to this point is that nobody's bothered to authenticate the keystore on each individual device, so the keystore itself can't assert that it generated the key with knowledge of the policy governing said key generation. If the enrolling certifier has evidence that the key was generated properly -and- that it was submitted by the principal, it can securely enroll additional keys. > > This is not impossible. It just requires examining things in the "how can I get past this problem?" inventing mindset. > >> It is essentially Google and Apple that run this show nowadays. Since they >> also have the services, there is an entirely new motivation these days. >> >> Anyway, PKIX won't be there when it actually happens; that's for sure!!! > > ...unless everyone who's terrified of changing anything for fear of Violating The Purity Of The Design Spec is summarily removed from the organization, anyway. We need to make this work. It's unacceptable that we give excuses much like "you didn't create this signature under the dark of the moon with the blood of a sacrificed chicken on a ritually sanctified silver dagger washed in the tears of a virgin... so we're just going to interfere with and prevent you from doing the work you need to do." > > I mean no offense, but this really needs to be said. The PKI Priesthood is like the rigid hierarchy of Vatican Catholicism mixed with the "oh God please let this be sufficient to not do what I fear You will" and kosher laws of Orthodox Judaism and the blood sacrifice consecration of Haitian Vodoun all rolled into one horrible blasphemy of rote ritual for all the wrong reasons. Can't we defrock the PKI Priests? Or am I stuck in the establishment-questioning shoes of Martin Luther (father of Lutheranism after he denounced Vatican Catholicism as corrupt)? > > -Kyle H From DPKemp@missi.ncsc.mil Wed Apr 18 07:23:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D3121F8549 for ; Wed, 18 Apr 2012 07:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfFX8X-BpxBH for ; Wed, 18 Apr 2012 07:23:07 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 86C1321F84FD for ; Wed, 18 Apr 2012 07:23:06 -0700 (PDT) Received: from AUGUSTINE.missi.ncsc.mil (augustine.missi.ncsc.mil [144.51.60.33]) by stingray.missi.ncsc.mil with ESMTP id q3IEN5tx064860 for ; Wed, 18 Apr 2012 10:23:05 -0400 (EDT) Received: from DABECK.missi.ncsc.mil ([144.51.60.15]) by AUGUSTINE.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Apr 2012 10:23:05 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Apr 2012 10:23:04 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI Thread-Index: Ac0c4yL5hMraSD6bR6mwVEoJc5jHdQAg5mGA References: <4F856D3A.1060103@telia.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 18 Apr 2012 14:23:05.0310 (UTC) FILETIME=[C50BB7E0:01CD1D6E] Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:23:11 -0000 From: Kyle Hamilton > I am of the opinion that "enrollment is cheap, verification > is expensive." Once the identity is verified, there's no > reason at all to avoid enrolling additional keys and linking > them to the same record, as long as you define the enrollment > process as more than just the application of a single key per-party. You'll get no argument from the priesthood on that point, as long as vocabulary is understood. To some, "registration" includes both identity management and credential issuance, while "enrollment" means assigning privileges to existing identities. (Common English usage provides no help - you can either enroll or register once as a college student, and then register or enroll in multiple courses.) Identity management itself is overloaded - in my taxonomy it includes just management of identifying information about entities and excludes credential issuance and privilege assignment. Others include two or all three of those functions under identity management. You apparently use verification to mean identity proofing as part of credential issuance, others think it means authenticating the source of a request. > What's happened to this point is that nobody's bothered to > authenticate the keystore on each individual device, so the > keystore itself can't assert that it generated the key with > knowledge of the policy governing said key generation. > If the enrolling certifier has evidence that the key was > generated properly -and- that it was submitted by the principal, > it can securely enroll additional keys. Which requires management of device identities and issuance of device credentials, an area of active research. My employer currently supports only web servers and domain controllers in its device identity and credential management system. As Anders says, mobile devices are here now, and developing usable ways to use device identities and user identities to express user privileges is an urgent unmet need. Device identities alone are insufficient - my daughter calls home with a friend's phone more often than she uses her own, and it's a non-starter to assume that devices will not be borrowed or shared in business environments. I never hand someone my badge or drivers license to use, whereas I have an operational requirement to lend or share my tablet or smartphone without giving the user access to my credit cards and email accounts.=20 "Verification" (of who's behind an action, regardless of which devices or keys are used to authenticate a protocol message) is indeed hard. Key generation and credential issuance are not "easy", but they are trivial mechanical tasks, unlike properly managing identities and privileges. Dave From anders.rundgren@telia.com Wed Apr 18 12:33:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5272E11E8094 for ; Wed, 18 Apr 2012 12:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6fnmZqAUhZi for ; Wed, 18 Apr 2012 12:33:36 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id A4E8911E8091 for ; Wed, 18 Apr 2012 12:33:35 -0700 (PDT) Received: from [192.168.0.200] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB81D00A3A249 for pkix@ietf.org; Wed, 18 Apr 2012 21:33:33 +0200 Message-ID: <4F8F170A.3090203@telia.com> Date: Wed, 18 Apr 2012 21:33:30 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <4F856D3A.1060103@telia.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 19:33:40 -0000 On 2012-04-18 16:23, Kemp, David P. wrote: There is indeed a pretty large terminology variation/confusion in this space. Regarding the mentioned use-case, multiple users for a single device, I do not see that as the *most* pressing issue to solve. It is rather a single user having multiple roles that intrigues me as well as the device vendors. It is possible that you could address David's use-case with a "guest" VM that only allows you to phone and surf. The problem is really how to switch between these modes without creating too much fuzz for the true user. I'm not sure that "device identities" is a universally understood term. I only use it for a fixed credential that is bolted onto a cryptographic platform and can attest that platform's brand and serial number. It is used for supporting end-to-end-secured enrollment/credential issuance. One of the things enabled by such a scheme is to use your CAC/PIV/eID (or AD login) as "bootstrap" for a securely provisioned ID "clone" in another device using a self-service process. Eventually the ID clone will surpass its origin in usability, presumably also supporting physical access control. Pretty mind-boggling in my opinion! I expect this platform to be a part of future processors from vendors like Intel, because the entire caboodle won't take more than 0.1% of the silicon real estate of a current PC CPU: http://openkeystore.googlecode.com/svn/trunk/resources/docs/tee-se-combo.pdf Like all powerful technologies, the concentration of power has unwanted side-effects when it breaks down. Anders > > From: Kyle Hamilton > >> I am of the opinion that "enrollment is cheap, verification >> is expensive." Once the identity is verified, there's no >> reason at all to avoid enrolling additional keys and linking >> them to the same record, as long as you define the enrollment >> process as more than just the application of a single key per-party. > > You'll get no argument from the priesthood on that point, as long as > vocabulary is understood. To some, "registration" includes both > identity management and credential issuance, while "enrollment" means > assigning privileges to existing identities. (Common English usage > provides no help - you can either enroll or register once as a college > student, and then register or enroll in multiple courses.) Identity > management itself is overloaded - in my taxonomy it includes just > management of identifying information about entities and excludes > credential issuance and privilege assignment. Others include two or all > three of those functions under identity management. You apparently use > verification to mean identity proofing as part of credential issuance, > others think it means authenticating the source of a request. > >> What's happened to this point is that nobody's bothered to >> authenticate the keystore on each individual device, so the >> keystore itself can't assert that it generated the key with >> knowledge of the policy governing said key generation. >> If the enrolling certifier has evidence that the key was >> generated properly -and- that it was submitted by the principal, >> it can securely enroll additional keys. > > Which requires management of device identities and issuance of device > credentials, an area of active research. My employer currently supports > only web servers and domain controllers in its device identity and > credential management system. As Anders says, mobile devices are here > now, and developing usable ways to use device identities and user > identities to express user privileges is an urgent unmet need. Device > identities alone are insufficient - my daughter calls home with a > friend's phone more often than she uses her own, and it's a non-starter > to assume that devices will not be borrowed or shared in business > environments. I never hand someone my badge or drivers license to use, > whereas I have an operational requirement to lend or share my tablet or > smartphone without giving the user access to my credit cards and email > accounts. > > "Verification" (of who's behind an action, regardless of which devices > or keys are used to authenticate a protocol message) is indeed hard. > Key generation and credential issuance are not "easy", but they are > trivial mechanical tasks, unlike properly managing identities and > privileges. > > Dave > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From benlaurie@gmail.com Wed Apr 18 13:18:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095A811E809D for ; Wed, 18 Apr 2012 13:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBlNKvqn-3v5 for ; Wed, 18 Apr 2012 13:18:23 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 334E411E8094 for ; Wed, 18 Apr 2012 13:18:23 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1508651vcb.31 for ; Wed, 18 Apr 2012 13:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=R6xhZlRVoKfTcci+QvcjwlhJK7jUtS47FJXICZ52VW8=; b=QaXBXTG5i8a+HNBARbUVQGpSoTNcmB+pBjGqvcGNsSz7uW2QKi8HJA3VA2QZZxOCX2 XPgFEFNnsKcvZiKOsWNuZLbrs58PgbYl5ByWrQhZ0t6zVK6kzXzJfMxY6Rb/VGHxvJpi D48EAH2B7gV3+UfIUQOPHWSnt8z1ViTV227ZKNLSH2FApsJePj6XWwFur6XlIS8hZ/wN y2ANaqXCY7Un36f8wkQ0Wn7uosYPQoIRYnRjlZBzud20pn0SUEHyRX+lQFNaoVZUKkRR WBfG8WcdBfZ+SX7rsakXoHqfCuV6mNDAkaciG4j9DLCOw7LCBIbROsrhxY3go/yNbnk/ ZDaQ== MIME-Version: 1.0 Received: by 10.52.88.2 with SMTP id bc2mr1515177vdb.82.1334780302691; Wed, 18 Apr 2012 13:18:22 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.52.171.14 with HTTP; Wed, 18 Apr 2012 13:18:22 -0700 (PDT) In-Reply-To: <4F86B2F3.7090406@telia.com> References: <4F856D3A.1060103@telia.com> <4F85E303.3090700@lockstep.com.au> <4F866EFF.3020207@telia.com> <4F86AADC.10906@lockstep.com.au> <4F86B2F3.7090406@telia.com> Date: Wed, 18 Apr 2012 21:18:22 +0100 X-Google-Sender-Auth: H4kH2HG31-ZdLX0SjNtc1F7vhqk Message-ID: From: Ben Laurie To: Anders Rundgren Content-Type: multipart/alternative; boundary=bcaec501638fcb8e8304bdf9c1a3 Cc: "pkix@ietf.org" Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:18:28 -0000 --bcaec501638fcb8e8304bdf9c1a3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 12, 2012 at 11:48 AM, Anders Rundgren wrote: > > This is of course a part of enrollment on the web but that's the beauty of > the web; you can sign-up for anything. What's missing (IMO...) is a way to > enroll that instead of providing you with yet another usersid/password > combination, equips you with an X.509 certificate and matching private key. > http://www.browserauth.net/ --bcaec501638fcb8e8304bdf9c1a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 12, 2012 at 11:48 AM, Anders= Rundgren <anders.rundgren@telia.com> wrote:
This is of course a part of enrollment on the web but that's the beauty= of
the web; you can sign-up for anything. =A0What's missing (IMO...) is a = way to
enroll that instead of providing you with yet another usersid/password
combination, equips you with an X.509 certificate and matching private key.=

=A0
--bcaec501638fcb8e8304bdf9c1a3-- From ron.ogle@technicolor.com Wed Apr 18 13:34:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A89511E8091 for ; Wed, 18 Apr 2012 13:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+Z+qeR4KgUv for ; Wed, 18 Apr 2012 13:34:09 -0700 (PDT) Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with ESMTP id 9311111E8085 for ; Wed, 18 Apr 2012 13:34:07 -0700 (PDT) Received: from INDYSEDGE01.am.thmulti.com ([157.254.234.137]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKT48lPT7l8PSLt9BWk/dvXzLB32QQH5ok@postini.com; Wed, 18 Apr 2012 13:34:08 PDT Received: from INDYSMAILHT01.am.thmulti.com (157.254.98.93) by INDYSEDGE01.am.thmulti.com (157.254.234.136) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 18 Apr 2012 16:33:27 -0400 Received: from INDYSMAILMB04.am.thmulti.com ([169.254.2.162]) by INDYSMAILHT01.am.thmulti.com ([157.254.98.93]) with mapi; Wed, 18 Apr 2012 16:33:28 -0400 From: Ogle Ron To: Anders Rundgren , "pkix@ietf.org" , "Kemp, David P." Date: Wed, 18 Apr 2012 16:33:27 -0400 Thread-Topic: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI Thread-Index: Ac0dooLa5atzg14OSPSNhFVi+PgT8g== Message-ID: In-Reply-To: <4F8F170A.3090203@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:34:13 -0000 We are going through similar problems but with consumer electronics products instead of the typical PC/iphone/ipad device. During manufacturing, we are installing a "device" certificate that uniquely identifies that device to the world. We can then use that device ID to impart other functions/features. Again like your situation, we are working on imparting additional Ids into the device that can define users and/or services that device is allowed to use. An interesting part to this is that these Ids can only be as trusted as the device itself allows. So in this case, the issuer of these additional Ids along with any RP has to not only understand the ID but also the device it originated. For example, you can have a cable modem that doesn't do much protection. Any additional ID that it uses would be of low assurance. However a set top box that is more expensive and has dedicated crypto functions can provide protections of the credentials at a very high level. This situation may be telling by using OIDs in these additional ID certs, but it is very difficult to provide inter-operable designs that way. Maybe a better solution would be to extend TLS to allow for multiple client-side Ids to be provided during authentication. To give the military folks an idea on this, I'll provide an example. As you may have noticed, the newer TV systems are incorporating some basic PC functionality using the network. So now you want to do some on-line shopping at the PX or you want to look at your medical or something else that requires CAC access. You plug in your USB card reader to the TV and insert your CAC card and provide your PIN. The TV browser recognizes the CAC card and uses if for authentication. No problems. Now what if instead of using the CAC card all of the time, the CAC card was just used to download another temporary cert that is originated from the TV itself or maybe hanging out there in the cloud but could be retrieved by the TV to be used by you. This is where I think things are going and makes PKI usable from the client side. It all becomes part of those background processes like DNS. So now you can do what you did before, but you don't necessarily have to have a CAC with you all of the time. Of course, now the problem becomes how can we trust the TV. For regular folks, we don't have a CAC card, but we need to do the same thing as I described above. Anyway, isn't it interesting to see how the PC world and consumer electronics world is becoming one. My .02 Ron Ogle On 4/18/12 15:33 , "Anders Rundgren" wrote: >On 2012-04-18 16:23, Kemp, David P. wrote: > >There is indeed a pretty large terminology variation/confusion in this >space. > >Regarding the mentioned use-case, multiple users for a single device, >I do not see that as the *most* pressing issue to solve. > >It is rather a single user having multiple roles that intrigues >me as well as the device vendors. It is possible that you could >address David's use-case with a "guest" VM that only allows you to >phone and surf. The problem is really how to switch between these modes >without creating too much fuzz for the true user. > >I'm not sure that "device identities" is a universally understood term. >I only use it for a fixed credential that is bolted onto a cryptographic >platform and can attest that platform's brand and serial number. It is >used for supporting end-to-end-secured enrollment/credential issuance. > >One of the things enabled by such a scheme is to use your CAC/PIV/eID >(or AD login) as "bootstrap" for a securely provisioned ID "clone" in >another device using a self-service process. > >Eventually the ID clone will surpass its origin in usability, presumably >also supporting physical access control. > >Pretty mind-boggling in my opinion! > >I expect this platform to be a part of future processors from vendors >like Intel, because the entire caboodle won't take more than 0.1% of >the silicon real estate of a current PC CPU: >http://openkeystore.googlecode.com/svn/trunk/resources/docs/tee-se-combo.p >df > >Like all powerful technologies, the concentration of power has unwanted >side-effects when it breaks down. > >Anders > > >>=20 >> From: Kyle Hamilton >>=20 >>> I am of the opinion that "enrollment is cheap, verification >>> is expensive." Once the identity is verified, there's no >>> reason at all to avoid enrolling additional keys and linking >>> them to the same record, as long as you define the enrollment >>> process as more than just the application of a single key per-party. >>=20 >> You'll get no argument from the priesthood on that point, as long as >> vocabulary is understood. To some, "registration" includes both >> identity management and credential issuance, while "enrollment" means >> assigning privileges to existing identities. (Common English usage >> provides no help - you can either enroll or register once as a college >> student, and then register or enroll in multiple courses.) Identity >> management itself is overloaded - in my taxonomy it includes just >> management of identifying information about entities and excludes >> credential issuance and privilege assignment. Others include two or all >> three of those functions under identity management. You apparently use >> verification to mean identity proofing as part of credential issuance, >> others think it means authenticating the source of a request. >>=20 >>> What's happened to this point is that nobody's bothered to >>> authenticate the keystore on each individual device, so the >>> keystore itself can't assert that it generated the key with >>> knowledge of the policy governing said key generation. >>> If the enrolling certifier has evidence that the key was >>> generated properly -and- that it was submitted by the principal, >>> it can securely enroll additional keys. >>=20 >> Which requires management of device identities and issuance of device >> credentials, an area of active research. My employer currently supports >> only web servers and domain controllers in its device identity and >> credential management system. As Anders says, mobile devices are here >> now, and developing usable ways to use device identities and user >> identities to express user privileges is an urgent unmet need. Device >> identities alone are insufficient - my daughter calls home with a >> friend's phone more often than she uses her own, and it's a non-starter >> to assume that devices will not be borrowed or shared in business >> environments. I never hand someone my badge or drivers license to use, >> whereas I have an operational requirement to lend or share my tablet or >> smartphone without giving the user access to my credit cards and email >> accounts.=20 >>=20 >> "Verification" (of who's behind an action, regardless of which devices >> or keys are used to authenticate a protocol message) is indeed hard. >> Key generation and credential issuance are not "easy", but they are >> trivial mechanical tasks, unlike properly managing identities and >> privileges. >>=20 >> Dave >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >>=20 > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From kyanha@kyanha.net Wed Apr 18 16:52:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D255221F84EC for ; Wed, 18 Apr 2012 16:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.076 X-Spam-Level: X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9thJaMVG9Qs for ; Wed, 18 Apr 2012 16:52:37 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id A5D9621F84DE for ; Wed, 18 Apr 2012 16:52:37 -0700 (PDT) Received: by dady13 with SMTP id y13so14501508dad.27 for ; Wed, 18 Apr 2012 16:52:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type:x-gm-message-state; bh=0gUPyoVL3GIlmEx4bToX0SU8voQXPMQdRVdMKTn/D60=; b=Pw9t/3+wR5pSnSyA3z2aPIGpoHsGcnmcUzE+D3370a7T/G+iuC/yv9jOM0M97XweXR lsHZZ4++LOUFDUXBMfxJvhbjFVpStW1av+rrEO5s7JVmRVReGJeRFKUgEtC1kyMaowQU 3h9JpIJENAnJbzja1/C6j2n7+71TnlhOT4U4YYaYemUwhO60sY/raupZzcTq5hslf5MR hpm2o3f3zAv1adMXPS/nVOwKVj47yNQ3kloEID8fVS+dhfSqul2tqNjLr2L1V9bSl++9 D5FHhR0fRZ+JvZhRXfM2Oyjn7O4KE4BEQfwnMvHZ9EWY9B+cmLyu+ZtSMNiCLUbz/4cE F+Vw== Received: by 10.68.225.195 with SMTP id rm3mr99700pbc.96.1334793157054; Wed, 18 Apr 2012 16:52:37 -0700 (PDT) Received: from penango ([64.9.242.215]) by mx.google.com with ESMTPS id la9sm521060pbc.1.2012.04.18.16.52.35 (version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 16:52:36 -0700 (PDT) From: "Kyle Hamilton" To: "Anders Rundgren" Date: Wed, 18 Apr 2012 16:52:36 -0700 (Pacific Daylight Time) Message-ID: In-Reply-To: <4F856D3A.1060103@telia.com> References: <4F856D3A.1060103@telia.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.6eqh171drgrm9139p8huv2 X-Gm-Message-State: ALoCoQl0h+yg7rsqV/HRwAZqNG7AFZ2j9WW14pJqjUb1uv9WGsvpxJz9lOtdY2DV3fb4J9jmoZfW Cc: "pkix@ietf.org" Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 23:52:41 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.6eqh171drgrm9139p8huv2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 QW5kZXJzLA0KDQpJIGFtIGVudGlyZWx5IHdpdGggeW91IG9uICJnZXR0aW5nIGF3YXkgZnJvbSBw YXNzd29yZHMiLiAgVGhvdWdoLCBpbnN0ZWFkIG9mIHdyaW5naW5nIG15IGhhbmRzIGFib3V0IGl0 IGFuZCB0aGlua2luZyB0aGF0IEkgY2FuJ3QgZG8gYW55dGhpbmcgZm9yIGl0LCBJJ20gY3JlYXRp bmcgdGhlIHN5c3RlbSB0aGF0IEkgcGVyY2VpdmUgdGhlIG5lZWQgZm9yLiAgSSBkZXNwaXNlIHBh c3N3b3JkcywgYW5kIEkgYmVsaWV2ZSB0aGF0IHRoZXkgc2hvdWxkIGhhdmUgYmVlbiBkb25lIGF3 YXkgd2l0aCAxNSB5ZWFycyBhZ28sIHRoZSBtb21lbnQgdGhlIFdhc3Nlbm5hciBBcnJhbmdlbWVu dCB3YXMgaW5rZWQgaW4gMTk5OC4NCg0KVGhlcmUgZXhpc3QgYSBjb3VwbGUgb2YgYmFycmllcnMg d2hpY2ggcHJldmVudCBwYXNzd29yZHMgZnJvbSBnb2luZyBleHRpbmN0LiAgVGhlcmUgYXJlIHR3 byB0aGF0IEkgaGF2ZSBteSBleWVzIG9uLiAgT25lIGV4aXN0cyBhdCBNb3ppbGxhLCB0aGUgb3Ro ZXIgYXQgQXBhY2hlIGh0dHBkLg0KDQpPbiBUdWUsIEFwciAxNywgMjAxMiBhdCAxMTozMSBQTSwg QW5kZXJzIFJ1bmRncmVuIDxhbmRlcnMucnVuZGdyZW5AdGVsaWEuY29tPiB3cm90ZToNCj4gSGkg S3lsZSwNCj4gSSdtIG5vdCBhYmxlIHRvIHJlc3BvbmQgdG8geW91ciBlbGFib3JhdGUgaW5wdXQg YmVjYXVzZSBJJ20gd29ya2luZyB3aXRoIGEgbXVjaA0KPiBtb3JlIGJhc2ljIHF1ZXN0aW9uIHdo aWNoIGlzICJnZXR0aW5nIGF3YXkgZnJvbSBwYXNzd29yZHMiLiCgVG8gaGF2ZSBhIGNoYW5jZSBv Zg0KPiBzdWNjZWVkaW5nIHlvdSBuZWVkIFZpc2lvbiwgQW1iaXRpb24sIE1hcmtldGluZywgQ29t cGV0ZW5jZSwgYW5kIEZ1bmRpbmcuIKBNYXliZQ0KPiB5b3UgZXZlbiBuZWVkIGEgcG9ydGlvbiBv ZiBsdWNrIDotKQ0KDQpNeSB2aXNpb246IEkgYmVsaWV2ZSB0aGF0IGV2ZXJ5IGluZGl2aWR1YWwg aW4gdGhlIHdvcmxkIGhhcyB0aGUgYWJzb2x1dGUgcmlnaHQgdG8ga2VlcCBoaXMgb3duIHNlY3Jl dHMuICBFdmVyeSBwZXJzb24gaW4gdGhlIHdvcmxkIGhhcyB0aGUgcmlnaHQgdG8gYmUgc2FmZSBm cm9tIGltcGVyc29uYXRpb24gZnJhdWQuICBFdmVyeSBwZXJzb24gaW4gdGhlIHdvcmxkIGhhcyB0 aGUgcmlnaHQgdG8gZm9ybSBoaXMgb3duIGFzc29jaWF0aW9ucywgYW5kIHRvIGNyZWF0ZSBzeXN0 ZW1zIHRvIGhlbHAgdGhvc2UgYXNzb2NpYXRpb25zIHdvcmsgYXMgZXhwZWN0ZWQgYnkgdGhlIHBh cnRpY2lwYW50cy4gIFdoYXQgaGFzIHByZXZlbnRlZCBpdCB0byB0aGlzIHBvaW50IGlzIHRoZSBs YWNrIG9mIGEgdXNlZnVsLCBjb21wcmVoZW5zaWJsZSBpbnRlcmZhY2UuICBUaGUgQ2xlcmsgb2Yg Q291cnRzIGV4ZW1wbGlmaWVzIGV2ZXJ5dGhpbmcgdGhhdCB3ZSBleHBlY3QgZnJvbSBvdXIgaW5m b3JtYXRpb24gc3lzdGVtcywgYW5kIHNob3VsZCBiZSB0aGUgcm9sZSBtb2RlbCB3ZSB0cnkgdG8g ZW11bGF0ZS4NCkFtYml0aW9uOiBJJ20gZ29pbmcgdG8gbWFrZSBzdXJlIHRoYXQgZXZlcnlvbmUg aGFzIHRoZSBjYXBhY2l0eSB0byBrZWVwIGhpcyBvd24gc2VjcmV0cywgd2l0aCBhbiBpbnRlcmZh Y2UgbXVjaCBsaWtlIHRoZSBDbGVyayBvZiBDb3VydHMgcHJlc2VudHMgdG8gdGhlIEp1ZGdlcyBv ZiB0aGUgQ291cnRzLCBtZWFuaW5nIG5lYXJseSBpbnZpc2libGUgYnV0IHByb3ZpZGluZyBleGFj dGx5IHdoYXQgaW5mb3JtYXRpb24vcGFwZXJ3b3JrIGlzIG5lZWRlZCBhdCBhbnkgZ2l2ZW4gbW9t ZW50Lg0KQ29tcGV0ZW5jZTogSSBqdWdnbGUgY3J5cHRvZ3JhcGhpYyBidWlsZGluZyBibG9ja3Mg dW50aWwgZXZlcnkgbmVlZCBpcyBtZXQuICBBdCB0aGlzIHBvaW50LCBJJ20gbG9va2luZyBmb3Ig cGVvcGxlIHRvIGV2YWx1YXRlIHRoZSBkZXNpZ24gSSBjcmVhdGVkIHRvIG1ha2UgcGFzc3dvcmRz IHRoZSB3YXZlIG9mIHRoZSBwYXN0LiAgWW91IHNlZW0gdG8gYmUgaW50ZXJlc3RlZCBlbm91Z2gg aW4gdGhlIHRvcGljIGFuZCBjb21wZXRlbnQgZW5vdWdoIGluIHRoZSBmaWVsZCB0byBiZSBhYmxl IHRvIGdpdmUgZmVlZGJhY2suDQpNYXJrZXRpbmcvRnVuZGluZzogSSdsbCBoYW5kIGl0IHRvIE1v emlsbGEgYW5kL29yIEFwYWNoZS4NCkx1Y2s6IHRoYXQgbm9ib2R5IGVsc2UgaGFzIHlldCBkb25l IGl0IHJpZ2h0LiA6LSkNCg0KSSdtIHdvcmtpbmcgdG8gaW1wcm92ZSBNb3ppbGxhJ3MgcGxhdGZv cm0gc28gdGhhdCBzaXRlcyBjYW4gY3JlYXRlIGFuZCBlbnJvbGwgdGhlaXIgb3duIGNyZWRlbnRp YWxzIHdpdGhvdXQgdGhyb3dpbmcgYXdheSB0aGUgYmVuZWZpdHMgb2YgaXRzIHJvb3QgcHJvZ3Jh bS4gIChUaGUgYnVnOiBsb2NhbGx5LXRydXN0ZWQgY2VydGlmaWNhdGVzIHByZXNlbnQgdGhlIHNh bWUgVUkgYXMgcm9vdCBwcm9ncmFtIGNlcnRpZmljYXRlcy4pDQoNCkknbSBhbHNvIHdvcmtpbmcg dG8gcmVtb3ZlIEFwYWNoZSBtb2Rfc3NsIHRlY2huaWNhbCBkb2N1bWVudGF0aW9uIGFib3V0IFNT TFZlcmlmeUNsaWVudCwgd2hpY2ggZGlzbWlzc2VzIHRoZSBjYXBhY2l0eSB0byBwcmVzZW50IGEg Y3VzdG9tIGNyZWRlbnRpYWwgZXJyb3IgcmVjb3ZlcnkgZmxvdyBhcyBub3QgImludGVyZXN0aW5n IiAoaS5lLiwgb3B0aW9uYWxfbm9fY2EpLg0KDQpUaGUgc3lzdGVtIEkgdGhpbmsgd2UgbmVlZDog YSB3b3JrZmxvdyBpbXBsZW1lbnRhdGlvbiBzeXN0ZW0gZm9yIHRoZSBlbmQtdXNlciB3aXRoIHBy ZWRlc2lnbmVkIHdvcmtmbG93cyBmb3IgYWxtb3N0IGV2ZXJ5dGhpbmcgdGhhdCBvbmUgd291bGQg d2FudCB0byBkbyB3aXRoIGNyeXB0b2dyYXBoeSBhbmQgaW5mb3JtYXRpb24gc3RvcmFnZSwgcHJv dmlkaW5nIGEga2luZCBvZiBzZWN1cmUgYnVuZGxpbmcgb2YgYXNzb2NpYXRlZCBpbmZvcm1hdGlv biBhbmQgcHJlc2VudGluZyB0aGUga2luZCBvZiAidGhpcyBpcyB3aGF0IHlvdSBuZWVkIGF0IHRo aXMgbW9tZW50IiBzZXJ2aWNlIHRoYXQgdGhlIENsZXJrIHByb3ZpZGVzIHRvIHRoZSBKdWRnZS4N Cg0KPiBPbmUgb2YgdGhlIHByb2JsZW1zIGlzIHRoYXQgaWYgeW91IGludGVuZCB0byBjcmVhdGUg c29tZXRoaW5nIG9mIHRoaXMga2luZCB5b3UNCj4gW3ByZXN1bWFibHldIG5lZWQgYSByZXF1aXJl bWVudCBsaXN0LiCgVGhlIG5ha2VkIHRydXRoIGlzIHRoYXQgZ2V0dGluZyBzdWNoIGENCj4gdGhp bmcgaXMgZXNzZW50aWFsbHkgaW1wb3NzaWJsZSBiZWNhdXNlIHRoZSBleGlzdGluZyB1c2VycyBv ZiBjb25zdW1lciBQS0kgZG9uJ3QNCj4ga25vdyB3aGljaCBvbmUgb2YgdGhlIGdhemlsbGlvbiBz ZWN1cml0eSBzdGFuZGFyZHMgZWZmb3J0cyBhcmUgZm9yICJyZWFsIiwgYW5kDQo+IHRoZXJlZm9y ZSBkbyBub3QgW2FjdGl2ZWx5XSBzdXBwb3J0IGFueSBvZiB0aGVtLg0KDQpXaGljaCBpcyB3aHkg SSd2ZSBjcmVhdGVkIG15IG93biBSZXF1aXJlbWVudHMuICBJJ20gc3VyZSB0aGUgcmVzdCBvZiB0 aGUgd29ybGQgd2lsbCBjYXRjaCB1cCBldmVudHVhbGx5Og0KMSkgQXNzZXJ0IG11bHRpcGxlIGNy ZWRlbnRpYWwgY2hhaW5zIGZyb20gbXVsdGlwbGUgY3JlZGVudGlhbCBzb3VyY2VzIGF0b21pY2Fs bHksIGluIHZlcmlmaWFibGUgZm9ybS4NCjIpIEFzc2VydCBub24tdmVyaWZpYWJsZSBkYXRhIGlu IHRoZSBzYW1lIGF0b20uDQozKSBQcm92aWRlIGFuIG9wdGlvbmFsIG1lYW5zIHRvIGVuY3J5cHQg dGhhdCBjcmVkZW50aWFsIGNoYWluIGF0b20gdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudC4NCjQp IFByb3ZpZGUgYSBtZWFucyB0byBlbnN1cmUgdGhhdCBldmVuIGlmIHRoZSBkaWdlc3RzIHVzZWQg Zm9yIHRoZSBzaWduYXR1cmVzIGFyZSBjb21wcm9taXNlZCwgdGhlIGRhdGEgY2FuIHN0aWxsIGJl IGtub3duIGdvb2QuDQo1KSBQcm92aWRlIHN0YXBsZWQgT0NTUCByZXNwb25zZXMgb3IgdGhlIGN1 cnJlbnQgQ1JMIGZvciBldmVyeSBjZXJ0aWZpY2F0ZSBpbiBldmVyeSBjcmVkZW50aWFsIGNoYWlu Lg0KNikgUHJvdmlkZSBhIHRpbWVzdGFtcCwgc28gdGhhdCB0aGUgdGltZSBvZiBzaWduYXR1cmUg Y2FuIGJlIHNob3duIHRvIGV4aXN0IHdpdGhpbiB0aGUgdmFsaWRpdHkgcGVyaW9kcyBvZiB0aGUg Y2VydGlmaWNhdGUgY2hhaW5zJyBPQ1NQLg0KNykgSW5jbHVkZSBldmVyeSBkZXZpY2UgdGhlIHVz ZXIgaGFzIHRoYXQgY2FuIHVuZGVyc3RhbmQgdGhlIHByb3RvY29sLCBpbmNsdWRpbmcgUENzLCBu b3RlYm9va3MsIHRhYmxldHMsIHBob25lcywgYW5kIGNyZWRlbnRpYWwgc3RvcmVzLg0KOCkgUmV1 c2UgYXMgbXVjaCBjcnlwdG8sIHN0YW5kYXJkIGFuZCBjb2RlIGFzIHBvc3NpYmxlLCBzdWJqZWN0 IHRvIHRoZSBjb25zdHJhaW50cyAxLTguICBJZiBwb3NzaWJsZSwgdXNlIGFyZWFzIG9mIHRoZSBz dGFuZGFyZHMgdGhhdCBoYXZlIGJlZW4gZGlzY2xhaW1lZCBieSB0aGUgc3RhbmRhcmRzIGJvZGll cyB0aGVtc2VsdmVzIChzdWNoIGFzIHNlbGYtc2lnbmVkIFguNTA5IHN0cnVjdHVyZXMgYXMgc29t ZXRoaW5nIG90aGVyIHRoYW4gYSB0cnVzdCBhbmNob3IgY29udGFpbmVyKS4NCjkpIFByZXNlbnQg YXV0aG9yaXphdGlvbiBVSSBvbiBvbmUgb3IgbW9yZSBkZXZpY2VzIG90aGVyIHRoYW4gdGhlIGNy ZWRlbnRpYWwgc3RvcmUgYW5kIHRoZSBkZXZpY2Ugd2hpY2ggc3VibWl0dGVkIHRoZSBzaWduYXR1 cmUgcmVxdWVzdCwgdG8gcmVkdWNlIHRoZSBvcHBvcnR1bml0eSBmb3IgbWFsd2FyZSBvbiB0aGUg bWFpbiBpbnRlcmZhY2UgdG8gYXBwbHkgYW4gdW5hdXRob3JpemVkIHNpZ25hdHVyZS4NCjEwKSBT YXZlIC1ldmVyeXRoaW5nLSB0aGF0IGhhcyBldmVyIGJlZW4gc2lnbmVkLg0KDQpNaWdodCB5b3Ug YmUgaW50ZXJlc3RlZCBpbiBhIGRhdGEgZm9ybWF0IHdoaWNoIGVuYWJsZXMgdGhlc2UgdG8gYmUg bWV0LCB3aXRob3V0IGNoYW5nZXMgdG8gdGhlIGV4aXN0aW5nIENBIGluZnJhc3RydWN0dXJlLCB3 aXRob3V0IGFueSBjaGFuZ2VzIHRvIGFueSB0ZWNobmljYWwgc3RhbmRhcmRzIGluY2x1ZGluZyBU TFMgYW5kIFMvTUlNRSwgYW5kIHdpdGhvdXQgd29ycnlpbmcgYWJvdXQgdGhlIGxhY2sgb2YgbW90 aW9uIGluIHN0YW5kYXJkcyBib2RpZXM/ICBTdGFuZGFyZHMgY29tZSBhYm91dCBiZWNhdXNlIHNv bWV0aGluZyB3b3Jrcywgbm90IGJlY2F1c2UgcGVvcGxlIHRoaW5rIHRoYXQgaXQgd2lsbCB3b3Jr IGlmIHRoZXkncmUgYnVpbHQgdG8uICBUaGlzIGlzIHRoZSBmYWlsdXJlIG9mIFBLSVgtV0cuDQoN Cj4gRHVlIHRvIHRoaXMsIHRoZSBmYXRlIG9mIGNvbnN1bWVyIFBLSSBmaXJtbHkgcmVzaWRlcyBp biB0aGUgaGFuZHMgb2YgYmlnIHZlbmRvcnMNCg0KVGhpcyBpcyBwZXJoYXBzIGluY29ycmVjdC4g IFRoZSBmYXRlIG9mIGNvbnN1bWVyIFBLSSBpbiBVUyBhcHBlYXJzIHRvIHJlc2lkZSBpbiBteSBo YW5kcywgYXMgSSBzZWVtIHRvIGJlIHRoZSBvbmx5IHBlcnNvbiBpbiBVUyB3aG8gdGhpbmtzIHRo YXQgdGhlcmUgZG9lcyBleGlzdCBhIGJ1c2luZXNzIGNhc2UgZm9yIGl0Lg0KDQpJZiB5b3Ugd2Fu dCBzb21ldGhpbmcgY3J5cHRvZ3JhcGhpYyBkb25lLCB5b3UgcHJldHR5IG11Y2ggaGF2ZSB0byBy b2xsIHlvdXIgb3duIGJlY2F1c2UgdGhlIGN1cnJlbnQgc3RhbmRhcmRzIGFyZSBzbyBkaXN0cmVz c2luZ2x5IGlnbm9yYW50IG9mIHJlYWxpdHkuIDooDQoNCj4gd2hpY2ggYXJlIGV4Y2x1c2l2ZWx5 IHRhcmdldGluZyBtb2JpbGUgZGV2aWNlcyB3aXRoIGVtYmVkZGVkIHNlY3VyaXR5IGhhcmR3YXJl Lg0KPiBUaGUgc21hcnQgY2FyZCBjb25jZXB0IG5ldmVyIHdvcmtlZCB3ZWxsIGFzIGNvbnN1bWVy IHNvbHV0aW9uIGluIGRlc2t0b3AgUENzLg0KDQpBZ3JlZWQuICBJIGhhdmUgYSBsYXB0b3Agd2l0 aCBhIHNtYXJ0IGNhcmQgcmVhZGVyLiAgSXQgaXMgbXVjaCBtb3JlIGhhc3NsZSB0aGFuIGl0J3Mg d29ydGguDQoNCj4gSU1PLCB0aGVyZSBpcyBhY3R1YWxseSBhIHdheSBhaGVhZCBhbmQgdGhhdCBp cyAicHV0dGluZyB0aGUgY2FydCBiZWZvcmUgdGhlIGhvcnNlIg0KPiB3aGljaCBtZWFucyB0aGF0 IGluc3RlYWQgb2YgZm9sbG93aW5nIHRoZSB3aGltcyBvZiB0aGUgc2V2ZXJlbHkgZGl2aWRlZCBz bWFydCBjYXJkDQo+IGNvbW11bml0eSwgeW91IGRlZmluZSBhIHN0YW5kYXJkIGNhcmQgYW5kIHBy b3ZpZGUgYSAqZml4ZWQqIGRyaXZlci4goEltcGxlbWVudGluZw0KPiBhIG1pbnV0ZSBzZXQgb2Yg Y3J5cHRvZ3JhcGhpYyBvcGVyYXRpb25zIGlzIGFjdHVhbGx5IG5vdCByb2NrZXQgc2NpZW5jZSB3 aGlsZQ0KPiBkZXZlbG9waW5nIGFuZCBkaXN0cmlidXRpbmcgbWlkZGxld2FyZSBmb3IgYSBodWdl IG51bWJlciBvZiBldmVyLWNoYW5naW5nIHBsYXRmb3Jtcw0KPiB0YWtlcyBmb3JldmVyIGFuZCBz dGlsbCB5b3UgbmV2ZXIga25vdyBmb3Igc3VyZSBpZiBpdCBpcyBhY3R1YWxseSB3b3JraW5nIQ0K PiBCeSBtYWtpbmcgdGhlIGRyaXZlciBhICpwbGF0Zm9ybSB2ZW5kb3IgaXNzdWUgb25seSosIHRo aW5ncyBnZXQgbXVjaCBlYXNpZXIuDQoNCkkgZG9uJ3QgYWN0dWFsbHkgdGhpbmsgdGhpcyBpcyB0 aGUgd2F5IGFoZWFkLiAgVGhlIHdheSBhaGVhZCBpcyB0byBtYWtlIGl0IHdvcmssIGFuZCB0aGVu IGxldCBvdGhlciBwZW9wbGUgaW50byB0aGUgZ2FtZS4NCg0KVGhlIHByb2JsZW0gaXMgcGFydGlh bGx5IFBLQ1MjMTEsIGJ1dCBtdWNoIG1vcmUgZ2xvYmFsbHkgSVNPL0lFQyA3ODE2LSouDQoNCkZv ciBhdWRpdGFiaWxpdHkgSSB3YW50IHRvIGVuc3VyZSB0aGF0IEkgaGF2ZSBhYnNvbHV0ZSBjb250 cm9sIG92ZXIgdGhlIGNvbnRhaW5lciBhbmQgaXRzIGF1ZGl0aW5nIGF0IGFsbCB0aW1lcywgYW5k IHRoYXQgaXMgaW1wb3NzaWJsZSB3aXRoIGEgc21hcnQgY2FyZCAob3IgYW55IFBLQ1MxMSBtb2R1 bGUpIHRoYXQgZG9lc24ndCBoYXZlIGEgY3VzdG9tIGVuY2xvc3VyZS4NCg0KPiBQSVYgd2FzIGEg c3RlcCBpbiB0aGlzIGRpcmVjdGlvbiBidXQgTklTVCBkaWRuJ3Qgc3RhbmRhcmRpemUgdGhlIG1h bmFnZW1lbnQNCj4gZnVuY3Rpb25zIHNpbmNlIHRoZSBjYXJkIGluZHVzdHJ5IHdhbnRlZCB0byBr ZWVwIHNvbWV0aGluZyB0byBiZSB1bmlxdWUgd2l0aC4NCg0KTklTVCBpcyBwYXJ0IG9mIHRoZSBw cm9ibGVtLCBwdWJsaXNoaW5nIG9ubHkgaGFsZi1iYWtlZCBzZW1pc3RhbmRhcmRzLiAgQnV0LCBJ IGRvbid0IHRoaW5rIHRoZSBhY3R1YWwgcHJvYmxlbSBwcmV2ZW50aW5nIGNvbnN1bWVyIFBLSSBm cm9tIHRha2luZyByb290IGlzIE5JU1QuICBUaGUgZmFjdCB0aGF0IHNtYXJ0IGNhcmRzIGV4aXN0 IChhbmQgdGhlIHZlbmRvcnMgYXJlIGFsbG93ZWQgdG8gY29udGludWUgcHVzaGluZyBhbmQgZW5m b3JjaW5nIHRoZWlyIHByb3ByaWV0YXJ5IGV4dGVuc2lvbnMpIGlzIGl0c2VsZiBUaGUgUHJvYmxl bS4gIFNtYXJ0IGNhcmRzIGFyZSB0aGUgd3JvbmcgdGVjaG5vbG9neSwgbW9zdGx5IGJlY2F1c2Ug b2YgdGhlIHByb3ByaWV0YXJ5IHZlbmRvciBsb2NrLWluIHRoYXQgdGhlc2Ugc2VtaS1zdGFuZGFy ZHMgaGF2ZSBjcmVhdGVkLg0KDQpTbywgSSdtIG1vcmUgdGhhbiBoYXBweSB0byBub3Qgb25seSAi aWdub3JlIHRoZSBzbWFydCBjYXJkIGluZHVzdHJ5J3MgZGVzaXJlcyIsIGJ1dCAiaWdub3JlIHRo ZSBzbWFydCBjYXJkIGluZHVzdHJ5J3MgZXhpc3RlbmNlIi4NCg0KVGhlIFJhc3BiZXJyeSBQaSAo aHR0cDovL3d3dy5yYXNwYmVycnlwaS5vcmcvKSBpcyBhbiBvcGVuIGRldmljZSB3aXRoIGFuIDgw ME1IeiBwcm9jZXNzb3IgYW5kIGEgJDI1IHByaWNlIHRhZy4gIFRoaXMgaXMgdGhlIGNyZWRlbnRp YWwgc3RvcmFnZSBkZXZpY2Ugb2YgdGhlIGZ1dHVyZSwgbG93LWxldmVsIGVub3VnaCB0aGF0IEkg Y2FuIHRha2UgY29tcGxldGUgY29udHJvbCBhcyBJIG5lZWQgdG8sIGZhc3QgZW5vdWdoIHRoYXQg aXQgY2FuIHBlcmZvcm0gYWNjZXB0YWJseS4gIFdpdGggSVB2NiwgZXZlcnlvbmUgb24gZWFydGgg Y291bGQgaGF2ZSB0ZW4gb2YgdGhlbSBhbmQgdGhlcmUgd291bGQgc3RpbGwgYmUgbW9yZSB0aGFu IDMuNDBFKzM4ICgzNDArIHNob3J0LXNjYWxlIHVuZGVjaWxsaW9uKSBhZGRyZXNzZXMgbGVmdCwg c3ViamVjdCB0byB0aGUgbG9zc2FnZSBvZiBuZXR3b3JrIHZlcnN1cyBpbnRlcmZhY2UgYWRkcmVz c2luZy4NCg0KTWl4aW5nIHRoaXMgd2l0aCBhIHNtYXJ0cGhvbmUgbWVhbnMgdGhhdCB5b3Ugc3Vk ZGVubHkgaGF2ZSBhIHJlbW90ZSBrZXlzdG9yZSB0aGF0IHlvdSBjYW4gc2VuZCB1bnNpZ25lZCBy ZXF1ZXN0cyBhbmQgc2lnbmVkIGF1dGhvcml0aWVzIHRvLCB2aWEgYSBVSSBkZXZpY2UgeW91J3Zl IGFscmVhZHkgZ290IGluIHlvdXIgcG9ja2V0Lg0KDQpJIHNlZW0gdG8gYmUgdGhlIG9ubHkgc2Vj dXJpdHktbWluZGVkIHBlcnNvbiBpbiBVUyB3aG8gdGhpbmtzIHRoYXQgSVB2NiB1dGlsaXR5IGlz IG5vdCBvbmx5IGF3ZXNvbWVzYXVjZSBidXQgdGhlIG9ubHkgd2F5IGZvcndhcmQsIGJlY2F1c2Ug d2UgY3VycmVudGx5IGNhbm5vdCB1c2Ugb3VyIGNyeXB0b2dyYXBoaWMga2V5cyBhcyBvdXIgSVAg YWRkcmVzc2VzLiAgQnV0LCB3ZSBjYW4gZW5hYmxlIHRoYXQgaWYgd2UgdXNlIHRoZW0gYXMgcG9y dGlvbnMgb2YgbXVsdGljYXN0IGFkZHJlc3Nlcy4gIChwaHlzaWNhbCBsb2NhdGlvbiBpcyBwZXJz b25hbCBpbmZvcm1hdGlvbiBhbmQgbXVzdCBiZSBwcm90ZWN0ZWQuKQ0KDQpJIGFsc28gYXBwZWFy IHRvIGJlIHRoZSBvbmx5IHBlcnNvbiBpbiBVUyB3aG8gdGhpbmtzIHRoYXQgZXZlcnkgYXN5bW1l dHJpYyBrZXkgKHdpdGggZmV3IGVub3VnaCBleGNlcHRpb25zIHRoYXQgdGhpcyBpcyBhIGdvb2Qg Z2VuZXJhbCBydWxlKSBpcyBub25leHBvcnRhYmx5IGJvdW5kIHRvIGhhcmR3YXJlLCBhbmQgaGFy ZHdhcmUgZGllcywgc28gd2Ugc2hhbGwgbG9zZSBldmVyeSBwcml2YXRlIGtleSB3ZSBjYXJlIGFi b3V0LiAgV2UgbXVzdCBwbGFuIGZvciB0aGF0IGV2ZW50dWFsaXR5IHdoaWxlIHN0aWxsIHByb3Zp ZGluZyBhZGVxdWF0ZSBzZWN1cml0eSBmb3Igb3VyIGNsaWVudHMuICANCg0KSSd2ZSBnb3QgYSBk ZXNpZ24gZm9yIHRoaXMgdGhhdCB3b3JrcyBvbiBwYXBlciwgYW5kIEknbSB3b3JraW5nIHRvIG1h a2UgaXQgcmVhbGl0eS4NCg0KQ2hlZXJzIQ0KDQotS3lsZSBIDQoNCg0KPg0KPiBBbmRlcnMNCj4N Cj4gT24gMjAxMi0wNC0xNyAyMzo0MywgS3lsZSBIYW1pbHRvbiB3cm90ZToNCj4+DQo+PiBPbiBU aHUsIEFwciAxMiwgMjAxMiBhdCA5OjIzIFBNLCBBbmRlcnMgUnVuZGdyZW4gPGFuZGVycy5ydW5k Z3JlbkB0ZWxpYS5jb20+IHdyb3RlOg0KPj4+IE15IHBlcnNwZWN0aXZlIG9uIHRoaXMgaXMgc2xp Z2h0bHkgZGlmZmVyZW50LiCgSU1PIHRoaXMgaXNzdWUgKGFzIHdlbGwgYXMgUEtJLi4uKQ0KPj4+ IGlzIGVzc2VudGlhbGx5ICJvd25lZCIgYnkgdGhyZWUgbWFqb3IgbGFnZ2FyZHM6IEdvdmVybm1l bnRzLCBCYW5rcywgYW5kIE1pY3Jvc29mdC4NCj4+DQo+PiBUaGlzIGlzc3VlIGlzICJvd25lZCIg YnkgSVNPLCB3aGljaCBtZWFucyB0aGF0IGl0J3Mgb24gdGhlIGdvdmVybm1lbnRzIHdobyBhcmUg cGFydGljaXBhdGluZyBpbiBJU08uDQo+Pg0KPj4gVGhlIG1vc3QgaW1wb3J0YW50IGFzcGVjdCBv ZiBhbnkgYWNjZXNzLWNvbnRyb2wgc3lzdGVtIChlc3BlY2lhbGx5IGZpbmFuY2lhbCkgaXMgYXVk aXRhYmlsaXR5LCBhbmQgdGhlIElTTyBzdGFuZGFyZHMgZG9uJ3QgY2F1c2UgZW5vdWdoIGRhdGEg dG8gYmUgdHJhbnNtaXR0ZWQgdG8gdGhlIGNyeXB0b2dyYXBoaWMgY29udGFpbmVyIGZvciB0aGUg Y29udGFpbmVyIHRvIHdyaXRlIGl0cyBvd24gYXVkaXQgbG9ncy4goFBLQ1MjMTEgZXhwb3NlcyBJ U08gZnVuY3Rpb25hbGl0eSwgc28gaXQgZG9lc24ndCBoYXZlIGEgIkknbSBzZW5kaW5nIHlvdSBz b21ldGhpbmcgdGhhdCBJIHdhbnQgeW91IHRvIGRpZ2VzdCBmb3IgbWUiIGNhbGwuIKBUaHVzLCB3 ZSBoYXZlIG5vIGlkZWEgdGhhdCB0aGUgZGlnZXN0cyBzdWJtaXR0ZWQgYXJlIGJlaW5nIGNhbGN1 bGF0ZWQgY29ycmVjdGx5LCBhbmQgbm8gaWRlYSB3aGF0IHRoZSBkaWdlc3RzIHdlJ3JlIHNpZ25p bmcgYWN0dWFsbHkgbWVhbi4NCj4+DQo+PiBJbnN0ZWFkLCB3ZSBoYXZlIHRvIGltcGxlbWVudCB0 aGUgYXVkaXRpbmcgc2VydmljZSBleHRlcm5hbGx5LCB3aGljaCBtZWFucyB0aGF0IHdlIG11c3Qg YmUgYWJsZSB0byB0cnVzdCB0aGF0IHdlIGFyZSB0aGUgc29sZSBjb250cm9sbGVycyBvZiB0aGUg Y3J5cHRvZ3JhcGhpYyBjb250YWluZXJzIGludm9sdmVkLg0KPj4NCj4+PiBTaW5jZSB0aGUgZmly c3QgdHdvIGFyZSBudW1lcm91cyBhcyB3ZWxsIGFzIGdlb2dyYXBoaWNhbGx5IGFuZCBjdWx0dXJh bGx5DQo+Pj4gZGl2ZXJzZSBpdCB3b3VsZCBiZSB3cm9uZyBnaXZpbmcgdGhlbSB0aGUgYmxhbWUu IKBIb3dldmVyLCBzaW5jZSB0aGV5IHRvDQo+Pj4gc29tZSA5MCUgaGF2ZSByZWxpZWQgb24gYSBz aW5nbGUgY2xpZW50LU9TIHZlbmRvciwgdGhlIGdlbmVyYWxseSBwaXRpZnVsDQo+Pj4gc3RhdGUg b2YgY2xpZW50LXNpZGUgUEtJIGluIGNvbnN1bWVyIFBDcyBpcyB1bmlsYXRlcmFsbHkgZHVlIHRv IE1pY3Jvc29mdCdzDQo+Pj4gbGltaXRlZCBvZiB1bmRlcnN0YW5kaW5nIG9mIHRoaXMgbWFya2V0 LiCgT3ZlciB0aGUgeWVhcnMgSSBoYXZlIG1ldCBxdWl0ZQ0KPj4+IGEgYnVuY2ggb2YgTWljcm9z b2Z0IFByb2dyYW0gTWFuYWdlcnMgYW5kIHRoZXkgYWxsIHNheSB0aGUgc2FtZSB0aGluZzoNCj4+ PiAiVGhlcmUgaXMgbm8gYnVzaW5lc3MgY2FzZSBmb3IgY29uc3VtZXIgUEtJIi4goEluIHNvbWUg d2F5IHRoaXMgaXMgYWxzbw0KPj4+IHRydWUgc2luY2UgdGhlcmUgaXMgbm8gcGF5aW5nIGN1c3Rv bWVyIG91dCB0aGVyZS4NCj4+DQo+PiBBaCwgTWljcm9zb2Z0IHNwcmVhZGluZyBsaWVzIGFnYWlu Lg0KPj4NCj4+IFRoZXJlIGlzIG5vIGJ1c2luZXNzIGNhc2UgZm9yIGRpc2NhcmRpbmcgQXBhY2hl IGh0dHBkJ3MgU1NMVmVyaWZ5Q2xpZW50IG9wdGlvbmFsX25vX2NhLCBidXQgaXQncyBkaXNjYXJk ZWQgYnkgdGhlIHRlY2huaWNhbCBwZW9wbGUgYmVjYXVzZSBpdHMgZG9jdW1lbnRhdGlvbiBzYXlz IHRoYXQgIm9wdGlvbmFsX25vX2NhIGlzIGFjdHVhbGx5IGFnYWluc3QgdGhlIGlkZWEgb2YgYXV0 aGVudGljYXRpb24iLiCgSW5zdGVhZCwgd2UgZW5kIHVwIHdpdGggYXBwbGljYXRpb25zIHdoaWNo IGhhbmRsZSB0aGVpciBvd24gdXNlcm5hbWUgYW5kIHBhc3N3b3JkIGVycm9yIGZsb3dzIGJlY2F1 c2Ugb3B0aW9uYWxfbm9fY2EgaXMgaW4gZmFjdCB0aGUgb25seSB3YXkgdG8gcHJlc2VudCBhIGN1 c3RvbSBlcnJvciBwYWdlIHdoZW4gcGVvcGxlIGluYWR2ZXJ0ZW50bHkgdHJ5IHRvIGxvZyBpbiB3 aXRoIHRoZSB3cm9uZyBjZXJ0aWZpY2F0ZSBvciBiZWZvcmUgdGhleSd2ZSBldmVyIGJlZW4gaXNz dWVkIGEgY2VydGlmaWNhdGUgZm9yIHRoZSBzZXJ2aWNlIGluIHF1ZXN0aW9uLg0KPj4NCj4+IFRo ZXJlIGlzIG5vIGJ1c2luZXNzIGNhc2UgZm9yIGNvbnN1bWVyIFguNTA5LWFzLXRpZWQtdG8tWC41 MDAuIKBUaGVyZSBpcyBhIGJ1c2luZXNzIGNhc2UgZm9yIGVucm9sbGluZyB5b3VyIHNpdGUncyBv d24gY3JlZGVudGlhbHMuIKBUaGVyZSBpcyBhIGJ1c2luZXNzIGNhc2UgZm9yIHdoaXNwZXJpbmcg dG8gYSBmcmllbmQuIKAoVGhlIHByb2JsZW0gaXMgdGhhdCBhdHRlbXB0cyBsaWtlIHRoaXMgdG8g cmVwdXJwb3NlIFguNTA5IGFyZSBtYWxpZ25lZCBieSBlLmcuIEZpcmVmb3guKQ0KPj4NCj4+PiBE dWUgdG8gdGhhdCwgdGhlIGJhbmtzIGluIHRoZSBFVSB0aGF0IGFjdHVhbGx5IHVzZSBjb25zdW1l ciBQS0kgaGF2ZSBiZWVuDQo+Pj4gZm9yY2VkIGRldmVsb3BpbmcgdGhlaXIgb3duIGNsaWVudC1z aWRlIHNvZnR3YXJlLiCgSSBndWVzcyBTdGVmYW4gKFBLSVgNCj4+PiBjby1jaGFyKSwgbmV2ZXIg dG9sZCB0aGF0IHRvIGhpcyBib3NzIHdoZW4gaGUgd29ya2VkIGZvciBNaWNyb3NvZnQgKGluIHRo ZQ0KPj4+IFVTIGEgc3Vib3JkaW5hdGUgdHlwaWNhbGx5IGdldHMgZmlyZWQgaWYgaGUvc2hlIGNy aXRpY2l6ZXMgY29tcGFueSBzdHJhdGVneSkuDQo+Pg0KPj4gLi4uc28gd2h5IGhhdmVuJ3QgdGhl eSBnb3R0ZW4gdG9nZXRoZXIgdG8gZnVuZCB0aGUgZGV2ZWxvcG1lbnQgb2YgYSB1bmlmaWVkIGlu dGVyZmFjZT8goFdoeSBoYXZlbid0IHRoZXkgY29udHJpYnV0ZWQgdGhlaXIgcXVhbnR1bSBsZWFw cyBpbiBjbGllbnQgUEtJIHByZXNlbnRhdGlvbj8goEhvdyBtdWNoIG9mIHRoZSBibGFtZSBsaWtl cyBpbiB0aGVpciBkZXNpcmUgdG8gaGF2ZSBhIHByb3ByaWV0YXJ5IGVkZ2U/DQo+Pg0KPj4+IFRo aXMgaGFzIGFuZCBzdGlsbCBpcyB0aGUgcHJpbWFyeSBtb3RpdmF0aW9uIGJlaGluZCBteSBlbnJv bGxtZW50ICJjcnVzYWRlIi4NCj4+PiBIb3dldmVyLCBpdCBpcyBhbHNvIHBvc3NpYmxlIHRoYXQg dGhlIHdob2xlIGlkZWEgcmV2aXZpbmcgdHJhZGl0aW9uYWwgUENzIGlzDQo+Pj4gdG9hc3QsIGl0 IGlzIHJlYWxseSB0aGUgbW9iaWxlIGRldmljZXMgdGhhdCBhcmUgaW4gdGhlIGNlbnRlciB0aGVz ZSBkYXlzLg0KPj4NCj4+IEkgYW0gb2YgdGhlIG9waW5pb24gdGhhdCAiZW5yb2xsbWVudCBpcyBj aGVhcCwgdmVyaWZpY2F0aW9uIGlzIGV4cGVuc2l2ZS4iIKBPbmNlIHRoZSBpZGVudGl0eSBpcyB2 ZXJpZmllZCwgdGhlcmUncyBubyByZWFzb24gYXQgYWxsIHRvIGF2b2lkIGVucm9sbGluZyBhZGRp dGlvbmFsIGtleXMgYW5kIGxpbmtpbmcgdGhlbSB0byB0aGUgc2FtZSByZWNvcmQsIGFzIGxvbmcg YXMgeW91IGRlZmluZSB0aGUgZW5yb2xsbWVudCBwcm9jZXNzIGFzIG1vcmUgdGhhbiBqdXN0IHRo ZSBhcHBsaWNhdGlvbiBvZiBhIHNpbmdsZSBrZXkgcGVyLXBhcnR5Lg0KPj4NCj4+IFdoYXQncyBo YXBwZW5lZCB0byB0aGlzIHBvaW50IGlzIHRoYXQgbm9ib2R5J3MgYm90aGVyZWQgdG8gYXV0aGVu dGljYXRlIHRoZSBrZXlzdG9yZSBvbiBlYWNoIGluZGl2aWR1YWwgZGV2aWNlLCBzbyB0aGUga2V5 c3RvcmUgaXRzZWxmIGNhbid0IGFzc2VydCB0aGF0IGl0IGdlbmVyYXRlZCB0aGUga2V5IHdpdGgg a25vd2xlZGdlIG9mIHRoZSBwb2xpY3kgZ292ZXJuaW5nIHNhaWQga2V5IGdlbmVyYXRpb24uIKBJ ZiB0aGUgZW5yb2xsaW5nIGNlcnRpZmllciBoYXMgZXZpZGVuY2UgdGhhdCB0aGUga2V5IHdhcyBn ZW5lcmF0ZWQgcHJvcGVybHkgLWFuZC0gdGhhdCBpdCB3YXMgc3VibWl0dGVkIGJ5IHRoZSBwcmlu Y2lwYWwsIGl0IGNhbiBzZWN1cmVseSBlbnJvbGwgYWRkaXRpb25hbCBrZXlzLg0KPj4NCj4+IFRo aXMgaXMgbm90IGltcG9zc2libGUuIKBJdCBqdXN0IHJlcXVpcmVzIGV4YW1pbmluZyB0aGluZ3Mg aW4gdGhlICJob3cgY2FuIEkgZ2V0IHBhc3QgdGhpcyBwcm9ibGVtPyIgaW52ZW50aW5nIG1pbmRz ZXQuDQo+Pg0KPj4+IEl0IGlzIGVzc2VudGlhbGx5IEdvb2dsZSBhbmQgQXBwbGUgdGhhdCBydW4g dGhpcyBzaG93IG5vd2FkYXlzLiCgU2luY2UgdGhleQ0KPj4+IGFsc28gaGF2ZSB0aGUgc2Vydmlj ZXMsIHRoZXJlIGlzIGFuIGVudGlyZWx5IG5ldyBtb3RpdmF0aW9uIHRoZXNlIGRheXMuDQo+Pj4N Cj4+PiBBbnl3YXksIFBLSVggd29uJ3QgYmUgdGhlcmUgd2hlbiBpdCBhY3R1YWxseSBoYXBwZW5z OyB0aGF0J3MgZm9yIHN1cmUhISENCj4+DQo+PiAuLi51bmxlc3MgZXZlcnlvbmUgd2hvJ3MgdGVy cmlmaWVkIG9mIGNoYW5naW5nIGFueXRoaW5nIGZvciBmZWFyIG9mIFZpb2xhdGluZyBUaGUgUHVy aXR5IE9mIFRoZSBEZXNpZ24gU3BlYyBpcyBzdW1tYXJpbHkgcmVtb3ZlZCBmcm9tIHRoZSBvcmdh bml6YXRpb24sIGFueXdheS4goFdlIG5lZWQgdG8gbWFrZSB0aGlzIHdvcmsuIKBJdCdzIHVuYWNj ZXB0YWJsZSB0aGF0IHdlIGdpdmUgZXhjdXNlcyBtdWNoIGxpa2UgInlvdSBkaWRuJ3QgY3JlYXRl IHRoaXMgc2lnbmF0dXJlIHVuZGVyIHRoZSBkYXJrIG9mIHRoZSBtb29uIHdpdGggdGhlIGJsb29k IG9mIGEgc2FjcmlmaWNlZCBjaGlja2VuIG9uIGEgcml0dWFsbHkgc2FuY3RpZmllZCBzaWx2ZXIg ZGFnZ2VyIHdhc2hlZCBpbiB0aGUgdGVhcnMgb2YgYSB2aXJnaW4uLi4gc28gd2UncmUganVzdCBn b2luZyB0byBpbnRlcmZlcmUgd2l0aCBhbmQgcHJldmVudCB5b3UgZnJvbSBkb2luZyB0aGUgd29y ayB5b3UgbmVlZCB0byBkby4iDQo+Pg0KPj4gSSBtZWFuIG5vIG9mZmVuc2UsIGJ1dCB0aGlzIHJl YWxseSBuZWVkcyB0byBiZSBzYWlkLiCgVGhlIFBLSSBQcmllc3Rob29kIGlzIGxpa2UgdGhlIHJp Z2lkIGhpZXJhcmNoeSBvZiBWYXRpY2FuIENhdGhvbGljaXNtIG1peGVkIHdpdGggdGhlICJvaCBH b2QgcGxlYXNlIGxldCB0aGlzIGJlIHN1ZmZpY2llbnQgdG8gbm90IGRvIHdoYXQgSSBmZWFyIFlv dSB3aWxsIiBhbmQga29zaGVyIGxhd3Mgb2YgT3J0aG9kb3ggSnVkYWlzbSBhbmQgdGhlIGJsb29k IHNhY3JpZmljZSBjb25zZWNyYXRpb24gb2YgSGFpdGlhbiBWb2RvdW4gYWxsIHJvbGxlZCBpbnRv IG9uZSBob3JyaWJsZSBibGFzcGhlbXkgb2Ygcm90ZSByaXR1YWwgZm9yIGFsbCB0aGUgd3Jvbmcg cmVhc29ucy4goENhbid0IHdlIGRlZnJvY2sgdGhlIFBLSSBQcmllc3RzPyCgT3IgYW0gSSBzdHVj ayBpbiB0aGUgZXN0YWJsaXNobWVudC1xdWVzdGlvbmluZyBzaG9lcyBvZiBNYXJ0aW4gTHV0aGVy IChmYXRoZXIgb2YgTHV0aGVyYW5pc20gYWZ0ZXIgaGUgZGVub3VuY2VkIFZhdGljYW4gQ2F0aG9s aWNpc20gYXMgY29ycnVwdCk/DQo+Pg0KPj4gLUt5bGUgSA0KPg0KDQo= --gmsm1.9.6eqh171drgrm9139p8huv2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINAjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGxjCCBa6g AwIBAgICCMUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNzE5MDFaFw0xMjA2MDUyMDMxMzFaMIHAMSAwHgYDVQQNExcyMDc2MDUtQzh5TUxvb3ll VE85NFFKeDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xIDAeBgkqhkiG9w0BCQEWEWt5YW5oYUBreWFuaGEubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5YylxEUtOSlqBT0sxqB7H0YUDx30ADzggTrSLA9n JVa0QCcIXhk04n7VUD5Augbc40rWhgmB8xl6N9pQ5qvAQZj8JmNej6LRlueN/et9MCjNN0euH0Ky zzKBSE5fxoUPYTTa6QBBurmKNR0navAKWBi8ITLRPi864zTay2oW1A1E1nt69SgJGn3PAv/LyKII WWMzu9YeJsRCd4u6vLHOsGHvr5rc7Dq4bXx8x+vyHgSuYccAnNu81lOC2Unea4TORMoULiwKOTRb pEy35H9Y7MW+SCTlaQiSLgxvYB260OuofHZgcS0wr/OnbGVAEUeBRYhfu3BaxNlZ6zY7mvs9NwID AQABo4IC+jCCAvYwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBThUNrymHVQVA3i/K/6BF4dnrmTqDAfBgNVHSMEGDAWgBSuVYNv 7DHKufcd+q9rMfPIHeOsuzAcBgNVHREEFTATgRFreWFuaGFAa3lhbmhhLm5ldDCCAUIGA1UdIASC ATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p bnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFM aW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9v Y3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDov L3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAjquLhQpUqqxo pg1hbv8zADjhTUY1Gxm1Ha/5Ntdjds7HZ54jOqD2fVwWRbqLAtq+rwHIaudvk13icftTedJlV01r +6VjmOZhSwOPPiYG/v81ABitv8bfyOkei/3BblORXOyzwuXHrbmMOgaEcCmQmqyTo1UJiNMy5Tw0 CvDt+KbSbGP2lQL8BAGyLhswuGePoReqw221KsX6sZJ4Eovk70SlNN19YiRAFYdWL+ggY5mMPn9S qXk8GGLaOyg3g2HnVr7Y4MLYfI0pheoRvoGxj8a4xofTz3u6OlGYE/3D5/uLQbw/rTz6GVVgUFPi GFSKZjzXwfEYJ3Kd1BMXCyfE6zGCAnwwggJ4AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAgjFMAkGBSsOAwIaBQCggb4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTIwNDE4MjM1MjM2WjAjBgkqhkiG9w0BCQQxFgQUJQoK4JY4d8Zds0WT1S/W1Ii/ clQwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIIBAFVZW+fxly095ap+t1CHFExoBbJGNGY+s5tE76WWFDb4lHCsTac1KrlAYsFh5REOTalvRYup 2yMMCVUON9zneyAXAJG5UNw5bw8KK7qIyTGuacVDZ1aUU3fvu+tK1qIpgxNOWVWqo03zVaerk1yM r58BceaJIIOt98s34uD643a3nTmbH8lWsVazswWABsMR1fXvjQD0n1oMuGsIoAKRYMPjV0/xOFJ2 o+G9gn9PDdos3jlESuVdWowytNZ1/7SqKRoO5iBqSgq5UDOmgaIZmrnKWwnPR7LpaCJSpMKTJuUz /nV4+eCl2OyzaUmUhB4p6tSaJs4BjX5N8q845Z7hDI8AAAAAAAA= --gmsm1.9.6eqh171drgrm9139p8huv2-- From swilson@lockstep.com.au Wed Apr 18 19:50:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657A411E8089 for ; Wed, 18 Apr 2012 19:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OEDrqjsFwVW for ; Wed, 18 Apr 2012 19:49:57 -0700 (PDT) Received: from smtp142.iad.emailsrvr.com (smtp142.iad.emailsrvr.com [207.97.245.142]) by ietfa.amsl.com (Postfix) with ESMTP id D92DA11E8086 for ; Wed, 18 Apr 2012 19:49:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 5BFE71A043B for ; Wed, 18 Apr 2012 22:49:56 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id BA1D01A02E2 for ; Wed, 18 Apr 2012 22:49:54 -0400 (EDT) Message-ID: <4F8F7D4C.7060503@lockstep.com.au> Date: Thu, 19 Apr 2012 12:49:48 +1000 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "pkix@ietf.org" References: <4F856D3A.1060103@telia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 02:50:02 -0000 Just quickly, would you care to clarify what it means to get rid of passwords? Do you really mean single factor authentication (i.e. passwords on the own)? Do you imagine PKI based cards / devices would still be password activated? Do you really mean reduce the number of passwords? Do you advocate radical SSO, so that once logged in, you stay logged in across arbitrarily many services without ever reentering a password? I won't apologise for nitpicking, because there's too much woolly language in the identity space. We see maniacal media reports about NSTIC doing away with passwords altogether. And what about the common perception that biometrics will do away with passwords? Then along comes this palm scanning ATM where that's not only false, but it even requires an additional secret over and above the PIN? http://news.discovery.com/tech/scan-hand-atm-cash-120414.html So let's be sure we set the right expectations! Cheers, Steve Wilson Lockstep/http://lockstep.com.au On 19/04/2012 9:52 AM, Kyle Hamilton wrote: > Anders, > > I am entirely with you on "getting away from passwords". Though, > instead of wringing my hands about it and thinking that I can't do > anything for it, I'm creating the system that I perceive the need > for. I despise passwords, and I believe that they should have been > done away with 15 years ago, the moment the Wassennar Arrangement was > inked in 1998. > > There exist a couple of barriers which prevent passwords from going > extinct. There are two that I have my eyes on. One exists at > Mozilla, the other at Apache httpd. > > On Tue, Apr 17, 2012 at 11:31 PM, Anders Rundgren > wrote: >> Hi Kyle, >> I'm not able to respond to your elaborate input because I'm working >> with a much >> more basic question which is "getting away from passwords". To have >> a chance of >> succeeding you need Vision, Ambition, Marketing, Competence, and >> Funding. Maybe >> you even need a portion of luck :-) > > My vision: I believe that every individual in the world has the > absolute right to keep his own secrets. Every person in the world has > the right to be safe from impersonation fraud. Every person in the > world has the right to form his own associations, and to create > systems to help those associations work as expected by the > participants. What has prevented it to this point is the lack of a > useful, comprehensible interface. The Clerk of Courts exemplifies > everything that we expect from our information systems, and should be > the role model we try to emulate. > Ambition: I'm going to make sure that everyone has the capacity to > keep his own secrets, with an interface much like the Clerk of Courts > presents to the Judges of the Courts, meaning nearly invisible but > providing exactly what information/paperwork is needed at any given > moment. > Competence: I juggle cryptographic building blocks until every need is > met. At this point, I'm looking for people to evaluate the design I > created to make passwords the wave of the past. You seem to be > interested enough in the topic and competent enough in the field to be > able to give feedback. > Marketing/Funding: I'll hand it to Mozilla and/or Apache. > Luck: that nobody else has yet done it right. :-) > > I'm working to improve Mozilla's platform so that sites can create and > enroll their own credentials without throwing away the benefits of its > root program. (The bug: locally-trusted certificates present the same > UI as root program certificates.) > > I'm also working to remove Apache mod_ssl technical documentation > about SSLVerifyClient, which dismisses the capacity to present a > custom credential error recovery flow as not "interesting" (i.e., > optional_no_ca). > > The system I think we need: a workflow implementation system for the > end-user with predesigned workflows for almost everything that one > would want to do with cryptography and information storage, providing > a kind of secure bundling of associated information and presenting the > kind of "this is what you need at this moment" service that the Clerk > provides to the Judge. > >> One of the problems is that if you intend to create something of this >> kind you >> [presumably] need a requirement list. The naked truth is that >> getting such a >> thing is essentially impossible because the existing users of >> consumer PKI don't >> know which one of the gazillion security standards efforts are for >> "real", and >> therefore do not [actively] support any of them. > > Which is why I've created my own Requirements. I'm sure the rest of > the world will catch up eventually: > 1) Assert multiple credential chains from multiple credential sources > atomically, in verifiable form. > 2) Assert non-verifiable data in the same atom. > 3) Provide an optional means to encrypt that credential chain atom to > the intended recipient. > 4) Provide a means to ensure that even if the digests used for the > signatures are compromised, the data can still be known good. > 5) Provide stapled OCSP responses or the current CRL for every > certificate in every credential chain. > 6) Provide a timestamp, so that the time of signature can be shown to > exist within the validity periods of the certificate chains' OCSP. > 7) Include every device the user has that can understand the protocol, > including PCs, notebooks, tablets, phones, and credential stores. > 8) Reuse as much crypto, standard and code as possible, subject to the > constraints 1-8. If possible, use areas of the standards that have > been disclaimed by the standards bodies themselves (such as > self-signed X.509 structures as something other than a trust anchor > container). > 9) Present authorization UI on one or more devices other than the > credential store and the device which submitted the signature request, > to reduce the opportunity for malware on the main interface to apply > an unauthorized signature. > 10) Save -everything- that has ever been signed. > > Might you be interested in a data format which enables these to be > met, without changes to the existing CA infrastructure, without any > changes to any technical standards including TLS and S/MIME, and > without worrying about the lack of motion in standards bodies? > Standards come about because something works, not because people think > that it will work if they're built to. This is the failure of PKIX-WG. > >> Due to this, the fate of consumer PKI firmly resides in the hands of >> big vendors > > This is perhaps incorrect. The fate of consumer PKI in US appears to > reside in my hands, as I seem to be the only person in US who thinks > that there does exist a business case for it. > > If you want something cryptographic done, you pretty much have to roll > your own because the current standards are so distressingly ignorant > of reality. :( > >> which are exclusively targeting mobile devices with embedded security >> hardware. >> The smart card concept never worked well as consumer solution in >> desktop PCs. > > Agreed. I have a laptop with a smart card reader. It is much more > hassle than it's worth. > >> IMO, there is actually a way ahead and that is "putting the cart >> before the horse" >> which means that instead of following the whims of the severely >> divided smart card >> community, you define a standard card and provide a *fixed* driver. >> Implementing >> a minute set of cryptographic operations is actually not rocket >> science while >> developing and distributing middleware for a huge number of >> ever-changing platforms >> takes forever and still you never know for sure if it is actually >> working! >> By making the driver a *platform vendor issue only*, things get much >> easier. > > I don't actually think this is the way ahead. The way ahead is to > make it work, and then let other people into the game. > > The problem is partially PKCS#11, but much more globally ISO/IEC 7816-*. > > For auditability I want to ensure that I have absolute control over > the container and its auditing at all times, and that is impossible > with a smart card (or any PKCS11 module) that doesn't have a custom > enclosure. > >> PIV was a step in this direction but NIST didn't standardize the >> management >> functions since the card industry wanted to keep something to be >> unique with. > > NIST is part of the problem, publishing only half-baked > semistandards. But, I don't think the actual problem preventing > consumer PKI from taking root is NIST. The fact that smart cards > exist (and the vendors are allowed to continue pushing and enforcing > their proprietary extensions) is itself The Problem. Smart cards are > the wrong technology, mostly because of the proprietary vendor lock-in > that these semi-standards have created. > > So, I'm more than happy to not only "ignore the smart card industry's > desires", but "ignore the smart card industry's existence". > > The Raspberry Pi (http://www.raspberrypi.org/) is an open device with > an 800MHz processor and a $25 price tag. This is the credential > storage device of the future, low-level enough that I can take > complete control as I need to, fast enough that it can perform > acceptably. With IPv6, everyone on earth could have ten of them and > there would still be more than 3.40E+38 (340+ short-scale undecillion) > addresses left, subject to the lossage of network versus interface > addressing. > > Mixing this with a smartphone means that you suddenly have a remote > keystore that you can send unsigned requests and signed authorities > to, via a UI device you've already got in your pocket. > > I seem to be the only security-minded person in US who thinks that > IPv6 utility is not only awesomesauce but the only way forward, > because we currently cannot use our cryptographic keys as our IP > addresses. But, we can enable that if we use them as portions of > multicast addresses. (physical location is personal information and > must be protected.) > > I also appear to be the only person in US who thinks that every > asymmetric key (with few enough exceptions that this is a good general > rule) is nonexportably bound to hardware, and hardware dies, so we > shall lose every private key we care about. We must plan for that > eventuality while still providing adequate security for our clients. > I've got a design for this that works on paper, and I'm working to > make it reality. > > Cheers! > > -Kyle H > > >> >> Anders >> >> On 2012-04-17 23:43, Kyle Hamilton wrote: >>> >>> On Thu, Apr 12, 2012 at 9:23 PM, Anders Rundgren >>> wrote: >>>> My perspective on this is slightly different. IMO this issue (as >>>> well as PKI...) >>>> is essentially "owned" by three major laggards: Governments, Banks, >>>> and Microsoft. >>> >>> This issue is "owned" by ISO, which means that it's on the >>> governments who are participating in ISO. >>> >>> The most important aspect of any access-control system (especially >>> financial) is auditability, and the ISO standards don't cause enough >>> data to be transmitted to the cryptographic container for the >>> container to write its own audit logs. PKCS#11 exposes ISO >>> functionality, so it doesn't have a "I'm sending you something that >>> I want you to digest for me" call. Thus, we have no idea that the >>> digests submitted are being calculated correctly, and no idea what >>> the digests we're signing actually mean. >>> >>> Instead, we have to implement the auditing service externally, which >>> means that we must be able to trust that we are the sole controllers >>> of the cryptographic containers involved. >>> >>>> Since the first two are numerous as well as geographically and >>>> culturally >>>> diverse it would be wrong giving them the blame. However, since >>>> they to >>>> some 90% have relied on a single client-OS vendor, the generally >>>> pitiful >>>> state of client-side PKI in consumer PCs is unilaterally due to >>>> Microsoft's >>>> limited of understanding of this market. Over the years I have met >>>> quite >>>> a bunch of Microsoft Program Managers and they all say the same thing: >>>> "There is no business case for consumer PKI". In some way this is >>>> also >>>> true since there is no paying customer out there. >>> >>> Ah, Microsoft spreading lies again. >>> >>> There is no business case for discarding Apache httpd's >>> SSLVerifyClient optional_no_ca, but it's discarded by the technical >>> people because its documentation says that "optional_no_ca is >>> actually against the idea of authentication". Instead, we end up >>> with applications which handle their own username and password error >>> flows because optional_no_ca is in fact the only way to present a >>> custom error page when people inadvertently try to log in with the >>> wrong certificate or before they've ever been issued a certificate >>> for the service in question. >>> >>> There is no business case for consumer X.509-as-tied-to-X.500. >>> There is a business case for enrolling your site's own credentials. >>> There is a business case for whispering to a friend. (The problem >>> is that attempts like this to repurpose X.509 are maligned by e.g. >>> Firefox.) >>> >>>> Due to that, the banks in the EU that actually use consumer PKI >>>> have been >>>> forced developing their own client-side software. I guess Stefan >>>> (PKIX >>>> co-char), never told that to his boss when he worked for Microsoft >>>> (in the >>>> US a subordinate typically gets fired if he/she criticizes company >>>> strategy). >>> >>> ...so why haven't they gotten together to fund the development of a >>> unified interface? Why haven't they contributed their quantum leaps >>> in client PKI presentation? How much of the blame likes in their >>> desire to have a proprietary edge? >>> >>>> This has and still is the primary motivation behind my enrollment >>>> "crusade". >>>> However, it is also possible that the whole idea reviving >>>> traditional PCs is >>>> toast, it is really the mobile devices that are in the center these >>>> days. >>> >>> I am of the opinion that "enrollment is cheap, verification is >>> expensive." Once the identity is verified, there's no reason at all >>> to avoid enrolling additional keys and linking them to the same >>> record, as long as you define the enrollment process as more than >>> just the application of a single key per-party. >>> >>> What's happened to this point is that nobody's bothered to >>> authenticate the keystore on each individual device, so the keystore >>> itself can't assert that it generated the key with knowledge of the >>> policy governing said key generation. If the enrolling certifier >>> has evidence that the key was generated properly -and- that it was >>> submitted by the principal, it can securely enroll additional keys. >>> >>> This is not impossible. It just requires examining things in the >>> "how can I get past this problem?" inventing mindset. >>> >>>> It is essentially Google and Apple that run this show nowadays. >>>> Since they >>>> also have the services, there is an entirely new motivation these >>>> days. >>>> >>>> Anyway, PKIX won't be there when it actually happens; that's for >>>> sure!!! >>> >>> ...unless everyone who's terrified of changing anything for fear of >>> Violating The Purity Of The Design Spec is summarily removed from >>> the organization, anyway. We need to make this work. It's >>> unacceptable that we give excuses much like "you didn't create this >>> signature under the dark of the moon with the blood of a sacrificed >>> chicken on a ritually sanctified silver dagger washed in the tears >>> of a virgin... so we're just going to interfere with and prevent you >>> from doing the work you need to do." >>> >>> I mean no offense, but this really needs to be said. The PKI >>> Priesthood is like the rigid hierarchy of Vatican Catholicism mixed >>> with the "oh God please let this be sufficient to not do what I fear >>> You will" and kosher laws of Orthodox Judaism and the blood >>> sacrifice consecration of Haitian Vodoun all rolled into one >>> horrible blasphemy of rote ritual for all the wrong reasons. Can't >>> we defrock the PKI Priests? Or am I stuck in the >>> establishment-questioning shoes of Martin Luther (father of >>> Lutheranism after he denounced Vatican Catholicism as corrupt)? >>> >>> -Kyle H >> > From mrex@sap.com Wed Apr 18 20:33:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7324311E807F for ; Wed, 18 Apr 2012 20:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiGTLyvknrRS for ; Wed, 18 Apr 2012 20:33:46 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DED0D11E8075 for ; Wed, 18 Apr 2012 20:33:45 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3J3Xgfo029106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Apr 2012 05:33:42 +0200 (MEST) From: Martin Rex Message-Id: <201204190333.q3J3Xfgf022200@fs4113.wdf.sap.corp> To: swilson@lockstep.com.au Date: Thu, 19 Apr 2012 05:33:41 +0200 (MEST) In-Reply-To: <4F8F7D4C.7060503@lockstep.com.au> from "Stephen Wilson" at Apr 19, 12 12:49:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 03:33:50 -0000 Stephen Wilson wrote: > > Just quickly, would you care to clarify what it means to get rid of > passwords? Passwords will be vulnerable and subject to social engineering as long as users can not reliable recognize authorized password prompts. The only reliable solution is to restrict passwords exclusively to trustworthy (=personally owned) hardware. All other authentication should be restricted to replay&MITM-safe strong crypto protocols between the trustworthy (=personally owned) hardware. > > I won't apologise for nitpicking, because there's too much woolly > language in the identity space. We see maniacal media reports about > NSTIC doing away with passwords altogether. And what about the common > perception that biometrics will do away with passwords? Then along comes > this palm scanning ATM where that's not only false, but it even requires > an additional secret over and above the PIN? > http://news.discovery.com/tech/scan-hand-atm-cash-120414.html That is an exceptionally stupid idea. You can not change your biometrics, therefore you MUST NOT reveal any of your biometrics that might enable someone else to impersonate you to untrustworthy hardware. An ATM is unconditionally untrustworthy hardware (unless it is YOUR OWN ATM and locket up in a safe which only you yourself can open, but that is pointless -- simply using the safe directly would be much less cumbersome). -Martin From kyanha@kyanha.net Wed Apr 18 20:43:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442C111E807F for ; Wed, 18 Apr 2012 20:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.574 X-Spam-Level: X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcgcckXoGcxA for ; Wed, 18 Apr 2012 20:43:19 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 643AD11E8075 for ; Wed, 18 Apr 2012 20:43:19 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so7658083pbb.31 for ; Wed, 18 Apr 2012 20:43:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type:x-gm-message-state; bh=XjWQkPkJ68yRvu3vZdiHBn3uHj/vAm6NUt2v0lNkaKY=; b=KzcVIduel3lqbU/Tp9ndExKoDScMFzuhbV12nLNPRUZ0uB1LKxpY2tHIaGRzfZIuI4 zj1IdRNl9p2JCbt/Fn9dD0sJNkubhb0Wd2vQt4wJLMzYi9rFB/CgqiVRJgCtF5vPciye sK2dDqePda/NS5brr46EzfMgh3HwQ+B3k80zcFNCULahjutIfejj/aYJOxtt5ys3Gmsh uN+4dRkTRaR8EngY/RhDIW681cnvx9V7kPb5WWCv5L5u4FZXRSTaOGXTgLw7XBM1r+JH 7QlLGrLKukAKLO25/oEWb94htjtw8LwMsD9rah7WdAet45EqoEnYPmFtJjIpruEeXtBa vblw== Received: by 10.68.218.137 with SMTP id pg9mr1642430pbc.26.1334806998632; Wed, 18 Apr 2012 20:43:18 -0700 (PDT) Received: from penango ([64.9.243.41]) by mx.google.com with ESMTPS id kn6sm1003471pbc.17.2012.04.18.20.43.15 (version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 20:43:17 -0700 (PDT) From: "Kyle Hamilton" To: swilson@lockstep.com.au Date: Wed, 18 Apr 2012 20:43:20 -0700 (Pacific Daylight Time) Message-ID: In-Reply-To: <4F856D3A.1060103@telia.com> References: <4F856D3A.1060103@telia.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.6eqh179mhpwvss8sz6kd42 X-Gm-Message-State: ALoCoQkiq/B9GJhiMGVZbIcN0jcO7GBFI4pvlamd6TglZDQXVHDqNqS/VPGW1ARBgpek198L1pd+ Cc: "pkix@ietf.org" Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 03:43:24 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.6eqh179mhpwvss8sz6kd42 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 SGkgU3RldmUsDQoNCkkgd2hvbGVoZWFydGVkbHkgYWdyZWUgd2l0aCB5b3Ugb24gdGhlIHdvb2x5 IGZ1enp5IGxhbmd1YWdlLiAgU28sIEknbGwgdHJ5IHRvIGJlIGNvbmNpc2U6DQoNCkkgd2lzaCB0 byBlcmFkaWNhdGUgYWNjb3VudCBuYW1lcyBhbmQgcGFzc3dvcmRzLCB0aGUgMS1mYWN0b3IgYXV0 aGVudGljYXRpb24gdGhhdCBuZWFybHkgZXZlcnkgd2Vic2l0ZSBvbiB0aGUgSW50ZXJuZXQgc3Rp bGwgdXNlcy4gIFRoZXJlIGhhdmUgYmVlbiBtYW55IGF0dGVtcHRzIChpbmNsdWRpbmcgRmxhc2gt YmFzZWQgcGVyc2lzdGVudCBicm93c2VyIG9iamVjdHMpIHRvIGNyZWF0ZSBhIDJuZCBmYWN0b3Ig c28gdGhhdCBhdXRob3JpemVkIHN5c3RlbXMgZG9uJ3QgaGF2ZSB0byBnbyB0aHJvdWdoIHRoZSBt b3JlIGFubm95aW5nIGF1dGhlbnRpY2F0aW9uIHN5c3RlbSB3aGljaCBpcyBnZW5lcmFsbHkgdXNl ZCB0byBhdXRob3JpemUgdGhlIHN5c3RlbS4gIEkgYWdyZWUgd2l0aCBNYXJ0aW4gUmV4J3MgcmVw bHkgYXMgd2VsbCAtLSBwYXNzd29yZHMgYXJlIG9ubHkgYXBwcm9wcmlhdGUgZm9yIHVzZSBpbiB0 aGUgdXNlcidzIG93biByZWFsbSBvZiBhdXRoZW50aWNhdGlvbiB0byBoaXMgZGV2aWNlcy4NCg0K SSBhZ3JlZSB3aXRoIHRoZSBpZGVhIG9mIGF1dGhvcml6aW5nIGFuZCBhdXRoZW50aWNhdGluZyB0 aGUgc3lzdGVtLCBieSB0aGUgd2F5LCBmb3IgYSBwYXJ0aWN1bGFyIHJlYXNvbjogaWYgZXZlcnkg aW5kZXBlbmRlbnQga2V5c3RvcmUgaGFzIGl0cyBvd24ga2V5cGFpcnMgZm9yIGl0cyBvd24gbWFu YWdlbWVudCwgaXQncyBwb3NzaWJsZSB0byBlbnJvbGwgYWRkaXRpb25hbCBrZXlzIGluIGEgbWFu bmVyIHdoaWNoIGxldHMgYW55IHJlY29nbml6ZWQgY29tcHJvbWlzZSBjYXVzZSBhIGdsb2JhbCBy ZXZvY2F0aW9uIG9mIGV2ZXJ5IGtleSBjZXJ0aWZpZWQgYXMgYmVpbmcgd2l0aGluIHRoYXQga2V5 c3RvcmUuICBUaGlzIGlzIGEgcGFyYW1vdW50IGV4cG9zdXJlLWxpbWl0aW5nIG5lY2Vzc2l0eS4N Cg0KSSB3b3VsZCBwcmVmZXIgdGhhdCBQS0kgYmFzZWQgZGV2aWNlcyB1c2VkIHNvbWUgY29tYmlu YXRpb24gb2YgZmFjdG9ycyByYXRoZXIgdGhhbiBzb21lICJrbm93bGVkZ2UiLCBidXQgSSdsbCBi ZSBxdWl0ZSBoYXBweSB0byBsZXQgdXNlcnMgaGF2ZSB0aGUgY2FwYWNpdHkgdG8gZmlndXJlIG91 dCB3aGF0IGtpbmQgb2Yga2V5IHByb3RlY3Rpb24gdGhleSBuZWVkIGZvciB2YXJpb3VzIHRoaW5n cy4gICJrbm93bGVkZ2UiIGlzIHNvbWV0aGluZyB0aGF0J3MgZmFyIHRvbyBlYXN5IHRvIGNvbXBy b21pc2UsIGluIGJvdGggdGhlICJubywgcmVhbGx5LCBJIGRvbid0IHJlbWVtYmVyIiBhbmQgInNv bWVvbmUgZWxzZSBrbm93cyB0aGlzIHRvbyIgbWFubmVycy4NCg0KSSBkbyBub3QgY29uc2lkZXIg bXkgdmlzaW9uIHRvIHJlYWxseSBiZSBhbnkga2luZCBvZiBTU08gZW52aXJvbm1lbnQsIHRob3Vn aC4gIFdlIGtub3cgdGhhdCBuZWFybHkgZXZlcnkgdXNlciBoYXMgbXVsdGlwbGUgZGV2aWNlcy4g IFdoeSBhcmVuJ3Qgd2UgdXNpbmcgdGhpcyBrbm93bGVkZ2UgdG8gc2VjdXJlbHkgc2VuZCBhIHNp Z25hdHVyZSByZXF1ZXN0IG91dCB0byBhbiBhZ2VudCBvbiB0aGUgdXNlcidzIHBob25lLCBhbmQg dGhlbiByZWNlaXZlIGFuIGF1dGhvcml6aW5nIHNpZ25hdHVyZSBmcm9tIGEga2V5IGhlbGQgb24g dGhhdCBkZXZpY2UgYmVmb3JlIGFwcGx5aW5nIHRoZSBtYWluIG9uZT8gIChGb3IgYm9udXMgcG9p bnRzLCBjcmVhdGUgYSBzd2l0Y2ggb24gdGhlIHVzZXIgZGV2aWNlIHdoaWNoIHB1dHMgaXQgZWl0 aGVyIGludG8gInNlY3VyaXR5IGF1dGhvcml0eSIgbW9kZSBvciAiYXBwbGljYXRpb25zIiBtb2Rl LCBhbmQgY2F1c2UgYW4gaW5jb21pbmcgc2lnbmF0dXJlIHJlcXVlc3QgdG8gc2F5ICJoZXksIGhp dCB0aGlzIHN3aXRjaCwgc29tZXRoaW5nIHdhbnRzIHlvdXIgYXV0aG9yaXR5IiBvdmVyIHRoZSBh cHBsaWNhdGlvbnMuKQ0KDQpJbiB0aGUgZW5kIGFuYWx5c2lzLCBJIHdvdWxkIHByZWZlciB0byBs ZXQgZXZlcnkgaW5kaXZpZHVhbCBzZXJ2aWNlIGJlIG9wdGVkIGludG8gU1NPIHRyZWF0bWVudCBi eSB0aGUgdXNlciwgYWNjb3JkaW5nIHRvIHRoYXQgdXNlcidzIHdpbGxpbmduZXNzIHRvIGFjY2Vw dCBleHBvc3VyZSBhbmQgbGlhYmlsaXR5IGZvciBpdHMgcG90ZW50aWFsIG1pc3VzZS4gIChXZSBk byBhbHJlYWR5IGhhdmUgdGhpcyBraW5kIG9mIHNpdHVhdGlvbiB3aXRoIHBhc3N3b3JkIG1hbmFn ZXJzIGxpa2UgdGhlIG9uZSBidWlsdCBpbnRvIEZpcmVmb3gsIGFuZCB0aGVyZSBhcmUgcGx1c2Vz IGFuZCBtaW51c2VzIHRvIGl0LiAgTXkgbWFpbiBjb25jZXJuIGlzIHRoYXQgY3VycmVudGx5LCBl dmVyeSB1c2Ugb2YgYSBrZXkgaXMgYSBoaWdoLXNlY3VyaXR5IHJpdHVhbCB0aGF0J3MgcGFpbmZ1 bCBhbmQgYXdrd2FyZCwgbm8gbWF0dGVyIGhvdyBpbmFuZSB0aGUgYWN0dWFsIHV0aWxpdHkuICBJ IHRoaW5rIEknZCBiZSBxdWl0ZSBoYXBweSwgZm9yIGV4YW1wbGUsIHRvIGFsbG93IG15IGNvbXB1 dGVyIHRvIHN0YXkgbG9nZ2VkIGluIHRvIHNsYXNoZG90LCBpbiBzdWNoIGEgd2F5IHRoYXQgSSBk b24ndCBoYXZlIHRvIHdvcnJ5IGFib3V0IHRoZSBrZXkgYmVpbmcgaW4gYW4gdWx0cmEgdGlnaHQg c2VjdXJpdHkgYXV0aG9yaXphdGlvbiBlbnZpcm9ubWVudCBhbmQgaGF2aW5nIHRvIHdyYWNrIG15 IGJyYWluIG9yIHJlbHkgb24gbXVzY2xlIG1lbW9yeSB0byBrZXkgaW4gYSBwYXNzd29yZC4gIEkg Y2VydGFpbmx5IHdvdWxkIG5vdCBiZSBva2F5IHdpdGggbXkgYmFuayBjcmVkZW50aWFscyBiZWlu ZyBoYW5kbGVkIGluIHRoYXQgbWFubmVyLikNCg0KVGhlIHdlYiBhbmQgd29ybGQgYXJlIGFscmVh ZHkgaW5zZWN1cmUuICBXaHkgd291bGQgdGhlIGFkZGl0aW9uIG9mIGEgY3J5cHRvZ3JhcGhpYyBs YXllciBuZWNlc3NhcmlseSBtYWtlIHRoYXQgYW55IGxlc3MgdGhlIGNhc2U/DQoNCi1LeWxlIEgN Cg0KT24gV2VkLCBBcHIgMTgsIDIwMTIgYXQgNzo0OSBQTSwgU3RlcGhlbiBXaWxzb24gPHN3aWxz b25AbG9ja3N0ZXAuY29tLmF1PiB3cm90ZToNCj4NCj4gSnVzdCBxdWlja2x5LCB3b3VsZCB5b3Ug Y2FyZSB0byBjbGFyaWZ5IHdoYXQgaXQgbWVhbnMgdG8gZ2V0IHJpZCBvZg0KPiBwYXNzd29yZHM/ DQo+DQo+IERvIHlvdSByZWFsbHkgbWVhbiBzaW5nbGUgZmFjdG9yIGF1dGhlbnRpY2F0aW9uIChp LmUuIHBhc3N3b3JkcyBvbiB0aGUgb3duKT8NCj4NCj4gRG8geW91IGltYWdpbmUgUEtJIGJhc2Vk IGNhcmRzIC8gZGV2aWNlcyB3b3VsZCBzdGlsbCBiZSBwYXNzd29yZCBhY3RpdmF0ZWQ/DQo+DQo+ IERvIHlvdSByZWFsbHkgbWVhbiByZWR1Y2UgdGhlIG51bWJlciBvZiBwYXNzd29yZHM/DQo+DQo+ IERvIHlvdSBhZHZvY2F0ZSByYWRpY2FsIFNTTywgc28gdGhhdCBvbmNlIGxvZ2dlZCBpbiwgeW91 IHN0YXkgbG9nZ2VkIGluDQo+IGFjcm9zcyBhcmJpdHJhcmlseSBtYW55IHNlcnZpY2VzIHdpdGhv dXQgZXZlciByZWVudGVyaW5nIGEgcGFzc3dvcmQ/DQo+DQo+IEkgd29uJ3QgYXBvbG9naXNlIGZv ciBuaXRwaWNraW5nLCBiZWNhdXNlIHRoZXJlJ3MgdG9vIG11Y2ggd29vbGx5IGxhbmd1YWdlDQo+ IGluIHRoZSBpZGVudGl0eSBzcGFjZS4goFdlIHNlZSBtYW5pYWNhbCBtZWRpYSByZXBvcnRzIGFi b3V0IE5TVElDIGRvaW5nIGF3YXkNCj4gd2l0aCBwYXNzd29yZHMgYWx0b2dldGhlci4goEFuZCB3 aGF0IGFib3V0IHRoZSBjb21tb24gcGVyY2VwdGlvbiB0aGF0DQo+IGJpb21ldHJpY3Mgd2lsbCBk byBhd2F5IHdpdGggcGFzc3dvcmRzPyBUaGVuIGFsb25nIGNvbWVzIHRoaXMgcGFsbSBzY2Fubmlu Zw0KPiBBVE0gd2hlcmUgdGhhdCdzIG5vdCBvbmx5IGZhbHNlLCBidXQgaXQgZXZlbiByZXF1aXJl cyBhbiBhZGRpdGlvbmFsIHNlY3JldA0KPiBvdmVyIGFuZCBhYm92ZSB0aGUgUElOPw0KPiBodHRw Oi8vbmV3cy5kaXNjb3ZlcnkuY29tL3RlY2gvc2Nhbi1oYW5kLWF0bS1jYXNoLTEyMDQxNC5odG1s DQo+DQo+IFNvIGxldCdzIGJlIHN1cmUgd2Ugc2V0IHRoZSByaWdodCBleHBlY3RhdGlvbnMhDQo+ DQo+IENoZWVycywNCj4NCj4gU3RldmUgV2lsc29uDQo+IExvY2tzdGVwL2h0dHA6Ly9sb2Nrc3Rl cC5jb20uYXUNCj4NCj4NCj4NCj4NCj4gT24gMTkvMDQvMjAxMiA5OjUyIEFNLCBLeWxlIEhhbWls dG9uIHdyb3RlOg0KPj4NCj4+IEFuZGVycywNCj4+DQo+PiBJIGFtIGVudGlyZWx5IHdpdGggeW91 IG9uICJnZXR0aW5nIGF3YXkgZnJvbSBwYXNzd29yZHMiLiCgVGhvdWdoLCBpbnN0ZWFkDQo+PiBv ZiB3cmluZ2luZyBteSBoYW5kcyBhYm91dCBpdCBhbmQgdGhpbmtpbmcgdGhhdCBJIGNhbid0IGRv IGFueXRoaW5nIGZvciBpdCwNCj4+IEknbSBjcmVhdGluZyB0aGUgc3lzdGVtIHRoYXQgSSBwZXJj ZWl2ZSB0aGUgbmVlZCBmb3IuIKBJIGRlc3Bpc2UgcGFzc3dvcmRzLA0KPj4gYW5kIEkgYmVsaWV2 ZSB0aGF0IHRoZXkgc2hvdWxkIGhhdmUgYmVlbiBkb25lIGF3YXkgd2l0aCAxNSB5ZWFycyBhZ28s IHRoZQ0KPj4gbW9tZW50IHRoZSBXYXNzZW5uYXIgQXJyYW5nZW1lbnQgd2FzIGlua2VkIGluIDE5 OTguDQo+Pg0KPj4gVGhlcmUgZXhpc3QgYSBjb3VwbGUgb2YgYmFycmllcnMgd2hpY2ggcHJldmVu dCBwYXNzd29yZHMgZnJvbSBnb2luZw0KPj4gZXh0aW5jdC4goFRoZXJlIGFyZSB0d28gdGhhdCBJ IGhhdmUgbXkgZXllcyBvbi4goE9uZSBleGlzdHMgYXQgTW96aWxsYSwgdGhlDQo+PiBvdGhlciBh dCBBcGFjaGUgaHR0cGQuDQo+Pg0KPj4gT24gVHVlLCBBcHIgMTcsIDIwMTIgYXQgMTE6MzEgUE0s IEFuZGVycyBSdW5kZ3Jlbg0KPj4gPGFuZGVycy5ydW5kZ3JlbkB0ZWxpYS5jb20+IHdyb3RlOg0K Pj4+DQo+Pj4gSGkgS3lsZSwNCj4+PiBJJ20gbm90IGFibGUgdG8gcmVzcG9uZCB0byB5b3VyIGVs YWJvcmF0ZSBpbnB1dCBiZWNhdXNlIEknbSB3b3JraW5nIHdpdGgNCj4+PiBhIG11Y2gNCj4+PiBt b3JlIGJhc2ljIHF1ZXN0aW9uIHdoaWNoIGlzICJnZXR0aW5nIGF3YXkgZnJvbSBwYXNzd29yZHMi LiCgVG8gaGF2ZSBhDQo+Pj4gY2hhbmNlIG9mDQo+Pj4gc3VjY2VlZGluZyB5b3UgbmVlZCBWaXNp b24sIEFtYml0aW9uLCBNYXJrZXRpbmcsIENvbXBldGVuY2UsIGFuZCBGdW5kaW5nLg0KPj4+IKBN YXliZQ0KPj4+IHlvdSBldmVuIG5lZWQgYSBwb3J0aW9uIG9mIGx1Y2sgOi0pDQo+Pg0KPj4NCj4+ IE15IHZpc2lvbjogSSBiZWxpZXZlIHRoYXQgZXZlcnkgaW5kaXZpZHVhbCBpbiB0aGUgd29ybGQg aGFzIHRoZSBhYnNvbHV0ZQ0KPj4gcmlnaHQgdG8ga2VlcCBoaXMgb3duIHNlY3JldHMuIKBFdmVy eSBwZXJzb24gaW4gdGhlIHdvcmxkIGhhcyB0aGUgcmlnaHQgdG8NCj4+IGJlIHNhZmUgZnJvbSBp bXBlcnNvbmF0aW9uIGZyYXVkLiCgRXZlcnkgcGVyc29uIGluIHRoZSB3b3JsZCBoYXMgdGhlIHJp Z2h0DQo+PiB0byBmb3JtIGhpcyBvd24gYXNzb2NpYXRpb25zLCBhbmQgdG8gY3JlYXRlIHN5c3Rl bXMgdG8gaGVscCB0aG9zZQ0KPj4gYXNzb2NpYXRpb25zIHdvcmsgYXMgZXhwZWN0ZWQgYnkgdGhl IHBhcnRpY2lwYW50cy4goFdoYXQgaGFzIHByZXZlbnRlZCBpdCB0bw0KPj4gdGhpcyBwb2ludCBp cyB0aGUgbGFjayBvZiBhIHVzZWZ1bCwgY29tcHJlaGVuc2libGUgaW50ZXJmYWNlLiCgVGhlIENs ZXJrIG9mDQo+PiBDb3VydHMgZXhlbXBsaWZpZXMgZXZlcnl0aGluZyB0aGF0IHdlIGV4cGVjdCBm cm9tIG91ciBpbmZvcm1hdGlvbiBzeXN0ZW1zLA0KPj4gYW5kIHNob3VsZCBiZSB0aGUgcm9sZSBt b2RlbCB3ZSB0cnkgdG8gZW11bGF0ZS4NCj4+IEFtYml0aW9uOiBJJ20gZ29pbmcgdG8gbWFrZSBz dXJlIHRoYXQgZXZlcnlvbmUgaGFzIHRoZSBjYXBhY2l0eSB0byBrZWVwDQo+PiBoaXMgb3duIHNl Y3JldHMsIHdpdGggYW4gaW50ZXJmYWNlIG11Y2ggbGlrZSB0aGUgQ2xlcmsgb2YgQ291cnRzIHBy ZXNlbnRzIHRvDQo+PiB0aGUgSnVkZ2VzIG9mIHRoZSBDb3VydHMsIG1lYW5pbmcgbmVhcmx5IGlu dmlzaWJsZSBidXQgcHJvdmlkaW5nIGV4YWN0bHkNCj4+IHdoYXQgaW5mb3JtYXRpb24vcGFwZXJ3 b3JrIGlzIG5lZWRlZCBhdCBhbnkgZ2l2ZW4gbW9tZW50Lg0KPj4gQ29tcGV0ZW5jZTogSSBqdWdn bGUgY3J5cHRvZ3JhcGhpYyBidWlsZGluZyBibG9ja3MgdW50aWwgZXZlcnkgbmVlZCBpcw0KPj4g bWV0LiCgQXQgdGhpcyBwb2ludCwgSSdtIGxvb2tpbmcgZm9yIHBlb3BsZSB0byBldmFsdWF0ZSB0 aGUgZGVzaWduIEkgY3JlYXRlZA0KPj4gdG8gbWFrZSBwYXNzd29yZHMgdGhlIHdhdmUgb2YgdGhl IHBhc3QuIKBZb3Ugc2VlbSB0byBiZSBpbnRlcmVzdGVkIGVub3VnaCBpbg0KPj4gdGhlIHRvcGlj IGFuZCBjb21wZXRlbnQgZW5vdWdoIGluIHRoZSBmaWVsZCB0byBiZSBhYmxlIHRvIGdpdmUgZmVl ZGJhY2suDQo+PiBNYXJrZXRpbmcvRnVuZGluZzogSSdsbCBoYW5kIGl0IHRvIE1vemlsbGEgYW5k L29yIEFwYWNoZS4NCj4+IEx1Y2s6IHRoYXQgbm9ib2R5IGVsc2UgaGFzIHlldCBkb25lIGl0IHJp Z2h0LiA6LSkNCj4+DQo+PiBJJ20gd29ya2luZyB0byBpbXByb3ZlIE1vemlsbGEncyBwbGF0Zm9y bSBzbyB0aGF0IHNpdGVzIGNhbiBjcmVhdGUgYW5kDQo+PiBlbnJvbGwgdGhlaXIgb3duIGNyZWRl bnRpYWxzIHdpdGhvdXQgdGhyb3dpbmcgYXdheSB0aGUgYmVuZWZpdHMgb2YgaXRzIHJvb3QNCj4+ IHByb2dyYW0uIKAoVGhlIGJ1ZzogbG9jYWxseS10cnVzdGVkIGNlcnRpZmljYXRlcyBwcmVzZW50 IHRoZSBzYW1lIFVJIGFzIHJvb3QNCj4+IHByb2dyYW0gY2VydGlmaWNhdGVzLikNCj4+DQo+PiBJ J20gYWxzbyB3b3JraW5nIHRvIHJlbW92ZSBBcGFjaGUgbW9kX3NzbCB0ZWNobmljYWwgZG9jdW1l bnRhdGlvbiBhYm91dA0KPj4gU1NMVmVyaWZ5Q2xpZW50LCB3aGljaCBkaXNtaXNzZXMgdGhlIGNh cGFjaXR5IHRvIHByZXNlbnQgYSBjdXN0b20gY3JlZGVudGlhbA0KPj4gZXJyb3IgcmVjb3Zlcnkg ZmxvdyBhcyBub3QgImludGVyZXN0aW5nIiAoaS5lLiwgb3B0aW9uYWxfbm9fY2EpLg0KPj4NCj4+ IFRoZSBzeXN0ZW0gSSB0aGluayB3ZSBuZWVkOiBhIHdvcmtmbG93IGltcGxlbWVudGF0aW9uIHN5 c3RlbSBmb3IgdGhlDQo+PiBlbmQtdXNlciB3aXRoIHByZWRlc2lnbmVkIHdvcmtmbG93cyBmb3Ig YWxtb3N0IGV2ZXJ5dGhpbmcgdGhhdCBvbmUgd291bGQNCj4+IHdhbnQgdG8gZG8gd2l0aCBjcnlw dG9ncmFwaHkgYW5kIGluZm9ybWF0aW9uIHN0b3JhZ2UsIHByb3ZpZGluZyBhIGtpbmQgb2YNCj4+ IHNlY3VyZSBidW5kbGluZyBvZiBhc3NvY2lhdGVkIGluZm9ybWF0aW9uIGFuZCBwcmVzZW50aW5n IHRoZSBraW5kIG9mICJ0aGlzDQo+PiBpcyB3aGF0IHlvdSBuZWVkIGF0IHRoaXMgbW9tZW50IiBz ZXJ2aWNlIHRoYXQgdGhlIENsZXJrIHByb3ZpZGVzIHRvIHRoZQ0KPj4gSnVkZ2UuDQo+Pg0KPj4+ IE9uZSBvZiB0aGUgcHJvYmxlbXMgaXMgdGhhdCBpZiB5b3UgaW50ZW5kIHRvIGNyZWF0ZSBzb21l dGhpbmcgb2YgdGhpcw0KPj4+IGtpbmQgeW91DQo+Pj4gW3ByZXN1bWFibHldIG5lZWQgYSByZXF1 aXJlbWVudCBsaXN0LiCgVGhlIG5ha2VkIHRydXRoIGlzIHRoYXQgZ2V0dGluZw0KPj4+IHN1Y2gg YQ0KPj4+IHRoaW5nIGlzIGVzc2VudGlhbGx5IGltcG9zc2libGUgYmVjYXVzZSB0aGUgZXhpc3Rp bmcgdXNlcnMgb2YgY29uc3VtZXINCj4+PiBQS0kgZG9uJ3QNCj4+PiBrbm93IHdoaWNoIG9uZSBv ZiB0aGUgZ2F6aWxsaW9uIHNlY3VyaXR5IHN0YW5kYXJkcyBlZmZvcnRzIGFyZSBmb3INCj4+PiAi cmVhbCIsIGFuZA0KPj4+IHRoZXJlZm9yZSBkbyBub3QgW2FjdGl2ZWx5XSBzdXBwb3J0IGFueSBv ZiB0aGVtLg0KPj4NCj4+DQo+PiBXaGljaCBpcyB3aHkgSSd2ZSBjcmVhdGVkIG15IG93biBSZXF1 aXJlbWVudHMuIKBJJ20gc3VyZSB0aGUgcmVzdCBvZiB0aGUNCj4+IHdvcmxkIHdpbGwgY2F0Y2gg dXAgZXZlbnR1YWxseToNCj4+IDEpIEFzc2VydCBtdWx0aXBsZSBjcmVkZW50aWFsIGNoYWlucyBm cm9tIG11bHRpcGxlIGNyZWRlbnRpYWwgc291cmNlcw0KPj4gYXRvbWljYWxseSwgaW4gdmVyaWZp YWJsZSBmb3JtLg0KPj4gMikgQXNzZXJ0IG5vbi12ZXJpZmlhYmxlIGRhdGEgaW4gdGhlIHNhbWUg YXRvbS4NCj4+IDMpIFByb3ZpZGUgYW4gb3B0aW9uYWwgbWVhbnMgdG8gZW5jcnlwdCB0aGF0IGNy ZWRlbnRpYWwgY2hhaW4gYXRvbSB0byB0aGUNCj4+IGludGVuZGVkIHJlY2lwaWVudC4NCj4+IDQp IFByb3ZpZGUgYSBtZWFucyB0byBlbnN1cmUgdGhhdCBldmVuIGlmIHRoZSBkaWdlc3RzIHVzZWQg Zm9yIHRoZQ0KPj4gc2lnbmF0dXJlcyBhcmUgY29tcHJvbWlzZWQsIHRoZSBkYXRhIGNhbiBzdGls bCBiZSBrbm93biBnb29kLg0KPj4gNSkgUHJvdmlkZSBzdGFwbGVkIE9DU1AgcmVzcG9uc2VzIG9y IHRoZSBjdXJyZW50IENSTCBmb3IgZXZlcnkgY2VydGlmaWNhdGUNCj4+IGluIGV2ZXJ5IGNyZWRl bnRpYWwgY2hhaW4uDQo+PiA2KSBQcm92aWRlIGEgdGltZXN0YW1wLCBzbyB0aGF0IHRoZSB0aW1l IG9mIHNpZ25hdHVyZSBjYW4gYmUgc2hvd24gdG8NCj4+IGV4aXN0IHdpdGhpbiB0aGUgdmFsaWRp dHkgcGVyaW9kcyBvZiB0aGUgY2VydGlmaWNhdGUgY2hhaW5zJyBPQ1NQLg0KPj4gNykgSW5jbHVk ZSBldmVyeSBkZXZpY2UgdGhlIHVzZXIgaGFzIHRoYXQgY2FuIHVuZGVyc3RhbmQgdGhlIHByb3Rv Y29sLA0KPj4gaW5jbHVkaW5nIFBDcywgbm90ZWJvb2tzLCB0YWJsZXRzLCBwaG9uZXMsIGFuZCBj cmVkZW50aWFsIHN0b3Jlcy4NCj4+IDgpIFJldXNlIGFzIG11Y2ggY3J5cHRvLCBzdGFuZGFyZCBh bmQgY29kZSBhcyBwb3NzaWJsZSwgc3ViamVjdCB0byB0aGUNCj4+IGNvbnN0cmFpbnRzIDEtOC4g oElmIHBvc3NpYmxlLCB1c2UgYXJlYXMgb2YgdGhlIHN0YW5kYXJkcyB0aGF0IGhhdmUgYmVlbg0K Pj4gZGlzY2xhaW1lZCBieSB0aGUgc3RhbmRhcmRzIGJvZGllcyB0aGVtc2VsdmVzIChzdWNoIGFz IHNlbGYtc2lnbmVkIFguNTA5DQo+PiBzdHJ1Y3R1cmVzIGFzIHNvbWV0aGluZyBvdGhlciB0aGFu IGEgdHJ1c3QgYW5jaG9yIGNvbnRhaW5lcikuDQo+PiA5KSBQcmVzZW50IGF1dGhvcml6YXRpb24g VUkgb24gb25lIG9yIG1vcmUgZGV2aWNlcyBvdGhlciB0aGFuIHRoZQ0KPj4gY3JlZGVudGlhbCBz dG9yZSBhbmQgdGhlIGRldmljZSB3aGljaCBzdWJtaXR0ZWQgdGhlIHNpZ25hdHVyZSByZXF1ZXN0 LCB0bw0KPj4gcmVkdWNlIHRoZSBvcHBvcnR1bml0eSBmb3IgbWFsd2FyZSBvbiB0aGUgbWFpbiBp bnRlcmZhY2UgdG8gYXBwbHkgYW4NCj4+IHVuYXV0aG9yaXplZCBzaWduYXR1cmUuDQo+PiAxMCkg U2F2ZSAtZXZlcnl0aGluZy0gdGhhdCBoYXMgZXZlciBiZWVuIHNpZ25lZC4NCj4+DQo+PiBNaWdo dCB5b3UgYmUgaW50ZXJlc3RlZCBpbiBhIGRhdGEgZm9ybWF0IHdoaWNoIGVuYWJsZXMgdGhlc2Ug dG8gYmUgbWV0LA0KPj4gd2l0aG91dCBjaGFuZ2VzIHRvIHRoZSBleGlzdGluZyBDQSBpbmZyYXN0 cnVjdHVyZSwgd2l0aG91dCBhbnkgY2hhbmdlcyB0bw0KPj4gYW55IHRlY2huaWNhbCBzdGFuZGFy ZHMgaW5jbHVkaW5nIFRMUyBhbmQgUy9NSU1FLCBhbmQgd2l0aG91dCB3b3JyeWluZyBhYm91dA0K Pj4gdGhlIGxhY2sgb2YgbW90aW9uIGluIHN0YW5kYXJkcyBib2RpZXM/IKBTdGFuZGFyZHMgY29t ZSBhYm91dCBiZWNhdXNlDQo+PiBzb21ldGhpbmcgd29ya3MsIG5vdCBiZWNhdXNlIHBlb3BsZSB0 aGluayB0aGF0IGl0IHdpbGwgd29yayBpZiB0aGV5J3JlIGJ1aWx0DQo+PiB0by4goFRoaXMgaXMg dGhlIGZhaWx1cmUgb2YgUEtJWC1XRy4NCj4+DQo+Pj4gRHVlIHRvIHRoaXMsIHRoZSBmYXRlIG9m IGNvbnN1bWVyIFBLSSBmaXJtbHkgcmVzaWRlcyBpbiB0aGUgaGFuZHMgb2YgYmlnDQo+Pj4gdmVu ZG9ycw0KPj4NCj4+DQo+PiBUaGlzIGlzIHBlcmhhcHMgaW5jb3JyZWN0LiCgVGhlIGZhdGUgb2Yg Y29uc3VtZXIgUEtJIGluIFVTIGFwcGVhcnMgdG8NCj4+IHJlc2lkZSBpbiBteSBoYW5kcywgYXMg SSBzZWVtIHRvIGJlIHRoZSBvbmx5IHBlcnNvbiBpbiBVUyB3aG8gdGhpbmtzIHRoYXQNCj4+IHRo ZXJlIGRvZXMgZXhpc3QgYSBidXNpbmVzcyBjYXNlIGZvciBpdC4NCj4+DQo+PiBJZiB5b3Ugd2Fu dCBzb21ldGhpbmcgY3J5cHRvZ3JhcGhpYyBkb25lLCB5b3UgcHJldHR5IG11Y2ggaGF2ZSB0byBy b2xsDQo+PiB5b3VyIG93biBiZWNhdXNlIHRoZSBjdXJyZW50IHN0YW5kYXJkcyBhcmUgc28gZGlz dHJlc3NpbmdseSBpZ25vcmFudCBvZg0KPj4gcmVhbGl0eS4gOigNCj4+DQo+Pj4gd2hpY2ggYXJl IGV4Y2x1c2l2ZWx5IHRhcmdldGluZyBtb2JpbGUgZGV2aWNlcyB3aXRoIGVtYmVkZGVkIHNlY3Vy aXR5DQo+Pj4gaGFyZHdhcmUuDQo+Pj4gVGhlIHNtYXJ0IGNhcmQgY29uY2VwdCBuZXZlciB3b3Jr ZWQgd2VsbCBhcyBjb25zdW1lciBzb2x1dGlvbiBpbiBkZXNrdG9wDQo+Pj4gUENzLg0KPj4NCj4+ DQo+PiBBZ3JlZWQuIKBJIGhhdmUgYSBsYXB0b3Agd2l0aCBhIHNtYXJ0IGNhcmQgcmVhZGVyLiCg SXQgaXMgbXVjaCBtb3JlIGhhc3NsZQ0KPj4gdGhhbiBpdCdzIHdvcnRoLg0KPj4NCj4+PiBJTU8s IHRoZXJlIGlzIGFjdHVhbGx5IGEgd2F5IGFoZWFkIGFuZCB0aGF0IGlzICJwdXR0aW5nIHRoZSBj YXJ0IGJlZm9yZQ0KPj4+IHRoZSBob3JzZSINCj4+PiB3aGljaCBtZWFucyB0aGF0IGluc3RlYWQg b2YgZm9sbG93aW5nIHRoZSB3aGltcyBvZiB0aGUgc2V2ZXJlbHkgZGl2aWRlZA0KPj4+IHNtYXJ0 IGNhcmQNCj4+PiBjb21tdW5pdHksIHlvdSBkZWZpbmUgYSBzdGFuZGFyZCBjYXJkIGFuZCBwcm92 aWRlIGEgKmZpeGVkKiBkcml2ZXIuDQo+Pj4goEltcGxlbWVudGluZw0KPj4+IGEgbWludXRlIHNl dCBvZiBjcnlwdG9ncmFwaGljIG9wZXJhdGlvbnMgaXMgYWN0dWFsbHkgbm90IHJvY2tldCBzY2ll bmNlDQo+Pj4gd2hpbGUNCj4+PiBkZXZlbG9waW5nIGFuZCBkaXN0cmlidXRpbmcgbWlkZGxld2Fy ZSBmb3IgYSBodWdlIG51bWJlciBvZiBldmVyLWNoYW5naW5nDQo+Pj4gcGxhdGZvcm1zDQo+Pj4g dGFrZXMgZm9yZXZlciBhbmQgc3RpbGwgeW91IG5ldmVyIGtub3cgZm9yIHN1cmUgaWYgaXQgaXMg YWN0dWFsbHkNCj4+PiB3b3JraW5nIQ0KPj4+IEJ5IG1ha2luZyB0aGUgZHJpdmVyIGEgKnBsYXRm b3JtIHZlbmRvciBpc3N1ZSBvbmx5KiwgdGhpbmdzIGdldCBtdWNoDQo+Pj4gZWFzaWVyLg0KPj4N Cj4+DQo+PiBJIGRvbid0IGFjdHVhbGx5IHRoaW5rIHRoaXMgaXMgdGhlIHdheSBhaGVhZC4goFRo ZSB3YXkgYWhlYWQgaXMgdG8gbWFrZSBpdA0KPj4gd29yaywgYW5kIHRoZW4gbGV0IG90aGVyIHBl b3BsZSBpbnRvIHRoZSBnYW1lLg0KPj4NCj4+IFRoZSBwcm9ibGVtIGlzIHBhcnRpYWxseSBQS0NT IzExLCBidXQgbXVjaCBtb3JlIGdsb2JhbGx5IElTTy9JRUMgNzgxNi0qLg0KPj4NCj4+IEZvciBh dWRpdGFiaWxpdHkgSSB3YW50IHRvIGVuc3VyZSB0aGF0IEkgaGF2ZSBhYnNvbHV0ZSBjb250cm9s IG92ZXIgdGhlDQo+PiBjb250YWluZXIgYW5kIGl0cyBhdWRpdGluZyBhdCBhbGwgdGltZXMsIGFu ZCB0aGF0IGlzIGltcG9zc2libGUgd2l0aCBhIHNtYXJ0DQo+PiBjYXJkIChvciBhbnkgUEtDUzEx IG1vZHVsZSkgdGhhdCBkb2Vzbid0IGhhdmUgYSBjdXN0b20gZW5jbG9zdXJlLg0KPj4NCj4+PiBQ SVYgd2FzIGEgc3RlcCBpbiB0aGlzIGRpcmVjdGlvbiBidXQgTklTVCBkaWRuJ3Qgc3RhbmRhcmRp emUgdGhlDQo+Pj4gbWFuYWdlbWVudA0KPj4+IGZ1bmN0aW9ucyBzaW5jZSB0aGUgY2FyZCBpbmR1 c3RyeSB3YW50ZWQgdG8ga2VlcCBzb21ldGhpbmcgdG8gYmUgdW5pcXVlDQo+Pj4gd2l0aC4NCj4+ DQo+Pg0KPj4gTklTVCBpcyBwYXJ0IG9mIHRoZSBwcm9ibGVtLCBwdWJsaXNoaW5nIG9ubHkgaGFs Zi1iYWtlZCBzZW1pc3RhbmRhcmRzLg0KPj4goEJ1dCwgSSBkb24ndCB0aGluayB0aGUgYWN0dWFs IHByb2JsZW0gcHJldmVudGluZyBjb25zdW1lciBQS0kgZnJvbSB0YWtpbmcNCj4+IHJvb3QgaXMg TklTVC4goFRoZSBmYWN0IHRoYXQgc21hcnQgY2FyZHMgZXhpc3QgKGFuZCB0aGUgdmVuZG9ycyBh cmUgYWxsb3dlZA0KPj4gdG8gY29udGludWUgcHVzaGluZyBhbmQgZW5mb3JjaW5nIHRoZWlyIHBy b3ByaWV0YXJ5IGV4dGVuc2lvbnMpIGlzIGl0c2VsZg0KPj4gVGhlIFByb2JsZW0uIKBTbWFydCBj YXJkcyBhcmUgdGhlIHdyb25nIHRlY2hub2xvZ3ksIG1vc3RseSBiZWNhdXNlIG9mIHRoZQ0KPj4g cHJvcHJpZXRhcnkgdmVuZG9yIGxvY2staW4gdGhhdCB0aGVzZSBzZW1pLXN0YW5kYXJkcyBoYXZl IGNyZWF0ZWQuDQo+Pg0KPj4gU28sIEknbSBtb3JlIHRoYW4gaGFwcHkgdG8gbm90IG9ubHkgImln bm9yZSB0aGUgc21hcnQgY2FyZCBpbmR1c3RyeSdzDQo+PiBkZXNpcmVzIiwgYnV0ICJpZ25vcmUg dGhlIHNtYXJ0IGNhcmQgaW5kdXN0cnkncyBleGlzdGVuY2UiLg0KPj4NCj4+IFRoZSBSYXNwYmVy cnkgUGkgKGh0dHA6Ly93d3cucmFzcGJlcnJ5cGkub3JnLykgaXMgYW4gb3BlbiBkZXZpY2Ugd2l0 aCBhbg0KPj4gODAwTUh6IHByb2Nlc3NvciBhbmQgYSAkMjUgcHJpY2UgdGFnLiCgVGhpcyBpcyB0 aGUgY3JlZGVudGlhbCBzdG9yYWdlIGRldmljZQ0KPj4gb2YgdGhlIGZ1dHVyZSwgbG93LWxldmVs IGVub3VnaCB0aGF0IEkgY2FuIHRha2UgY29tcGxldGUgY29udHJvbCBhcyBJIG5lZWQNCj4+IHRv LCBmYXN0IGVub3VnaCB0aGF0IGl0IGNhbiBwZXJmb3JtIGFjY2VwdGFibHkuIKBXaXRoIElQdjYs IGV2ZXJ5b25lIG9uDQo+PiBlYXJ0aCBjb3VsZCBoYXZlIHRlbiBvZiB0aGVtIGFuZCB0aGVyZSB3 b3VsZCBzdGlsbCBiZSBtb3JlIHRoYW4gMy40MEUrMzgNCj4+ICgzNDArIHNob3J0LXNjYWxlIHVu ZGVjaWxsaW9uKSBhZGRyZXNzZXMgbGVmdCwgc3ViamVjdCB0byB0aGUgbG9zc2FnZSBvZg0KPj4g bmV0d29yayB2ZXJzdXMgaW50ZXJmYWNlIGFkZHJlc3NpbmcuDQo+Pg0KPj4gTWl4aW5nIHRoaXMg d2l0aCBhIHNtYXJ0cGhvbmUgbWVhbnMgdGhhdCB5b3Ugc3VkZGVubHkgaGF2ZSBhIHJlbW90ZQ0K Pj4ga2V5c3RvcmUgdGhhdCB5b3UgY2FuIHNlbmQgdW5zaWduZWQgcmVxdWVzdHMgYW5kIHNpZ25l ZCBhdXRob3JpdGllcyB0bywgdmlhDQo+PiBhIFVJIGRldmljZSB5b3UndmUgYWxyZWFkeSBnb3Qg aW4geW91ciBwb2NrZXQuDQo+Pg0KPj4gSSBzZWVtIHRvIGJlIHRoZSBvbmx5IHNlY3VyaXR5LW1p bmRlZCBwZXJzb24gaW4gVVMgd2hvIHRoaW5rcyB0aGF0IElQdjYNCj4+IHV0aWxpdHkgaXMgbm90 IG9ubHkgYXdlc29tZXNhdWNlIGJ1dCB0aGUgb25seSB3YXkgZm9yd2FyZCwgYmVjYXVzZSB3ZQ0K Pj4gY3VycmVudGx5IGNhbm5vdCB1c2Ugb3VyIGNyeXB0b2dyYXBoaWMga2V5cyBhcyBvdXIgSVAg YWRkcmVzc2VzLiCgQnV0LCB3ZQ0KPj4gY2FuIGVuYWJsZSB0aGF0IGlmIHdlIHVzZSB0aGVtIGFz IHBvcnRpb25zIG9mIG11bHRpY2FzdCBhZGRyZXNzZXMuDQo+PiCgKHBoeXNpY2FsIGxvY2F0aW9u IGlzIHBlcnNvbmFsIGluZm9ybWF0aW9uIGFuZCBtdXN0IGJlIHByb3RlY3RlZC4pDQo+Pg0KPj4g SSBhbHNvIGFwcGVhciB0byBiZSB0aGUgb25seSBwZXJzb24gaW4gVVMgd2hvIHRoaW5rcyB0aGF0 IGV2ZXJ5IGFzeW1tZXRyaWMNCj4+IGtleSAod2l0aCBmZXcgZW5vdWdoIGV4Y2VwdGlvbnMgdGhh dCB0aGlzIGlzIGEgZ29vZCBnZW5lcmFsIHJ1bGUpIGlzDQo+PiBub25leHBvcnRhYmx5IGJvdW5k IHRvIGhhcmR3YXJlLCBhbmQgaGFyZHdhcmUgZGllcywgc28gd2Ugc2hhbGwgbG9zZSBldmVyeQ0K Pj4gcHJpdmF0ZSBrZXkgd2UgY2FyZSBhYm91dC4goFdlIG11c3QgcGxhbiBmb3IgdGhhdCBldmVu dHVhbGl0eSB3aGlsZSBzdGlsbA0KPj4gcHJvdmlkaW5nIGFkZXF1YXRlIHNlY3VyaXR5IGZvciBv dXIgY2xpZW50cy4NCj4+IEkndmUgZ290IGEgZGVzaWduIGZvciB0aGlzIHRoYXQgd29ya3Mgb24g cGFwZXIsIGFuZCBJJ20gd29ya2luZyB0byBtYWtlIGl0DQo+PiByZWFsaXR5Lg0KPj4NCj4+IENo ZWVycyENCj4+DQo+PiAtS3lsZSBIDQo+Pg0KPj4NCj4+Pg0KPj4+IEFuZGVycw0KPj4+DQo+Pj4g T24gMjAxMi0wNC0xNyAyMzo0MywgS3lsZSBIYW1pbHRvbiB3cm90ZToNCj4+Pj4NCj4+Pj4NCj4+ Pj4gT24gVGh1LCBBcHIgMTIsIDIwMTIgYXQgOToyMyBQTSwgQW5kZXJzIFJ1bmRncmVuDQo+Pj4+ IDxhbmRlcnMucnVuZGdyZW5AdGVsaWEuY29tPiB3cm90ZToNCj4+Pj4+DQo+Pj4+PiBNeSBwZXJz cGVjdGl2ZSBvbiB0aGlzIGlzIHNsaWdodGx5IGRpZmZlcmVudC4goElNTyB0aGlzIGlzc3VlIChh cyB3ZWxsDQo+Pj4+PiBhcyBQS0kuLi4pDQo+Pj4+PiBpcyBlc3NlbnRpYWxseSAib3duZWQiIGJ5 IHRocmVlIG1ham9yIGxhZ2dhcmRzOiBHb3Zlcm5tZW50cywgQmFua3MsIGFuZA0KPj4+Pj4gTWlj cm9zb2Z0Lg0KPj4+Pg0KPj4+Pg0KPj4+PiBUaGlzIGlzc3VlIGlzICJvd25lZCIgYnkgSVNPLCB3 aGljaCBtZWFucyB0aGF0IGl0J3Mgb24gdGhlIGdvdmVybm1lbnRzDQo+Pj4+IHdobyBhcmUgcGFy dGljaXBhdGluZyBpbiBJU08uDQo+Pj4+DQo+Pj4+IFRoZSBtb3N0IGltcG9ydGFudCBhc3BlY3Qg b2YgYW55IGFjY2Vzcy1jb250cm9sIHN5c3RlbSAoZXNwZWNpYWxseQ0KPj4+PiBmaW5hbmNpYWwp IGlzIGF1ZGl0YWJpbGl0eSwgYW5kIHRoZSBJU08gc3RhbmRhcmRzIGRvbid0IGNhdXNlIGVub3Vn aCBkYXRhIHRvDQo+Pj4+IGJlIHRyYW5zbWl0dGVkIHRvIHRoZSBjcnlwdG9ncmFwaGljIGNvbnRh aW5lciBmb3IgdGhlIGNvbnRhaW5lciB0byB3cml0ZSBpdHMNCj4+Pj4gb3duIGF1ZGl0IGxvZ3Mu IKBQS0NTIzExIGV4cG9zZXMgSVNPIGZ1bmN0aW9uYWxpdHksIHNvIGl0IGRvZXNuJ3QgaGF2ZSBh DQo+Pj4+ICJJJ20gc2VuZGluZyB5b3Ugc29tZXRoaW5nIHRoYXQgSSB3YW50IHlvdSB0byBkaWdl c3QgZm9yIG1lIiBjYWxsLiCgVGh1cywgd2UNCj4+Pj4gaGF2ZSBubyBpZGVhIHRoYXQgdGhlIGRp Z2VzdHMgc3VibWl0dGVkIGFyZSBiZWluZyBjYWxjdWxhdGVkIGNvcnJlY3RseSwgYW5kDQo+Pj4+ IG5vIGlkZWEgd2hhdCB0aGUgZGlnZXN0cyB3ZSdyZSBzaWduaW5nIGFjdHVhbGx5IG1lYW4uDQo+ Pj4+DQo+Pj4+IEluc3RlYWQsIHdlIGhhdmUgdG8gaW1wbGVtZW50IHRoZSBhdWRpdGluZyBzZXJ2 aWNlIGV4dGVybmFsbHksIHdoaWNoDQo+Pj4+IG1lYW5zIHRoYXQgd2UgbXVzdCBiZSBhYmxlIHRv IHRydXN0IHRoYXQgd2UgYXJlIHRoZSBzb2xlIGNvbnRyb2xsZXJzIG9mIHRoZQ0KPj4+PiBjcnlw dG9ncmFwaGljIGNvbnRhaW5lcnMgaW52b2x2ZWQuDQo+Pj4+DQo+Pj4+PiBTaW5jZSB0aGUgZmly c3QgdHdvIGFyZSBudW1lcm91cyBhcyB3ZWxsIGFzIGdlb2dyYXBoaWNhbGx5IGFuZA0KPj4+Pj4g Y3VsdHVyYWxseQ0KPj4+Pj4gZGl2ZXJzZSBpdCB3b3VsZCBiZSB3cm9uZyBnaXZpbmcgdGhlbSB0 aGUgYmxhbWUuIKBIb3dldmVyLCBzaW5jZSB0aGV5DQo+Pj4+PiB0bw0KPj4+Pj4gc29tZSA5MCUg aGF2ZSByZWxpZWQgb24gYSBzaW5nbGUgY2xpZW50LU9TIHZlbmRvciwgdGhlIGdlbmVyYWxseQ0K Pj4+Pj4gcGl0aWZ1bA0KPj4+Pj4gc3RhdGUgb2YgY2xpZW50LXNpZGUgUEtJIGluIGNvbnN1bWVy IFBDcyBpcyB1bmlsYXRlcmFsbHkgZHVlIHRvDQo+Pj4+PiBNaWNyb3NvZnQncw0KPj4+Pj4gbGlt aXRlZCBvZiB1bmRlcnN0YW5kaW5nIG9mIHRoaXMgbWFya2V0LiCgT3ZlciB0aGUgeWVhcnMgSSBo YXZlIG1ldA0KPj4+Pj4gcXVpdGUNCj4+Pj4+IGEgYnVuY2ggb2YgTWljcm9zb2Z0IFByb2dyYW0g TWFuYWdlcnMgYW5kIHRoZXkgYWxsIHNheSB0aGUgc2FtZSB0aGluZzoNCj4+Pj4+ICJUaGVyZSBp cyBubyBidXNpbmVzcyBjYXNlIGZvciBjb25zdW1lciBQS0kiLiCgSW4gc29tZSB3YXkgdGhpcyBp cyBhbHNvDQo+Pj4+PiB0cnVlIHNpbmNlIHRoZXJlIGlzIG5vIHBheWluZyBjdXN0b21lciBvdXQg dGhlcmUuDQo+Pj4+DQo+Pj4+DQo+Pj4+IEFoLCBNaWNyb3NvZnQgc3ByZWFkaW5nIGxpZXMgYWdh aW4uDQo+Pj4+DQo+Pj4+IFRoZXJlIGlzIG5vIGJ1c2luZXNzIGNhc2UgZm9yIGRpc2NhcmRpbmcg QXBhY2hlIGh0dHBkJ3MgU1NMVmVyaWZ5Q2xpZW50DQo+Pj4+IG9wdGlvbmFsX25vX2NhLCBidXQg aXQncyBkaXNjYXJkZWQgYnkgdGhlIHRlY2huaWNhbCBwZW9wbGUgYmVjYXVzZSBpdHMNCj4+Pj4g ZG9jdW1lbnRhdGlvbiBzYXlzIHRoYXQgIm9wdGlvbmFsX25vX2NhIGlzIGFjdHVhbGx5IGFnYWlu c3QgdGhlIGlkZWEgb2YNCj4+Pj4gYXV0aGVudGljYXRpb24iLiCgSW5zdGVhZCwgd2UgZW5kIHVw IHdpdGggYXBwbGljYXRpb25zIHdoaWNoIGhhbmRsZSB0aGVpcg0KPj4+PiBvd24gdXNlcm5hbWUg YW5kIHBhc3N3b3JkIGVycm9yIGZsb3dzIGJlY2F1c2Ugb3B0aW9uYWxfbm9fY2EgaXMgaW4gZmFj dCB0aGUNCj4+Pj4gb25seSB3YXkgdG8gcHJlc2VudCBhIGN1c3RvbSBlcnJvciBwYWdlIHdoZW4g cGVvcGxlIGluYWR2ZXJ0ZW50bHkgdHJ5IHRvIGxvZw0KPj4+PiBpbiB3aXRoIHRoZSB3cm9uZyBj ZXJ0aWZpY2F0ZSBvciBiZWZvcmUgdGhleSd2ZSBldmVyIGJlZW4gaXNzdWVkIGENCj4+Pj4gY2Vy dGlmaWNhdGUgZm9yIHRoZSBzZXJ2aWNlIGluIHF1ZXN0aW9uLg0KPj4+Pg0KPj4+PiBUaGVyZSBp cyBubyBidXNpbmVzcyBjYXNlIGZvciBjb25zdW1lciBYLjUwOS1hcy10aWVkLXRvLVguNTAwLiCg VGhlcmUgaXMNCj4+Pj4gYSBidXNpbmVzcyBjYXNlIGZvciBlbnJvbGxpbmcgeW91ciBzaXRlJ3Mg b3duIGNyZWRlbnRpYWxzLiCgVGhlcmUgaXMgYQ0KPj4+PiBidXNpbmVzcyBjYXNlIGZvciB3aGlz cGVyaW5nIHRvIGEgZnJpZW5kLiCgKFRoZSBwcm9ibGVtIGlzIHRoYXQgYXR0ZW1wdHMNCj4+Pj4g bGlrZSB0aGlzIHRvIHJlcHVycG9zZSBYLjUwOSBhcmUgbWFsaWduZWQgYnkgZS5nLiBGaXJlZm94 LikNCj4+Pj4NCj4+Pj4+IER1ZSB0byB0aGF0LCB0aGUgYmFua3MgaW4gdGhlIEVVIHRoYXQgYWN0 dWFsbHkgdXNlIGNvbnN1bWVyIFBLSSBoYXZlDQo+Pj4+PiBiZWVuDQo+Pj4+PiBmb3JjZWQgZGV2 ZWxvcGluZyB0aGVpciBvd24gY2xpZW50LXNpZGUgc29mdHdhcmUuIKBJIGd1ZXNzIFN0ZWZhbiAo UEtJWA0KPj4+Pj4gY28tY2hhciksIG5ldmVyIHRvbGQgdGhhdCB0byBoaXMgYm9zcyB3aGVuIGhl IHdvcmtlZCBmb3IgTWljcm9zb2Z0IChpbg0KPj4+Pj4gdGhlDQo+Pj4+PiBVUyBhIHN1Ym9yZGlu YXRlIHR5cGljYWxseSBnZXRzIGZpcmVkIGlmIGhlL3NoZSBjcml0aWNpemVzIGNvbXBhbnkNCj4+ Pj4+IHN0cmF0ZWd5KS4NCj4+Pj4NCj4+Pj4NCj4+Pj4gLi4uc28gd2h5IGhhdmVuJ3QgdGhleSBn b3R0ZW4gdG9nZXRoZXIgdG8gZnVuZCB0aGUgZGV2ZWxvcG1lbnQgb2YgYQ0KPj4+PiB1bmlmaWVk IGludGVyZmFjZT8goFdoeSBoYXZlbid0IHRoZXkgY29udHJpYnV0ZWQgdGhlaXIgcXVhbnR1bSBs ZWFwcyBpbg0KPj4+PiBjbGllbnQgUEtJIHByZXNlbnRhdGlvbj8goEhvdyBtdWNoIG9mIHRoZSBi bGFtZSBsaWtlcyBpbiB0aGVpciBkZXNpcmUgdG8NCj4+Pj4gaGF2ZSBhIHByb3ByaWV0YXJ5IGVk Z2U/DQo+Pj4+DQo+Pj4+PiBUaGlzIGhhcyBhbmQgc3RpbGwgaXMgdGhlIHByaW1hcnkgbW90aXZh dGlvbiBiZWhpbmQgbXkgZW5yb2xsbWVudA0KPj4+Pj4gImNydXNhZGUiLg0KPj4+Pj4gSG93ZXZl ciwgaXQgaXMgYWxzbyBwb3NzaWJsZSB0aGF0IHRoZSB3aG9sZSBpZGVhIHJldml2aW5nIHRyYWRp dGlvbmFsDQo+Pj4+PiBQQ3MgaXMNCj4+Pj4+IHRvYXN0LCBpdCBpcyByZWFsbHkgdGhlIG1vYmls ZSBkZXZpY2VzIHRoYXQgYXJlIGluIHRoZSBjZW50ZXIgdGhlc2UNCj4+Pj4+IGRheXMuDQo+Pj4+ DQo+Pj4+DQo+Pj4+IEkgYW0gb2YgdGhlIG9waW5pb24gdGhhdCAiZW5yb2xsbWVudCBpcyBjaGVh cCwgdmVyaWZpY2F0aW9uIGlzDQo+Pj4+IGV4cGVuc2l2ZS4iIKBPbmNlIHRoZSBpZGVudGl0eSBp cyB2ZXJpZmllZCwgdGhlcmUncyBubyByZWFzb24gYXQgYWxsIHRvDQo+Pj4+IGF2b2lkIGVucm9s bGluZyBhZGRpdGlvbmFsIGtleXMgYW5kIGxpbmtpbmcgdGhlbSB0byB0aGUgc2FtZSByZWNvcmQs IGFzIGxvbmcNCj4+Pj4gYXMgeW91IGRlZmluZSB0aGUgZW5yb2xsbWVudCBwcm9jZXNzIGFzIG1v cmUgdGhhbiBqdXN0IHRoZSBhcHBsaWNhdGlvbiBvZiBhDQo+Pj4+IHNpbmdsZSBrZXkgcGVyLXBh cnR5Lg0KPj4+Pg0KPj4+PiBXaGF0J3MgaGFwcGVuZWQgdG8gdGhpcyBwb2ludCBpcyB0aGF0IG5v Ym9keSdzIGJvdGhlcmVkIHRvIGF1dGhlbnRpY2F0ZQ0KPj4+PiB0aGUga2V5c3RvcmUgb24gZWFj aCBpbmRpdmlkdWFsIGRldmljZSwgc28gdGhlIGtleXN0b3JlIGl0c2VsZiBjYW4ndCBhc3NlcnQN Cj4+Pj4gdGhhdCBpdCBnZW5lcmF0ZWQgdGhlIGtleSB3aXRoIGtub3dsZWRnZSBvZiB0aGUgcG9s aWN5IGdvdmVybmluZyBzYWlkIGtleQ0KPj4+PiBnZW5lcmF0aW9uLiCgSWYgdGhlIGVucm9sbGlu ZyBjZXJ0aWZpZXIgaGFzIGV2aWRlbmNlIHRoYXQgdGhlIGtleSB3YXMNCj4+Pj4gZ2VuZXJhdGVk IHByb3Blcmx5IC1hbmQtIHRoYXQgaXQgd2FzIHN1Ym1pdHRlZCBieSB0aGUgcHJpbmNpcGFsLCBp dCBjYW4NCj4+Pj4gc2VjdXJlbHkgZW5yb2xsIGFkZGl0aW9uYWwga2V5cy4NCj4+Pj4NCj4+Pj4g VGhpcyBpcyBub3QgaW1wb3NzaWJsZS4goEl0IGp1c3QgcmVxdWlyZXMgZXhhbWluaW5nIHRoaW5n cyBpbiB0aGUgImhvdw0KPj4+PiBjYW4gSSBnZXQgcGFzdCB0aGlzIHByb2JsZW0/IiBpbnZlbnRp bmcgbWluZHNldC4NCj4+Pj4NCj4+Pj4+IEl0IGlzIGVzc2VudGlhbGx5IEdvb2dsZSBhbmQgQXBw bGUgdGhhdCBydW4gdGhpcyBzaG93IG5vd2FkYXlzLiCgU2luY2UNCj4+Pj4+IHRoZXkNCj4+Pj4+ IGFsc28gaGF2ZSB0aGUgc2VydmljZXMsIHRoZXJlIGlzIGFuIGVudGlyZWx5IG5ldyBtb3RpdmF0 aW9uIHRoZXNlIGRheXMuDQo+Pj4+Pg0KPj4+Pj4gQW55d2F5LCBQS0lYIHdvbid0IGJlIHRoZXJl IHdoZW4gaXQgYWN0dWFsbHkgaGFwcGVuczsgdGhhdCdzIGZvcg0KPj4+Pj4gc3VyZSEhIQ0KPj4+ Pg0KPj4+Pg0KPj4+PiAuLi51bmxlc3MgZXZlcnlvbmUgd2hvJ3MgdGVycmlmaWVkIG9mIGNoYW5n aW5nIGFueXRoaW5nIGZvciBmZWFyIG9mDQo+Pj4+IFZpb2xhdGluZyBUaGUgUHVyaXR5IE9mIFRo ZSBEZXNpZ24gU3BlYyBpcyBzdW1tYXJpbHkgcmVtb3ZlZCBmcm9tIHRoZQ0KPj4+PiBvcmdhbml6 YXRpb24sIGFueXdheS4goFdlIG5lZWQgdG8gbWFrZSB0aGlzIHdvcmsuIKBJdCdzIHVuYWNjZXB0 YWJsZSB0aGF0IHdlDQo+Pj4+IGdpdmUgZXhjdXNlcyBtdWNoIGxpa2UgInlvdSBkaWRuJ3QgY3Jl YXRlIHRoaXMgc2lnbmF0dXJlIHVuZGVyIHRoZSBkYXJrIG9mDQo+Pj4+IHRoZSBtb29uIHdpdGgg dGhlIGJsb29kIG9mIGEgc2FjcmlmaWNlZCBjaGlja2VuIG9uIGEgcml0dWFsbHkgc2FuY3RpZmll ZA0KPj4+PiBzaWx2ZXIgZGFnZ2VyIHdhc2hlZCBpbiB0aGUgdGVhcnMgb2YgYSB2aXJnaW4uLi4g c28gd2UncmUganVzdCBnb2luZyB0bw0KPj4+PiBpbnRlcmZlcmUgd2l0aCBhbmQgcHJldmVudCB5 b3UgZnJvbSBkb2luZyB0aGUgd29yayB5b3UgbmVlZCB0byBkby4iDQo+Pj4+DQo+Pj4+IEkgbWVh biBubyBvZmZlbnNlLCBidXQgdGhpcyByZWFsbHkgbmVlZHMgdG8gYmUgc2FpZC4goFRoZSBQS0kg UHJpZXN0aG9vZA0KPj4+PiBpcyBsaWtlIHRoZSByaWdpZCBoaWVyYXJjaHkgb2YgVmF0aWNhbiBD YXRob2xpY2lzbSBtaXhlZCB3aXRoIHRoZSAib2ggR29kDQo+Pj4+IHBsZWFzZSBsZXQgdGhpcyBi ZSBzdWZmaWNpZW50IHRvIG5vdCBkbyB3aGF0IEkgZmVhciBZb3Ugd2lsbCIgYW5kIGtvc2hlcg0K Pj4+PiBsYXdzIG9mIE9ydGhvZG94IEp1ZGFpc20gYW5kIHRoZSBibG9vZCBzYWNyaWZpY2UgY29u c2VjcmF0aW9uIG9mIEhhaXRpYW4NCj4+Pj4gVm9kb3VuIGFsbCByb2xsZWQgaW50byBvbmUgaG9y cmlibGUgYmxhc3BoZW15IG9mIHJvdGUgcml0dWFsIGZvciBhbGwgdGhlDQo+Pj4+IHdyb25nIHJl YXNvbnMuIKBDYW4ndCB3ZSBkZWZyb2NrIHRoZSBQS0kgUHJpZXN0cz8goE9yIGFtIEkgc3R1Y2sg aW4gdGhlDQo+Pj4+IGVzdGFibGlzaG1lbnQtcXVlc3Rpb25pbmcgc2hvZXMgb2YgTWFydGluIEx1 dGhlciAoZmF0aGVyIG9mIEx1dGhlcmFuaXNtDQo+Pj4+IGFmdGVyIGhlIGRlbm91bmNlZCBWYXRp Y2FuIENhdGhvbGljaXNtIGFzIGNvcnJ1cHQpPw0KPj4+Pg0KPj4+PiAtS3lsZSBIDQo+Pj4NCj4+ Pg0KPj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gcGtpeCBtYWlsaW5nIGxpc3QNCj4gcGtpeEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXgNCg0K --gmsm1.9.6eqh179mhpwvss8sz6kd42 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINAjCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGxjCCBa6g AwIBAgICCMUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNzE5MDFaFw0xMjA2MDUyMDMxMzFaMIHAMSAwHgYDVQQNExcyMDc2MDUtQzh5TUxvb3ll VE85NFFKeDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xIDAeBgkqhkiG9w0BCQEWEWt5YW5oYUBreWFuaGEubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5YylxEUtOSlqBT0sxqB7H0YUDx30ADzggTrSLA9n JVa0QCcIXhk04n7VUD5Augbc40rWhgmB8xl6N9pQ5qvAQZj8JmNej6LRlueN/et9MCjNN0euH0Ky zzKBSE5fxoUPYTTa6QBBurmKNR0navAKWBi8ITLRPi864zTay2oW1A1E1nt69SgJGn3PAv/LyKII WWMzu9YeJsRCd4u6vLHOsGHvr5rc7Dq4bXx8x+vyHgSuYccAnNu81lOC2Unea4TORMoULiwKOTRb pEy35H9Y7MW+SCTlaQiSLgxvYB260OuofHZgcS0wr/OnbGVAEUeBRYhfu3BaxNlZ6zY7mvs9NwID AQABo4IC+jCCAvYwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIG CCsGAQUFBwMEMB0GA1UdDgQWBBThUNrymHVQVA3i/K/6BF4dnrmTqDAfBgNVHSMEGDAWgBSuVYNv 7DHKufcd+q9rMfPIHeOsuzAcBgNVHREEFTATgRFreWFuaGFAa3lhbmhhLm5ldDCCAUIGA1UdIASC ATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9p bnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFM aW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUg U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9v Y3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDov L3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQuY2EuY3J0MCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAjquLhQpUqqxo pg1hbv8zADjhTUY1Gxm1Ha/5Ntdjds7HZ54jOqD2fVwWRbqLAtq+rwHIaudvk13icftTedJlV01r +6VjmOZhSwOPPiYG/v81ABitv8bfyOkei/3BblORXOyzwuXHrbmMOgaEcCmQmqyTo1UJiNMy5Tw0 CvDt+KbSbGP2lQL8BAGyLhswuGePoReqw221KsX6sZJ4Eovk70SlNN19YiRAFYdWL+ggY5mMPn9S qXk8GGLaOyg3g2HnVr7Y4MLYfI0pheoRvoGxj8a4xofTz3u6OlGYE/3D5/uLQbw/rTz6GVVgUFPi GFSKZjzXwfEYJ3Kd1BMXCyfE6zGCAnwwggJ4AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0ECAgjFMAkGBSsOAwIaBQCggb4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTIwNDE5MDM0MzIwWjAjBgkqhkiG9w0BCQQxFgQUL8NJhU/E943ej32z1/mVZqlB RvQwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA BIIBAKJLLJi6gFKtT33CWKxt4mJSuWZqEKMFvjIT2EhEFySK+tEc1F3qupKdRFX0P6wRlOGcm32J 8HhYYOMoBf+V8Yd6VO+eXZC4vFvbuvFerME8wKT//s25faoLvT1yy9KIKFLnCD3kV7V5xTrRX1X8 9tl+mfmWN3KfMBZqYB/NWfQvYAWmoTFQQpMpR7sOkZyZPjdNtpzLhoVzQKJJO9NUJJVvO+sSjKcL M3UvDAW0n9U6a8dDMcZ/lgN7NxoyN5NgzVe9vcWRy1DsYy+7wBJhIzga64ZVzkj4PN8NUFYwjGfC mkAN1fLod9R+3Cmiu5NpVeerx9AaS+4JL/kWM4r4ztoAAAAAAAA= --gmsm1.9.6eqh179mhpwvss8sz6kd42-- From anders.rundgren@telia.com Thu Apr 19 03:37:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB9321F858F for ; Thu, 19 Apr 2012 03:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryiX+UmFxMYQ for ; Thu, 19 Apr 2012 03:37:43 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id D29FB21F8566 for ; Thu, 19 Apr 2012 03:37:41 -0700 (PDT) Received: from [192.168.3.131] (193.12.106.2) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E00E6FB4B; Thu, 19 Apr 2012 12:37:38 +0200 Message-ID: <4F8FEAEE.9070807@telia.com> Date: Thu, 19 Apr 2012 12:37:34 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: swilson@lockstep.com.au References: <4F856D3A.1060103@telia.com> <4F8F7D4C.7060503@lockstep.com.au> In-Reply-To: <4F8F7D4C.7060503@lockstep.com.au> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 10:37:49 -0000 On 2012-04-19 04:49, Stephen Wilson wrote: > > Just quickly, would you care to clarify what it means to get rid of > passwords? > > Do you really mean single factor authentication (i.e. passwords on the > own)? > > Do you imagine PKI based cards / devices would still be password activated? > > Do you really mean reduce the number of passwords? > > Do you advocate radical SSO, so that once logged in, you stay logged in > across arbitrarily many services without ever reentering a password? > > I won't apologise for nitpicking, because there's too much woolly > language in the identity space. We see maniacal media reports about > NSTIC doing away with passwords altogether. And what about the common > perception that biometrics will do away with passwords? Then along comes > this palm scanning ATM where that's not only false, but it even requires > an additional secret over and above the PIN? > http://news.discovery.com/tech/scan-hand-atm-cash-120414.html > > So let's be sure we set the right expectations! Stephen, I hate to say it but my answer is a clear "Yes" to all your questions. That is, I don't advocate SSO or one credential/RP, I'm working with schemes that are intended to give the market a chance to mix and match as much as it wants between different identity models as well as with policy choices. In fact, even old champ OTP is a part of the plot. Regarding "radical SSO", I guess the link Ben Laurie posted the other day is about as far as you can possibly go: http://www.browserauth.net I'm personally more into another Google thingie, the Wallet. Yes, it is indeed Google that is running the show these days! Anders > > Cheers, > > Steve Wilson > Lockstep/http://lockstep.com.au > > > > On 19/04/2012 9:52 AM, Kyle Hamilton wrote: >> Anders, >> >> I am entirely with you on "getting away from passwords". Though, >> instead of wringing my hands about it and thinking that I can't do >> anything for it, I'm creating the system that I perceive the need >> for. I despise passwords, and I believe that they should have been >> done away with 15 years ago, the moment the Wassennar Arrangement was >> inked in 1998. >> >> There exist a couple of barriers which prevent passwords from going >> extinct. There are two that I have my eyes on. One exists at >> Mozilla, the other at Apache httpd. >> >> On Tue, Apr 17, 2012 at 11:31 PM, Anders Rundgren >> wrote: >>> Hi Kyle, >>> I'm not able to respond to your elaborate input because I'm working >>> with a much >>> more basic question which is "getting away from passwords". To have >>> a chance of >>> succeeding you need Vision, Ambition, Marketing, Competence, and >>> Funding. Maybe >>> you even need a portion of luck :-) >> >> My vision: I believe that every individual in the world has the >> absolute right to keep his own secrets. Every person in the world has >> the right to be safe from impersonation fraud. Every person in the >> world has the right to form his own associations, and to create >> systems to help those associations work as expected by the >> participants. What has prevented it to this point is the lack of a >> useful, comprehensible interface. The Clerk of Courts exemplifies >> everything that we expect from our information systems, and should be >> the role model we try to emulate. >> Ambition: I'm going to make sure that everyone has the capacity to >> keep his own secrets, with an interface much like the Clerk of Courts >> presents to the Judges of the Courts, meaning nearly invisible but >> providing exactly what information/paperwork is needed at any given >> moment. >> Competence: I juggle cryptographic building blocks until every need is >> met. At this point, I'm looking for people to evaluate the design I >> created to make passwords the wave of the past. You seem to be >> interested enough in the topic and competent enough in the field to be >> able to give feedback. >> Marketing/Funding: I'll hand it to Mozilla and/or Apache. >> Luck: that nobody else has yet done it right. :-) >> >> I'm working to improve Mozilla's platform so that sites can create and >> enroll their own credentials without throwing away the benefits of its >> root program. (The bug: locally-trusted certificates present the same >> UI as root program certificates.) >> >> I'm also working to remove Apache mod_ssl technical documentation >> about SSLVerifyClient, which dismisses the capacity to present a >> custom credential error recovery flow as not "interesting" (i.e., >> optional_no_ca). >> >> The system I think we need: a workflow implementation system for the >> end-user with predesigned workflows for almost everything that one >> would want to do with cryptography and information storage, providing >> a kind of secure bundling of associated information and presenting the >> kind of "this is what you need at this moment" service that the Clerk >> provides to the Judge. >> >>> One of the problems is that if you intend to create something of this >>> kind you >>> [presumably] need a requirement list. The naked truth is that >>> getting such a >>> thing is essentially impossible because the existing users of >>> consumer PKI don't >>> know which one of the gazillion security standards efforts are for >>> "real", and >>> therefore do not [actively] support any of them. >> >> Which is why I've created my own Requirements. I'm sure the rest of >> the world will catch up eventually: >> 1) Assert multiple credential chains from multiple credential sources >> atomically, in verifiable form. >> 2) Assert non-verifiable data in the same atom. >> 3) Provide an optional means to encrypt that credential chain atom to >> the intended recipient. >> 4) Provide a means to ensure that even if the digests used for the >> signatures are compromised, the data can still be known good. >> 5) Provide stapled OCSP responses or the current CRL for every >> certificate in every credential chain. >> 6) Provide a timestamp, so that the time of signature can be shown to >> exist within the validity periods of the certificate chains' OCSP. >> 7) Include every device the user has that can understand the protocol, >> including PCs, notebooks, tablets, phones, and credential stores. >> 8) Reuse as much crypto, standard and code as possible, subject to the >> constraints 1-8. If possible, use areas of the standards that have >> been disclaimed by the standards bodies themselves (such as >> self-signed X.509 structures as something other than a trust anchor >> container). >> 9) Present authorization UI on one or more devices other than the >> credential store and the device which submitted the signature request, >> to reduce the opportunity for malware on the main interface to apply >> an unauthorized signature. >> 10) Save -everything- that has ever been signed. >> >> Might you be interested in a data format which enables these to be >> met, without changes to the existing CA infrastructure, without any >> changes to any technical standards including TLS and S/MIME, and >> without worrying about the lack of motion in standards bodies? >> Standards come about because something works, not because people think >> that it will work if they're built to. This is the failure of PKIX-WG. >> >>> Due to this, the fate of consumer PKI firmly resides in the hands of >>> big vendors >> >> This is perhaps incorrect. The fate of consumer PKI in US appears to >> reside in my hands, as I seem to be the only person in US who thinks >> that there does exist a business case for it. >> >> If you want something cryptographic done, you pretty much have to roll >> your own because the current standards are so distressingly ignorant >> of reality. :( >> >>> which are exclusively targeting mobile devices with embedded security >>> hardware. >>> The smart card concept never worked well as consumer solution in >>> desktop PCs. >> >> Agreed. I have a laptop with a smart card reader. It is much more >> hassle than it's worth. >> >>> IMO, there is actually a way ahead and that is "putting the cart >>> before the horse" >>> which means that instead of following the whims of the severely >>> divided smart card >>> community, you define a standard card and provide a *fixed* driver. >>> Implementing >>> a minute set of cryptographic operations is actually not rocket >>> science while >>> developing and distributing middleware for a huge number of >>> ever-changing platforms >>> takes forever and still you never know for sure if it is actually >>> working! >>> By making the driver a *platform vendor issue only*, things get much >>> easier. >> >> I don't actually think this is the way ahead. The way ahead is to >> make it work, and then let other people into the game. >> >> The problem is partially PKCS#11, but much more globally ISO/IEC 7816-*. >> >> For auditability I want to ensure that I have absolute control over >> the container and its auditing at all times, and that is impossible >> with a smart card (or any PKCS11 module) that doesn't have a custom >> enclosure. >> >>> PIV was a step in this direction but NIST didn't standardize the >>> management >>> functions since the card industry wanted to keep something to be >>> unique with. >> >> NIST is part of the problem, publishing only half-baked >> semistandards. But, I don't think the actual problem preventing >> consumer PKI from taking root is NIST. The fact that smart cards >> exist (and the vendors are allowed to continue pushing and enforcing >> their proprietary extensions) is itself The Problem. Smart cards are >> the wrong technology, mostly because of the proprietary vendor lock-in >> that these semi-standards have created. >> >> So, I'm more than happy to not only "ignore the smart card industry's >> desires", but "ignore the smart card industry's existence". >> >> The Raspberry Pi (http://www.raspberrypi.org/) is an open device with >> an 800MHz processor and a $25 price tag. This is the credential >> storage device of the future, low-level enough that I can take >> complete control as I need to, fast enough that it can perform >> acceptably. With IPv6, everyone on earth could have ten of them and >> there would still be more than 3.40E+38 (340+ short-scale undecillion) >> addresses left, subject to the lossage of network versus interface >> addressing. >> >> Mixing this with a smartphone means that you suddenly have a remote >> keystore that you can send unsigned requests and signed authorities >> to, via a UI device you've already got in your pocket. >> >> I seem to be the only security-minded person in US who thinks that >> IPv6 utility is not only awesomesauce but the only way forward, >> because we currently cannot use our cryptographic keys as our IP >> addresses. But, we can enable that if we use them as portions of >> multicast addresses. (physical location is personal information and >> must be protected.) >> >> I also appear to be the only person in US who thinks that every >> asymmetric key (with few enough exceptions that this is a good general >> rule) is nonexportably bound to hardware, and hardware dies, so we >> shall lose every private key we care about. We must plan for that >> eventuality while still providing adequate security for our clients. >> I've got a design for this that works on paper, and I'm working to >> make it reality. >> >> Cheers! >> >> -Kyle H >> >> >>> >>> Anders >>> >>> On 2012-04-17 23:43, Kyle Hamilton wrote: >>>> >>>> On Thu, Apr 12, 2012 at 9:23 PM, Anders Rundgren >>>> wrote: >>>>> My perspective on this is slightly different. IMO this issue (as >>>>> well as PKI...) >>>>> is essentially "owned" by three major laggards: Governments, Banks, >>>>> and Microsoft. >>>> >>>> This issue is "owned" by ISO, which means that it's on the >>>> governments who are participating in ISO. >>>> >>>> The most important aspect of any access-control system (especially >>>> financial) is auditability, and the ISO standards don't cause enough >>>> data to be transmitted to the cryptographic container for the >>>> container to write its own audit logs. PKCS#11 exposes ISO >>>> functionality, so it doesn't have a "I'm sending you something that >>>> I want you to digest for me" call. Thus, we have no idea that the >>>> digests submitted are being calculated correctly, and no idea what >>>> the digests we're signing actually mean. >>>> >>>> Instead, we have to implement the auditing service externally, which >>>> means that we must be able to trust that we are the sole controllers >>>> of the cryptographic containers involved. >>>> >>>>> Since the first two are numerous as well as geographically and >>>>> culturally >>>>> diverse it would be wrong giving them the blame. However, since >>>>> they to >>>>> some 90% have relied on a single client-OS vendor, the generally >>>>> pitiful >>>>> state of client-side PKI in consumer PCs is unilaterally due to >>>>> Microsoft's >>>>> limited of understanding of this market. Over the years I have met >>>>> quite >>>>> a bunch of Microsoft Program Managers and they all say the same thing: >>>>> "There is no business case for consumer PKI". In some way this is >>>>> also >>>>> true since there is no paying customer out there. >>>> >>>> Ah, Microsoft spreading lies again. >>>> >>>> There is no business case for discarding Apache httpd's >>>> SSLVerifyClient optional_no_ca, but it's discarded by the technical >>>> people because its documentation says that "optional_no_ca is >>>> actually against the idea of authentication". Instead, we end up >>>> with applications which handle their own username and password error >>>> flows because optional_no_ca is in fact the only way to present a >>>> custom error page when people inadvertently try to log in with the >>>> wrong certificate or before they've ever been issued a certificate >>>> for the service in question. >>>> >>>> There is no business case for consumer X.509-as-tied-to-X.500. >>>> There is a business case for enrolling your site's own credentials. >>>> There is a business case for whispering to a friend. (The problem >>>> is that attempts like this to repurpose X.509 are maligned by e.g. >>>> Firefox.) >>>> >>>>> Due to that, the banks in the EU that actually use consumer PKI >>>>> have been >>>>> forced developing their own client-side software. I guess Stefan >>>>> (PKIX >>>>> co-char), never told that to his boss when he worked for Microsoft >>>>> (in the >>>>> US a subordinate typically gets fired if he/she criticizes company >>>>> strategy). >>>> >>>> ...so why haven't they gotten together to fund the development of a >>>> unified interface? Why haven't they contributed their quantum leaps >>>> in client PKI presentation? How much of the blame likes in their >>>> desire to have a proprietary edge? >>>> >>>>> This has and still is the primary motivation behind my enrollment >>>>> "crusade". >>>>> However, it is also possible that the whole idea reviving >>>>> traditional PCs is >>>>> toast, it is really the mobile devices that are in the center these >>>>> days. >>>> >>>> I am of the opinion that "enrollment is cheap, verification is >>>> expensive." Once the identity is verified, there's no reason at all >>>> to avoid enrolling additional keys and linking them to the same >>>> record, as long as you define the enrollment process as more than >>>> just the application of a single key per-party. >>>> >>>> What's happened to this point is that nobody's bothered to >>>> authenticate the keystore on each individual device, so the keystore >>>> itself can't assert that it generated the key with knowledge of the >>>> policy governing said key generation. If the enrolling certifier >>>> has evidence that the key was generated properly -and- that it was >>>> submitted by the principal, it can securely enroll additional keys. >>>> >>>> This is not impossible. It just requires examining things in the >>>> "how can I get past this problem?" inventing mindset. >>>> >>>>> It is essentially Google and Apple that run this show nowadays. >>>>> Since they >>>>> also have the services, there is an entirely new motivation these >>>>> days. >>>>> >>>>> Anyway, PKIX won't be there when it actually happens; that's for >>>>> sure!!! >>>> >>>> ...unless everyone who's terrified of changing anything for fear of >>>> Violating The Purity Of The Design Spec is summarily removed from >>>> the organization, anyway. We need to make this work. It's >>>> unacceptable that we give excuses much like "you didn't create this >>>> signature under the dark of the moon with the blood of a sacrificed >>>> chicken on a ritually sanctified silver dagger washed in the tears >>>> of a virgin... so we're just going to interfere with and prevent you >>>> from doing the work you need to do." >>>> >>>> I mean no offense, but this really needs to be said. The PKI >>>> Priesthood is like the rigid hierarchy of Vatican Catholicism mixed >>>> with the "oh God please let this be sufficient to not do what I fear >>>> You will" and kosher laws of Orthodox Judaism and the blood >>>> sacrifice consecration of Haitian Vodoun all rolled into one >>>> horrible blasphemy of rote ritual for all the wrong reasons. Can't >>>> we defrock the PKI Priests? Or am I stuck in the >>>> establishment-questioning shoes of Martin Luther (father of >>>> Lutheranism after he denounced Vatican Catholicism as corrupt)? >>>> >>>> -Kyle H >>> >> > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From turners@ieca.com Sat Apr 21 07:27:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC7F21F85C6 for ; Sat, 21 Apr 2012 07:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.259 X-Spam-Level: X-Spam-Status: No, score=-102.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTf56h7Hwriz for ; Sat, 21 Apr 2012 07:27:46 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [64.5.50.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7543B21F8464 for ; Sat, 21 Apr 2012 07:27:46 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id E7D7F3FDE7029; Sat, 21 Apr 2012 09:27:45 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id DDB623FDE7009 for ; Sat, 21 Apr 2012 09:27:45 -0500 (CDT) Received: from [96.231.117.132] (port=46066 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SLbHt-0003zn-HX for pkix@ietf.org; Sat, 21 Apr 2012 09:27:45 -0500 Message-ID: <4F92C3E0.4050105@ieca.com> Date: Sat, 21 Apr 2012 10:27:44 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <20120416205733.2509.7901.idtracker@ietfa.amsl.com> In-Reply-To: <20120416205733.2509.7901.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120416205733.2509.7901.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-117-132.washdc.east.verizon.net (thunderfish.local) [96.231.117.132]:46066 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 11 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [pkix] Fwd: I-D Action: draft-turner-additional-methods-4kis-01.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 14:27:50 -0000 For those of you who might be interested. Comments are welcome. spt -------- Original Message -------- Subject: I-D Action: draft-turner-additional-methods-4kis-01.txt Date: Mon, 16 Apr 2012 13:57:33 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Additional Methods for Generating Key Identifiers Author(s) : Sean Turner Stephen Kent Filename : draft-turner-additional-methods-4kis-01.txt Pages : 8 Date : 2012-04-16 This document specifies additional methods for generating key identifiers from a public key. This document also specifies an extension to identify the algorithms used to generate the key identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From internet-drafts@ietf.org Sat Apr 21 08:13:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCD921F8601; Sat, 21 Apr 2012 08:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvr9bez64p7q; Sat, 21 Apr 2012 08:13:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193AE21F85D7; Sat, 21 Apr 2012 08:13:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120421151310.30512.78204.idtracker@ietfa.amsl.com> Date: Sat, 21 Apr 2012 08:13:10 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-caa-06.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 15:13:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource= Record Author(s) : Phillip Hallam-Baker Rob Stradling Filename : draft-ietf-pkix-caa-06.txt Pages : 16 Date : 2012-04-21 The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis- issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-caa-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-caa-06.txt From turners@ieca.com Mon Apr 23 11:04:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC4021F864D for ; Mon, 23 Apr 2012 11:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.123 X-Spam-Level: X-Spam-Status: No, score=-102.123 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHchKnamGwtJ for ; Mon, 23 Apr 2012 11:04:59 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.150.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7714521F8638 for ; Mon, 23 Apr 2012 11:04:59 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 209723E4FE8CA; Mon, 23 Apr 2012 13:04:59 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 12D903E4FE8A2 for ; Mon, 23 Apr 2012 13:04:59 -0500 (CDT) Received: from [96.231.115.177] (port=46584 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SMNdC-0008Ln-Oo; Mon, 23 Apr 2012 13:04:58 -0500 Message-ID: <4F9599C9.2090304@ieca.com> Date: Mon, 23 Apr 2012 14:04:57 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-115-177.washdc.east.verizon.net (thunderfish.local) [96.231.115.177]:46584 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: draft-ietf-pkix-caa@tools.ietf.org Subject: [pkix] Early AD review of draft-ietf-pkix-caa X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:05:00 -0000 Philip/Rod, Thanks for this update. Here's my early AD comments: 1. s1.2: Maybe add an informative reference to RFC 3647 in the CP/CPS definitions. Certification Policy (CP) Specifies the criteria that a Certification Authority undertakes to meet in its issue of certificates. See [RFC3647]. Certification Practices Statement (CPS) Specifies the means by which the criteria of the Certification Policy are met. In most cases this will be the document against which the operations of the Certification Authority are audited. See [RFC3647]. 2. s2: I think the following paragraph is good fodder for the proto write-up but could be left out of the draft: Verification of certificate requests against CAA records published in the corresponding domain is currently under consideration by the CA- Browser Forum as a required element of the Basic Requirements for Certificate issue. 3. s4.1: r/futuree/future spt From hallam@gmail.com Mon Apr 23 11:09:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C4121F860D for ; Mon, 23 Apr 2012 11:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu5klH6FmeJb for ; Mon, 23 Apr 2012 11:09:43 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D6C4C21F85F9 for ; Mon, 23 Apr 2012 11:09:42 -0700 (PDT) Received: by yhkk25 with SMTP id k25so7327692yhk.31 for ; Mon, 23 Apr 2012 11:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=N4KU6cA8TjnlyWRPKbP/Bf/Ppgnc/80ckzx3ssz2UR8=; b=VekUatCyXke7F4AKNAzHZ6ODMRFL9GaMpodS3PUp85Ba7g2qrylfHEEVmGL+f2eXLm 1IRJdvKJawLP6D/Aex7SJ9XgRyjZbFrfXJxaFY4GLA47omyU4acTY3SK2u/+Lbcf58B2 t48K9Ni4thW6Jy1JfBbweGF0FVXgDUebilI+W3IpetLYncWHtKz+ccYmTLaJNQecMeZX N7jQ4CqvdINYV10ZuGdXCU5HhD1B2aJZAG3vQy9yk4eoBCkoPwHMVNtAHUF8Zlyrn9l+ ELU+tq2BRNjVXakTgXVZFpyHT8d2xoFdZ6uG5LFYU+PkAoDNeChXaD3ETTt2F2OL4zQ2 aXmg== MIME-Version: 1.0 Received: by 10.60.27.7 with SMTP id p7mr255682oeg.56.1335204580677; Mon, 23 Apr 2012 11:09:40 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Mon, 23 Apr 2012 11:09:40 -0700 (PDT) In-Reply-To: <4F9599C9.2090304@ieca.com> References: <4F9599C9.2090304@ieca.com> Date: Mon, 23 Apr 2012 14:09:40 -0400 Message-ID: From: Phillip Hallam-Baker To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org, draft-ietf-pkix-caa@tools.ietf.org Subject: Re: [pkix] Early AD review of draft-ietf-pkix-caa X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:09:43 -0000 OK, I can fix these. I have no problem leaving out the CABForum reference. It was only really in there to demonstrate that the necessary deployment constituency exists. On Mon, Apr 23, 2012 at 2:04 PM, Sean Turner wrote: > Philip/Rod, > > Thanks for this update. =A0Here's my early AD comments: > > 1. s1.2: Maybe add an informative reference to RFC 3647 in the CP/CPS > definitions. > > =A0Certification Policy (CP) =A0Specifies the criteria that a > =A0 =A0 =A0Certification Authority undertakes to meet in its issue of > =A0 =A0 =A0certificates. =A0See [RFC3647]. > > =A0 Certification Practices Statement (CPS) =A0Specifies the means by whi= ch > =A0 =A0 =A0the criteria of the Certification Policy are met. =A0In most c= ases > =A0 =A0 =A0this will be the document against which the operations of the > =A0 =A0 =A0Certification Authority are audited. =A0See [RFC3647]. > > 2. s2: I think the following paragraph is good fodder for the proto write= -up > but could be left out of the draft: > > =A0Verification of certificate requests against CAA records published in > =A0the corresponding domain is currently under consideration by the CA- > =A0Browser Forum as a required element of the Basic Requirements for > =A0Certificate issue. > > 3. s4.1: r/futuree/future > > spt > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From turners@ieca.com Mon Apr 23 11:38:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5513021F85C0 for ; Mon, 23 Apr 2012 11:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISMAvbBYtkeI for ; Mon, 23 Apr 2012 11:38:29 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.7.10]) by ietfa.amsl.com (Postfix) with ESMTP id D4FF021F85CD for ; Mon, 23 Apr 2012 11:38:29 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id 751D03E2F74C3; Mon, 23 Apr 2012 13:38:29 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id 629803E2F7473 for ; Mon, 23 Apr 2012 13:38:29 -0500 (CDT) Received: from [96.231.115.177] (port=38739 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SMO9c-0004pG-VF for pkix@ietf.org; Mon, 23 Apr 2012 13:38:29 -0500 Message-ID: <4F95A1A4.5060209@ieca.com> Date: Mon, 23 Apr 2012 14:38:28 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <20120423183151.1989.87952.idtracker@ietfa.amsl.com> In-Reply-To: <20120423183151.1989.87952.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120423183151.1989.87952.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-115-177.washdc.east.verizon.net (thunderfish.local) [96.231.115.177]:38739 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [pkix] Fwd: I-D Action: draft-turner-additional-methods-4kis-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:38:30 -0000 The previous version assumed that the input to the hash was always the private key. Somebody pointed out that this might not always be the case so I added a field (an OID) to indicate the semantics of the hash input. I also defined one value to indicate for SubjectpublicKeyInfo to be the input to the hash alg. spt -------- Original Message -------- Subject: I-D Action: draft-turner-additional-methods-4kis-02.txt Date: Mon, 23 Apr 2012 11:31:51 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Additional Methods for Generating Key Identifiers Author(s) : Sean Turner Stephen Kent Filename : draft-turner-additional-methods-4kis-02.txt Pages : 8 Date : 2012-04-23 This document specifies additional methods for generating key identifiers from a public key. This document also specifies an extension to identify the algorithms used to generate the key identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From eabalea@gmail.com Mon Apr 23 13:11:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EC721F85EA for ; Mon, 23 Apr 2012 13:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q5wMCavRfPP for ; Mon, 23 Apr 2012 13:11:33 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8DA321F8555 for ; Mon, 23 Apr 2012 13:11:33 -0700 (PDT) Received: by yhkk25 with SMTP id k25so7446763yhk.31 for ; Mon, 23 Apr 2012 13:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xdj7PmhNRUovBDEbXi4vKCdbOoPbNZeWnHrxGmsJgCk=; b=qmMLLmRvvuWUXe/0jUg0U0gbgLNzCYzoAy/uUcgOQlFb6kAbrNp9SyDi/31w1bhEbb CG964ysxzS+M2FE8RFUD01MHSftrotbjpuQwa7FbLkOaGsY3rpmbT6CDyD0oMddCw3D8 MJT1Drl0E5Qp8DJ88maZKVSEpT8ZQpjIsqPUI+fL1WTZbbp/xg60m38ry3o4SyscuAcL X+eAgEwxTv1URKwvkHrCigYdpUt0mClkN5DQNrL+G3Ds9o/N/1zRDMlkgWLkaQKm/k3k xpW6Zg/JSKPSmOLoc2LZPxUvwODUpcy5dpebXey/9Xm1zwdtTy9JN9q2tmgG0ocgmiTa 1AEA== MIME-Version: 1.0 Received: by 10.236.181.133 with SMTP id l5mr10976849yhm.71.1335211893332; Mon, 23 Apr 2012 13:11:33 -0700 (PDT) Received: by 10.236.102.148 with HTTP; Mon, 23 Apr 2012 13:11:32 -0700 (PDT) Received: by 10.236.102.148 with HTTP; Mon, 23 Apr 2012 13:11:32 -0700 (PDT) In-Reply-To: <4F9599C9.2090304@ieca.com> References: <4F9599C9.2090304@ieca.com> Date: Mon, 23 Apr 2012 22:11:32 +0200 Message-ID: From: Erwann Abalea To: Sean Turner Content-Type: multipart/alternative; boundary=20cf303f6bb69a1b2a04be5e3eb4 Cc: pkix@ietf.org, draft-ietf-pkix-caa@tools.ietf.org Subject: Re: [pkix] Early AD review of draft-ietf-pkix-caa X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 20:11:34 -0000 --20cf303f6bb69a1b2a04be5e3eb4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A CP is not a Certification Policy, but a Certificate Policy, i.e. what the certificate can be used for. --=20 Erwann. Le 23 avr. 2012 20:05, "Sean Turner" a =C3=A9crit : > > Philip/Rod, > > Thanks for this update. Here's my early AD comments: > > 1. s1.2: Maybe add an informative reference to RFC 3647 in the CP/CPS definitions. > > Certification Policy (CP) Specifies the criteria that a > Certification Authority undertakes to meet in its issue of > certificates. See [RFC3647]. > > Certification Practices Statement (CPS) Specifies the means by which > the criteria of the Certification Policy are met. In most cases > this will be the document against which the operations of the > Certification Authority are audited. See [RFC3647]. --20cf303f6bb69a1b2a04be5e3eb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A CP is not a Certification Policy, but a Certificate Policy, i.e. what = the certificate can be used for.

--
Erwann.

Le 23 avr. 2012 20:05, "Sean Turner" <turners@ieca.com> a =C3=A9crit=C2=A0:
>
> Philip/Rod,
>
> Thanks for this update. =C2=A0Here's my early AD comments:
>
> 1. s1.2: Maybe add an informative reference to RFC 3647 in the CP/CPS = definitions.
>
> =C2=A0Certification Policy (CP) =C2=A0Specifies the criteria that a > =C2=A0 =C2=A0 =C2=A0Certification Authority undertakes to meet in its = issue of
> =C2=A0 =C2=A0 =C2=A0certificates. =C2=A0See [RFC3647].
>
> =C2=A0 Certification Practices Statement (CPS) =C2=A0Specifies the mea= ns by which
> =C2=A0 =C2=A0 =C2=A0the criteria of the Certification Policy are met. = =C2=A0In most cases
> =C2=A0 =C2=A0 =C2=A0this will be the document against which the operat= ions of the
> =C2=A0 =C2=A0 =C2=A0Certification Authority are audited. =C2=A0See [RF= C3647].

--20cf303f6bb69a1b2a04be5e3eb4-- From turners@ieca.com Mon Apr 23 13:20:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF9C21F8642 for ; Mon, 23 Apr 2012 13:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5VT3MVdJogJ for ; Mon, 23 Apr 2012 13:20:04 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [64.5.52.9]) by ietfa.amsl.com (Postfix) with ESMTP id 61EB521F863D for ; Mon, 23 Apr 2012 13:20:04 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id F016C424E43C6; Mon, 23 Apr 2012 15:20:03 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id E5DCB424E43A6 for ; Mon, 23 Apr 2012 15:20:03 -0500 (CDT) Received: from [96.231.115.177] (port=45192 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SMPjv-0008R8-E8; Mon, 23 Apr 2012 15:20:03 -0500 Message-ID: <4F95B972.1090101@ieca.com> Date: Mon, 23 Apr 2012 16:20:02 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Erwann Abalea References: <4F9599C9.2090304@ieca.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-115-177.washdc.east.verizon.net (thunderfish.local) [96.231.115.177]:45192 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: pkix@ietf.org, draft-ietf-pkix-caa@tools.ietf.org Subject: Re: [pkix] Early AD review of draft-ietf-pkix-caa X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 20:20:08 -0000 You're right I glossed over that. It's probably something that should be changed through the draft. spt On 4/23/12 4:11 PM, Erwann Abalea wrote: > A CP is not a Certification Policy, but a Certificate Policy, i.e. what > the certificate can be used for. > > -- > Erwann. > > Le 23 avr. 2012 20:05, "Sean Turner" > a écrit : > > > > Philip/Rod, > > > > Thanks for this update. Here's my early AD comments: > > > > 1. s1.2: Maybe add an informative reference to RFC 3647 in the CP/CPS > definitions. > > > > Certification Policy (CP) Specifies the criteria that a > > Certification Authority undertakes to meet in its issue of > > certificates. See [RFC3647]. > > > > Certification Practices Statement (CPS) Specifies the means by which > > the criteria of the Certification Policy are met. In most cases > > this will be the document against which the operations of the > > Certification Authority are audited. See [RFC3647]. > From turners@ieca.com Mon Apr 23 13:29:08 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEF511E8076 for ; Mon, 23 Apr 2012 13:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPVvU4elaaG3 for ; Mon, 23 Apr 2012 13:29:08 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [70.85.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4698511E8072 for ; Mon, 23 Apr 2012 13:29:08 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id CDF9341EFF839; Mon, 23 Apr 2012 15:29:07 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id C0C1C41EFF819 for ; Mon, 23 Apr 2012 15:29:07 -0500 (CDT) Received: from [96.231.115.177] (port=37804 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SMPsh-0003N2-H1 for pkix@ietf.org; Mon, 23 Apr 2012 15:29:07 -0500 Message-ID: <4F95BB92.6080206@ieca.com> Date: Mon, 23 Apr 2012 16:29:06 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <4C18DCF2.2030703@ieca.com> In-Reply-To: <4C18DCF2.2030703@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-115-177.washdc.east.verizon.net (thunderfish.local) [96.231.115.177]:37804 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [pkix] Possible new work item: additional methods for generating key identifiers X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 20:29:08 -0000 I've resurrected this draft after making some changes/additions to it based on mailing list comments. The latest version can be found at: http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ I'd like to ask the WG (again) to consider adopting this a WG item. spt On 6/16/10 10:17 AM, Sean Turner wrote: > Greetings. Steve and I have whipped up a short I-D that specifies > additional methods for generating key identifiers from a public key. The > draft can be found at: > > http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ > > I'd like to ask the WG to consider adopting this as a WG item. > > Cheers, > > spt* > > * (with no hat on) > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From rstruik.ext@gmail.com Mon Apr 23 14:47:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7445921E8041 for ; Mon, 23 Apr 2012 14:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGZ0nT7IS+Zy for ; Mon, 23 Apr 2012 14:47:11 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A83221E8039 for ; Mon, 23 Apr 2012 14:47:11 -0700 (PDT) Received: by ghbg16 with SMTP id g16so7869ghb.31 for ; Mon, 23 Apr 2012 14:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=mXZXoH8cDBlHQbnp/6MaplzdyTvRstIyD+OyK7K0hlc=; b=Fdx1yiLSpAqEnC7R5Sxr004QPlbb4TQGv1XqPW0hAZAMr4p5F2Ia658BSRHYYVPJa0 Vor6m8jf/yLLcKeiGUh1XtNdycBmgQqo27zJ9fV2CjR7J6DLI76eEIxWJU5qZFzCNmyv GRMhd2Yz22oGva3F9wbnGNDZcTLdnwdtGi9+OYQmrcVmHHXWl0tzvmDpIdwPCnfhav2F 4hN/a7bOTh93vQTmQgLQqrfMxoM4dpFENcE+4mCU+WHN4vj1udn8fZFcwP0OvV9jfCgw bwF6lBavtiQO9BGKC6y/DP+AGBKc1YHggtzmijqvvKCLYXIq0jDQP4EbWJYmel/Isq5N 7msA== Received: by 10.50.203.74 with SMTP id ko10mr7882866igc.7.1335217630714; Mon, 23 Apr 2012 14:47:10 -0700 (PDT) Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [72.138.34.10]) by mx.google.com with ESMTPS id k8sm28572847igz.4.2012.04.23.14.47.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 14:47:09 -0700 (PDT) Message-ID: <4F95CDCE.4080109@gmail.com> Date: Mon, 23 Apr 2012 17:46:54 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Sean Turner References: <4C18DCF2.2030703@ieca.com> <4F95BB92.6080206@ieca.com> In-Reply-To: <4F95BB92.6080206@ieca.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Possible new work item: additional methods for generating key identifiers X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 21:47:12 -0000 Hi Sean: You defined the key identifier to be the hash of the public key, truncated to 160 bits. Shouldn't one have different key identifiers if the policy fields assoicated with the public key are different (e.g., if the same public key Qa associated with some entity A gets rolled over and assigned a new validity period)? Similarly, shouldn't one include the unique id of the presumed key holder (e.g.,so as to preclude people cloning a public/private key pair to another device [I am sure implementers contemplating this exist] without notice)? Best regards, Rene On 23/04/2012 4:29 PM, Sean Turner wrote: > > > I've resurrected this draft after making some changes/additions to it > based on mailing list comments. The latest version can be found at: > > http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ > > I'd like to ask the WG (again) to consider adopting this a WG item. > > spt > > > > On 6/16/10 10:17 AM, Sean Turner wrote: >> Greetings. Steve and I have whipped up a short I-D that specifies >> additional methods for generating key identifiers from a public key. The >> draft can be found at: >> >> http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ >> >> I'd like to ask the WG to consider adopting this as a WG item. >> >> Cheers, >> >> spt* >> >> * (with no hat on) >> _______________________________________________ >> 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 -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From James.H.Manger@team.telstra.com Mon Apr 23 20:15:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE68021F847E for ; Mon, 23 Apr 2012 20:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX6cFxSP32rC for ; Mon, 23 Apr 2012 20:15:44 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id BDEB621F84C9 for ; Mon, 23 Apr 2012 20:15:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,472,1330866000"; d="scan'208";a="70896274" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 24 Apr 2012 13:15:41 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6690"; a="60111319" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipccvi.tcif.telstra.com.au with ESMTP; 24 Apr 2012 13:15:40 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Tue, 24 Apr 2012 13:15:40 +1000 From: "Manger, James H" To: Sean Turner , "pkix@ietf.org" Date: Tue, 24 Apr 2012 13:15:37 +1000 Thread-Topic: [pkix] Fwd: I-D Action: draft-turner-additional-methods-4kis-02.txt Thread-Index: Ac0hgFAo7MLGLfMxQXq0HWnWd2V2SQAQeFIg Message-ID: <255B9BB34FB7D647A506DC292726F6E114F0C4080F@WSMSG3153V.srv.dir.telstra.com> References: <20120423183151.1989.87952.idtracker@ietfa.amsl.com> <4F95A1A4.5060209@ieca.com> In-Reply-To: <4F95A1A4.5060209@ieca.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Fwd: I-D Action: draft-turner-additional-methods-4kis-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 03:15:45 -0000 > Title : Additional Methods for Generating Key Identifiers > Filename : draft-turner-additional-methods-4kis-04.txt Using a more recent hash alg than SHA-1 to generate key ids sounds fine. Keeping the 160-bit size "to avoid adversely affecting relying party code" = sounds strange. RFC5280 already recommends 2 methods with different lengths= (160-bit and 64-bit) so relying party code better handle that. Perhaps usi= ng a size no longer than 160-bit is nice (so it takes no more space in a da= tabase field, for instance). Since we are truncating the hashes in all the = new algs, why not truncate to something shorter? 64-bits would be a good ch= oice (matching the shorter existing recommended method). We could even set = the first 4 bits to 0101, 0110, 0111, 1000 for the 4 new methods so it matc= hes the existing recommendation even more closely. What is the reason for having a certificate extension to describe how a key= id is generated? I don't think the draft gives any reason. The kiLength field seems pointless. You can look at the actual key id (also= in the cert) to get its length. A kiHashInput value of id-subjectPublicKey seems to mean the same thing as = the kiHashInput field being absent. Two ways to say the same thing is bad. -- James Manger From internet-drafts@ietf.org Tue Apr 24 00:32:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9870B21F85F6; Tue, 24 Apr 2012 00:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGQA0KpPJkFp; Tue, 24 Apr 2012 00:32:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ACB21F85DD; Tue, 24 Apr 2012 00:32:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120424073210.15854.28781.idtracker@ietfa.amsl.com> Date: Tue, 24 Apr 2012 00:32:10 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-pubkey-caps-05.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 07:32:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : S/MIME Capabilities for Public Key Definitions Author(s) : Jim Schaad Filename : draft-ietf-pkix-pubkey-caps-05.txt Pages : 24 Date : 2012-04-24 This document defines a set of S/MIME Capability types for ASN.1 encoding for the current set of public keys define in the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. An example of where this is used is with the OCSP Agility draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-pubkey-caps/ From turners@ieca.com Tue Apr 24 04:07:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D976821F86C5 for ; Tue, 24 Apr 2012 04:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Zy9lFHPXFU7 for ; Tue, 24 Apr 2012 04:07:41 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.41.248.18]) by ietfa.amsl.com (Postfix) with ESMTP id 46BB321F86B8 for ; Tue, 24 Apr 2012 04:07:41 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id E1D1046D33882; Tue, 24 Apr 2012 06:07:40 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id D79E046D33862 for ; Tue, 24 Apr 2012 06:07:40 -0500 (CDT) Received: from [96.231.123.106] (port=33334 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SMdat-0001BZ-UY; Tue, 24 Apr 2012 06:07:40 -0500 Message-ID: <4F96897A.7020906@ieca.com> Date: Tue, 24 Apr 2012 07:07:38 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Rene Struik References: <4C18DCF2.2030703@ieca.com> <4F95BB92.6080206@ieca.com> <4F95CDCE.4080109@gmail.com> In-Reply-To: <4F95CDCE.4080109@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-123-106.washdc.east.verizon.net (thunderfish.local) [96.231.123.106]:33334 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: pkix@ietf.org Subject: Re: [pkix] Possible new work item: additional methods for generating key identifiers X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 11:07:42 -0000 Rene, Thanks for reviewing. Comments inline. spt On 4/23/12 5:46 PM, Rene Struik wrote: > Hi Sean: > > You defined the key identifier to be the hash of the public key, > truncated to 160 bits. There's two parts of this draft: - Describing methods for generating a key identifier that are the same as one of the example methods in 5280 except they ones in the draft use the SHA2 algs. - Defining an extension to allow CAs to indicate the alg used to compute they key identifier, the input to the hash alg, and the output length. > Shouldn't one have different key identifiers if > the policy fields assoicated with the public key are different (e.g., if > the same public key Qa associated with some entity A gets rolled over > and assigned a new validity period)? If I'm reading RFC 5280 correctly, then I think it might go against it: Where a key identifier has been previously established, the CA SHOULD use the previously established identifier. > Similarly, shouldn't one include > the unique id of the presumed key holder (e.g.,so as to preclude people > cloning a public/private key pair to another device [I am sure > implementers contemplating this exist] without notice)? I'm certainly not precluding anybody from using whatever they want as an input to hash alg used to generate the key identifiers. I'm just listing some additional methods. To play devil's advocate here, I can already see the questions on this one: how do you know the identifier for the key holder is unique. > Best regards, Rene > > On 23/04/2012 4:29 PM, Sean Turner wrote: >> >> >> I've resurrected this draft after making some changes/additions to it >> based on mailing list comments. The latest version can be found at: >> >> http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ >> >> I'd like to ask the WG (again) to consider adopting this a WG item. >> >> spt >> >> >> >> On 6/16/10 10:17 AM, Sean Turner wrote: >>> Greetings. Steve and I have whipped up a short I-D that specifies >>> additional methods for generating key identifiers from a public key. The >>> draft can be found at: >>> >>> http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ >>> >>> I'd like to ask the WG to consider adopting this as a WG item. >>> >>> Cheers, >>> >>> spt* >>> >>> * (with no hat on) >>> _______________________________________________ >>> 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 turners@ieca.com Tue Apr 24 05:28:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B92821F87B4 for ; Tue, 24 Apr 2012 05:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.193 X-Spam-Level: X-Spam-Status: No, score=-102.193 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKUGzKKGm0kQ for ; Tue, 24 Apr 2012 05:28:05 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.125.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0049721F8686 for ; Tue, 24 Apr 2012 05:28:04 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 7516A4375A32E; Tue, 24 Apr 2012 07:28:04 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 6ABA34375A30E for ; Tue, 24 Apr 2012 07:28:04 -0500 (CDT) Received: from [96.231.123.106] (port=47732 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SMeqf-0000Ed-2j; Tue, 24 Apr 2012 07:28:04 -0500 Message-ID: <4F969C50.2070601@ieca.com> Date: Tue, 24 Apr 2012 08:28:00 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Manger, James H" References: <20120423183151.1989.87952.idtracker@ietfa.amsl.com> <4F95A1A4.5060209@ieca.com> <255B9BB34FB7D647A506DC292726F6E114F0C4080F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114F0C4080F@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-123-106.washdc.east.verizon.net (thunderfish.local) [96.231.123.106]:47732 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 12 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "pkix@ietf.org" Subject: Re: [pkix] Fwd: I-D Action: draft-turner-additional-methods-4kis-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 12:28:05 -0000 James, Thanks for the review. Comments inline. spt On 4/23/12 11:15 PM, Manger, James H wrote: >> Title : Additional Methods for Generating Key Identifiers >> Filename : draft-turner-additional-methods-4kis-04.txt > > Using a more recent hash alg than SHA-1 to generate key ids sounds fine. > > Keeping the 160-bit size "to avoid adversely affecting relying party code" sounds strange. RFC5280 already recommends 2 methods with different lengths (160-bit and 64-bit) so relying party code better handle that. Perhaps using a size no longer than 160-bit is nice (so it takes no more space in a database field, for instance). Since we are truncating the hashes in all the new algs, why not truncate to something shorter? 64-bits would be a good choice (matching the shorter existing recommended method). We could even set the first 4 bits to 0101, 0110, 0111, 1000 for the 4 new methods so it matches the existing recommendation even more closely. Okay I struck "to avoid ...". My primary reason for picking the 160-bit truncated length was that in sidr there was some discussion about what the output lengths would be if the alg to generate the key identifier was from the SHA2 family. Some of the implementers seemed to like the idea of having it documented and fixed to the same length as the 160-bit truncated SHA-1 example in 5280 (which is what they use now). I realize that they could define any old method they wanted in their drafts, but this has come up a couple of times for me and I just wanted to document something so that it could be referenced. Given the above, I don't want to remove the 160-bit truncated versions, but I don't have any problem adding the 64-bit methods you describe. Remember these are just listing some example methods - implementers are free to do these or not. Sound like a plan? > What is the reason for having a certificate extension to describe how a key id is generated? > I don't think the draft gives any reason. I added it because there was some discussion on the list about it - granted it was like 2 years ago. Some folks were on about it here: https://www.ietf.org/mail-archive/web/pkix/current/msg27849.html I'll add some wording after I've run it by my co-author. > The kiLength field seems pointless. You can look at the actual key id (also in the cert) to get its length. I think you're right here and I'll remove kiLength. > A kiHashInput value of id-subjectPublicKey seems to mean the same thing as the kiHashInput field being absent. Two ways to say the same thing is bad. Ah that should have been id-subjectPublicKeyInfo which is different than just the key because it includes alg id/parameters. From rstruik.ext@gmail.com Tue Apr 24 06:31:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB8121F8802 for ; Tue, 24 Apr 2012 06:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dsy3e7lbxiaA for ; Tue, 24 Apr 2012 06:31:45 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B329221F87EE for ; Tue, 24 Apr 2012 06:31:42 -0700 (PDT) Received: by iazz13 with SMTP id z13so1282661iaz.31 for ; Tue, 24 Apr 2012 06:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=nSAkNJWK5oUMOf1+SNDu67ghPxl1VywSy0N48c5dl3U=; b=oqP6uFPmsmBvzBxd74G8eYrjrnyt0jUa7nh2+8KxLtFj0kvls7nKI/gF3HHfQJVmHq yJd4h9XpaziFNP2xU09Rd/sbiJbIHrlP+gSwrL7CHSpF4xhxVz/lvDfekrZW+MIi1jD3 FtV8I+eENBZd2X5doCXLbY5xC0TRKDoXLC6kh0nvhG29mLKhZDQDmYUoSBGZSmOtdztd oASM4MURUUaK12+HnpTpJfWljeUy/eqliJyUTaDYKY5YNSrKEZjAANnRwr7v2B56G5qV bZujNoUBFUYcxqxJwXS/4cRPDeIGrAnZeY5RqYtxVPzFHRzKjAHBPv5F7XTPdBRMISao T4kA== Received: by 10.50.51.134 with SMTP id k6mr10153970igo.47.1335274301617; Tue, 24 Apr 2012 06:31:41 -0700 (PDT) Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [72.138.34.10]) by mx.google.com with ESMTPS id gb4sm3544628igc.1.2012.04.24.06.31.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 06:31:40 -0700 (PDT) Message-ID: <4F96AB39.4060600@gmail.com> Date: Tue, 24 Apr 2012 09:31:37 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Sean Turner References: <4C18DCF2.2030703@ieca.com> <4F95BB92.6080206@ieca.com> <4F95CDCE.4080109@gmail.com> <4F96897A.7020906@ieca.com> In-Reply-To: <4F96897A.7020906@ieca.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Possible new work item: additional methods for generating key identifiers X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 13:31:46 -0000 Hi Sean: Thanks for the feedback. Your feedback seems more procedural (since you refer to SHOULD language in RFC 5280. My comment was more technical (granted - it did not look at your write-up in the context of RFC5280). draft-turner-additional-methods-4kis-03, Section 1, first para suggests the following: These key identifiers are used by PKI-enabled security protocols, such as CMP (Certificate Management Protocol) [RFC4210] and CMS (Cryptographic Message Syntax) [RFC5652], to identify the certificate used to protect a message, a session, etc. If so, referring to the same public key in different policy context via the same identifier does not seem to serve the purpose. After all, if one has CertCA(IdA, Qa, Valid0) and CertCA(IdA,Qa,Valid1), how can one identify which of these two certificates to use if the key identifier only depends on the common part of both certs? To me, a key identifier identifies a key and associated keying information that is bound to it. I do agree it is hard to enforce uniqueness of identifiers (but that is true for any requirement in a specification, even if one would use SHALL language). Best regards, Rene On 24/04/2012 7:07 AM, Sean Turner wrote: > Rene, > > Thanks for reviewing. Comments inline. > > spt > > On 4/23/12 5:46 PM, Rene Struik wrote: >> Hi Sean: >> >> You defined the key identifier to be the hash of the public key, >> truncated to 160 bits. > > There's two parts of this draft: > > - Describing methods for generating a key identifier that are the same > as one of the example methods in 5280 except they ones in the draft > use the SHA2 algs. > > - Defining an extension to allow CAs to indicate the alg used to > compute they key identifier, the input to the hash alg, and the output > length. > >> Shouldn't one have different key identifiers if >> the policy fields assoicated with the public key are different (e.g., if >> the same public key Qa associated with some entity A gets rolled over >> and assigned a new validity period)? > > If I'm reading RFC 5280 correctly, then I think it might go against it: > > Where a key identifier has been previously established, > the CA SHOULD use the previously established identifier. > >> Similarly, shouldn't one include >> the unique id of the presumed key holder (e.g.,so as to preclude people >> cloning a public/private key pair to another device [I am sure >> implementers contemplating this exist] without notice)? > > I'm certainly not precluding anybody from using whatever they want as > an input to hash alg used to generate the key identifiers. I'm just > listing some additional methods. > > To play devil's advocate here, I can already see the questions on this > one: how do you know the identifier for the key holder is unique. > >> Best regards, Rene >> >> On 23/04/2012 4:29 PM, Sean Turner wrote: >>> >>> >>> I've resurrected this draft after making some changes/additions to it >>> based on mailing list comments. The latest version can be found at: >>> >>> http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ >>> >>> I'd like to ask the WG (again) to consider adopting this a WG item. >>> >>> spt >>> >>> >>> >>> On 6/16/10 10:17 AM, Sean Turner wrote: >>>> Greetings. Steve and I have whipped up a short I-D that specifies >>>> additional methods for generating key identifiers from a public >>>> key. The >>>> draft can be found at: >>>> >>>> http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ >>>> >>>> I'd like to ask the WG to consider adopting this as a WG item. >>>> >>>> Cheers, >>>> >>>> spt* >>>> >>>> * (with no hat on) >>>> _______________________________________________ >>>> 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 >> >> -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From turners@ieca.com Tue Apr 24 09:22:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F156421E804A for ; Tue, 24 Apr 2012 09:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.897 X-Spam-Level: X-Spam-Status: No, score=-101.897 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_63=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fMCB955YDmG for ; Tue, 24 Apr 2012 09:22:57 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.81.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0A50921E8048 for ; Tue, 24 Apr 2012 09:22:57 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 6CDB84652B38E; Tue, 24 Apr 2012 11:22:56 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 57FAE4652B334 for ; Tue, 24 Apr 2012 11:22:56 -0500 (CDT) Received: from [96.231.123.106] (port=43677 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SMiVy-00065Z-U7; Tue, 24 Apr 2012 11:22:56 -0500 Message-ID: <4F96D35D.2060305@ieca.com> Date: Tue, 24 Apr 2012 12:22:53 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Rene Struik References: <4C18DCF2.2030703@ieca.com> <4F95BB92.6080206@ieca.com> <4F95CDCE.4080109@gmail.com> <4F96897A.7020906@ieca.com> <4F96AB39.4060600@gmail.com> In-Reply-To: <4F96AB39.4060600@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-123-106.washdc.east.verizon.net (thunderfish.local) [96.231.123.106]:43677 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: pkix@ietf.org Subject: Re: [pkix] Possible new work item: additional methods for generating key identifiers X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 16:22:58 -0000 On 4/24/12 9:31 AM, Rene Struik wrote: > Hi Sean: > > Thanks for the feedback. Your feedback seems more procedural (since you > refer to SHOULD language in RFC 5280. My comment was more technical > (granted - it did not look at your write-up in the context of RFC5280). > > draft-turner-additional-methods-4kis-03, Section 1, first para suggests > the following: > > These key identifiers are used by PKI-enabled security protocols, > such as CMP (Certificate Management Protocol) [RFC4210] and CMS > (Cryptographic Message Syntax) [RFC5652], > to identify the certificate used to protect a message, a session, etc. > > If so, referring to the same public key in different policy context via > the same identifier does not seem to serve the purpose. After all, if > one has CertCA(IdA, Qa, Valid0) and CertCA(IdA,Qa,Valid1), how can one > identify which of these two certificates to use if the key identifier > only depends on the common part of both certs? Ah so if the entity that holds both of CertCA's certs is doing the signing/encrypting - it usually includes the certificate in the protocol. So, it's really just helping the recipient figure out which one of the certs in the certs bag to start with. In the general case, if an EE only has one key and the CA has two valid certificates, then the RP is going to use which ever path works and it might have to check both. > To me, a key identifier identifies a key and associated keying > information that is bound to it. Isn't that a certificate? ;) But, I'm not trying to redefine what a key identifier is. I'm just going with what RFC 5280 says in s4.2.1.1 and s4.2.1.2. spt > I do agree it is hard to enforce uniqueness of identifiers (but that is > true for any requirement in a specification, even if one would use SHALL > language). > > Best regards, Rene > > > On 24/04/2012 7:07 AM, Sean Turner wrote: >> Rene, >> >> Thanks for reviewing. Comments inline. >> >> spt >> >> On 4/23/12 5:46 PM, Rene Struik wrote: >>> Hi Sean: >>> >>> You defined the key identifier to be the hash of the public key, >>> truncated to 160 bits. >> >> There's two parts of this draft: >> >> - Describing methods for generating a key identifier that are the same >> as one of the example methods in 5280 except they ones in the draft >> use the SHA2 algs. >> >> - Defining an extension to allow CAs to indicate the alg used to >> compute they key identifier, the input to the hash alg, and the output >> length. >> >>> Shouldn't one have different key identifiers if >>> the policy fields assoicated with the public key are different (e.g., if >>> the same public key Qa associated with some entity A gets rolled over >>> and assigned a new validity period)? >> >> If I'm reading RFC 5280 correctly, then I think it might go against it: >> >> Where a key identifier has been previously established, >> the CA SHOULD use the previously established identifier. >> >>> Similarly, shouldn't one include >>> the unique id of the presumed key holder (e.g.,so as to preclude people >>> cloning a public/private key pair to another device [I am sure >>> implementers contemplating this exist] without notice)? >> >> I'm certainly not precluding anybody from using whatever they want as >> an input to hash alg used to generate the key identifiers. I'm just >> listing some additional methods. >> >> To play devil's advocate here, I can already see the questions on this >> one: how do you know the identifier for the key holder is unique. >> >>> Best regards, Rene >>> >>> On 23/04/2012 4:29 PM, Sean Turner wrote: >>>> >>>> >>>> I've resurrected this draft after making some changes/additions to it >>>> based on mailing list comments. The latest version can be found at: >>>> >>>> http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ >>>> >>>> I'd like to ask the WG (again) to consider adopting this a WG item. >>>> >>>> spt >>>> >>>> >>>> >>>> On 6/16/10 10:17 AM, Sean Turner wrote: >>>>> Greetings. Steve and I have whipped up a short I-D that specifies >>>>> additional methods for generating key identifiers from a public >>>>> key. The >>>>> draft can be found at: >>>>> >>>>> http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ >>>>> >>>>> I'd like to ask the WG to consider adopting this as a WG item. >>>>> >>>>> Cheers, >>>>> >>>>> spt* >>>>> >>>>> * (with no hat on) >>>>> _______________________________________________ >>>>> 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 rstruik.ext@gmail.com Tue Apr 24 09:45:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BD921E8089 for ; Tue, 24 Apr 2012 09:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NvT4cx3B+4Q for ; Tue, 24 Apr 2012 09:45:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA05821E8088 for ; Tue, 24 Apr 2012 09:45:38 -0700 (PDT) Received: by iazz13 with SMTP id z13so1532447iaz.31 for ; Tue, 24 Apr 2012 09:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=HDrkRpPDG70XRiSNBBMNsMDm5imAhmZJEND+M18rc8k=; b=UjgZhm68q5XIwWvV2ifJHPgzLNNobqEeDUSPwXc4yp7S6UOtUftomtYMWGhF7aKrnY YcTW9LE02wCkQxJo0c8Pl8GSWaqjuRgLcO28UslmrtlJuux0rgWN5oc11l4ZVhk4T/+p s08ZWg4D9wgKttZRIHiTpeN15B8YGIz2Wpl03ssxc220hou+uUCX3ApDT1vdQnobNL02 Wdcl9jJ6+/JlFtY/u1RxoMxqH8JfBagYQTbnokbUPF1gS9eFxHw+X3rxgB0AdUa7N8lD D56jjpu8moz3XzMstOCC3rI24x8zZ8tO1vvFQohVWdXIy/fMCcV9DYFVjJcDYTyAq1G9 k6IQ== Received: by 10.50.45.231 with SMTP id q7mr11044270igm.42.1335285938220; Tue, 24 Apr 2012 09:45:38 -0700 (PDT) Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [72.138.34.10]) by mx.google.com with ESMTPS id hq3sm37738425igc.0.2012.04.24.09.45.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 09:45:37 -0700 (PDT) Message-ID: <4F96D8A9.8050109@gmail.com> Date: Tue, 24 Apr 2012 12:45:29 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Sean Turner References: <4C18DCF2.2030703@ieca.com> <4F95BB92.6080206@ieca.com> <4F95CDCE.4080109@gmail.com> <4F96897A.7020906@ieca.com> <4F96AB39.4060600@gmail.com> <4F96D35D.2060305@ieca.com> In-Reply-To: <4F96D35D.2060305@ieca.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Possible new work item: additional methods for generating key identifiers X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 16:45:39 -0000 Hi Sean: On 24/04/2012 12:22 PM, Sean Turner wrote: > On 4/24/12 9:31 AM, Rene Struik wrote: >> Hi Sean: >> >> Thanks for the feedback. Your feedback seems more procedural (since you >> refer to SHOULD language in RFC 5280. My comment was more technical >> (granted - it did not look at your write-up in the context of RFC5280). >> >> draft-turner-additional-methods-4kis-03, Section 1, first para suggests >> the following: >> >> These key identifiers are used by PKI-enabled security protocols, >> such as CMP (Certificate Management Protocol) [RFC4210] and CMS >> (Cryptographic Message Syntax) [RFC5652], >> to identify the certificate used to protect a message, a >> session, etc. >> >> If so, referring to the same public key in different policy context via >> the same identifier does not seem to serve the purpose. After all, if >> one has CertCA(IdA, Qa, Valid0) and CertCA(IdA,Qa,Valid1), how can one >> identify which of these two certificates to use if the key identifier >> only depends on the common part of both certs? > > Ah so if the entity that holds both of CertCA's certs is doing the > signing/encrypting - it usually includes the certificate in the > protocol. So, it's really just helping the recipient figure out which > one of the certs in the certs bag to start with. > > In the general case, if an EE only has one key and the CA has two > valid certificates, then the RP is going to use which ever path works > and it might have to check both. > RS>> Hence, my suggestion, which would avoid having to check more than one option. <> To me, a key identifier identifies a key and associated keying >> information that is bound to it. > > Isn't that a certificate? ;) But, I'm not trying to redefine what a > key identifier is. I'm just going with what RFC 5280 says in s4.2.1.1 > and s4.2.1.2. > RS>> Usually, keying material takes the form (key, associated keying info), where the associated keying info was not created in a vacuum: it supposedly stipulates something about the key itself: key validity period, key usage, key originator, key owner, etc. Thus, my reference to "bound to it" (maybe, I should have written "[supposedly] bound to it"). With certs, one has the CA vouching for the binding of the key to other attributes via a signature, but there could be other mechanisms to attest to a binding (including attesting to this via symmetric key techniques or by just imprinting the keying material onto a device). < spt > >> I do agree it is hard to enforce uniqueness of identifiers (but that is >> true for any requirement in a specification, even if one would use SHALL >> language). >> >> Best regards, Rene >> >> >> On 24/04/2012 7:07 AM, Sean Turner wrote: >>> Rene, >>> >>> Thanks for reviewing. Comments inline. >>> >>> spt >>> >>> On 4/23/12 5:46 PM, Rene Struik wrote: >>>> Hi Sean: >>>> >>>> You defined the key identifier to be the hash of the public key, >>>> truncated to 160 bits. >>> >>> There's two parts of this draft: >>> >>> - Describing methods for generating a key identifier that are the same >>> as one of the example methods in 5280 except they ones in the draft >>> use the SHA2 algs. >>> >>> - Defining an extension to allow CAs to indicate the alg used to >>> compute they key identifier, the input to the hash alg, and the output >>> length. >>> >>>> Shouldn't one have different key identifiers if >>>> the policy fields assoicated with the public key are different >>>> (e.g., if >>>> the same public key Qa associated with some entity A gets rolled over >>>> and assigned a new validity period)? >>> >>> If I'm reading RFC 5280 correctly, then I think it might go against it: >>> >>> Where a key identifier has been previously established, >>> the CA SHOULD use the previously established identifier. >>> >>>> Similarly, shouldn't one include >>>> the unique id of the presumed key holder (e.g.,so as to preclude >>>> people >>>> cloning a public/private key pair to another device [I am sure >>>> implementers contemplating this exist] without notice)? >>> >>> I'm certainly not precluding anybody from using whatever they want as >>> an input to hash alg used to generate the key identifiers. I'm just >>> listing some additional methods. >>> >>> To play devil's advocate here, I can already see the questions on this >>> one: how do you know the identifier for the key holder is unique. >>> >>>> Best regards, Rene >>>> >>>> On 23/04/2012 4:29 PM, Sean Turner wrote: >>>>> >>>>> >>>>> I've resurrected this draft after making some changes/additions to it >>>>> based on mailing list comments. The latest version can be found at: >>>>> >>>>> http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ >>>>> >>>>> I'd like to ask the WG (again) to consider adopting this a WG item. >>>>> >>>>> spt >>>>> >>>>> >>>>> >>>>> On 6/16/10 10:17 AM, Sean Turner wrote: >>>>>> Greetings. Steve and I have whipped up a short I-D that specifies >>>>>> additional methods for generating key identifiers from a public >>>>>> key. The >>>>>> draft can be found at: >>>>>> >>>>>> http://datatracker.ietf.org/doc/draft-turner-additional-methods-4kis/ >>>>>> >>>>>> >>>>>> I'd like to ask the WG to consider adopting this as a WG item. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> spt* >>>>>> >>>>>> * (with no hat on) >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >> >> -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From tgindin@us.ibm.com Tue Apr 24 17:09:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB6911E80BB for ; Tue, 24 Apr 2012 17:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FyBcEUIGw-v for ; Tue, 24 Apr 2012 17:09:15 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by ietfa.amsl.com (Postfix) with ESMTP id 95FAF11E80B3 for ; Tue, 24 Apr 2012 17:09:07 -0700 (PDT) Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 24 Apr 2012 18:09:07 -0600 Received: from d01dlp03.pok.ibm.com (9.56.224.17) by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 24 Apr 2012 18:09:06 -0600 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id BB5C4C90057 for ; Tue, 24 Apr 2012 20:09:03 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3P095TP100032 for ; Tue, 24 Apr 2012 20:09:05 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3P5dvem009933 for ; Wed, 25 Apr 2012 01:39:57 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3P5dvKn009925; Wed, 25 Apr 2012 01:39:57 -0400 In-Reply-To: <4F95A1A4.5060209@ieca.com> References: <20120423183151.1989.87952.idtracker@ietfa.amsl.com> <4F95A1A4.5060209@ieca.com> To: Sean Turner MIME-Version: 1.0 X-KeepSent: 5CC0BE81:37CF218D-852579EA:0077CA87; type=4; name=$KeepSent X-Mailer: Lotus Notes Build V853_CD5_06022011 June 02, 2011 From: Tom Gindin Message-ID: Date: Tue, 24 Apr 2012 20:09:04 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/24/2012 20:09:03, Serialize complete at 04/24/2012 20:09:03 Content-Type: text/plain; charset="US-ASCII" X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12042500-3352-0000-0000-00000440AA2E Cc: pkix@ietf.org Subject: Re: [pkix] Fwd: I-D Action: draft-turner-additional-methods-4kis-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 00:09:15 -0000 RFC 5280 section 4.2.1.2 suggests using the public key, not the private, as does the same section in 3280 and 2459. I'm not sure why the private key would be better, and I can think of several reasons why the public key should be used as the basis for a certificate field rather than the private key. We should probably stick with the earlier approach. Tom Gindin From: Sean Turner To: pkix@ietf.org, Date: 04/23/2012 02:40 PM Subject: [pkix] Fwd: I-D Action: draft-turner-additional-methods-4kis-02.txt Sent by: pkix-bounces@ietf.org The previous version assumed that the input to the hash was always the private key. Somebody pointed out that this might not always be the case so I added a field (an OID) to indicate the semantics of the hash input. I also defined one value to indicate for SubjectpublicKeyInfo to be the input to the hash alg. spt -------- Original Message -------- Subject: I-D Action: draft-turner-additional-methods-4kis-02.txt Date: Mon, 23 Apr 2012 11:31:51 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Additional Methods for Generating Key Identifiers Author(s) : Sean Turner Stephen Kent Filename : draft-turner-additional-methods-4kis-02.txt Pages : 8 Date : 2012-04-23 This document specifies additional methods for generating key identifiers from a public key. This document also specifies an extension to identify the algorithms used to generate the key identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From turners@ieca.com Tue Apr 24 19:19:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759F621E802B for ; Tue, 24 Apr 2012 19:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMnqu-oQCzeM for ; Tue, 24 Apr 2012 19:19:54 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.125.4]) by ietfa.amsl.com (Postfix) with ESMTP id D87E621E8026 for ; Tue, 24 Apr 2012 19:19:53 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 546DD4486EF05; Tue, 24 Apr 2012 21:19:53 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 4A2C54486EEE5 for ; Tue, 24 Apr 2012 21:19:53 -0500 (CDT) Received: from [96.231.123.106] (port=42600 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SMrpg-0007kQ-Cz; Tue, 24 Apr 2012 21:19:53 -0500 Message-ID: <4F975F47.8040006@ieca.com> Date: Tue, 24 Apr 2012 22:19:51 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Tom Gindin References: <20120423183151.1989.87952.idtracker@ietfa.amsl.com> <4F95A1A4.5060209@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-123-106.washdc.east.verizon.net (thunderfish.local) [96.231.123.106]:42600 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: pkix@ietf.org Subject: Re: [pkix] Fwd: I-D Action: draft-turner-additional-methods-4kis-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 02:19:54 -0000 An amazingly bad typo on my part - should have been: The previous version assumed that the input to the hash was always the public key. spt On 4/24/12 8:09 PM, Tom Gindin wrote: > RFC 5280 section 4.2.1.2 suggests using the public key, not the > private, as does the same section in 3280 and 2459. I'm not sure why the > private key would be better, and I can think of several reasons why the > public key should be used as the basis for a certificate field rather than > the private key. We should probably stick with the earlier approach. > > Tom Gindin > > > > > > From: Sean Turner > To: pkix@ietf.org, > Date: 04/23/2012 02:40 PM > Subject: [pkix] Fwd: I-D Action: > draft-turner-additional-methods-4kis-02.txt > Sent by: pkix-bounces@ietf.org > > > > The previous version assumed that the input to the hash was always the > private key. Somebody pointed out that this might not always be the > case so I added a field (an OID) to indicate the semantics of the hash > input. I also defined one value to indicate for SubjectpublicKeyInfo to > be the input to the hash alg. > > spt > > -------- Original Message -------- > Subject: I-D Action: draft-turner-additional-methods-4kis-02.txt > Date: Mon, 23 Apr 2012 11:31:51 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Additional Methods for Generating Key > Identifiers > Author(s) : Sean Turner > Stephen Kent > Filename : > draft-turner-additional-methods-4kis-02.txt > Pages : 8 > Date : 2012-04-23 > > This document specifies additional methods for generating key > identifiers from a public key. This document also specifies an > extension to identify the algorithms used to generate the key > identifiers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-02.txt > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-turner-additional-methods-4kis-02.txt > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > > > From internet-drafts@ietf.org Wed Apr 25 11:12:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B695821F8824; Wed, 25 Apr 2012 11:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUcpKSMn3MXZ; Wed, 25 Apr 2012 11:12:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305C721F87FE; Wed, 25 Apr 2012 11:12:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120425181202.10593.16843.idtracker@ietfa.amsl.com> Date: Wed, 25 Apr 2012 11:12:02 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-caa-07.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 18:12:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource= Record Author(s) : Phillip Hallam-Baker Rob Stradling Filename : draft-ietf-pkix-caa-07.txt Pages : 16 Date : 2012-04-25 The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis- issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-caa-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-caa-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-caa/ From hallam@gmail.com Wed Apr 25 11:12:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A6221F8859 for ; Wed, 25 Apr 2012 11:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lGHkFVFzlnw for ; Wed, 25 Apr 2012 11:12:21 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8F121F8861 for ; Wed, 25 Apr 2012 11:12:20 -0700 (PDT) Received: by yenm5 with SMTP id m5so417653yen.31 for ; Wed, 25 Apr 2012 11:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mxKvgbtryETnnMzrNzBdV4XqxC4eRGUwUzt7Bc2EXXE=; b=GYRWiIEQR6QBog39UgJoMlfI+PmHfx3DLdMbByfvQS2pg4DZYiZVi28Y++qrTYYQEQ solf+KAdOliKE1k/QfQ1Vv1leAFt0E840sgZWz/H5FB7HQa9WiBWRhux/pKUjHhVW95k 22JVzpzNY4gVG+vALCK4oJyCo78SKUuXg+wfbsn3kYwOzWtnsqklvK/1TEUA3GTfamD9 Si4TboikUqXzxX+Niyu1uKI8mMQNpbZIOg8T6+65EAOikKFjAOjKhkk07zxtpMNB6+n3 D+rsft1rTfPxuuZD4gkFmIQbb0v56QpOLtkxKmXfS10mt56e7AwD/QtCctsR+XKuynC/ +BhQ== MIME-Version: 1.0 Received: by 10.60.20.38 with SMTP id k6mr4966404oee.26.1335377540369; Wed, 25 Apr 2012 11:12:20 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Wed, 25 Apr 2012 11:12:20 -0700 (PDT) In-Reply-To: <4F95B972.1090101@ieca.com> References: <4F9599C9.2090304@ieca.com> <4F95B972.1090101@ieca.com> Date: Wed, 25 Apr 2012 14:12:20 -0400 Message-ID: From: Phillip Hallam-Baker To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org, draft-ietf-pkix-caa@tools.ietf.org Subject: Re: [pkix] Early AD review of draft-ietf-pkix-caa X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 18:12:21 -0000 OK, have submitted a -07 which has these fixed On Mon, Apr 23, 2012 at 4:20 PM, Sean Turner wrote: > You're right I glossed over that. =A0It's probably something that should = be > changed through the draft. > > spt > > > On 4/23/12 4:11 PM, Erwann Abalea wrote: >> >> A CP is not a Certification Policy, but a Certificate Policy, i.e. what >> the certificate can be used for. >> >> -- >> Erwann. >> >> Le 23 avr. 2012 20:05, "Sean Turner" > > a =E9crit : >> >> =A0> >> =A0> Philip/Rod, >> =A0> >> =A0> Thanks for this update. =A0Here's my early AD comments: >> =A0> >> =A0> 1. s1.2: Maybe add an informative reference to RFC 3647 in the CP/C= PS >> definitions. >> =A0> >> =A0> =A0Certification Policy (CP) =A0Specifies the criteria that a >> =A0> =A0 =A0 =A0Certification Authority undertakes to meet in its issue = of >> =A0> =A0 =A0 =A0certificates. =A0See [RFC3647]. >> =A0> >> =A0> =A0 Certification Practices Statement (CPS) =A0Specifies the means = by which >> =A0> =A0 =A0 =A0the criteria of the Certification Policy are met. =A0In = most cases >> =A0> =A0 =A0 =A0this will be the document against which the operations o= f the >> =A0> =A0 =A0 =A0Certification Authority are audited. =A0See [RFC3647]. >> > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --=20 Website: http://hallambaker.com/ From housley@vigilsec.com Wed Apr 25 12:56:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1797921F88E7 for ; Wed, 25 Apr 2012 12:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.925 X-Spam-Level: X-Spam-Status: No, score=-101.925 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQ0OAXdRbU0y for ; Wed, 25 Apr 2012 12:56:38 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA9121F87D6 for ; Wed, 25 Apr 2012 12:56:38 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 7204FF2403E; Wed, 25 Apr 2012 15:25:37 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id mRNvIiTuo8UC; Wed, 25 Apr 2012 15:25:25 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-140-3.washdc.fios.verizon.net [96.255.140.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 59C1EF24040; Wed, 25 Apr 2012 15:25:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <016401cd227d$49c3af70$dd4b0e50$@augustcellars.com> Date: Wed, 25 Apr 2012 08:36:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0941B33A-54BB-43A1-9DFC-415A1E2DDAAA@vigilsec.com> References: <20120424094548.20531.28695.idtracker@ietfa.amsl.com> <016401cd227d$49c3af70$dd4b0e50$@augustcellars.com> To: IETF PKIX X-Mailer: Apple Mail (2.1084) Cc: Jim Schaad Subject: [pkix] Two Comments on draft-ietf-pkix-pubkey-caps-05 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:56:39 -0000 I am raising two non-blocking comments on = draft-ietf-pkix-pubkey-caps-05. (1) First comment: My comment: >> Should the capabilities in section 3.1 provide an optional way to >> specify sizes of P, Q, and G that are supported? >>=20 >> Similarly, should the capabilities in section 3.2 provide an = optional >> way to specify sizes of P and G that are supported? Jim's initial response: > I wish that you had brought this issue up when the document was still = in the working group. Please post a message to this effect to the = working group with a rational for why you believe that this is something = that should be done. My first blush impression is that for 3.1 the = response would be no as these sizes are generally fixed by the NIST = documents that cover the different sizes of DSA. >=20 > It might be useful for 3.2, but in general I don't believe that it = would generally be used. Do you have a situation where you think it = might be of importance? My reply to Jim's initial response: I am aware of hardware implementation that have limitations on the size = of these parameters. So, the reason for sizes here is the same as the = reason for RSA key sizes. (2) Second comment: My comment: >> In Section 4.1 and 4.2 and 4.3, I suggest a list of named curves >> instead of the very rich structure that is currently specified. >> Several other documents have taken this approach. Any popular curve >> can be assigned an object identifier to name it. Jim's initial response: > The current text effectively does this in the same way that PKIX = certificates do this. The text states that only the namedCurve option = of the ECParameters structure is going to be used. Do believe that this = is not sufficient? My reply to Jim's initial response: I do not think the current text does this. It says: | | ... As specified in [RFC3279], for PKIX compliant | certificates only the namedCurve choice of ECParameters is | expected to be used. | This does not say that only namedCurve is permitted. This says to me = that is the normal case, but be prepared to receive the others. Russ= From prvs=5462b7e9e1=atruskovsky@rim.com Wed Apr 25 15:34:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CC821F87F7 for ; Wed, 25 Apr 2012 15:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs6q-lpVqUBd for ; Wed, 25 Apr 2012 15:34:42 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id AC41E21F87CD for ; Wed, 25 Apr 2012 15:34:38 -0700 (PDT) X-AuditID: 0a41282f-b7f606d000000ca3-0d-4f987bfd378a Received: from XCT104CNC.rim.net (smtp-pop.rim.net [10.65.161.204]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 60.6D.03235.DFB789F4; Wed, 25 Apr 2012 22:34:37 +0000 (GMT) Received: from XMB108FCNC.rim.net ([fe80::b582:c49b:f967:ac82]) by XCT104CNC.rim.net ([fe80::bd22:1ec5:27cc:e392%17]) with mapi id 14.01.0339.001; Wed, 25 Apr 2012 18:34:37 -0400 From: Alexander Truskovsky To: "pritikin@cisco.com" , "pkix@ietf.org" Thread-Topic: Some comments on draft-ietf-pkix-est-01 Thread-Index: Ac0jM5f91gsgWogcTL6JKfpyjii2ZQ== Date: Wed, 25 Apr 2012 22:34:36 +0000 Message-ID: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsXC5bjwjO7f6hn+Bv+Wa1tcPFhk8XvnI3YH Jo8pvzeyeixZ8pMpgCmqgdEmKbGkLDgzPU/fziYxLy+/JLEkVSEltTjZVsknNT0xRyGgKLMs MblSwSWzODknMTM3tUhJITPFVslESaEgJzE5NTc1r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl 56dk5qXbKnkG++taWJha6hoq2ekmdPJkbJy9ibXgG0/Fwx832RoYV3J1MXJwSAiYSCx+qd3F yAlkiklcuLeeDcQWEuhlkrh0rb6LkQvI3sYo8ePafLAEm4CBRNfhl2C2iICfxPvfIA0cHMwC HhJnP9uCmMJAJUteRkBUmErsP7KdHcLWk1iy7TIjiM0ioCox48kKVhCbV8BT4tG+C2A1jAKy EmvnrASLMwuIS9x6Mp8J4jQBiSV7zjND2KISLx//Y4WwFSWenLzGAlGvJ3Fj6hQ2CFtbYtnC 18wQ8wUlTs58wjKBUWQWkrGzkLTMQtIyC0nLAkaWVYyCuRnFBmYGyXnJekWZuXp5qSWbGMHx rqG/g7Fvr9YhRgEORiUe3vD8Gf5CrIllxZW5hxglOJiVRHi9PIFCvCmJlVWpRfnxRaU5qcWH GC2Avp/ILMWdnA9MRXkl8cYGBigcJXHe6Nu1/kIC6cAkkp2aWpBaBNPKxMEJMppLSqQYmApS ixJLSzLiQQkrvhiYsqQaGMM/RWUxTDr013dVwXmrhe6aAXdWhv8omGnDNfF9kA+3RMCbzov8 nx9NaUjK+sQqNPHhoXIXzz05sfeyf/a7tfckrG5jMjlqqqHHdG0p/5725DrxPWEynNcjn1a1 lJmH+Tml3fb+777lfPz5oDVZbrVbzLJbRJtK9cs9M+NarD+dUjz3QOqOEktxRqKhFnNRcSIA XWCJ7SsDAAA= Cc: Chris Bender Subject: [pkix] Some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 22:34:43 -0000 Max, I have been implementing the current SCEP draft, and have come across severa= l issues that we are glad to see addressed in EST, specifically: 1) The use of a certificate issued by another PKI to authenticate the initia= l request is optional in SCEP.=A0 This is now a MUST requirement in EST (A3)= . 2) The GetCACaps response is not signed in SCEP.=A0 This is not a problem in= EST because of the TLS use. 3) The SCEP draft mentions that RSA is the only algorithm supported by the c= urrent implementations.=A0 Although there is no technical limitation that pr= events the usage of ECC in SCEP and some implementations do support ECC, we= are glad to see that algorithm agility is a MUST requirement in EST (K1). EST is a specification we would also consider deploying.=A0 There is an addi= tional use case we would like to see supported by EST. When renewing an ema= il protection certificate, it cannot be used to authenticate the request usi= ng the TLS client authentication.=A0 Although this can be achieved by using= a full CMC operation, it would be better if it were handled by plain EST.= =A0 Wrapping the PKCS10 in PKCS7 and signing it with the email protection ke= y would work without having to use a full CMC operation. We think the use of TLS client authentication, although elegant, makes it in= convenient to use in some cases because a full CMC operation needs to be use= d.=A0 We propose to continue using PKCS7 to wrap the PKCS10 to support this= and similar use cases. Thanks for your consideration, =A0=A0 Alex Alexander Truskovsky BlackBerry OS Security | Research In Motion --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From pritikin@cisco.com Wed Apr 25 16:31:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9888121E808B for ; Wed, 25 Apr 2012 16:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBnZh1bSBCCT for ; Wed, 25 Apr 2012 16:31:24 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BF5CA21E808C for ; Wed, 25 Apr 2012 16:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=3269; q=dns/txt; s=iport; t=1335396683; x=1336606283; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=maB4RCWRK+H3fvdTWF/HHiuEVI2YLZ/gRGTOyymUrng=; b=jkuX/XNG4g+djET/k7ghorB4DRM6EP0NPZH0dGB/o1cSiGK3JlgJ0VcE /QDiIL2ywcuPQEKf88T2YJ82WEOw/DIEV9c0rBbzby5S62a7qwTZrh6zV Yl7DXI7+V/q5XqVi+/8XE1a/FmEGJi2AwWtliGdXbSQ/1J8YC5drwSd5D o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIGAOSImE+rRDoJ/2dsb2JhbAA8CYMdrjGBB4IJAQEBAwESAWYFCwsOOFcGNYdoBJs8oBGKdYUIYwSIY40YhXSIYYFpgwiBPQ X-IronPort-AV: E=Sophos;i="4.75,483,1330905600"; d="scan'208";a="39075332" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 25 Apr 2012 23:31:23 +0000 Received: from [10.21.0.86] ([10.21.0.86]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3PNVMNe029898; Wed, 25 Apr 2012 23:31:23 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Max Pritikin In-Reply-To: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> Date: Wed, 25 Apr 2012 17:19:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <804932ED-5A3F-4776-AE05-A81683BE654E@cisco.com> References: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> To: Alexander Truskovsky X-Mailer: Apple Mail (2.1257) Cc: "pkix@ietf.org" , Chris Bender Subject: Re: [pkix] Some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 23:31:24 -0000 Thank you for the feedback on EST (and SCEP).=20 In regards for your request for EST functionality: I agree that dealing with clients that can't use their certificates for = digitalSignature is a problem -- but doesn't the same problem exist if = the client's key usage is such that they shouldn't be signing PKCS7/CMS = either?=20 "CMC provides a method to prove the client's identity based on a = client/server shared-secret" [RFC5272] ... but I don't believe it = provides an exception to the problem you're discussing. Is there general interest in finding another approach? I've hesitated to = suggest an exception to the RFC5280 key usage restrictions but haven't = been able to think of a different approach.=20 Do you have any suggestions? It is very possible I'm missing something, - max On Apr 25, 2012, at 4:34 PM, Alexander Truskovsky wrote: > Max, >=20 > I have been implementing the current SCEP draft, and have come across = several issues that we are glad to see addressed in EST, specifically: >=20 > 1) The use of a certificate issued by another PKI to authenticate the = initial request is optional in SCEP. This is now a MUST requirement in = EST (A3). > 2) The GetCACaps response is not signed in SCEP. This is not a = problem in EST because of the TLS use. > 3) The SCEP draft mentions that RSA is the only algorithm supported by = the current implementations. Although there is no technical limitation = that prevents the usage of ECC in SCEP and some implementations do = support ECC, we are glad to see that algorithm agility is a MUST = requirement in EST (K1). >=20 > EST is a specification we would also consider deploying. There is an = additional use case we would like to see supported by EST. When = renewing an email protection certificate, it cannot be used to = authenticate the request using the TLS client authentication. Although = this can be achieved by using a full CMC operation, it would be better = if it were handled by plain EST. Wrapping the PKCS10 in PKCS7 and = signing it with the email protection key would work without having to = use a full CMC operation. >=20 > We think the use of TLS client authentication, although elegant, makes = it inconvenient to use in some cases because a full CMC operation needs = to be used. We propose to continue using PKCS7 to wrap the PKCS10 to = support this and similar use cases. >=20 > Thanks for your consideration, > Alex >=20 >=20 > Alexander Truskovsky > BlackBerry OS Security | Research In Motion >=20 >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. From pritikin@cisco.com Wed Apr 25 16:34:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC83021E808E for ; Wed, 25 Apr 2012 16:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRvTtZAp3VA1 for ; Wed, 25 Apr 2012 16:34:48 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A406F21E8088 for ; Wed, 25 Apr 2012 16:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=3269; q=dns/txt; s=iport; t=1335396888; x=1336606488; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=maB4RCWRK+H3fvdTWF/HHiuEVI2YLZ/gRGTOyymUrng=; b=JZq+a88PtUU7rOwZ3QDcasaRZW3ri6Gzsbcoixb0vimTkHyaLzSUop9o oJlhxXpCnaQOhseEy8lh7+N7WNqthVcBv/Yh2wRpKG6TRuI6fNpx/OyqT TPn0ftGd8VF+H/2sC6vLkzaF7hpWHgOo9iZ8umhNInwqBIfV5rw1Oa3tC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIGAOSImE+rRDoG/2dsb2JhbAA8CYMdrjGBB4IJAQEBAwESAWYFCwsOOFcGNYdoBJs8oBGKdYUIYwSIY40YhXSIYYFpgwiBPQ X-IronPort-AV: E=Sophos;i="4.75,483,1330905600"; d="scan'208";a="42190570" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 25 Apr 2012 23:34:43 +0000 Received: from [10.21.0.86] ([10.21.0.86]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3PNYgNf026699; Wed, 25 Apr 2012 23:34:43 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Max Pritikin In-Reply-To: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> Date: Wed, 25 Apr 2012 17:19:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <804932ED-5A3F-4776-AE05-A81683BE654E@cisco.com> References: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> To: Alexander Truskovsky X-Mailer: Apple Mail (2.1257) Cc: "pkix@ietf.org" , Chris Bender Subject: Re: [pkix] Some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 23:34:49 -0000 Thank you for the feedback on EST (and SCEP).=20 In regards for your request for EST functionality: I agree that dealing with clients that can't use their certificates for = digitalSignature is a problem -- but doesn't the same problem exist if = the client's key usage is such that they shouldn't be signing PKCS7/CMS = either?=20 "CMC provides a method to prove the client's identity based on a = client/server shared-secret" [RFC5272] ... but I don't believe it = provides an exception to the problem you're discussing. Is there general interest in finding another approach? I've hesitated to = suggest an exception to the RFC5280 key usage restrictions but haven't = been able to think of a different approach.=20 Do you have any suggestions? It is very possible I'm missing something, - max On Apr 25, 2012, at 4:34 PM, Alexander Truskovsky wrote: > Max, >=20 > I have been implementing the current SCEP draft, and have come across = several issues that we are glad to see addressed in EST, specifically: >=20 > 1) The use of a certificate issued by another PKI to authenticate the = initial request is optional in SCEP. This is now a MUST requirement in = EST (A3). > 2) The GetCACaps response is not signed in SCEP. This is not a = problem in EST because of the TLS use. > 3) The SCEP draft mentions that RSA is the only algorithm supported by = the current implementations. Although there is no technical limitation = that prevents the usage of ECC in SCEP and some implementations do = support ECC, we are glad to see that algorithm agility is a MUST = requirement in EST (K1). >=20 > EST is a specification we would also consider deploying. There is an = additional use case we would like to see supported by EST. When = renewing an email protection certificate, it cannot be used to = authenticate the request using the TLS client authentication. Although = this can be achieved by using a full CMC operation, it would be better = if it were handled by plain EST. Wrapping the PKCS10 in PKCS7 and = signing it with the email protection key would work without having to = use a full CMC operation. >=20 > We think the use of TLS client authentication, although elegant, makes = it inconvenient to use in some cases because a full CMC operation needs = to be used. We propose to continue using PKCS7 to wrap the PKCS10 to = support this and similar use cases. >=20 > Thanks for your consideration, > Alex >=20 >=20 > Alexander Truskovsky > BlackBerry OS Security | Research In Motion >=20 >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. From James.H.Manger@team.telstra.com Wed Apr 25 22:38:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8865021F89C6 for ; Wed, 25 Apr 2012 22:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0f-SxnjxSE6 for ; Wed, 25 Apr 2012 22:38:28 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id B09ED21F8901 for ; Wed, 25 Apr 2012 22:38:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,484,1330866000"; d="scan'208";a="70516301" Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipocni.tcif.telstra.com.au with ESMTP; 26 Apr 2012 15:38:23 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6692"; a="58838580" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcdni.tcif.telstra.com.au with ESMTP; 26 Apr 2012 15:38:23 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Thu, 26 Apr 2012 15:38:23 +1000 From: "Manger, James H" To: Sean Turner Date: Thu, 26 Apr 2012 15:38:22 +1000 Thread-Topic: [pkix] Fwd: I-D Action: draft-turner-additional-methods-4kis-02.txt Thread-Index: Ac0iFbd00ON1XULrRteirOAWdzIEfQBTM02Q Message-ID: <255B9BB34FB7D647A506DC292726F6E114F0CDBFCD@WSMSG3153V.srv.dir.telstra.com> References: <20120423183151.1989.87952.idtracker@ietfa.amsl.com> <4F95A1A4.5060209@ieca.com> <255B9BB34FB7D647A506DC292726F6E114F0C4080F@WSMSG3153V.srv.dir.telstra.com> <4F969C50.2070601@ieca.com> In-Reply-To: <4F969C50.2070601@ieca.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Fwd: I-D Action: draft-turner-additional-methods-4kis-02.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 05:38:28 -0000 >>> Title : Additional Methods for Generating Key Identifiers >>> Filename : draft-turner-additional-methods-4kis-04.txt >> ...Since we are truncating the hashes in all the new algs, why not trunc= ate to something shorter? 64-bits would be a good choice... > ...I don't want to remove the 160-bit truncated versions,=20 but I don't have any problem adding the 64-bit methods you describe... > > Sound like a plan? No. One variety per hash is enough. I feel that 160-bits is so far beyond what you need to be unique with high = probability, that it is almost suggesting (erroneously) to the reader that = the key-id needs to have "crypto" strength. But if you want 160-bits, don't complicate it with shorter options as well. You could ditch the SHA-224 and SHA-384 methods. Those 2 algs are just trun= cations of SHA-256 and SHA-512 (with different initial constants) so it is = inconceivable that an implementation supports, say, SHA-224 but not SHA-256= . >> What is the reason for having a certificate extension to describe how a = key id is generated? >> I don't think the draft gives any reason. > I added it because there was some discussion on the list about it -=20 > granted it was like 2 years ago. Some folks were on about it here: > https://www.ietf.org/mail-archive/web/pkix/current/msg27849.html > > I'll add some wording after I've run it by my co-author. I look forward to seeing the reason. I read that thread, saw people asking = for the extension, but still failed to discern a reason.=20 How can you indicate that you used the 2nd recommended mechanism to generat= e a key-id (ie 0100 + truncate_to_60bits(sha1(public_key))) in the ext-kiAl= gAndLen extension? I don't think you can given the extensions assumption of= a purely truncated hash. Perhaps a special rule for 64-bit key ids is need= ed. -- James Manger=20 From ietf@augustcellars.com Wed Apr 25 23:37:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0160C11E80AD for ; Wed, 25 Apr 2012 23:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfCvxf36NCNb for ; Wed, 25 Apr 2012 23:37:41 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4B51811E809D for ; Wed, 25 Apr 2012 23:37:41 -0700 (PDT) Received: from Tobias (unknown [50.34.251.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id B9DBF38F13; Wed, 25 Apr 2012 23:06:35 -0700 (PDT) From: "Jim Schaad" To: "'Russ Housley'" , "'IETF PKIX'" References: <20120424094548.20531.28695.idtracker@ietfa.amsl.com> <016401cd227d$49c3af70$dd4b0e50$@augustcellars.com> <0941B33A-54BB-43A1-9DFC-415A1E2DDAAA@vigilsec.com> In-Reply-To: <0941B33A-54BB-43A1-9DFC-415A1E2DDAAA@vigilsec.com> Date: Wed, 25 Apr 2012 23:05:13 -0700 Message-ID: <01ee01cd2372$9b187e50$d1497af0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMABM+owESy1uPD/pMW4EpC+Vjh/gJLK/rHATYBZEKUKtFA8A== Content-Language: en-us Subject: Re: [pkix] Two Comments on draft-ietf-pkix-pubkey-caps-05 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 06:37:42 -0000 Russ has requested a change during IESG review of this document for the Diffie-Helman S/MIME Capability fields so that the lengths of P, Q and G can optionally be specified as well. Unless I hear objections from the working group, I plan to make this change over the week-end and re-post the draft. If the chairs believe that this change would require a new WGLC, please speak up. Jim > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Wednesday, April 25, 2012 5:36 AM > To: IETF PKIX > Cc: Jim Schaad > Subject: Two Comments on draft-ietf-pkix-pubkey-caps-05 > > I am raising two non-blocking comments on draft-ietf-pkix-pubkey-caps-05. > > (1) First comment: > > My comment: > >> Should the capabilities in section 3.1 provide an optional way to > >> specify sizes of P, Q, and G that are supported? > >> > >> Similarly, should the capabilities in section 3.2 provide an > >> optional way to specify sizes of P and G that are supported? > > Jim's initial response: > > I wish that you had brought this issue up when the document was still in > the working group. Please post a message to this effect to the working > group with a rational for why you believe that this is something that should > be done. My first blush impression is that for 3.1 the response would be no > as these sizes are generally fixed by the NIST documents that cover the > different sizes of DSA. > > > > It might be useful for 3.2, but in general I don't believe that it would > generally be used. Do you have a situation where you think it might be of > importance? > > My reply to Jim's initial response: > I am aware of hardware implementation that have limitations on the size of > these parameters. So, the reason for sizes here is the same as the reason for > RSA key sizes. > > > (2) Second comment: > > My comment: > >> In Section 4.1 and 4.2 and 4.3, I suggest a list of named curves > >> instead of the very rich structure that is currently specified. > >> Several other documents have taken this approach. Any popular curve > >> can be assigned an object identifier to name it. > > Jim's initial response: > > The current text effectively does this in the same way that PKIX certificates > do this. The text states that only the namedCurve option of the > ECParameters structure is going to be used. Do believe that this is not > sufficient? > > My reply to Jim's initial response: > I do not think the current text does this. It says: > | > | ... As specified in [RFC3279], for PKIX compliant certificates only > | the namedCurve choice of ECParameters is expected to be used. > | > This does not say that only namedCurve is permitted. This says to me that is > the normal case, but be prepared to receive the others. > > Russ= From wwwrun@rfc-editor.org Tue Apr 24 10:32:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7129221F8829 for ; Tue, 24 Apr 2012 10:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.175 X-Spam-Level: X-Spam-Status: No, score=-102.175 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twXNMOAfLWVl for ; Tue, 24 Apr 2012 10:32:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 09B7921F86F8 for ; Tue, 24 Apr 2012 10:32:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 07D61622E6; Tue, 24 Apr 2012 10:31:22 -0700 (PDT) To: david.cooper@nist.gov, stefans@microsoft.com, stephen.farrell@cs.tcd.ie, sharon.boeyen@entrust.com, housley@vigilsec.com, wpolk@nist.gov, stephen.farrell@cs.tcd.ie, turners@ieca.com, kent@bbn.com, stefan@aaa-sec.com From: RFC Errata System Message-Id: <20120424173122.07D61622E6@rfc-editor.org> Date: Tue, 24 Apr 2012 10:31:22 -0700 (PDT) X-Mailman-Approved-At: Wed, 25 Apr 2012 23:39:29 -0700 Cc: pkix@ietf.org, dmandelb@bbn.com, rfc-editor@rfc-editor.org Subject: [pkix] [Technical Errata Reported] RFC5280 (3200) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 17:32:46 -0000 The following errata report has been submitted for RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5280&eid=3200 -------------------------------------- Type: Technical Reported by: David Mandelberg Section: 4.1.2.2 Original Text ------------- The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer. Corrected Text -------------- The serial number MUST be a positive non-zero integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a positive integer. Notes ----- "positive" and "non-negative" do not mean the same thing. I used the third paragraph of the section as a tie-breaker to decide which of the two terms was intended: Note: Non-conforming CAs may issue certificates with serial numbers that are negative or zero. Certificate users SHOULD be prepared to gracefully handle such certificates. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5280 (draft-ietf-pkix-rfc3280bis-11) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Publication Date : May 2008 Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG From piyush@identicate.com Thu Apr 26 09:39:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083D421E8136 for ; Thu, 26 Apr 2012 09:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyalAnYwvuTu for ; Thu, 26 Apr 2012 09:39:35 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB6321E8137 for ; Thu, 26 Apr 2012 09:39:34 -0700 (PDT) Received: from mail65-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Apr 2012 16:39:33 +0000 Received: from mail65-ch1 (localhost [127.0.0.1]) by mail65-ch1-R.bigfish.com (Postfix) with ESMTP id 139ED3C016A for ; Thu, 26 Apr 2012 16:39:33 +0000 (UTC) X-SpamScore: -1 X-BigFish: PS-1(zzc85fh14ffIzz1202hzz8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:157.56.244.229; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0610HT005.namprd06.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail65-ch1: domain of identicate.com designates 157.56.244.229 as permitted sender) client-ip=157.56.244.229; envelope-from=piyush@identicate.com; helo=CH1PRD0610HT005.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail65-ch1 (localhost.localdomain [127.0.0.1]) by mail65-ch1 (MessageSwitch) id 1335458369925427_32760; Thu, 26 Apr 2012 16:39:29 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail65-ch1.bigfish.com (Postfix) with ESMTP id DC3123000A2 for ; Thu, 26 Apr 2012 16:39:29 +0000 (UTC) Received: from CH1PRD0610HT005.namprd06.prod.outlook.com (157.56.244.229) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Apr 2012 16:39:28 +0000 Received: from CH1PRD0610MB393.namprd06.prod.outlook.com ([169.254.8.27]) by CH1PRD0610HT005.namprd06.prod.outlook.com ([10.255.151.40]) with mapi id 14.16.0143.004; Thu, 26 Apr 2012 16:39:27 +0000 From: Piyush Jain To: "pkix@ietf.org" Thread-Topic: SCVP : nextUpdate in CertReply Thread-Index: Ac0jyVwYmavkXVh8TR2mNVEhWpYlEg== Date: Thu, 26 Apr 2012 16:39:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.25.128.241] Content-Type: multipart/alternative; boundary="_000_AA6BA445CBFDB84785CC1C45DAAE4C79A75F39CH1PRD0610MB393na_" MIME-Version: 1.0 X-OriginatorOrg: identicate.com Subject: [pkix] SCVP : nextUpdate in CertReply X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:39:36 -0000 --_000_AA6BA445CBFDB84785CC1C45DAAE4C79A75F39CH1PRD0610MB393na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, nextUpdate for CertReply is marked as optional in RFC 5055. However the tex= t describing this field is silent about its meaning when this field is not= set. It'll be useful to clarify it by adding something like "If the nextUpdate item is omitted, it indicates that newer information = about the referenced certificate is always available and the client should = not cache the information returned in this CertReply object." Thoughts? -Piyush --_000_AA6BA445CBFDB84785CC1C45DAAE4C79A75F39CH1PRD0610MB393na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

nextUpdate for CertReply is marked as optional in RF= C 5055. However the text describing this field is silent about its meaning = when this field  is not set.

It’ll be useful to clarify it by adding someth= ing like

 

   “If the nextUpdate item is = omitted, it indicates that newer information about the referenced certifica= te is always available and the client should not cache the information returned in this CertReply object.”

 

Thoughts?

 

-Piyush

 

 

 

--_000_AA6BA445CBFDB84785CC1C45DAAE4C79A75F39CH1PRD0610MB393na_-- From housley@vigilsec.com Thu Apr 26 12:50:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D29121E8190 for ; Thu, 26 Apr 2012 12:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRkIsaLh40s0 for ; Thu, 26 Apr 2012 12:50:27 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id A231321E817D for ; Thu, 26 Apr 2012 12:50:26 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 5BC22F2404E; Thu, 26 Apr 2012 15:50:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 6fk-uuwECamU; Thu, 26 Apr 2012 15:50:05 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-140-3.washdc.fios.verizon.net [96.255.140.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 26993F24048; Thu, 26 Apr 2012 15:50:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-185-680339191 From: Russ Housley In-Reply-To: Date: Thu, 26 Apr 2012 15:50:24 -0400 Message-Id: <438C907C-D677-46CC-9A99-01AE70DB15CA@vigilsec.com> References: To: Piyush Jain X-Mailer: Apple Mail (2.1084) Cc: "pkix@ietf.org" Subject: Re: [pkix] SCVP : nextUpdate in CertReply X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 19:50:28 -0000 --Apple-Mail-185-680339191 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 You do not know how long to cache it. Asking one second later is not = likely to get a different response. In the past, there was not = consensus for advice like you suggest. Russ On Apr 26, 2012, at 12:39 PM, Piyush Jain wrote: > Hi All, > =20 > nextUpdate for CertReply is marked as optional in RFC 5055. However = the text describing this field is silent about its meaning when this = field is not set. > It=92ll be useful to clarify it by adding something like > =20 > =93If the nextUpdate item is omitted, it indicates that newer = information about the referenced certificate is always available and the = client should not cache the information returned in this CertReply = object.=94 > =20 > Thoughts? > =20 > -Piyush --Apple-Mail-185-680339191 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 You = do not know how long to cache it.  Asking one second later is not = likely to get a different response.  In the past, there was not = consensus for advice like you = suggest.

Russ


On= Apr 26, 2012, at 12:39 PM, Piyush Jain wrote:

Hi All,
 
nextUpdate for CertReply is = marked as optional in RFC 5055. However the text describing this field = is silent about its meaning when this field  is not = set.
It=92ll be useful to clarify it by adding = something like
   =93If the = nextUpdate item is omitted, it indicates that newer information about = the referenced certificate is always available and the client should not = cache the information returned in this CertReply = object.=94
Subject: Re: [pkix] SCVP : nextUpdate in CertReply X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 20:21:18 -0000 --_000_AA6BA445CBFDB84785CC1C45DAAE4C79A786D5CH1PRD0610MB393na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fair enough. But the text should either provide some guidance on what NULL nextUpdate m= eans or make it mandatory. Here is the current text. The nextUpdate item tells the time at which the server expects a refresh of information regarding the validity of the certificate to become available. The nextUpdate item is especially interesting if the certificate revocation status information is not available or the certificate is suspended. The nextUpdate item represents the date and time in UTC, using the GeneralizedTime type. The encoding rules for GeneralizedTime in Section 3.2.7 MUST be used. BTW the meaning of NULL nextUpdate is clearly defined for validation policy= response If the nextUpdate item is omitted, it indicates a non-cached response generated in response to a specific request (i.e., the ValPolResponse is bound to a specific request). If this item is omitted, the requestNonce item MUST be present and MUST include the requestNonce value from the request. From: Russ Housley [mailto:housley@vigilsec.com] Sent: Thursday, April 26, 2012 12:50 PM To: Piyush Jain Cc: pkix@ietf.org Subject: Re: [pkix] SCVP : nextUpdate in CertReply You do not know how long to cache it. Asking one second later is not likel= y to get a different response. In the past, there was not consensus for ad= vice like you suggest. Russ On Apr 26, 2012, at 12:39 PM, Piyush Jain wrote: Hi All, nextUpdate for CertReply is marked as optional in RFC 5055. However the tex= t describing this field is silent about its meaning when this field is not= set. It'll be useful to clarify it by adding something like "If the nextUpdate item is omitted, it indicates that newer information = about the referenced certificate is always available and the client should = not cache the information returned in this CertReply object." Thoughts? -Piyush --_000_AA6BA445CBFDB84785CC1C45DAAE4C79A786D5CH1PRD0610MB393na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fair enough.

But the text should eithe= r  provide some guidance on what NULL nextUpdate means or make it mand= atory.

 <= /p>

Here is the current text.=

 <= /p>

   The nextUpdate item tells the tim= e at which the server expects a

   refresh of information regarding = the validity of the certificate to

   become available.  The nextU= pdate item is especially interesting if

   the certificate revocation status= information is not available or the

   certificate is suspended.  T= he nextUpdate item represents the date

   and time in UTC, using the Genera= lizedTime type.  The encoding rules

   for GeneralizedTime in Section 3.= 2.7 MUST be used.

 <= /p>

BTW the meaning of NULL n= extUpdate is clearly defined for validation policy response

   If the nextUpdate item is omi=
tted, it indicates a non-cached response
   generated in response to a sp=
ecific request (i.e., the ValPolResponse
   is bound to a specific reques=
t).  If this item is omitted, the
   requestNonce item MUST be pre=
sent and MUST include the requestNonce
   value from the request.<=
/o:p>

 <= /p>

From: Russ Hou= sley [mailto:housley@vigilsec.com]
Sent: Thursday, April 26, 2012 12:50 PM
To: Piyush Jain
Cc: pkix@ietf.org
Subject: Re: [pkix] SCVP : nextUpdate in CertReply=

 

You do not know how long to cache it.  Asking o= ne second later is not likely to get a different response.  In the pas= t, there was not consensus for advice like you suggest.

 

Russ

 

 

On Apr 26, 2012, at 12:39 PM, Piyush Jain wrote:



Hi All,

 

nextUpdate for CertReply is marked as o= ptional in RFC 5055. However the text describing this field is silent about= its meaning when this field  is not set.

It’ll be useful to clarify it by = adding something like

 

   “If the nextUpdate item is = omitted, it indicates that newer information about the referenced certifica= te is always available and the client should not cache the information returned in this CertReply object.”

 

Thoughts?

 

-Piyush<= /p>

 

--_000_AA6BA445CBFDB84785CC1C45DAAE4C79A786D5CH1PRD0610MB393na_-- From prvs=0464bf9d25=atruskovsky@rim.com Fri Apr 27 06:46:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249D321F86B3 for ; Fri, 27 Apr 2012 06:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UUApddXnS5H for ; Fri, 27 Apr 2012 06:46:29 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id C307421F86AD for ; Fri, 27 Apr 2012 06:46:28 -0700 (PDT) X-AuditID: 0a41282f-b7fb66d00000219c-12-4f9aa33104c8 Received: from XCT108CNC.rim.net (xct108cnc.rim.net [10.65.161.208]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 67.E9.08604.133AA9F4; Fri, 27 Apr 2012 13:46:25 +0000 (GMT) Received: from XMB108FCNC.rim.net ([fe80::b582:c49b:f967:ac82]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.01.0339.001; Fri, 27 Apr 2012 09:46:24 -0400 From: Alexander Truskovsky To: Max Pritikin Thread-Topic: Some comments on draft-ietf-pkix-est-01 Thread-Index: Ac0jM5f91gsgWogcTL6JKfpyjii2ZQAJ9HyAAEgf5sA= Date: Fri, 27 Apr 2012 13:46:23 +0000 Message-ID: <8243FA429BFB6047A330BE77EDBF8D0B11BE5E2C@XMB108FCNC.rim.net> References: <8243FA429BFB6047A330BE77EDBF8D0B11BE34BE@XMB108FCNC.rim.net> <804932ED-5A3F-4776-AE05-A81683BE654E@cisco.com> In-Reply-To: <804932ED-5A3F-4776-AE05-A81683BE654E@cisco.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsXC5bjwgq7h4ln+Bi/3iltcPFhk8XvnI3YH Jo8pvzeyeixZ8pMpgCmqgdEmKbGkLDgzPU/fziYxLy+/JLEkVSEltTjZVsknNT0xRyGgKLMs MblSwSWzODknMTM3tUhJITPFVslESaEgJzE5NTc1r8RWKbGgIDUvRcmOywYomJmnkJqXnJ+S mZduq+QZ7K9rYWFqqWuoZKeLCRKucWc82ZFc0Kda8eNkO3sDY7NcFyMnh4SAicTWxs3sELaY xIV769m6GLk4hAT6mCROrtvDDOFsY5TY0NjHBFLFJmAg0XX4JRuILSKgKtF96BsziM0skC2x aM1ZMFsYaOrZRctZIWpMJfYf2c4OYVtJLFo2iRHEZgHq/d75F8zmFfCUmNb1CqiGA2hZjUT/ VTGQMKeArcSZ6dvB1jIKyEqsnbOSFWKVuMStJ/OZII4WkFiy5zwzhC0q8fLxP1YIW1Hiyclr LBD1OhILdn9ig7C1JZYtfM0MsVZQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcUomJtRbGBm kJyXrFeUmauXl1qyiRGcIjT0dzD27dU6xCjAwajEw5s0f5a/EGtiWXFl7iFGCQ5mJRHeH8FA Id6UxMqq1KL8+KLSnNTiQ4wWwECZyCzFnZwPTF95JfHGBgYoHCVx3ujbtf5CAunAxJOdmlqQ WgTTysTBCTKaS0qkGJg+UosSS0sy4kFJLr4YmOakGhgzHxlNFys948eVy8Q06/+u6ydtnV2f iEyMK5/yml38mkF4UKVuwYITf95bNFTwJV8+vmqnfG2A1VKnjnzTY6+NwnmmX7+gcInn3/aV ZsmRTKU2RUzVQfu2WST/mrxApLfbIbpiQQlXX0BgwbFim5JljqZzZHykjj8sresLuqjTtS/5 qhdTpBJLcUaioRZzUXEiADQswPRFAwAA Cc: "pkix@ietf.org" , Chris Bender Subject: Re: [pkix] Some comments on draft-ietf-pkix-est-01 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 13:46:30 -0000 Max, You are correct, the same problem exists if CMS is used. I think an excepti= on to the RFC 5280 key usage restrictions is reasonable in the case of certi= ficate renewal only. When verifying certificates you have never seen before= , I believe it is important to ensure the key usage is appropriate and EST s= hould perform full certificate verification when authenticating the initial= CSRs using certificates issued by another PKI. In the case of certificate= renewal the EST server will be verifying certificates that it issued, and I= think ignoring the key usage here does not really degrade security. We are interested in deploying a solution that will work for Client Authenti= cation and Email Protection certificates (enrollment and renewal). I don't= think that mobile devices have the need to support enrollment for certifica= tes with any other extended key usage. I don't have any other suggestions right now. Perhaps the TLS client authen= tication can still be used if it is more convenient to some clients and CMS= can be used as a secondary option. It is certainly easier to override the= key usage warning in the EST server implementation when using CMS. Regards, Alex -----Original Message----- From: Max Pritikin [mailto:pritikin@cisco.com] Sent: Wednesday, April 25, 2012 7:20 PM To: Alexander Truskovsky Cc: pkix@ietf.org; Matthew Campagna; Chris Bender Subject: Re: Some comments on draft-ietf-pkix-est-01 Thank you for the feedback on EST (and SCEP). In regards for your request for EST functionality: I agree that dealing with clients that can't use their certificates for digi= talSignature is a problem -- but doesn't the same problem exist if the clien= t's key usage is such that they shouldn't be signing PKCS7/CMS either? "CMC provides a method to prove the client's identity based on a client/serv= er shared-secret" [RFC5272] ... but I don't believe it provides an exception= to the problem you're discussing. Is there general interest in finding another approach? I've hesitated to sug= gest an exception to the RFC5280 key usage restrictions but haven't been abl= e to think of a different approach. Do you have any suggestions? It is very possible I'm missing something, - max On Apr 25, 2012, at 4:34 PM, Alexander Truskovsky wrote: > Max, > > I have been implementing the current SCEP draft, and have come across seve= ral issues that we are glad to see addressed in EST, specifically: > > 1) The use of a certificate issued by another PKI to authenticate the init= ial request is optional in SCEP. This is now a MUST requirement in EST (A3)= . > 2) The GetCACaps response is not signed in SCEP. This is not a problem in= EST because of the TLS use. > 3) The SCEP draft mentions that RSA is the only algorithm supported by the= current implementations. Although there is no technical limitation that pr= events the usage of ECC in SCEP and some implementations do support ECC, we= are glad to see that algorithm agility is a MUST requirement in EST (K1). > > EST is a specification we would also consider deploying. There is an addi= tional use case we would like to see supported by EST. When renewing an ema= il protection certificate, it cannot be used to authenticate the request usi= ng the TLS client authentication. Although this can be achieved by using a= full CMC operation, it would be better if it were handled by plain EST. Wr= apping the PKCS10 in PKCS7 and signing it with the email protection key woul= d work without having to use a full CMC operation. > > We think the use of TLS client authentication, although elegant, makes it= inconvenient to use in some cases because a full CMC operation needs to be= used. We propose to continue using PKCS7 to wrap the PKCS10 to support thi= s and similar use cases. > > Thanks for your consideration, > Alex > > > Alexander Truskovsky > BlackBerry OS Security | Research In Motion > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From hallam@gmail.com Fri Apr 27 11:48:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB8621F8705 for ; Fri, 27 Apr 2012 11:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyXaFUCaxz3k for ; Fri, 27 Apr 2012 11:48:52 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2CC21F86F7 for ; Fri, 27 Apr 2012 11:48:52 -0700 (PDT) Received: by ghbg16 with SMTP id g16so731649ghb.31 for ; Fri, 27 Apr 2012 11:48:52 -0700 (PDT) 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; bh=6L2fdf1/kpKfgMvKASGoJyl7YqjTUONLIR4tWAkibD4=; b=GgZ6YXy73wx599J2qPPMKO3huYD+ce20shhbcMIHY8X/cjWjyNvii5DcHeRArzwkaS emq9vzwt62IRPHBIJn+152DwfSSEsur0lU9fe7wwcB4nrzdhYmBezr9I4O4ZY6pHtqpR iz17Xcf9YeJjpDAjWCSy3nrYjFf9twgNDAXc4nwXRVNbR0a0Ro89FRdfDCF554K9uWsb CYGloaH3ZjeER+NtF1f9DjIPUkPJMniuTDpHiQbMdNSHOrh0hsR/j+xeDU0LDYIhMcKo +TEZiesQgaZrxyFs0pYpHgmHq5DNNT9ZKRSRaoOOq+KRVF5kY9QEcnKro64KEj4T+BcS DMog== MIME-Version: 1.0 Received: by 10.60.9.102 with SMTP id y6mr16364987oea.46.1335552531540; Fri, 27 Apr 2012 11:48:51 -0700 (PDT) Received: by 10.182.41.165 with HTTP; Fri, 27 Apr 2012 11:48:51 -0700 (PDT) Date: Fri, 27 Apr 2012 14:48:51 -0400 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [pkix] TLS Security Policy Specification X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 18:48:53 -0000 In response to a CABForum working group meeting, I wrote up the proposal for improving revocation checking by allowing certificates to specify that a server supports stapling: http://www.ietf.org/id/draft-hallambaker-tlssecuritypolicy-00.txt http://www.ietf.org/id/draft-hallambaker-tlssecuritypolicy-00.pdf The approach is slightly broader in principle but as the draft explains, stapling is the only feature for which a certificate based security policy is currently relevant. Given that we have already had a long discussion of the merits of the scheme here, I suggest that people address the implementation approach unless they have something new to add. As the security considerations state, this control does not attempt to prevent every form of revocation based downgrade attacks, merely the ones that account for 99% of the reported incidents. There are other controls being developed to deal with the remaining cases. -- Website: http://hallambaker.com/ From era@x500.eu Sat Apr 28 01:17:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829A621F86E3 for ; Sat, 28 Apr 2012 01:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.011 X-Spam-Level: * X-Spam-Status: No, score=1.011 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-H3WQGW8DRD for ; Sat, 28 Apr 2012 01:17:16 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 29B7E21F86D8 for ; Sat, 28 Apr 2012 01:17:15 -0700 (PDT) Received: from Morten ([94.191.251.111]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id MMT01013 for ; Sat, 28 Apr 2012 10:17:13 +0200 From: "Erik Andersen" To: "PKIX" Date: Sat, 28 Apr 2012 10:17:06 +0200 Message-ID: <001b01cd2517$51b7adc0$f5270940$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CD2528.15407DC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0lF0xK+eI6NWwBQRueiON53+/U1w== Content-Language: da Subject: [pkix] Role specification in public-key certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 08:17:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001C_01CD2528.15407DC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If you want to specify the role of the subject in a public-key certificate, where would be the most appropriate place? Erik Andersen ------=_NextPart_000_001C_01CD2528.15407DC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you = want to specify the role of the subject in a public-key certificate, = where would be the most appropriate place?

 

Erik = Andersen

------=_NextPart_000_001C_01CD2528.15407DC0-- From swilson@lockstep.com.au Sat Apr 28 05:39:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B63521F869F for ; Sat, 28 Apr 2012 05:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbvCpw+tPJQL for ; Sat, 28 Apr 2012 05:38:59 -0700 (PDT) Received: from smtp152.iad.emailsrvr.com (smtp152.iad.emailsrvr.com [207.97.245.152]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCC721F869A for ; Sat, 28 Apr 2012 05:38:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp35.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 427482C80FD for ; Sat, 28 Apr 2012 08:38:58 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp35.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id AFE6A2C80F2 for ; Sat, 28 Apr 2012 08:38:56 -0400 (EDT) Message-ID: <4F9BE4B0.5040609@lockstep.com.au> Date: Sat, 28 Apr 2012 22:38:08 +1000 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: PKIX References: <001b01cd2517$51b7adc0$f5270940$@eu> In-Reply-To: <001b01cd2517$51b7adc0$f5270940$@eu> Content-Type: multipart/alternative; boundary="------------000608040106020003090401" Subject: Re: [pkix] Role specification in public-key certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 12:39:00 -0000 This is a multi-part message in MIME format. --------------000608040106020003090401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In modern closed PKI, I suggest role should be specified in detail in the Certificate Policy of a defined community of certificate holders; then the unique Policy OID stands for the role in question. For reasonably long lived roles in need of certificates, we should issue a different certificate for each role. See also http://lockstep.com.au/library/pki/relationship_certificates.html Cheers, Steve Wilson. Lockstep http://lockstep.com.au Lockstep Consulting provides independent specialist advice and analysis on digital identity and privacy.Lockstep Technologies develops unique new smart ID solutions that enhance privacy and prevent identity theft. On 28/04/2012 6:17 PM, Erik Andersen wrote: > > If you want to specify the role of the subject in a public-key > certificate, where would be the most appropriate place? > > Erik Andersen > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------000608040106020003090401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
In modern closed PKI, I suggest role should be specified in detail in the Certificate Policy of a defined community of certificate holders; then the unique Policy OID stands for the role in question.  For reasonably long lived roles in need of certificates, we should issue a different certificate for each role. 

See also http://lockstep.com.au/library/pki/relationship_certificates.html

Cheers,

Steve Wilson.

Lockstep

http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.  Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.


 

On 28/04/2012 6:17 PM, Erik Andersen wrote:

If you want to specify the role of the subject in a public-key certificate, where would be the most appropriate place?

 

Erik Andersen


 

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--------------000608040106020003090401-- From SChokhani@cygnacom.com Sat Apr 28 08:00:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFF521F8637 for ; Sat, 28 Apr 2012 08:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t97bPf3Z74un for ; Sat, 28 Apr 2012 08:00:17 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9742921F8665 for ; Sat, 28 Apr 2012 08:00:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,496,1330923600"; d="scan'208,217";a="4843237" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 28 Apr 2012 11:00:04 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sat, 28 Apr 2012 11:00:04 -0400 From: Santosh Chokhani To: Erik Andersen , PKIX Date: Sat, 28 Apr 2012 10:59:20 -0400 Thread-Topic: [pkix] Role specification in public-key certificates Thread-Index: Ac0lT31Sg+fKJ9sCQF+wdeb3c+te3Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF0F60C691scygexch7cygnac_" MIME-Version: 1.0 Subject: Re: [pkix] Role specification in public-key certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 15:00:18 -0000 --_000_B83745DA469B7847811819C5005244AF0F60C691scygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would think Subject Directory Attribute. A word of caution about practical aspects of this leading to the need for c= oordination between role and identity vetting and dynamicity of role leadin= g to more frequent revocation of the public key certificate. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Eri= k Andersen Sent: Saturday, April 28, 2012 4:17 AM To: PKIX Subject: [pkix] Role specification in public-key certificates If you want to specify the role of the subject in a public-key certificate,= where would be the most appropriate place? Erik Andersen --_000_B83745DA469B7847811819C5005244AF0F60C691scygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would thin= k Subject Directory Attribute.

 

A word of caution ab= out practical aspects of this leading to the need for coordination between = role and identity vetting and dynamicity of role leading to more frequent r= evocation of the public key certificate.

 

= From:= pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Erik Andersen
Sent: Saturday, April 28, 2012 4:17 AM
To:<= /b> PKIX
Subject: [pkix] Role specification in public-key certifi= cates

 

If you want to specify the ro= le of the subject in a public-key certificate, where would be the most appr= opriate place?

 

Erik A= ndersen

= --_000_B83745DA469B7847811819C5005244AF0F60C691scygexch7cygnac_-- From mstjohns@comcast.net Sat Apr 28 08:16:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE7F21F8601 for ; Sat, 28 Apr 2012 08:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.711 X-Spam-Level: X-Spam-Status: No, score=-101.711 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx7eT+0OnDox for ; Sat, 28 Apr 2012 08:16:47 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by ietfa.amsl.com (Postfix) with ESMTP id 388D321F85F4 for ; Sat, 28 Apr 2012 08:16:47 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 3SNW1j0011smiN4A3TGnFg; Sat, 28 Apr 2012 15:16:47 +0000 Received: from [192.168.1.101] ([68.83.222.237]) by omta20.emeryville.ca.mail.comcast.net with comcast id 3TGl1j00J57vnMg8gTGlZX; Sat, 28 Apr 2012 15:16:46 +0000 References: <001b01cd2517$51b7adc0$f5270940$@eu> In-Reply-To: <001b01cd2517$51b7adc0$f5270940$@eu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-32F7F584-D032-423E-91D8-4455604FD162 Message-Id: X-Mailer: iPad Mail (9B176) From: Michael StJohns Date: Sat, 28 Apr 2012 11:16:46 -0400 To: Erik Andersen Cc: PKIX Subject: Re: [pkix] Role specification in public-key certificates X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 15:16:47 -0000 --Apple-Mail-32F7F584-D032-423E-91D8-4455604FD162 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii How about in an attribute certificate? Specifically with the role attribute= . That's sort of what they're there for. =20 Sent from my iPad On Apr 28, 2012, at 4:17, "Erik Andersen" wrote: > If you want to specify the role of the subject in a public-key certificate= , where would be the most appropriate place? > =20 > Erik Andersen > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-32F7F584-D032-423E-91D8-4455604FD162 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
How about in an attribute certificate?  Specifically with the role attribute.    That's sort of what they're there for.  

Sent from my iPad

On Apr 28, 2012, at 4:17, "Erik Andersen" <era@x500.eu> wrote:

If you want to specify the role of the subject in a public-key certificate, where would be the most appropriate place?

 

Erik Andersen

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--Apple-Mail-32F7F584-D032-423E-91D8-4455604FD162-- From agl@google.com Mon Apr 30 07:48:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E5A21F8551 for ; Mon, 30 Apr 2012 07:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97fnubDdB4v6 for ; Mon, 30 Apr 2012 07:48:55 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D64721F8541 for ; Mon, 30 Apr 2012 07:48:55 -0700 (PDT) Received: by yenm5 with SMTP id m5so1560751yen.31 for ; Mon, 30 Apr 2012 07:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=4StalfHb1uSyerBtH0Lb1H/0r3JxO64joBaJNF2l59c=; b=F03zdPJq5HIKIiF+6JIt6c+faf51a9GGxPA15+EfpSkxBSGLQh8D1Gxerm7deDaF8I MBvmBmAHQ0h2lVLXRJ+1IkDX0F8ts8tp9YaWOXV369tHOFhIKInUIsGw6sF3HzMt5e7e fGeMm2WnzdRJfsjxpjgMY7yqqTUXftMaWv3sTTKmbz4b4N7IowTSZqlQr/kpuzFF/ZWo qDFePqp3zNHtXJBxeQWs6P+zluCKC5dJ80ifRGG4FxiJpCtZnhPj7s4PWyibxH5NrgLj K7lgE5l9tlo64159g70LxttSnx4F+c+zwAg+1UVdq0ptFge5BRHZxsc3jdqixqU71cYB Us5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=4StalfHb1uSyerBtH0Lb1H/0r3JxO64joBaJNF2l59c=; b=mJq7MhIOEcSXTP63yY0b7NvaM7j6p8IAQWsz2uvxdBG7ikRKTNeDowwr8pl6D5ONoR DjmHJckpBpG6+jsmd0N/uQseNXL8wO4cxxDnPo5ApHlLaec+APhMEXcyq0wzTE50LiH6 x3KGzann4BCpwMMxKoy0bla43YIghBIeafSSRqm1tqnOmcz0CunapihN4TNlEWlldfHV 1WplnhEs46U8ybXsjOWyDzzMBWlXHjHZkdnW2BJ3LefrwjH8pDgEKhYbyKF/uPMHUvcJ LxUVn2JAYOLdxm8HCEcq0sFv9VwblLSObSIxAYfXml++UhPjVPDUboPDSWUHN/jRXIJO urOg== Received: by 10.50.169.65 with SMTP id ac1mr10758237igc.54.1335797334726; Mon, 30 Apr 2012 07:48:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.169.65 with SMTP id ac1mr10758228igc.54.1335797334601; Mon, 30 Apr 2012 07:48:54 -0700 (PDT) Sender: agl@google.com Received: by 10.231.188.230 with HTTP; Mon, 30 Apr 2012 07:48:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Apr 2012 10:48:54 -0400 X-Google-Sender-Auth: KTfVr4z1vLAc1j4pSWofRZ4L_uo Message-ID: From: Adam Langley To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkybuT457m2XnkdwROZ+h0LCJgidBt4h1NwAg7ujZvzRBZxhPI7wLEkN3RDH/yYgEx+ydHzBn0tN5anJuyOoBu7aKXphbWtU3TjYO+ok50VXiAOpeO2OGcL5OmpS0dTX1z1i0H7 Cc: pkix@ietf.org Subject: Re: [pkix] TLS Security Policy Specification X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 14:48:56 -0000 On Fri, Apr 27, 2012 at 2:48 PM, Phillip Hallam-Baker wrote: > The approach is slightly broader in principle but as the draft > explains, stapling is the only feature for which a certificate based > security policy is currently relevant. Generally, looks good to me. For the minVersion, using x to mean TLS 1.(x-1) seems unnecessarily complex. Why not have x mean TLS 1.x? (i.e. 0 -> TLS 1.0, 1 -> TLS 1.1 etc?) I think the following client behaviour needs to be specified: 1) what happens when minVersion is greater than what I support? Should I abort, or carry on as best I can? 2) what happens when extensions contains a value that I don't know about? Should I ignore it? Cheers AGL From era@x500.eu Mon Apr 30 08:36:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790D521F866D for ; Mon, 30 Apr 2012 08:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.011 X-Spam-Level: * X-Spam-Status: No, score=1.011 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DK=1.009, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izV8+K54oFU9 for ; Mon, 30 Apr 2012 08:36:29 -0700 (PDT) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9F521F85A5 for ; Mon, 30 Apr 2012 08:36:28 -0700 (PDT) Received: from Morten ([212.27.25.236]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id OTO19326 for ; Mon, 30 Apr 2012 17:36:26 +0200 From: "Erik Andersen" To: "PKIX" Date: Mon, 30 Apr 2012 17:36:22 +0200 Message-ID: <002101cd26e7$0255ca10$07015e30$@eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CD26F7.C5DE9A10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0m5v7mGAZcWKB6TjOkQnLvKB1SVA== Content-Language: da Subject: [pkix] License fee for running a PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:36:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0022_01CD26F7.C5DE9A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Folks, I have received questions for which I need help to answer. The question is as follows - Is that any government requires payment of fees by electronic signature service providers - If this is the case, what is the frequency of payment and above what is the amount I believe that the first question is: Are there examples where a PKI service provider needs to pay a license fee to the government? Any help is highly appreciated. Erik ------=_NextPart_000_0022_01CD26F7.C5DE9A10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

I have = received questions for which I need help to answer. The question is as = follows

 

- Is that any government requires payment of fees = by electronic signature service providers

 

- If = this is the case, what is the frequency of payment and above what is the = amount

 

I believe that the first question is: Are there = examples where a PKI service provider needs to pay a license fee to the = government?

 

Any help is highly appreciated.

 

Erik =

 

------=_NextPart_000_0022_01CD26F7.C5DE9A10-- From mrex@sap.com Mon Apr 30 08:58:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D34921F86A3 for ; Mon, 30 Apr 2012 08:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.125 X-Spam-Level: X-Spam-Status: No, score=-10.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+7Ggn1Tmv7E for ; Mon, 30 Apr 2012 08:58:40 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id CC13C21F8698 for ; Mon, 30 Apr 2012 08:58:39 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3UFwbNm016995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 17:58:38 +0200 (MEST) From: Martin Rex Message-Id: <201204301558.q3UFwboA014619@fs4113.wdf.sap.corp> To: era@x500.eu (Erik Andersen) Date: Mon, 30 Apr 2012 17:58:37 +0200 (MEST) In-Reply-To: <002101cd26e7$0255ca10$07015e30$@eu> from "Erik Andersen" at Apr 30, 12 05:36:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] License fee for running a PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 15:58:41 -0000 Erik Andersen wrote: > > I have received questions for which I need help to answer. The question is > as follows > > - Is that any government requires payment of fees by electronic signature > service providers > > - If this is the case, what is the frequency of payment and above what is > the amount > > I believe that the first question is: Are there examples where a PKI service > provider needs to pay a license fee to the government? I doubt that countries sell "license for running electronic signature services" similar to how they sell licenses for radio frequencies. But the cost incurred (audits,accreditation) to create "trustworthy" electronic signatures might be non-marginal, e.g. such as for issuing certs that permit creation of "qualified signatures" in the EU: http://europa.eu/legislation_summaries/information_society/other_policies/l24118_en.htm -Martin From md@e-net.lt Mon Apr 30 10:53:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F06021E808E for ; Mon, 30 Apr 2012 10:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZC+-dE3xpB2 for ; Mon, 30 Apr 2012 10:52:59 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id BFDCF21E8084 for ; Mon, 30 Apr 2012 10:52:58 -0700 (PDT) Received: from [84.240.23.136] (helo=[192.168.1.100]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1SOumL-0007Q4-0E; Mon, 30 Apr 2012 20:52:53 +0300 Message-ID: <4F9ED174.8000704@e-net.lt> Date: Mon, 30 Apr 2012 20:52:52 +0300 From: "Moudrick M. Dadashov" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: mrex@sap.com References: <201204301558.q3UFwboA014619@fs4113.wdf.sap.corp> In-Reply-To: <201204301558.q3UFwboA014619@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] License fee for running a PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 17:53:00 -0000 Directive 1999/93/EC: in order to stimulate the Community-wide provision of certification services over open networks, certification-service-providers should be free to provide their services without prior authorisation; prior authorisation means not only any permission whereby the certification-service-provider concerned has to obtain a decision by national authorities before being allowed to provide its certification services, but also any other measures having the same effect; Thanks, M.D. On 4/30/2012 6:58 PM, Martin Rex wrote: > Erik Andersen wrote: >> I have received questions for which I need help to answer. The question is >> as follows >> >> - Is that any government requires payment of fees by electronic signature >> service providers >> >> - If this is the case, what is the frequency of payment and above what is >> the amount >> >> I believe that the first question is: Are there examples where a PKI service >> provider needs to pay a license fee to the government? > > I doubt that countries sell "license for running electronic signature > services" similar to how they sell licenses for radio frequencies. > > But the cost incurred (audits,accreditation) to create "trustworthy" > electronic signatures might be non-marginal, e.g. such as for issuing > certs that permit creation of "qualified signatures" in the EU: > > http://europa.eu/legislation_summaries/information_society/other_policies/l24118_en.htm > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Mon Apr 30 11:03:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABA711E8076 for ; Mon, 30 Apr 2012 11:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.13 X-Spam-Level: X-Spam-Status: No, score=-10.13 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zta8Rxzjs3z for ; Mon, 30 Apr 2012 11:03:46 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3021E802B for ; Mon, 30 Apr 2012 11:03:45 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3UI3hN5028492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 20:03:43 +0200 (MEST) From: Martin Rex Message-Id: <201204301803.q3UI3gPO021732@fs4113.wdf.sap.corp> To: md@e-net.lt (Moudrick M. Dadashov) Date: Mon, 30 Apr 2012 20:03:42 +0200 (MEST) In-Reply-To: <4F9ED174.8000704@e-net.lt> from "Moudrick M. Dadashov" at Apr 30, 12 08:52:52 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] License fee for running a PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 18:03:47 -0000 Moudrick M. Dadashov wrote: > > Directive 1999/93/EC: > > in order to stimulate the Community-wide provision of certification > services over open networks, certification-service-providers should be > free to provide their services without prior authorisation; prior > authorisation means not only any permission whereby the > certification-service-provider concerned has to obtain a decision by > national authorities before being allowed to provide its certification > services, but also any other measures having the same effect; In practice, the legal requirements (at least in Germany) for most regulated usage scenarios require the use of a "qualified signature" or a specific trust center (e.g. Elster, GKVNet). -Martin > On 4/30/2012 6:58 PM, Martin Rex wrote: > > Erik Andersen wrote: > >> I have received questions for which I need help to answer. The question is > >> as follows > >> > >> - Is that any government requires payment of fees by electronic signature > >> service providers > >> > >> - If this is the case, what is the frequency of payment and above what is > >> the amount > >> > >> I believe that the first question is: Are there examples where a PKI service > >> provider needs to pay a license fee to the government? > > > > I doubt that countries sell "license for running electronic signature > > services" similar to how they sell licenses for radio frequencies. > > > > But the cost incurred (audits,accreditation) to create "trustworthy" > > electronic signatures might be non-marginal, e.g. such as for issuing > > certs that permit creation of "qualified signatures" in the EU: > > > > http://europa.eu/legislation_summaries/information_society/other_policies/l24118_en.htm > > > > > > -Martin > > _______________________________________________ > > pkix mailing list > > pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > > From internet-drafts@ietf.org Mon Apr 30 15:14:13 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D85021E80CC; Mon, 30 Apr 2012 15:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-fWN4u4rDls; Mon, 30 Apr 2012 15:14:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD1821E80A1; Mon, 30 Apr 2012 15:14:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120430221412.14637.78574.idtracker@ietfa.amsl.com> Date: Mon, 30 Apr 2012 15:14:12 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-pubkey-caps-06.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 22:14:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Wor= king Group of the IETF. Title : S/MIME Capabilities for Public Key Definitions Author(s) : Jim Schaad Filename : draft-ietf-pkix-pubkey-caps-06.txt Pages : 25 Date : 2012-04-30 This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. An example of where this is used is is detailed in Online Certificate Status Protocol Algorithm Agility (RFC 6277). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-pubkey-caps/ From md@e-net.lt Mon Apr 30 16:13:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8B421E80DF for ; Mon, 30 Apr 2012 16:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuROaL1M89dI for ; Mon, 30 Apr 2012 16:13:23 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by ietfa.amsl.com (Postfix) with ESMTP id 61DD821E8041 for ; Mon, 30 Apr 2012 16:13:23 -0700 (PDT) Received: from [84.240.23.136] (helo=[192.168.1.100]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1SOzmR-0004Xm-FT; Tue, 01 May 2012 02:13:19 +0300 Message-ID: <4F9F1C8F.5080405@e-net.lt> Date: Tue, 01 May 2012 02:13:19 +0300 From: "Moudrick M. Dadashov" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: mrex@sap.com References: <201204301803.q3UI3gPO021732@fs4113.wdf.sap.corp> In-Reply-To: <201204301803.q3UI3gPO021732@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] License fee for running a PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 23:13:24 -0000 Do those "trust centers" need a formal registration/approval by local authorities? Thanks, M.D. On 4/30/2012 9:03 PM, Martin Rex wrote: > Moudrick M. Dadashov wrote: >> Directive 1999/93/EC: >> >> in order to stimulate the Community-wide provision of certification >> services over open networks, certification-service-providers should be >> free to provide their services without prior authorisation; prior >> authorisation means not only any permission whereby the >> certification-service-provider concerned has to obtain a decision by >> national authorities before being allowed to provide its certification >> services, but also any other measures having the same effect; > In practice, the legal requirements (at least in Germany) for most > regulated usage scenarios require the use of a "qualified signature" > or a specific trust center (e.g. Elster, GKVNet). > > -Martin > > >> On 4/30/2012 6:58 PM, Martin Rex wrote: >>> Erik Andersen wrote: >>>> I have received questions for which I need help to answer. The question is >>>> as follows >>>> >>>> - Is that any government requires payment of fees by electronic signature >>>> service providers >>>> >>>> - If this is the case, what is the frequency of payment and above what is >>>> the amount >>>> >>>> I believe that the first question is: Are there examples where a PKI service >>>> provider needs to pay a license fee to the government? >>> I doubt that countries sell "license for running electronic signature >>> services" similar to how they sell licenses for radio frequencies. >>> >>> But the cost incurred (audits,accreditation) to create "trustworthy" >>> electronic signatures might be non-marginal, e.g. such as for issuing >>> certs that permit creation of "qualified signatures" in the EU: >>> >>> http://europa.eu/legislation_summaries/information_society/other_policies/l24118_en.htm >>> >>> >>> -Martin >>> _______________________________________________ >>> pkix mailing list >>> pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix >> From mrex@sap.com Mon Apr 30 16:50:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0475B21E8114 for ; Mon, 30 Apr 2012 16:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.522 X-Spam-Level: X-Spam-Status: No, score=-9.522 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EErz4p9Pw4ME for ; Mon, 30 Apr 2012 16:50:30 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1A321E8041 for ; Mon, 30 Apr 2012 16:50:29 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3UNoP6U029300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 01:50:26 +0200 (MEST) From: Martin Rex Message-Id: <201204302350.q3UNoP06011331@fs4113.wdf.sap.corp> To: md@e-net.lt (Moudrick M. Dadashov) Date: Tue, 1 May 2012 01:50:25 +2600 (MEST) In-Reply-To: <4F9F1C8F.5080405@e-net.lt> from "Moudrick M. Dadashov" at May 1, 12 02:13:19 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] License fee for running a PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 23:50:31 -0000 Moudrick M. Dadashov wrote: > > Do those "trust centers" need a formal registration/approval by local > authorities? No. But that that question does not fit here. The organizations or authorities that have been tasked (by applicable laws) to provide secure electronic data transmissions have defined the data formats, and set up a trust center that will issue certificates matching their requirements with respect to (a) consistently identifying entities participating in the data exchange and (b) ensure a consistent level of "authentication" before issuing PKI credentials. It's no so much different from various different organizations issuing plastic "membership" cards that populates everyone's wallet these days. -Martin > On 4/30/2012 9:03 PM, Martin Rex wrote: > > Moudrick M. Dadashov wrote: > >> Directive 1999/93/EC: > >> > >> in order to stimulate the Community-wide provision of certification > >> services over open networks, certification-service-providers should be > >> free to provide their services without prior authorisation; prior > >> authorisation means not only any permission whereby the > >> certification-service-provider concerned has to obtain a decision by > >> national authorities before being allowed to provide its certification > >> services, but also any other measures having the same effect; > > In practice, the legal requirements (at least in Germany) for most > > regulated usage scenarios require the use of a "qualified signature" > > or a specific trust center (e.g. Elster, GKVNet). > > > > -Martin > > > > > >> On 4/30/2012 6:58 PM, Martin Rex wrote: > >>> Erik Andersen wrote: > >>>> I have received questions for which I need help to answer. The question is > >>>> as follows > >>>> > >>>> - Is that any government requires payment of fees by electronic signature > >>>> service providers > >>>> > >>>> - If this is the case, what is the frequency of payment and above what is > >>>> the amount > >>>> > >>>> I believe that the first question is: Are there examples where a PKI service > >>>> provider needs to pay a license fee to the government? > >>> I doubt that countries sell "license for running electronic signature > >>> services" similar to how they sell licenses for radio frequencies. > >>> > >>> But the cost incurred (audits,accreditation) to create "trustworthy" > >>> electronic signatures might be non-marginal, e.g. such as for issuing > >>> certs that permit creation of "qualified signatures" in the EU: > >>> > >>> http://europa.eu/legislation_summaries/information_society/other_policies/l24118_en.htm > >>> > >>> > >>> -Martin > >>> _______________________________________________ > >>> pkix mailing list > >>> pkix@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pkix > >> > > From swilson@lockstep.com.au Mon Apr 30 22:20:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BCD21F87E8 for ; Mon, 30 Apr 2012 22:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uhwbl8EkBARU for ; Mon, 30 Apr 2012 22:20:16 -0700 (PDT) Received: from smtp152.iad.emailsrvr.com (smtp152.iad.emailsrvr.com [207.97.245.152]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF6021F87E7 for ; Mon, 30 Apr 2012 22:20:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp45.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 15FF790221 for ; Tue, 1 May 2012 01:20:11 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp45.relay.iad1a.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTPA id BBE1990244 for ; Tue, 1 May 2012 01:20:09 -0400 (EDT) Message-ID: <4F9F7273.8040200@lockstep.com.au> Date: Tue, 01 May 2012 15:19:47 +1000 From: Stephen Wilson User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <201204301803.q3UI3gPO021732@fs4113.wdf.sap.corp> <4F9F1C8F.5080405@e-net.lt> In-Reply-To: <4F9F1C8F.5080405@e-net.lt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] License fee for running a PKI X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: swilson@lockstep.com.au List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 05:20:17 -0000 Yes, in Europe, for all parties to fully enjoy the protections of qualified e-signatures laws, the CAs have to be accredited under a recognised scheme like "tScheme". I thought the same thing applied in the very first digital signatures regime in Utah? I thought CAs there had to be licensed, and part of that was audit by a recognised accounting firm? A similar scheme technically applies in Hong Kong where the CA Recognition Authority is supposed to accredit CAs under the E-Tansactions Ordinance. I say "technically" because participation in CARO and all similay systems even in Europe is weak. There are costs involved and the cost-benefit remains uncertain while usage of certificates in open commerce remains low. On the other hand, use of certificates in closed commerce is healthy but does not require independent homolugation because specific contracts apply. If there is cause for government endorsement of digital certificates, then it follows that a conformance assessment regime is necessary, and there would generally be costs associated with participating. Costs of doing business, just like the need for banks, medical establishments, airplane manufacturers and so on to be audited under all sorts of rules. Cheers, Steve Wilson Lockstep http://lockstep.com.au On 1/05/2012 9:13 AM, Moudrick M. Dadashov wrote: > Do those "trust centers" need a formal registration/approval by local > authorities? > > Thanks, > M.D. > > On 4/30/2012 9:03 PM, Martin Rex wrote: >> Moudrick M. Dadashov wrote: >>> Directive 1999/93/EC: >>> >>> in order to stimulate the Community-wide provision of certification >>> services over open networks, certification-service-providers should be >>> free to provide their services without prior authorisation; prior >>> authorisation means not only any permission whereby the >>> certification-service-provider concerned has to obtain a decision by >>> national authorities before being allowed to provide its certification >>> services, but also any other measures having the same effect; >> In practice, the legal requirements (at least in Germany) for most >> regulated usage scenarios require the use of a "qualified signature" >> or a specific trust center (e.g. Elster, GKVNet). >> >> -Martin >> >> >>> On 4/30/2012 6:58 PM, Martin Rex wrote: >>>> Erik Andersen wrote: >>>>> I have received questions for which I need help to answer. The >>>>> question is >>>>> as follows >>>>> >>>>> - Is that any government requires payment of fees by electronic >>>>> signature >>>>> service providers >>>>> >>>>> - If this is the case, what is the frequency of payment and above >>>>> what is >>>>> the amount >>>>> >>>>> I believe that the first question is: Are there examples where a >>>>> PKI service >>>>> provider needs to pay a license fee to the government? >>>> I doubt that countries sell "license for running electronic signature >>>> services" similar to how they sell licenses for radio frequencies. >>>> >>>> But the cost incurred (audits,accreditation) to create "trustworthy" >>>> electronic signatures might be non-marginal, e.g. such as for issuing >>>> certs that permit creation of "qualified signatures" in the EU: >>>> >>>> http://europa.eu/legislation_summaries/information_society/other_policies/l24118_en.htm >>>> >>>> >>>> >>>> -Martin >>>> _______________________________________________ >>>> 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 ietf@augustcellars.com Mon Apr 30 22:33:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E516421F862F for ; Mon, 30 Apr 2012 22:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFDfh2u2oN5x for ; Mon, 30 Apr 2012 22:33:53 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3612F21F8615 for ; Mon, 30 Apr 2012 22:33:53 -0700 (PDT) Received: from Tobias (static-50-34-17-238.evrt.wa.frontiernet.net [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id D90282CA11 for ; Mon, 30 Apr 2012 22:33:51 -0700 (PDT) From: "Jim Schaad" To: References: <20120430221412.14637.78574.idtracker@ietfa.amsl.com> In-Reply-To: <20120430221412.14637.78574.idtracker@ietfa.amsl.com> Date: Mon, 30 Apr 2012 22:32:50 -0700 Message-ID: <015501cd275b$dbdd8f10$9398ad30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH2am+JGaXlIRPxbwtwpnnfB9A/jpZh4sAQ Content-Language: en-us Subject: [pkix] FW: I-D Action: draft-ietf-pkix-pubkey-caps-06.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 05:33:54 -0000 This update is to address IESG comments. > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, April 30, 2012 3:14 PM > To: i-d-announce@ietf.org > Cc: pkix@ietf.org > Subject: [pkix] I-D Action: draft-ietf-pkix-pubkey-caps-06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Public-Key Infrastructure (X.509) Working > Group of the IETF. > > Title : S/MIME Capabilities for Public Key Definitions > Author(s) : Jim Schaad > Filename : draft-ietf-pkix-pubkey-caps-06.txt > Pages : 25 > Date : 2012-04-30 > > This document defines a set of Secure/Multipurpose Internet Mail > Extensions (S/MIME) Capability types for ASN.1 encoding for the > current set of public keys defined by the PKIX working group. This > facilitates the ability for a requester to specify information on the > public keys and signature algorithms to be used in responses. An > example of where this is used is is detailed in Online Certificate > Status Protocol Algorithm Agility (RFC 6277). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-pubkey-caps-06.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-pkix-pubkey-caps/ > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix