Re: [Trans] defining "mis-issuance"

Santosh Chokhani <> Mon, 29 September 2014 17:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D4A0B1A9008 for <>; Mon, 29 Sep 2014 10:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9weUbdzCCsLk for <>; Mon, 29 Sep 2014 10:42:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 33C621A90EB for <>; Mon, 29 Sep 2014 10:42:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.04,621,1406606400"; d="scan'208,217";a="2156545"
Received: from unknown (HELO ([]) by with ESMTP; 29 Sep 2014 13:42:36 -0400
Received: from ([::1]) by ([::1]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 13:42:36 -0400
From: Santosh Chokhani <>
To: Stephen Kent <>, "" <>
Thread-Topic: [Trans] defining "mis-issuance"
Thread-Index: AQHP2P2J/GbBAtvYc0yp/9C5G2ZUf5wV1HnggAKmo4D//+vBgA==
Date: Mon, 29 Sep 2014 17:42:35 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4262AC0DB9856847A2D00EF817E8113923361Escygexch10cygnaco_"
MIME-Version: 1.0
Subject: Re: [Trans] defining "mis-issuance"
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: Mon, 29 Sep 2014 17:42:40 -0000


See I will respond to the other thread you created for path validation.  That seems to be a more appropriate place.

I will be sure to include the EKU processing language there.

From: Trans [] On Behalf Of Stephen Kent
Sent: Monday, September 29, 2014 10:53 AM
Subject: Re: [Trans] defining "mis-issuance"



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.