[KEYPROV] [Technical Errata Reported] RFC6030 (3369)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 03 October 2012 07:52 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: keyprov@ietfa.amsl.com
Delivered-To: keyprov@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3517F21F84A2 for <keyprov@ietfa.amsl.com>; Wed, 3 Oct 2012 00:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.304
X-Spam-Level:
X-Spam-Status: No, score=-102.304 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7nMSnV9wh81 for <keyprov@ietfa.amsl.com>; Wed, 3 Oct 2012 00:51:59 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 47DAD21F849B for <keyprov@ietf.org>; Wed, 3 Oct 2012 00:51:53 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id A303DB1E003; Wed, 3 Oct 2012 00:47:27 -0700 (PDT)
To: phoyer@actividentity.com, mpei@verisign.com, smachani@diversinet.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, phill@hallambaker.com, Hannes.Tschofenig@gmx.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20121003074727.A303DB1E003@rfc-editor.org>
Date: Wed, 3 Oct 2012 00:47:27 -0700 (PDT)
Cc: keyprov@ietf.org, rfc-editor@rfc-editor.org
Subject: [KEYPROV] [Technical Errata Reported] RFC6030 (3369)
X-BeenThere: keyprov@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Provisioning of Symmetric Keys \(keyprov\)" <keyprov.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/keyprov>, <mailto:keyprov-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyprov>
List-Post: <mailto:keyprov@ietf.org>
List-Help: <mailto:keyprov-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyprov>, <mailto:keyprov-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Oct 2012 07:52:00 -0000

The following errata report has been submitted for RFC6030,
"Portable Symmetric Key Container (PSKC)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6030&eid=3369

--------------------------------------
Type: Technical
Reported by: Simon Josefsson <simon@josefsson.org>;

Section: 4.3.1

Original Text
-------------
   <Manufacturer>:  This element indicates the manufacturer of the
      device.  Values for the <Manufacturer> element MUST be taken from
      either [OATHMAN] prefixes (i.e., the left column) or from the IANA
      Private Enterprise Number Registry [IANAPENREG], using the
      Organization value.  When the value is taken from [OATHMAN],
      "oath."  MUST be prepended to the value (e.g., "oath.<prefix value
      from [OATHMAN]>").  When the value is taken from [IANAPENREG],
      "iana."  MUST be prepended to the value (e.g., "iana.<Organization
      value from [IANAPENREG]>").


Corrected Text
--------------
   <Manufacturer>:  This element indicates the manufacturer of the
      device.  Values for the <Manufacturer> element MAY be taken from
      either [OATHMAN] prefixes (i.e., the left column) or from the IANA
      Private Enterprise Number Registry [IANAPENREG], using the
      Organization value.  When the value is taken from [OATHMAN],
      "oath."  MUST be prepended to the value (e.g., "oath.<prefix value
      from [OATHMAN]>").  When the value is taken from [IANAPENREG],
      "iana."  MUST be prepended to the value (e.g., "iana.<Organization
      value from [IANAPENREG]>").


Notes
-----
The only thing changed is relaxing MUST to MAY.

The requirement that manufacturer strings begin with "oath." and "iana." is often ignored by implementations/deployments.  Further, none of the examples throughout the document conform to the syntax.  While we could regard these as implementation/deployment and editorial document bugs, I would argue that we could just as well relax the technical requirement because there appears to be no harm in allowing free-form text.  This is what people appear to be using out there already.

Examples of non-conforming <Manufacturer> fields out there:
http://tools.ietf.org/html/draft-hoyer-keyprov-pskc-algorithm-profiles-01
http://download.gooze.eu/otp/seeds/20120919-test001-4282.xml

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6030 (draft-ietf-keyprov-pskc-09)
--------------------------------------
Title               : Portable Symmetric Key Container (PSKC)
Publication Date    : October 2010
Author(s)           : P. Hoyer, M. Pei, S. Machani
Category            : PROPOSED STANDARD
Source              : Provisioning of Symmetric Keys
Area                : Security
Stream              : IETF
Verifying Party     : IESG