IETF Logo Mail Archive

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

Dmitry Belyavsky <beldmit@gmail.com> Wed, 13 September 2017 11:22 UTC

Return-Path: <beldmit@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 7C22B120720; Wed, 13 Sep 2017 04:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 yYZMWCV4kSiC; Wed, 13 Sep 2017 04:22:19 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DC2133341; Wed, 13 Sep 2017 04:22:18 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id a137so7247058wma.0; Wed, 13 Sep 2017 04:22:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bfjVObCiCgnNgXq38MobIKw1e0SFCac2liIqS1vO1EQ=; b=qPn40AcB0ypgZ6N15g2mIs38pQ5qUBsq1Ti3tsyKsIKMUtCYkDWdNyYH0GIr2dsZMV UqWBS96T5U7X8X84Wlk9DLDJhO8cd1sQG6Q+OIcvtoNRJjSVNCc+3mi9xp8sYG0Aw3SM EQGta+wIyrVLnsdVY8zk96QDxOAuOcxht/gTfmB+bfFLyAYSwbJ7gG7mBnHB0YkCciIT dZGIuG7VBBeoTxw3XJtjeSFg5dH0GwgtS7NlecdORF2WH87cwuR8WALjdh6Mm9g2bNbX vTDHqwBWUn2sguXy8mLRjOAFcPMTRL7v4jjTUerTzQ9xuk/VGyX6GJ86tNlzU2P1xk/V pVEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bfjVObCiCgnNgXq38MobIKw1e0SFCac2liIqS1vO1EQ=; b=amexFCdou+dc4Dyj3JJZo8dIkxgqPmxKIjpMJKmUKz+b1An4x4/BbCo/7TkWOsO39k W6c1VYifXs+z2HGGwQSOAUeNMmDof7Jtn1IXisQoY+1KyYXlm58sxrB/VE4PwyR4frUW NeXoO/F9drcd1o1SkUe2vaRxqZyF9rx3fk9Ol4/XE21w4Bw1rJSfPc34ZaEMabxsP8pg oRyCXFERniqPLQoIlwO9drYUo+bbOA4HkNy3XQ8HiNyhh8Xi3m5hDgYzIURmAYzzLY2b HszJAJZkW0zGHl7Sz6Db5oXXNHIG/m7IfgR5tr+ndGZaN7Xio0tw8jPirokwEsTypcQ+ Rr9w==
X-Gm-Message-State: AHPjjUh3srZQkaxoZoTT1Y+MW+w+qEtbUUBfrz2tIrFyaUqGZzCoU1ko wrMc4yPE5yl8CgBhvePVvPoGoL8ypvqheJq5+Eg=
X-Google-Smtp-Source: ADKCNb4+k0R1/F7EKBZjgrBrrqWMxalFHtiaNjd5UoRLLZhdy3TYv7IECGLZZVC3/c1NwdoOek9pZ6RuyMFvb7B/fec=
X-Received: by 10.80.153.98 with SMTP id l31mr13607104edb.69.1505301737412; Wed, 13 Sep 2017 04:22:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.186.44 with HTTP; Wed, 13 Sep 2017 04:22:16 -0700 (PDT)
In-Reply-To: <CAJU7zaLsza65gvERm__njLYM82jGWx9ht_QwHi+e6WQAtFKsZA@mail.gmail.com>
References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> <CADqLbz+OB86s4E-Ntr6eaEow+sBtxscJ703nGN+PAS7zQmJ==Q@mail.gmail.com> <CAJU7zaLsza65gvERm__njLYM82jGWx9ht_QwHi+e6WQAtFKsZA@mail.gmail.com>
From: Dmitry Belyavsky <beldmit@gmail.com>
Date: Wed, 13 Sep 2017 14:22:16 +0300
Message-ID: <CADqLbzJHKu9O6XuzJAnFV2JgUL8HtYPVNLdU=UF=n-HqYK4-VQ@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Cc: "saag@ietf.org" <saag@ietf.org>, LAMPS <spasm@ietf.org>, dev-security-policy@lists.mozilla.org, pkix@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0de59c569dc00559105f15"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/-GkrvbPs-Xava3iB3D6YllWFPwY>
Subject: Re: [pkix] [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 13 Sep 2017 11:22:26 -0000

Dear Nikos,

On Wed, Sep 13, 2017 at 9:39 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org>
wrote:

> On Tue, Sep 12, 2017 at 2:59 PM, Dmitry Belyavsky <beldmit@gmail.com>
> wrote:
> > Hello,
> >
> > Here is the new version of the draft updated according to the discussion
> on
> > mozilla-dev-security list.
>
> Hi,
>  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:
>

The format will be CRL-like.

>
> 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?
>

The main intended case is "require Certificate Transparency".
Currently using the CT is not mandatory for all CAs.


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

issuedNotAfter - we do not trust to the certificates issued after the date.
trustNotAfter - we do not trust certificates after the date XXX, if they
have notAfter > XXX


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

I'm not so familiar with ASN1 format. I think that syntax from RFC5280 will
fit here.

>
> 4. How do you handle extensions to this format?
>
> Simillary to CRL. Do you have ideas of the extensions?


> 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
> path?
>
> regards,
> Nikos
>
> [0]. https://p11-glue.freedesktop.org/doc/storing-trust-policy/
> storing-trust-model.html
> [1]. http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-
> certificates.html
>

Thank you very much, I'll look at it.

-- 
SY, Dmitry Belyavsky

v2.23.0 | Report a Bug | By Email