Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.

Erwann Abalea <eabalea@gmail.com> Tue, 19 February 2013 17:08 UTC

Return-Path: <eabalea@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E87C21F8A64 for <pkix@ietfa.amsl.com>; Tue, 19 Feb 2013 09:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level:
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+OC-GzSCIy9 for <pkix@ietfa.amsl.com>; Tue, 19 Feb 2013 09:08:11 -0800 (PST)
Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4DA21F8A52 for <pkix@ietf.org>; Tue, 19 Feb 2013 09:08:11 -0800 (PST)
Received: by mail-vc0-f182.google.com with SMTP id fl17so4444170vcb.13 for <pkix@ietf.org>; Tue, 19 Feb 2013 09:08:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uECMospdkywRbMjptomgxUFlAj5ZeYwSw3g6dpPZp5g=; b=iMv0jq3WCiGheE7q0DBmwrn/nOJFXtwHc/BZB8xz7UKFcrHVKEoRhWONTnCzrNmOnZ 9NNohjlmM4K2rQVUaiNxsGlY0ZzFNs4Ffx59TCu9ExrVGvBrGeE6ZvrGdItKWv4BLrBC wzC4ODa8OTT230BMmdgi/8lkoALS5g/j/+YbyvsI1wyswvwHQiPjU4tgf0Gn/IjOq0dK 60W7H5m+drjg1SuVrhtcwACWn6izJOUEBKrmG/GvemXl61pnQbGWgKIi9G8H9W2IRU/M 83AIoHfpNonw+0Uz5CSyTzRQ+n5xlEZbT/oaXE+iCnq3+EYxEqrsqDnnvEFDi2v5gjBN QzQQ==
MIME-Version: 1.0
X-Received: by 10.220.219.208 with SMTP id hv16mr6013418vcb.62.1361293690679; Tue, 19 Feb 2013 09:08:10 -0800 (PST)
Received: by 10.52.156.49 with HTTP; Tue, 19 Feb 2013 09:08:10 -0800 (PST)
In-Reply-To: <5123AD0B.4050709@bull.net>
References: <5123AD0B.4050709@bull.net>
Date: Tue, 19 Feb 2013 18:08:10 +0100
Message-ID: <CA+i=0E4g7GRmHAsM34RHEsvEMvwVxfkkfXayLA7ycSU7q-QTMQ@mail.gmail.com>
From: Erwann Abalea <eabalea@gmail.com>
To: Denis Pinkas <denis.pinkas@bull.net>
Content-Type: multipart/alternative; boundary="14dae9cfce5ede31e304d616e275"
Cc: pkix <pkix@ietf.org>
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 19 Feb 2013 17:08:12 -0000

Bonjour,

2013/2/19 Denis Pinkas <denis.pinkas@bull.net>
[...]

> Mozilla announces on
> https://lists.mozilla.org/listinfo/dev-security-policy: “*The subscribers
> list is only available to the list administrator”. *
>

That's classic.


> So it is quite hard to know who was on the discussion list and thus who
> participated to the discussion.
>

No, the list itself is public. You can use their newsgroup server, or
Google Groups to access it.
The discussion is accessible here
https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security.policy/Rbc-5j6i-vY


> ****
>
> Since the publication is recent (February 14, 2013), it might be
> appropriate to ask to the Mozilla community to respect the compliance
> to the standards. In order to fulfil its needs, the Mozilla community
> should:****
>
> -          either define its own extension,****
>
> -          or, propose a new extension so that it can be published in an
> RFC according to the IETF rules.****
>
>
I proposed to rely on certificatePolicies extension. That's the purpose of
this extension. Unfortunately, it's often incorrectly used, so that would
need a cleaning step and a definition of standardized policyIds for
specific purposes.

-- 
Erwann.