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

[Sean Turner <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
>>>
>>> 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
>>>
>