Re: [pkix] EKU for intermediate certificates
Carl Wallace <carl@redhoundsoftware.com> Thu, 04 February 2016 18:00 UTC
Return-Path: <carl@redhoundsoftware.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670FA1A8A65 for <pkix@ietfa.amsl.com>; Thu, 4 Feb 2016 10:00:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9ctEzLGF7Ya for <pkix@ietfa.amsl.com>; Thu, 4 Feb 2016 10:00:38 -0800 (PST)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FAE31A8A63 for <pkix@ietf.org>; Thu, 4 Feb 2016 10:00:38 -0800 (PST)
Received: by mail-qg0-x232.google.com with SMTP id y9so43431615qgd.3 for <pkix@ietf.org>; Thu, 04 Feb 2016 10:00:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ss0BCRkIpfi1o+8YGJjkE2kGe28zZxE6oY/V1fS5b+Y=; b=idZ3tX2oMLXxj+Ti1WB3OFCmJNiRIK5xMAI3ljCkfaSXpLQ+IuHlZpzMKFPKJok/RY zMQwwa4pd8AZ7WFIbVHgFgv3np2Bb/GsO+MXiVPOZqObgdXezbKegaKnv/ra7ae9CyV+ 7HU/YAc+bqngAOy79fLw6aDpIoMtKmv23s/0m5s7vEkibeaLmRXlHEeH2EZMjdEZQLBt VALNxrKYTI3EL7gwzIA9ujBfHtpo/OPpl+rIx8Lfejb0Cx3DcD0P+XGhT7os7/TkUCUk viha77cztIwUNo2AWT5mkdQj664UX2/cskXzyJhyVr580z+VMWzwsMYDYJv5X164wR8I Dmlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ss0BCRkIpfi1o+8YGJjkE2kGe28zZxE6oY/V1fS5b+Y=; b=mfFfHthTmJGGcgSgJ9/jLYFpZP+0O5L+ssX7/EI8BpxHpMhi6q5v4zeZB7tbL7GURG lzGRcWIXvsc2/T5HESCvIRSQlVhIZuF+gIBfMPalPRYkeV+fybCNzA1RFMJBgNTm50pf 6GuntzaBiTN07TVzEmZmBW4icKmRNFG/Vqc4FwmTp6hxz+ekKDv1tvygoD/mN4Rs62a7 Kpu5VjfcMRHPXwvZzNKkLa7CY7sREfNtftR5p5e/Qv6ZunaGKQPWzGAkQOuxt+WszYza acVpcXWUBoW1wkcayG3ckFun0plG1Q0uCgg/Nej1VryoLnz5uSyhfm6VTkIae4iGqmD9 veBA==
X-Gm-Message-State: AG10YOTsxuVR21SLUpQaqtG2ga0FPTNPh8tMSKuv7t5QI28T3krG7f1tSjm5XhmjLqBHXA==
X-Received: by 10.140.93.247 with SMTP id d110mr10790406qge.28.1454608837179; Thu, 04 Feb 2016 10:00:37 -0800 (PST)
Received: from [192.168.2.27] (pool-96-255-23-4.washdc.fios.verizon.net. [96.255.23.4]) by smtp.gmail.com with ESMTPSA id m11sm5711078qkl.47.2016.02.04.10.00.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 10:00:36 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.5.8.151023
Date: Thu, 04 Feb 2016 13:00:29 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: Peter Bowen <pzbowen@gmail.com>, Santosh Chokhani <santosh.chokhani@gmail.com>
Message-ID: <D2D8FB5B.4B529%carl@redhoundsoftware.com>
Thread-Topic: [pkix] EKU for intermediate certificates
References: <D2D8B816.4B461%carl@redhoundsoftware.com> <033501d15f64$a8a9e590$f9fdb0b0$@gmail.com> <CAK6vND-mnioLesh-Y6+CP2XBndszVx5yxiBnv6TnrEowcpf8FA@mail.gmail.com>
In-Reply-To: <CAK6vND-mnioLesh-Y6+CP2XBndszVx5yxiBnv6TnrEowcpf8FA@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/ji_EfXaAhTR-6xnBrnD15JSXbR8>
Cc: "<pkix@ietf.org>" <pkix@ietf.org>
Subject: Re: [pkix] EKU for intermediate certificates
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2016 18:00:40 -0000
On 2/4/16, 12:17 PM, "Peter Bowen" <pzbowen@gmail.com> wrote: >The CA/Browser Forum sets standards for Certification Authorities. It >does not set requirements on implementers of path validation. Does this mean there would be no issue with defining a flag to allow for EKU semantics to be selected, since we now have two? Else we will rely on folklore to know which implementations do what. > >That being said, many current web browsers and OS path validation >libraries do enforce such constraints. This includes Microsoft and >Mozilla libraries, which underpin Internet Explorer, Edge, Firefox, >and Chrome/Opera on Windows. > >Thanks, >Peter > >On Thu, Feb 4, 2016 at 7:56 AM, Santosh Chokhani ><santosh.chokhani@gmail.com> wrote: >> According the authors of the CABF criteria (I hope they will speak up), >>the >> intent of the language is not to make the enforcement of constraint on >>the >> certification path mandatory. >> >> >> >> They simply want the issuer to indicate limitations it imposes on the >>CA. >> >> >> >> I am generally sympathetic to enforcement of the constraint on the path, >> however this is a significant change to the semantics of the extension >>and >> path validation engine. >> >> >> >> From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Carl Wallace >> Sent: Thursday, February 4, 2016 8:14 AM >> To: Koichi Sugimoto <koichi.sugimoto@globalsign.com> >> Cc: pkix@ietf.org >> Subject: Re: [pkix] EKU for intermediate certificates >> >> >> >> in the CAB Forum concept, if there any mechanism to indicate to a >>compliant >> validation engine that 5280 EKU semantics ought be used? Allowing a >>toggle >> probably beats simply changing the semantics of the extension for all >>cases. >> >> >> >> From: pkix <pkix-bounces@ietf.org> on behalf of Koichi Sugimoto >> <koichi.sugimoto@globalsign.com> >> Date: Thursday, February 4, 2016 at 8:08 AM >> To: "pkix@ietf.org" <pkix@ietf.org> >> Subject: [pkix] EKU for intermediate certificates >> >> >> >> Hello. >> >> >> >> I hope the following definition should be changed. >> >> >> >>>4.2.1.12. Extended Key Usage >> >>> >> >>> This extension indicates one or more purposes for which the certified >> >>> public key may be used, in addition to or in place of the basic >> >>> purposes indicated in the key usage extension. In general, this >> >>> extension will appear only in end entity certificates. >> >> >> >> >> >> Now CABF (CA Browser Forum) specified Extended Key Usage as: >> >> >> >> P9: >> >> Technically Constrained Subordinate CA Certificate: A Subordinate CA >> certificate which uses a >> >> combination of Extended Key Usage settings and Name Constraint settings >>to >> limit the scope within which the >> >> Subordinate CA Certificate may issue Subscriber or additional >>Subordinate CA >> Certificates. >> >> >> >> P34: >> >> ** Generally Extended Key Usage will only appear within end entity >> certificates (as highlighted in RFC 5280 >> >> (4.2.1.12)), however, Subordinate CAs MAY include the extension to >>further >> protect relying parties until the >> >> use of the extension is consistent between Application Software >>Suppliers >> whose software is used by a >> >> substantial portion of Relying Parties worldwide. >> >> >> >> P38-39: >> >> For a Subordinate CA Certificate to be considered Technically >>Constrained, >> the certificate MUST include an >> >> Extended Key Usage (EKU) extension specifying all extended key usages >>that >> the Subordinate CA Certificate is >> >> authorized to issue certificates for. The anyExtendedKeyUsage >>KeyPurposeId >> MUST NOT appear within this >> >> extension. >> >> >> >> Major browsers already support this specification, therefore, the next >>RFC >> should reflect this notation, I think. >> >> This notation is very important because we can restrict the range of >> influence when end-entity certificates are >> >> unwillingly issued by attacks etc. >> >> >> >> >> >> Please see below: >> >> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.2.pdf >> >> >> >> >> >> Regards, >> >> Koichi Sugimoto. >> >> _______________________________________________ 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 >>
- Re: [pkix] EKU for intermediate certificates 王文正
- Re: [pkix] EKU for intermediate certificates Russ Housley
- [pkix] EKU for intermediate certificates Koichi Sugimoto
- Re: [pkix] EKU for intermediate certificates Carl Wallace
- Re: [pkix] EKU for intermediate certificates Santosh Chokhani
- Re: [pkix] EKU for intermediate certificates Peter Bowen
- Re: [pkix] EKU for intermediate certificates Carl Wallace
- Re: [pkix] EKU for intermediate certificates Peter Bowen
- Re: [pkix] EKU for intermediate certificates Carl Wallace
- Re: [pkix] EKU for intermediate certificates Peter Bowen
- Re: [pkix] EKU for intermediate certificates Koichi Sugimoto
- Re: [pkix] EKU for intermediate certificates Koichi Sugimoto
- Re: [pkix] EKU for intermediate certificates Stephen Farrell
- Re: [pkix] EKU for intermediate certificates Koichi Sugimoto
- Re: [pkix] EKU for intermediate certificates Rob Stradling
- Re: [pkix] EKU for intermediate certificates Koichi Sugimoto
- Re: [pkix] EKU for intermediate certificates Rob Stradling
- Re: [pkix] EKU for intermediate certificates Carl Wallace
- Re: [pkix] EKU for intermediate certificates Erwann Abalea
- Re: [pkix] EKU for intermediate certificates Erwann Abalea
- Re: [pkix] EKU for intermediate certificates Peter Bowen
- Re: [pkix] EKU for intermediate certificates Peter Bowen