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

Simon Josefsson <simon@josefsson.org> Wed, 28 November 2012 20:30 UTC

Return-Path: <simon@josefsson.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 02BBF21F867D for <keyprov@ietfa.amsl.com>; Wed, 28 Nov 2012 12:30:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.909
X-Spam-Level:
X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 HhnY-Vejny7t for <keyprov@ietfa.amsl.com>; Wed, 28 Nov 2012 12:30:49 -0800 (PST)
Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9324C21F841A for <keyprov@ietf.org>; Wed, 28 Nov 2012 12:30:47 -0800 (PST)
Received: from latte.josefsson.org (host-95-193-126-252.mobileonline.telia.com [95.193.126.252]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qASKU7qp000325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Nov 2012 21:30:09 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Sean Turner <turners@ieca.com>
References: <20121003074727.A303DB1E003@rfc-editor.org> <50B54DEC.5070302@ieca.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:121128:stephen.farrell@cs.tcd.ie::evEPYuuwIKHcRw7c:1Rx8
X-Hashcash: 1:22:121128:smachani@diversinet.com::gnD27iMq5P+Qr/fH:FxZ
X-Hashcash: 1:22:121128:turners@ieca.com::/H0sksVCHVl4Nn0q:9qNc
X-Hashcash: 1:22:121128:hannes.tschofenig@gmx.net::Ae6BWV7Kh7CFl7Oz:69tq
X-Hashcash: 1:22:121128:keyprov@ietf.org::qlndabZpu3/Sy9Uo:ZmKP
X-Hashcash: 1:22:121128:phoyer@actividentity.com::Fhp1oDTU93gZWUBC:OyVM
X-Hashcash: 1:22:121128:mpei@verisign.com::Gm+auUg1EXGKKNEy:siS2
X-Hashcash: 1:22:121128:phill@hallambaker.com::Ufw14gSRbP1t0P8p:l3WM
Date: Wed, 28 Nov 2012 21:30:02 +0100
In-Reply-To: <50B54DEC.5070302@ieca.com> (Sean Turner's message of "Tue, 27 Nov 2012 18:34:04 -0500")
Message-ID: <87txs9h3n9.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v
X-Virus-Status: Clean
Cc: phill@hallambaker.com, keyprov@ietf.org
Subject: Re: [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, 28 Nov 2012 20:30:50 -0000

I am also interested in learning how other implementations behave.

I understand you would want more implementer feedback before approving a
change like this.  The PSKC files I have seen all violate the MUST, but
I can't claim to have seen any representative proportion of all PSKC
files.  If people can share example PSKC files used in various
deployments, that would help.

The alternative to adopt this change is to update the examples
throughout the document to follow the MUST language.

/Simon

Sean Turner <turners@ieca.com> writes:

> I'm a little hesitant to make this change through an errata.  Two reasons:
>
> 1) This was the last discuss point to get resolved.  It was two
> SHOULDs before it became MUST oathman/iana.
>
> 2) It's changing 2119 language.
>
> If there's really multiple implementations out there do it differently
> could we spin a simple paragraph draft that explains there's no reason
> to restrict it & the old/new text to get this fixed more formally?
>
> Question: Do any of the other implementations fall over if you use
> something without a prefix?
>
> spt
>
>
> On 10/3/12 3:47 AM, RFC Errata System wrote:
>> 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
>>