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

From: Sean Turner <[email-masked]>
Date: Tue, 27 Nov 2012 18:34:04 -0500

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 <[email-masked]>
>
> 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
>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 28 Nov 2012 21:30:02 +0100

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 <[email-masked]> writes:

> 1) This was the last discuss point to get resolved.  It was two
> SHOULDs before it became MUST oathman/iana.
>

---

From: Sean Turner <[email-masked]>
Date: Thu, 29 Nov 2012 12:14:31 -0500

List,

Do others have examples they are willing to share?

spt