Re: [pkix] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt

Nikos Mavrogiannopoulos <> Wed, 13 September 2017 06:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D419F133077; Tue, 12 Sep 2017 23:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hBDY8916-zKd; Tue, 12 Sep 2017 23:40:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF5A11321A2; Tue, 12 Sep 2017 23:40:02 -0700 (PDT)
Received: by with SMTP id j5so436746qkd.0; Tue, 12 Sep 2017 23:40:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vmuhzgs6kGH2SyWUAWp1fH4uDVExcR8PV10GSAitkBA=; b=hEcNF2ljPvaE2LH0bR0nHVDYgdAJdkAwrg9xELatxGhio/tPuu9TpKDpxNxAFHgiOs u1Bcbf7ML4Pkee0RyFoLTFWKXBnbEQXNHPr2CQjar015WYyrA0FWadGQGnJbd26VGOa6 8lQtnidV6oDSG+wzM6730PHSfbvQBCod+nhNg0LEz57S/5wcJ/32gPM/b4BAzVLcsj49 cKvQGxLrS/hQA3Ge+p5pLTHgqBOeFrwGpWi6ohEqmm/RRwXdTsXy4l99HEx1kj+nmBzp BNpfvxP+YRRQCF9ugP77E/+OJYE0i8iBDGDcEeSyz7mxSu3dTRs0acDyVI0BxRBtRbEk Zp8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vmuhzgs6kGH2SyWUAWp1fH4uDVExcR8PV10GSAitkBA=; b=IS698P0Zuq43foVotrbueWfFTlNv3FYTsVBF42ZN4m7CkTQccQdpIA5k/PiQWeoz6b ho6ddjcOkKHmwdKm+RIsxR9d1MM9gKoXnYH4sZD14L+rdq2MW6WS7gNpz+XKCidW6fmI 9Aj0XyYYUa9S6yM3vX+tDlc0hj6ZAqP6Pzj/tRjW1LvSDSOzBL7lIGJH7LL+iFEVU3sj Zxy05XPuH+48AOO+Yl7QEI0vDP6a2OfCq/uqgLrupZ2XH7AHc4pTNlT3AVf6NtslfwbR u9Z9n+tgq5jnE2efOzC6rIF80yoQmqMpTGAiPMFfB3UXrJynO5F3/Qugnw9I66IKQ24U qoiQ==
X-Gm-Message-State: AHPjjUjj0iYljAohQAVnBOGTTDDO1z51plr1W8DJOcs2J5gr1qg3tEAJ sQyfd0DF2zedc0jKKthC0Vy8ueI4dGzNSzi6Kx68tDFH
X-Google-Smtp-Source: AOwi7QCbGWPjaFGNCtozIjRcuIi3D3N/nMHO0wWFI+mTbm8bjx5zZJl0FWaWOMjWhgAXuEjReYYx6bF4nWm+Gsrrz+Y=
X-Received: by with SMTP id e123mr24767138qkf.128.1505284801569; Tue, 12 Sep 2017 23:40:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 12 Sep 2017 23:39:21 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Nikos Mavrogiannopoulos <>
Date: Wed, 13 Sep 2017 08:39:21 +0200
X-Google-Sender-Auth: zTfCaHN7zsUhKnKDKgjEoQ4OiQE
Message-ID: <>
To: Dmitry Belyavsky <>
Cc: "" <>, LAMPS <>,,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [pkix] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Sep 2017 06:40:05 -0000

On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky <> wrote:
> Hello,
> Here is the new version of the draft updated according to the discussion on
> mozilla-dev-security list.

 It seems that most of the details of the underlying format are
missing. As far as I understand it is mostly an intentions document at
this point right? I have few comments:

1. requiredX509extensions: What's the reasoning behind this? If these
extensions are required and not present why keep the root certificate
in the trust store?

2. What is the difference between issuedNotAfter and trustNotAfter?
The description text is unclear to me.

3. applicationNameConstraints: very useful, however it is unclear from
the ASN.1 description how are these stored.

4. How do you handle extensions to this format?

Overall, why not use X.509 extensions to store such additional
constraints? We already (in the p11-kit trust store in Fedora/RHEL
systems) use the notion of stapled extensions to limit certificates
[0, 1] and seems quite a flexible approach. Have you considered that