Re: [Trans] Compatibility of name redaction and EV

Stephen Kent <kent@bbn.com> Mon, 18 August 2014 20:46 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 364D91A6F7A for <trans@ietfa.amsl.com>; Mon, 18 Aug 2014 13:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.869
X-Spam-Level:
X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 m8G1SLSD5GVe for <trans@ietfa.amsl.com>; Mon, 18 Aug 2014 13:46:08 -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 B4E091A6F76 for <trans@ietf.org>; Mon, 18 Aug 2014 13:46:08 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:54303 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XJToq-0006er-Tw; Mon, 18 Aug 2014 16:46:21 -0400
Message-ID: <53F26610.8000608@bbn.com>
Date: Mon, 18 Aug 2014 16:46:08 -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: Ben Laurie <benl@google.com>
References: <CABrd9SQ=mW7DoQUkXGv5M=nuoR1fTFG5N1Qc_PyK+mtm6E6s_A@mail.gmail.com> <53F25A33.5020405@bbn.com> <CABrd9SQcYQCV93CC-1DocNwOrKa0aJVqMaOMVRPWJt3pinvuiA@mail.gmail.com>
In-Reply-To: <CABrd9SQcYQCV93CC-1DocNwOrKa0aJVqMaOMVRPWJt3pinvuiA@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/5U6oRJncLKE886-E7SsR8uNtHN0
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Compatibility of name redaction and EV
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, 18 Aug 2014 20:46:10 -0000

Ben,

> On 18 August 2014 12:55, Stephen Kent <kent@bbn.com> wrote:
>> Ben,
>>
>> Thanks for the analysis you performed to start the discussion on
>> https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/_p8zRz5Em3s.
>>
>> However, I believe that this discussion should move to the
>> TRANS list, since it addresses a topic that is squarely within
>> the scope of the CT standard, right?
>>
>> Do you disagree?
> I am not against there being a discussion in TRANS, but I think there
> are two interlinked issues:
>
> 1. What signals CT provides for what kinds of certs.
>
> 2. What Chrome does in response to those signals.
>
> Each has its own appropriate venue.
I agree that these are separate topics. But the overall question of whether
the proposal for redacted certs, as part of 6962-bis, is "safe" for both
DV and EV certs, is appropriate for this list. (It's the subject of an
issue tracker entry that I submitted.)

The topic of how a CT-compliant TLS client deals with a redacted cert, 
of any type,
is within scope for TRANS.

What Chrome does is not a subject for TRANS, since you have already stated
that Chrome will do whatever Google decides, irrespective of any TRANS 
RFCs :-).

> I am also mildly confused about how an RFC interacts with standards
> that are not controlled by the IETF (i.e. the Base Requirements and
> the Extended Validation requirements).

Well, RFC 6125 is an example of a standards track RFC that talks about EV
certs in the TLS context, so there is a precedent.

Steve