Re: [TLS] ETSI releases standards for enterprise security and data centre management

Ryan Sleevi <> Tue, 11 December 2018 13:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 261001277CC for <>; Tue, 11 Dec 2018 05:39:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AP6_gqr-RYu6 for <>; Tue, 11 Dec 2018 05:39:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F5B0126BED for <>; Tue, 11 Dec 2018 05:39:27 -0800 (PST)
Received: by with SMTP id h65so3793433ith.3 for <>; Tue, 11 Dec 2018 05:39:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IwF/0gYfuvHzXRAcNMD4nhgMRW+iNbFt24o+8xDJTPA=; b=jX7+iceh3BZHng0eNQkw821Qr4emk23LwX1wBaGBu20BSQpBgjqrFejGePSRO1v5AX qVCQECzkISI14Xuk3qoB6OGS0lGLmVm673CVSMIghP/mJiOq9KlEojvx8GAyRjvNPGep jZtfAOpfvubTTcyX9lgifxVXEA0J9YBztb9Wu205yV7wNCUikFXC35vFLmpK6eWJozsm +SI3KhCThL5/bVcI8VKRgNlBcEc+sHKIEVB4xpHs5VZx0bWWzbfEiEpHcbEIyT5qF6c1 VFM+Y8WmGLCbgFX24PCBuZAk/9WdgQ64pQI1jDJkNjG+rnJ0AGGiNQpAVtpYhjRY38fX BmAQ==
X-Gm-Message-State: AA+aEWZ3CU6Irdv3LBIQKbjXYyzL2NxpJ61VdAUh6m+zzBVchto4o7Ba 3EnM8LNDvoSz2Dl2SJRXUFSOGObL
X-Google-Smtp-Source: AFSGD/XGPneuuLIesEBqPhgxzvkPk73MhsiIXHvXQ3OoPSCY8Iimt2uNVkdLFpeimZbNLvAN4m4IWA==
X-Received: by 2002:a02:4d46:: with SMTP id l67mr15728588jab.141.1544535566708; Tue, 11 Dec 2018 05:39:26 -0800 (PST)
Received: from ( []) by with ESMTPSA id 125sm1296491itk.28.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Dec 2018 05:39:26 -0800 (PST)
Received: by with SMTP id a6so3787785itl.4 for <>; Tue, 11 Dec 2018 05:39:26 -0800 (PST)
X-Received: by 2002:a02:8a69:: with SMTP id e38mr15564702jal.81.1544535566018; Tue, 11 Dec 2018 05:39:26 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Tue, 11 Dec 2018 08:39:14 -0500
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Daniel Kahn Gillmor <>
Cc: Kurt Roeckx <>,
Content-Type: multipart/alternative; boundary="000000000000c17075057cbf35f5"
Archived-At: <>
Subject: Re: [TLS] ETSI releases standards for enterprise security and data centre management
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Dec 2018 13:39:29 -0000

On Tue, Dec 11, 2018 at 6:58 AM Daniel Kahn Gillmor <>

> On Sun 2018-12-09 18:35:20 +0100, Kurt Roeckx wrote:
> > On Wed, Dec 05, 2018 at 07:07:30AM +0300, Daniel Kahn Gillmor wrote:
> >> One mitigating factor of the ETSI standard, i suppose, is that the
> >> CABForum's Baseline Requirements forbid issuance of a certificate with
> >> any subjectAltName other than dNSName or iPAddress, so otherName looks
> >> like it must not be issued by standard public CAs.
> >>
> >> top of p. 44 of
> >>
> >> Has anyone set up tools to monitor the CT logs for such a sAN to see
> >> whether that element of the BR is being honored?
> >
> > All the linters will give an error about that, see for instance:
> >,cablint,zlint
> right, so what is to be done about that, when some of these CAs are
> clearly violating the BRs?  Transparency is only as useful as the
> actions we can take once violations are uncovered.  Unactionable
> transparency just sounds like despair to me.  So what's the action?

The same as it is for any misissuance:
1) Report to the CA’s problem reporting mechanism. The  Baseline
Requirements require they provide one in Section 1.5.2 of their CPS (BRs
Section 4.9.3). The CA is obligated to revoke such certificates and,
according to various root policies, report and/or disclose to the root
programs they participate in or publicly.

If you are unsatisfied with the answer you get from the CA, or want to
ensure greater transparency, you can/should also
2) Report to any root programs that trust those CAs.

The example from Kurt is from a CA that is ONLY trusted by Microsoft, and
which other programs have, sometimes explicitly, declined to trust. If CAs
are violating the contractual or public requirements of Microsoft’s root
program, such as the one demonstrated (although notably, it is NOT
displaying the use of this ETSI MITM extension), then that is an
enforcement action for Microsoft, or something for their customers to
respond to if Microsoft is shipping insecure CAs to them.

Your best-best-case is that publicly trusted CAs never issue such
certificates. Your worst-best-case is that the CA has to revoke within 24
hours/5 days of issuance, and that the root program takes the violation
into consideration when evaluating whether to trust that CA. Your
worst-worst case is that the CA ignores the revocation requirements, as
they did the issuance requirements, and that root programs that trust those
CAs fail to take action to ensure consistency among the CAs they trust and
with the requirements.