Re: [Trans] Threat model outline, attack model

Ben Laurie <> Fri, 26 September 2014 14:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CFF991A88F1 for <>; Fri, 26 Sep 2014 07:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3toir7XjKZ7j for <>; Fri, 26 Sep 2014 07:28:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A34FE1A88E4 for <>; Fri, 26 Sep 2014 07:28:36 -0700 (PDT)
Received: by with SMTP id a13so950513igq.1 for <>; Fri, 26 Sep 2014 07:28:36 -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=VdhQx8zCdsSCNhoLfgUrk2VHJk4rEilettzpEt8ZpNE=; b=RzolGWa/U7fsk19PyzRyroHfzXHH184VMC0AFHcZ+kfOK6uVh28CftU6swcoGuqWmZ Hl+mYlJjfJfDFzPJTQ4PCSEt8uCbK3LLXN5Q3N8lv/4pv75qWlZsdN1LvyfiruyKIa0e wNaFe9CXUhAADYm0XOwDhjSYob7f8vYeM1ZuF0UqD/f4bz8XHhSMO3qaBTbUdg86WUQn xoLHuHjAEuTELdnbUuBm/27hI+pLwflJntUuIJYrwMHTrQYOCY23Me2o8t6kZuLVK6rE kEvF08AzNI+yoinw87yU1Oxzrmh2We5SlfZT9hj87FVOSTcvbYFVElM5lmiHnixWTAGp nOig==
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=VdhQx8zCdsSCNhoLfgUrk2VHJk4rEilettzpEt8ZpNE=; b=CIIdqIzt+03FbLJyuhp/Z0YP/ks0zE1dQsafDoNmL4k3UFMyh/lNiWG5YLxhCJd7SY Xv/UEGGNXVu5QxzafzhylgktysKkifGu9iLB3043Mzq+ybj9UK4OAfjjvhUQ4B/kA9nB T21G5opzPjTgpW6Cwb/jNZ7Z8ghqRUW7JIoJ9oTPsWsFbGFRRavUBlUqbS+q7MT5z5s8 mVFCtcD6YOr4Qo2YIsGBtOyjweBY7hNu+797Cn4QW3vHGdTnQaDKvu///9CjgqLeSr03 H4SPC2XcbPbtFmeDf9Z7BYqH9wHQTHeminEltC0to54lb/qvQ3I6D4817N15YaT5gorA m6cw==
X-Gm-Message-State: ALoCoQms4bJpisFMvB+eyi6e+PJA9rUDkXv06cxcsbLkMEvETAnwrso+Mn76wq3ClKya1wO+g6mL
MIME-Version: 1.0
X-Received: by with SMTP id f1mr30569211igr.38.1411741715971; Fri, 26 Sep 2014 07:28:35 -0700 (PDT)
Received: by with HTTP; Fri, 26 Sep 2014 07:28:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Fri, 26 Sep 2014 15:28:35 +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: Fri, 26 Sep 2014 14:28:43 -0000

On 25 September 2014 16:06, Stephen Kent <> wrote:
> Ben,
>> ...
>>> 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...
> Mis-issuance is the primary (sole?) rationale for CT, so I am not
> comfortable
> with the notion that mis-issuance is not well-defined.

Reality doesn't always make us comfortable :-)

We keep finding new ways for people to get certs wrong, and thus
creating new rules for them. Also, the exact rules are context
dependent, and may even depend on contracts and other things we can't
even see.

>>>      - 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).
> I'm puzzled; how would CT allow a Monitor to determine who generated the
> key pair used in a cert that was logged? I don't understand your example
> here.

I said it wouldn't, so you are right to be puzzled.

>> 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.
> Well, if we can't say how this is done, preferably based on some standard,
> then we can't make an argument that, after being being detected by CT, that
> there is a fix. If so, then the security considerations section will have to
> discuss this residual issue.

I think we have ample evidence that there are fixes to mis-issuance.
Some of them are based on standards, too (e.g. revoking in CRLs or via