Re: [lamps] New draft: rfc6844bis

Quirin Scheitle <scheitle@net.in.tum.de> Tue, 05 June 2018 14:46 UTC

Return-Path: <scheitle@net.in.tum.de>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D8A1310C4 for <spasm@ietfa.amsl.com>; Tue, 5 Jun 2018 07:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 V9HnJ7dFeEAz for <spasm@ietfa.amsl.com>; Tue, 5 Jun 2018 07:46:00 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF641310C1 for <spasm@ietf.org>; Tue, 5 Jun 2018 07:45:59 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id DE3EC282F030; Tue, 5 Jun 2018 16:45:52 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Quirin Scheitle <scheitle@net.in.tum.de>
In-Reply-To: <CAErg=HHwHpWeMB3BZQT3dRHU03tu5MYcqp3JMuHpWRdun3_O5Q@mail.gmail.com>
Date: Tue, 05 Jun 2018 16:45:52 +0200
Cc: Jacob Hoffman-Andrews <jsha@eff.org>, SPASM <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <87ED5E88-D2F8-4455-86B3-8FCC3661EA9F@net.in.tum.de>
References: <d25080b7-d21c-219e-8d99-7c19afb5b30f@eff.org> <98CFF920-80A3-420C-BD15-104140FAD48B@net.in.tum.de> <CAErg=HHwHpWeMB3BZQT3dRHU03tu5MYcqp3JMuHpWRdun3_O5Q@mail.gmail.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/KqYdvoxXdUQJVkh_QjIpRHgdaJw>
Subject: Re: [lamps] New draft: rfc6844bis
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jun 2018 14:46:03 -0000

> On 5. Jun 2018, at 12:02, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> 
> 
> 
> On Tue, Jun 5, 2018 at 3:49 AM, Quirin Scheitle <scheitle@net.in.tum.de> wrote:
> 3) Validation Type   ######################
> 
> We suggest a tag (i.e., not a parameter) to permit domain-level control of permitted/restricted validation methods. E.g., an entry such as 
> 
>   tum.de 0 CAA 128 dcv "dns-cname"
>   tum.de 0 CAA 128 dcv "domain-contact-postal"
> 
> would permit dns-cname and domain-contact-postal methods. An entry such as 
> 
>   tum.de 0 CAA 128 nodcv "tls-sni”
> 
> would restrict the tls-sni method, but permit all others. 
> A mapping of BR/ACME defined methods to usable names would have to be conceived. 
> This could have helped in the TLS-SNI problem a couple of months ago.  
> 
> 4) Validation Level    ######################
> 
> We suggest a tag to define a minimum validation level. E.g., 
>         tum.de 0 CAA 128 vlevel "ov"
> In this example, the validation level tag vlevel would specify
> that for tum.de, only OV or EV certificates may be issued.
> This could, e.g. be used by domain name holders that exclusively
> obtain EV certificates, such as financial institutions,
> to proactively close the attack surface of DV methods.

Hi Ryan,

thank you for your reply! 

> 
> I am not supportive of either of these as part of 6844-bis.
> 
> Both of these concepts are specific to a particular industry and set of policies (namely, the commercial Web PKI and the CA/Browser Forum documents), and as such, do not have normative references and are not standards themselves that can be referenced.

That sounds convincing to me. Happy to move that part (#3 and #4) over to CABF VWG.

> 
> I am supportive of the former, to be defined in the CA/Browser Forum. While this document might countenance syntax of such an expression, the semantics of such an expression is inherently tied to the CA/Browser Forum's validation requirements, and thus exclusively should be viewed in that lens.
> 
> I am not supportive of the latter, even in the CA/Browser Forum, as they're unnecessary expressions of syntax for what can already be achieved via policy. That is, by restricting the set of CAs that can issue, one can already restrict the type and nature of certificates issued. For nominal views of 'high' security, this is the only defensible position - as shown by the ample OV and EV misissuance of CAs.

The way I understand your answer, you imply it would be bad if “vlevel” would be used *instead* of issue/issuewild tags. I full agree to that.
I meant “vlevel” to be an addition to issue/issuewild:
If I am an institution only using EV, and permit only CAs X and Y, attackers could still obtain DV certificates from CAs X or Y. 
With vlevel “ev”, attacks only using DV level would fail. 
[This part of the discussion can also be continued at the VWG, I guess]

Kind regards
Quirin