IETF Logo Mail Archive

Re: [Trans] path validation

Stephen Kent <kent@bbn.com> Wed, 01 October 2014 14:30 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 D8EC11ACDB9 for <trans@ietfa.amsl.com>; Wed, 1 Oct 2014 07:30:44 -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 uhjUaRE801fn for <trans@ietfa.amsl.com>; Wed, 1 Oct 2014 07:30:38 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F9B1A8710 for <trans@ietf.org>; Wed, 1 Oct 2014 07:30:38 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:50751 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XZKvK-000KOS-6H; Wed, 01 Oct 2014 10:30:34 -0400
Message-ID: <542C1008.4060500@bbn.com>
Date: Wed, 01 Oct 2014 10:30:32 -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, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <5429C24B.1050002@gmail.com>
In-Reply-To: <5429C24B.1050002@gmail.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5agWt-20wRgcIAq_XlPQhzD3HGg
Subject: Re: [Trans] path validation
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, 01 Oct 2014 14:30:45 -0000

Stephen,

I'm puzzled by your "advice."

The IETF cites documents of other SDOs when relevant and when they
do not conflict with the scope of IETF WGs.

The CABF has created a profile of 5280, and 3647, for the Web PKI
context, precisely the context that CT is addressing.

Ben asserted that mis-issuance entails more than the simple
notion that a cert was issued to the "wrong" subject. He specifically
cited key size and EV cert criteria. These are criteria defined by the
CABF guidelines.

How can we proceed on CT if we don't have a solid definition of the
problem it purports to address? Certainly detecting mis-issuance
has to be well-defined.

Steve
> We've received a reminder from our friendly area director not
> to introduce any normative dependencies on CAB Forum documents
> or processes, as well as a query about how much x.509 processing
> should be specified, as well.
>
> Melinda
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

v2.23.0 | Report a Bug | By Email