Re: [pkix] Simple Certificate Enrollment Protocol (SCEP)

Stephen Kent <kent@bbn.com> Wed, 22 October 2014 23:39 UTC

Return-Path: <kent@bbn.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D621A87A3 for <pkix@ietfa.amsl.com>; Wed, 22 Oct 2014 16:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.19
X-Spam-Level:
X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 S42c9Cm2qzSD for <pkix@ietfa.amsl.com>; Wed, 22 Oct 2014 16:39:17 -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 562FE1A6F3A for <pkix@ietf.org>; Wed, 22 Oct 2014 16:39:17 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:34155 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Xh5Up-0003v6-T9 for pkix@ietf.org; Wed, 22 Oct 2014 19:39:15 -0400
Message-ID: <54484022.1010708@bbn.com>
Date: Wed, 22 Oct 2014 19:39:14 -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
CC: pkix <pkix@ietf.org>
References: <9A043F3CF02CD34C8E74AC1594475C739B9CAF27@uxcn10-tdc05.UoA.auckland.ac.nz> <001001cfe7a0$52f31640$f8d942c0$@x500.eu> <10AA61E0-BC44-4515-822D-8C9885C9D7EE@vpnc.org> <543D4F5C.4010000@bbn.com> <543D5DE3.50507@gmail.com> <544681B8.3080401@bbn.com> <D69A391A-E918-4752-9151-B21A702BF34C@vpnc.org>
In-Reply-To: <D69A391A-E918-4752-9151-B21A702BF34C@vpnc.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/pkix/DHywO9Z3dtFTD0BbikqSjLG7uGM
Subject: Re: [pkix] Simple Certificate Enrollment Protocol (SCEP)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Oct 2014 23:39:19 -0000

Paul,

The rules for what gets published as an RFC are flexible. Contrary to 
your assertion
I did not change the rules. Decisions about publishing documents 
developed outside
of WGs are based on inputs from relevant WG chairs (if any), and the 
IESG. The RFC
editor of the relevant stream has the final say in such matters.

In my role as PKIX chair I expressed my view that the cited 
justification for
publishing SCEP was not credible, and shared that view with the Sec ADs 
and the
IETF chair, i.e., I provided my input. However, I could not veto 
publication
unilaterally as you seem to have suggested. If the IESG or the cognizant 
RFC Editor
decided that the spec should be published as Informational or Historic 
they could
have done so.

In the end I suspect that IESG members involved with the discussion were 
as upset
as I by the disclosure that at least one Cisco staff member had an 
ulterior motive
for requesting publication.

Steve

> On Oct 21, 2014, at 8:54 AM, Stephen Kent<kent@bbn.com>  wrote:
>> The real issue is that the argument put before PKIX and the Sec ADs,
>> repeatedly, was that an RFC was needed to provide a stable reference document
>> for SCEP. This is an absurd assertion; Cisco was capable of publishing its
>> spec on a public Cisco web site, thus making it available to anyone who needed it.
>> Internet search was already adequate (in that time frame) for anyone interested
>> in the spec to find it on such a site. If Cisco vanishes, the doc will have been
>> archived and thus remain available for many years.
> If you want to change the rules for how RFCs are published, it might be better done so as a participant in an IETF-wide discussion, not as a WG chair who is preventing someone from using the process correctly. Otherwise, it simply looks like you are wielding power just to seem powerful.
>
> --Paul Hoffman