• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: karp

Current state: Submitted to IESG for Publication

Viewing the last 20 entries. Show full log.

(System)

State changed to Waiting for AD Go-Ahead from In Last Call

(System)

IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed

Amanda Baber

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-karp-crypto-key-table-07. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, a new registry is to be created called the "KeyTable Protocols" registry. The registry is to be maintained through Specification Required as defined in RFC 5226.

Therre are initial values in the registry as follows:

------------------------------------------------------------------------
Protocol Name | Specification | Protocol Specific Values
------------------------------------------------------------------------
IEEE 802.1X CAK IEEE Std 802.1X-2010, A Key Management Domain (KMD).
"IEEE Standard for Local A string of up to 253 UTF-8
and Metropolitan Area characters that names the
Networks -- Port-Based transmitting authenticator's
Network Access Control". key management domain.

A Network Identifier (NID).
A string of up to 100 UTF-8
characters that identifies
a network service. The NID
can also be null, indicating
the key is associated with
a default service.
----------------------------------------------------------------------

Second, a new registry will be created called the "KeyTable KDFs" registry. The registry is to be maintained through First Come First Served as defined in RFC 5226.

There are no initial values in the new registry.

Third, a new registry will be created called the "KeyTable AlgIDs" registry. The registry is to be maintained through First Come First Served as defined in RFC 5226.

There are no initial values in the new registry.

IANA understands that these are the only actions required to be completed by IANA upon approval of this document.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Amy Vezza

IANA Review state changed to IANA - Review Needed

Amy Vezza

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call: (Database of Long-Lived Symmetric Cryptographic Keys) to Proposed Standard

The IESG has received a request from the Keying and Authentication for
Routing Protocols WG (karp) to consider the following document:
- 'Database of Long-Lived Symmetric Cryptographic Keys'
as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-04-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

This document specifies the information contained in a conceptual
database of long-lived cryptographic keys used by many different
security protocols. The database is designed to support both manual
and automated key management. In addition to describing the schema
for the database, this document describes the operations that can be
performed on the database as well as the requirements for the
security protocols that wish to use the database. In many typical
scenarios, the security protocols do not directly use the long-lived
key, but rather a key derivation function is used to derive a short-
lived key from a long-lived key.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/ballot/

No IPR declarations have been submitted directly on this I-D.

Amy Vezza

State changed to In Last Call from Last Call Requested

Stewart Bryant

Last call was requested

Stewart Bryant

Ballot approval text was generated

Stewart Bryant

Ballot writeup was generated

Stewart Bryant

State changed to Last Call Requested from Publication Requested

Stewart Bryant

Last call announcement was generated

Stewart Bryant

IESG process started in state Publication Requested

(System)

Earlier history may be found in the Comment Log for /doc/draft-housley-saag-crypto-key-table/

Brian Weis

Changed protocol writeup

Brian Weis

IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead

Brian Weis

Changed protocol writeup

Brian Weis

Changed protocol writeup

Brian Weis

Annotation tag Doc Shepherd Follow-up Underway set.

Brian Weis

Changed protocol writeup

Brian Weis

Intended Status changed to Proposed Standard from None

Viewing the last 20 entries. Show full log.