X.509 Extended Key Usage (EKU) for configuration, updates and safety-communication
draft-ietf-lamps-automation-keyusages-08

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, debcooley1@gmail.com, draft-ietf-lamps-automation-keyusages@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rfc-editor@rfc-editor.org, spasm@ietf.org
Subject: Protocol Action: 'X.509 Extended Key Usage (EKU) for configuration, updates and safety-communication' to Proposed Standard (draft-ietf-lamps-automation-keyusages-08.txt)

The IESG has approved the following document:
- 'X.509 Extended Key Usage (EKU) for configuration, updates and safety-
   communication'
  (draft-ietf-lamps-automation-keyusages-08.txt) as Proposed Standard

This document is the product of the Limited Additional Mechanisms for PKIX
and SMIME Working Group.

The IESG contact persons are Paul Wouters and Deb Cooley.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-automation-keyusages/

Ballot Text

Technical Summary

   RFC 5280 specifies several extended key purpose identifiers
   (KeyPurposeIds) for X.509 certificates.  This document defines
   KeyPurposeIds for general-purpose and trust anchor configuration
   files, for software and firmware update packages, and for safety-
   critical communication to be included in the Extended Key Usage (EKU)
   extension of X.509 v3 public key certificates used by industrial
   automation and the Europe's Rail Joint Undertaking (ERJU) System Pillar.

Working Group Summary

  There is support for this document in the LAMPS WG.  Some people
  originally thought that this document was needed by too few
  implementers to become an RFC, but after a fair amount of
  discussion, there was consensus to go forward when it became
  clear that more than one vendor would likely need these key usage
  values. 

Document Quality

  ASN.1 is used.  It compiles without errors after inserting placeholder 
  values for the ones that need to be assigned by IANA.

  It is clear that there will be implementations.

Personnel

   The Document Shepherd for this document is Russ Housley. The Responsible
   Area Director is Deb Cooley.

RFC Editor Note