Re: [Trans] defining "mis-issuance"

Stephen Kent <kent@bbn.com> Mon, 29 September 2014 14:52 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 B04B11A8757 for <trans@ietfa.amsl.com>; Mon, 29 Sep 2014 07:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level:
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 rXLWtaxB5aQ5 for <trans@ietfa.amsl.com>; Mon, 29 Sep 2014 07:52:49 -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 1AA811A1ADB for <trans@ietf.org>; Mon, 29 Sep 2014 07:52:49 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:56762 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XYcJy-000EN0-OC for trans@ietf.org; Mon, 29 Sep 2014 10:53:02 -0400
Message-ID: <54297239.5010002@bbn.com>
Date: Mon, 29 Sep 2014 10:52:41 -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" <trans@ietf.org>
References: <542477E3.8070304@bbn.com> <4262AC0DB9856847A2D00EF817E81139232E23@scygexch10.cygnacom.com>
In-Reply-To: <4262AC0DB9856847A2D00EF817E81139232E23@scygexch10.cygnacom.com>
Content-Type: multipart/alternative; boundary="------------030608030806030905070703"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/aMshKqLexGN13tELlNJ_vSRDIAc
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: Mon, 29 Sep 2014 14:52:51 -0000

Santosh,
>
> Steve,
>
> I read 6962-bis saying submission of certificate chain.
>
> Why not add path validation to the list of rules you defined below.  
> That would be good given the wide variance in how browsers process 
> chains.  This gives us another opportunity at log level to have 
> correct logic for path validation.
>
I believe 6962-bit already requires a log operator to validate the cert 
chain to
one of the roots from which it accepts SCT requests, based on text in 
Section 3.1.
But I can add a specific reminder of the need to do that.
>
> Note that if one follows CABF, unlike RFC 5280 and X.509, EKU is 
> processed somewhat akin to certificate policy (less policy mapping).
Can you point to the CABF text that makes this clear? Also, I'd be 
thankful if you can
provide suggested changes to my text to highlight this.
>
> On a side note, I fail to see CABF requirement with respect to 
> interaction between name constraints and EKU.
I read Section**9.7 of the DV (1.1.9) spec as implying a linkage between 
the two, but
the wording is somewhat confusing to me.

Steve