Re: [Trans] Threat model outline, attack model

Ben Laurie <> Thu, 25 September 2014 11:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 68CAA1A1A85 for <>; Thu, 25 Sep 2014 04:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.765
X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z-EDHDdA4O0I for <>; Thu, 25 Sep 2014 04:42:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD2291A1A76 for <>; Thu, 25 Sep 2014 04:42:55 -0700 (PDT)
Received: by with SMTP id k15so4378423qaq.21 for <>; Thu, 25 Sep 2014 04:42:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AeAC2YvdaDy3n0ga0Uhch5Ysh4q1Ofe8bxVnYRnXDTM=; b=ouk8I4iQ5FhR+Z1Wj+V9Wpy4X6a5FkE0MbnnQuwOqwksAbrveOqH+POfaM+wFHGAcK UX6TQD1KzKqghX3wSHmWO3rsVaEtTDJJB9Kcmt4pwTO+Xjvwn7tezspFeRUl3+OWhaYc jf5FU/n2Yv4/760MmsBqC+RscqAxQISfM2UszaLZLR93ozVxBBGRr5RRh947tIrQu4+E MSnpiayEAP2TJmWI8ejuLvHl0Or4+Xsmapaii5An1nAImkQw3tZ54T1b1MLfskufRHGe EJNJ9NaGWPJAYGqoxjaor9q1mvZbDMxv0ixFcpCCAvOqS/6yDum4euOqBhLSP+4d1gCq htsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AeAC2YvdaDy3n0ga0Uhch5Ysh4q1Ofe8bxVnYRnXDTM=; b=ebuWKKQuzyZbuVnB3OkZWelihufuDhWhgB8teD4pitV1ZcKdy5BQcepC33ogpRA+tU N07SBggzfEVqQHG7gUPIy1l0eYC+d1ExxjcAp6rUD718tSX7tSNUzOKM1prPn4lYrc7M XTtEUHaebBDJsLLbwgXCX4X05yk0/syKgbKOVA61JYESYLfkv7UhWrMRuMHJs52/ECJz 4MFRpcH2Hnt93GvAAyZzggIRqNrWtmQCveNeDUXDZTGqC8FbQ+9kHOhkgZCdWKm/MLPS Urwv7Zp95gvAINjeGT9FYytvbddV9sg9pVuPssUubFxYH1OysnzjFbvWVXlRnfnSESVs SSuA==
X-Gm-Message-State: ALoCoQnn7WImHuyB3Sa7qfCuxwqdaCfwnnOonp7Lcn02eC3rVLH6jbXXmThZPFt02Q6fiRJx3Ddr
MIME-Version: 1.0
X-Received: by with SMTP id i11mr17400671qgf.70.1411645374787; Thu, 25 Sep 2014 04:42:54 -0700 (PDT)
Received: by with HTTP; Thu, 25 Sep 2014 04:42:54 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 25 Sep 2014 12:42:54 +0100
Message-ID: <>
From: Ben Laurie <>
To: Stephen Kent <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [Trans] Threat model outline, attack model
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Sep 2014 11:42:57 -0000

Apologies for delay.

On 15 September 2014 19:52, Stephen Kent <> wrote:
> Ben,
> Thanks for explaining what you and your co-authors have in mind when
> you use the term mis-issuance. This is a very important first step toward
> clarification for CT.
>>> A certificate is characterized as mis-issued if the certificate is issued
>>> to
>>> an entity that is not authorized to represent the host (web server) named
>>> in
>>> the certificate Subject field or Subject Alternative Name extension. <do
>>> we
>>> want to focus exclusively on SAN vs. Subject?)
>> This is not the only form of mis-issue - for example, the Baseline
>> Requirements impose key size limits, lifetime limits, usage bits
>> restrictions and so forth.
>> EV adds even more stuff.
> So the scope of mis-issuance is much broader than what I had imagined.
> I think we may need to add two things to 6269-bis:
>     - normative references to CABF documents that are the basis for the
> broader
>       set of cert issuance criteria that you note

This seems sensible. Note, though, that I would not want to constrain
mis-issue to be solely defined by CABF. Part of the point is that
anyone can monitor any aspect of issuance they want, and if they think
something is wrong, raise it to appropriate authorities...

>     - maybe two appendices to enumerate the criteria. this will be critical
> if
>       if the CABF docs contain other criteria that are outside the scope of
> CT,
>       e.g., criteria that cannot be evaluated based on what is logged.

It would certainly be interesting to know though I don't think it is
essential - an example of something CT cannot reveal is who generates
the key (obviously it is bad practice for CAs to do this for their
customers - I don't know if BRs or EV ban the practice though - in any
case, CT would not tell you who did it).

> Do you agree?
>>> ...
>> The other recourse is to revoke directly in the browsers - either the
>> whole CA or the offending certificate(s). This is what happened to
>> DigiNotar, for example.
> I agree that one might do that, but I am aware of no IETF standards for
> doing so. My understanding is that DigiNotar, as a trust anchor, was
> removed from the TA list. I am not aware (but then I am not a browser
> vendor) of an equivalent mechanism for CAs below TAs. Also, the TA list
> mechanism is not an IETF standard. We need to cite a spec, preferably
> a standard, on how to deal with browser-based revocation. Is there an
> appropriate CABF document that needs to become a normative reference?

As far as I know there are no standards in this area. Chrome contains
a blacklist of certificate hashes (from memory, its been a while since
I looked at this) - I don't know what other browsers do.