Re: [Trans] Precertificate format

Stephen Kent <kent@bbn.com> Wed, 10 September 2014 16:08 UTC

Return-Path: <kent@bbn.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82AE1A8786 for <trans@ietfa.amsl.com>; Wed, 10 Sep 2014 09:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.832
X-Spam-Level:
X-Spam-Status: No, score=-4.832 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
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 185ZaAfcoWem for <trans@ietfa.amsl.com>; Wed, 10 Sep 2014 09:08:21 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3A41A876A for <trans@ietf.org>; Wed, 10 Sep 2014 09:08:19 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:47844 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XRkRc-000JOi-Nk for trans@ietf.org; Wed, 10 Sep 2014 12:08:32 -0400
Message-ID: <54107771.501@bbn.com>
Date: Wed, 10 Sep 2014 12:08:17 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
CC: "trans@ietf.org" <trans@ietf.org>
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com> <4B184DAD-3C7A-4032-8BA6-634736BB2689@paypal.com> <540F3B42.3000708@bbn.com> <CABrd9SS4NgJo8mX72fB_9q4u8jQ5NQYsyk5hxPZvXxyfERvvcg@mail.gmail.com>
In-Reply-To: <CABrd9SS4NgJo8mX72fB_9q4u8jQ5NQYsyk5hxPZvXxyfERvvcg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/B1IY49kS3XaDz0oY-_Z-Tkxbz8E
Subject: Re: [Trans] Precertificate format
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Sep 2014 16:08:29 -0000

Ben,

> On 9 September 2014 18:39, Stephen Kent<kent@bbn.com>  wrote:
>> I agree that the serial number is critical if one plans to revoke the cert.
>> But ,
>> the I-D makes no mention of remediation mechanisms, an omission I noted in
>> my review
>> a while ago.
> It makes no mention because they are not in scope. The point of CT is
> to allow others to vet certificates and take appropriate action when
> needed.
As I noted earlier, there is no threat model for the CT mechanism.

And there is no mapping of CT to the threat model.

We usually do not standardize security mechanisms when these two
critical elements are missing.

> It is not up to us to describe all possible problems and how they are
> remedied. If you think that's a valuable exercise, be my guest.
There is a big difference between "all" and "none."
> However, when you suggest that inclusion of some particular thing is
> problematic, then we can, of course, refer to potential problems CT
> might reveal and available remedies as an illustration of why that
> thing is needed.
I don't know what this last, rather long sentence means. Please elaborate.

Steve