Results of IETF-conflict review for <draft-hotz-kx509-05.txt>

The IESG <iesg-secretary@ietf.org> Mon, 09 July 2012 16:41 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF0121F8567; Mon, 9 Jul 2012 09:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.48
X-Spam-Level:
X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ghwbfblN9-1; Mon, 9 Jul 2012 09:41:57 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2629E11E813E; Mon, 9 Jul 2012 09:41:57 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: Nevil Brownlee <rfc-ise@rfc-editor.org>
Subject: Results of IETF-conflict review for <draft-hotz-kx509-05.txt>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.30p3
Message-ID: <20120709164157.915.57477.idtracker@ietfa.amsl.com>
Date: Mon, 09 Jul 2012 09:41:57 -0700
Cc: iana@iana.org, The IESG <iesg@ietf.org>, ietf-announce@ietf.org
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2012 16:41:58 -0000

The IESG has completed a review of <draft-hotz-kx509> consistent with
RFC5742.  This review is applied to all non-IETF streams.

The IESG has no problem with the publication of 'KX509 Kerberized
Certificate Issuance Protocol in Use in 2012' <draft-hotz-kx509-05.txt>
as an Informational RFC.

The IESG would also like the RFC-Editor to review the comments in
the datatracker (http://datatracker.ietf.org/doc/draft-hotz-kx509/)
related to this document and determine whether or not they merit
incorporation into the document. Comments may exist in both the ballot
and the history log.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-hotz-kx509/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary




Technical Summary

   This document describes a protocol, called kx509, for using Kerberos
   tickets to acquire X.509 certificates.  These certificates may be
   used for many of the same purposes as X.509 certificates acquired by
   other means, but if a Kerberos infrastructure already exists then the
   overhead of using kx509 may be much less.

   While not (previously) standardized, this protocol is already in use
   at several large organizations, and certificates issued with this
   protocol are recognized by the International Grid Trust Federation.

Working Group Summary

  This document is an independent submission undergoing 
  RFC 5742 review.

Document Quality

  Stephen Farrell reviewed the document according to RFC 5472 
  and recommends responding that the IESG has no problem
  with the publication of draft-hotz-kx509 as an informational
  RFC. 
  
Personnel

  Stephen Farrell (stephen.farrell@cs.tcd.ie)  is the AD managing 
  the 5472 review.
  Russ Albery (rra@stanford.edu) is the document shepherd.

RFC Editor Note

The IESG has concluded that this work is related to IETF work
done in the kerberos and pkix working groups but this
relationship does not prevent publishing.

IESG Note

The following comments are offered as comments that the
ISE and authors might want to take into account.

- 2.1: I'm not clear if the RSA public key is input to the hash
as a DER encoded RSAPublicKey or a a DER encoded
(selfi-signed?) Certificate structure. Appendix C probably
does make that clear, but I didn't try parse the DER to 
check for sure.