Re: [KEYPROV] [Technical Errata Reported] RFC6030 (3369)
Sean Turner <turners@ieca.com> Thu, 29 November 2012 17:14 UTC
Return-Path: <turners@ieca.com>
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 9D48121F8B0F for <keyprov@ietfa.amsl.com>; Thu, 29 Nov 2012 09:14:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.261
X-Spam-Level:
X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 AlCkzcRWy5Iv for <keyprov@ietfa.amsl.com>; Thu, 29 Nov 2012 09:14:33 -0800 (PST)
Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [67.18.80.20]) by ietfa.amsl.com (Postfix) with ESMTP id EB3E021F8AE6 for <keyprov@ietf.org>; Thu, 29 Nov 2012 09:14:32 -0800 (PST)
Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id BFA348F46766C; Thu, 29 Nov 2012 11:14:31 -0600 (CST)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 8801E8F46750E for <keyprov@ietf.org>; Thu, 29 Nov 2012 11:14:31 -0600 (CST)
Received: from [108.45.19.185] (port=49788 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <turners@ieca.com>) id 1Te7h2-00076H-0w; Thu, 29 Nov 2012 11:14:32 -0600
Message-ID: <50B797F7.9050804@ieca.com>
Date: Thu, 29 Nov 2012 12:14:31 -0500
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: keyprov@ietf.org
References: <20121003074727.A303DB1E003@rfc-editor.org> <50B54DEC.5070302@ieca.com> <87txs9h3n9.fsf@latte.josefsson.org>
In-Reply-To: <87txs9h3n9.fsf@latte.josefsson.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: (thunderfish.local) [108.45.19.185]:49788
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 12
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: phill@hallambaker.com
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: Thu, 29 Nov 2012 17:14:33 -0000
List, Do others have examples they are willing to share? spt On 11/28/12 3:30 PM, Simon Josefsson wrote: > 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 >>> >
- [KEYPROV] [Technical Errata Reported] RFC6030 (33… RFC Errata System
- Re: [KEYPROV] [Technical Errata Reported] RFC6030… Sean Turner
- Re: [KEYPROV] [Technical Errata Reported] RFC6030… Simon Josefsson
- Re: [KEYPROV] [Technical Errata Reported] RFC6030… Sean Turner