Re: [Trans] defining "mis-issuance"

Stephen Kent <kent@bbn.com> Fri, 03 October 2014 19:25 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 41F461A88D3 for <trans@ietfa.amsl.com>; Fri, 3 Oct 2014 12:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level:
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 FEfjV50OEhyj for <trans@ietfa.amsl.com>; Fri, 3 Oct 2014 12:25:14 -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 B95001A88A4 for <trans@ietf.org>; Fri, 3 Oct 2014 12:25:05 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:51274 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Xa8Tf-0000qg-7g for trans@ietf.org; Fri, 03 Oct 2014 15:25:19 -0400
Message-ID: <542EF80D.8040802@bbn.com>
Date: Fri, 03 Oct 2014 15:25:01 -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
To: trans@ietf.org
References: <542477E3.8070304@bbn.com> <544B0DD62A64C1448B2DA253C011414607D1628D70@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <542971A7.7030700@bbn.com> <544B0DD62A64C1448B2DA253C011414607D174DEB1@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <542C1846.7060303@bbn.com> <542C1EA6.8050106@comodo.com> <542D79B5.7080508@bbn.com> <CABrd9SR7imHk2cvYswHbvvMvQgwV2PcMdhiWqP-4pY7UBuaQ7A@mail.gmail.com>
In-Reply-To: <CABrd9SR7imHk2cvYswHbvvMvQgwV2PcMdhiWqP-4pY7UBuaQ7A@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/yD_uvqZ4rJ7EZ0vcNOgYyo9lULo
Subject: Re: [Trans] defining "mis-issuance"
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: Fri, 03 Oct 2014 19:25:16 -0000

Ben,

> ...
> I have a suggested solution:
>
>      - require a CA submitting a pre-cert to assert one of the following:
>          1. no assertion is made wrt syntactic conformance to CABF guudelines
>          2. the cert conforms to DV Guidelines <insert guideline version>
>          3. the cert conforms to EV guidelines <insert guideline version>
>
>      - require a log to include the CA assertion in its SCT, along with one
> of the following:
>          1. this log does not check cert syntax
>          2. this log cannot check the specified CABF Guidelne version
> asserted by the CA
>          3. this log checked the cert against the CA's assertion and it
> passed
>          4. this log checked the cert against the CA's assertion and it
> failed
> Presumably this would apply to certs as well as precerts, which is the
> other reason rejecting isn't particularly helpful (certs are already
> issued by the time they're logged!).
I'm confused by your comment. There is no "rejection" of a cert in the 
text above.
That was the change I made to address the valid concerns that Rob and 
Rick raised.

If the cert failed checking it would still be logged, and an SCT issued,
but the fact that the syntax failed the checks would be noted in the SCT and
the log entry.

Steve

p.s. I realize that one more log-assigned value is needed, i.e., the
CA asserted #1, so the log didn't perform any check in this case