errata logo graphic

Found 7 records.

Status: Verified (5)

RFC6030, "Portable Symmetric Key Container (PSKC)", October 2010

Source of RFC: keyprov (sec)

Errata ID: 2759

Status: Verified
Type: Technical

Reported By: Philip Hoyer
Date Reported: 2011-03-30
Verifier Name: Sean Turner
Date Verified: 2011-03-31

Section 11 says:

     <xs:complexType name="AlgorithmParametersType">
          <xs:choice>



Hoyer, et al.                Standards Track                   [Page 42]

RFC 6030         Portable Symmetric Key Container (PSKC)    October 2010


               <xs:element name="Suite" type="xs:string" minOccurs="0"/>
               <xs:element name="ChallengeFormat" minOccurs="0">
                    <xs:complexType>
                         <xs:attribute name="Encoding"
                              type="pskc:ValueFormatType"
                                                      use="required"/>
                         <xs:attribute name="Min"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="Max"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="CheckDigits"
                              type="xs:boolean" default="false"/>
                    </xs:complexType>
               </xs:element>
               <xs:element name="ResponseFormat" minOccurs="0">
                    <xs:complexType>
                         <xs:attribute name="Encoding"
                              type="pskc:ValueFormatType"
                                                      use="required"/>
                         <xs:attribute name="Length"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="CheckDigits"
                              type="xs:boolean" default="false"/>
                    </xs:complexType>
               </xs:element>
               <xs:element name="Extensions"
                    type="pskc:ExtensionsType" minOccurs="0"
                    maxOccurs="unbounded"/>
          </xs:choice>
     </xs:complexType>

It should say:

     <xs:complexType name="AlgorithmParametersType">
          <xs:sequence>



Hoyer, et al.                Standards Track                   [Page 42]

RFC 6030         Portable Symmetric Key Container (PSKC)    October 2010


               <xs:element name="Suite" type="xs:string" minOccurs="0"/>
               <xs:element name="ChallengeFormat" minOccurs="0">
                    <xs:complexType>
                         <xs:attribute name="Encoding"
                              type="pskc:ValueFormatType"
                                                      use="required"/>
                         <xs:attribute name="Min"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="Max"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="CheckDigits"
                              type="xs:boolean" default="false"/>
                    </xs:complexType>
               </xs:element>
               <xs:element name="ResponseFormat" minOccurs="0">
                    <xs:complexType>
                         <xs:attribute name="Encoding"
                              type="pskc:ValueFormatType"
                                                      use="required"/>
                         <xs:attribute name="Length"
                              type="xs:unsignedInt" use="required"/>
                         <xs:attribute name="CheckDigits"
                              type="xs:boolean" default="false"/>
                    </xs:complexType>
               </xs:element>
               <xs:element name="Extensions"
                    type="pskc:ExtensionsType" minOccurs="0"
                    maxOccurs="unbounded"/>
          </xs:sequence>
     </xs:complexType>

Notes:

The AlgorithmParameter should have a sequqnce of subelements not a choice as for Challenge/Response algorithms it MUST be possible to define both the ChallengeFormat and the Response Format at the same time. Currently the schema uses <xs:choice> which allows either <ChallengeFormat> or <ResponseFormat> but not both.
This correction will bring it in line with intended description in Section 4.3.4


Errata ID: 3418

Status: Verified
Type: Technical

Reported By: Simon Josefsson
Date Reported: 2012-11-26
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section 7 and 11 says:

Section 7:
       <Signature>

Section 11:
               <xs:element name="Signature"
                    type="ds:SignatureType" minOccurs="0"/>

It should say:

Section 7:
       <ds:Signature>

Section 11:
               <xs:element ref="ds:Signature" minOccurs="0"/>

Notes:

It seems the Signature element is in the wrong namespace, making PSKC incompatible with the XMLDsig specification.

There is a thread on this on the XMLSec mailing list:

http://thread.gmane.org/gmane.text.xml.xmlsec/4178

Both Aleksey Sanin (author of the XMLSec library) and G. Ken Holman (XML
expert) appear to believe this is an error in the XML schema for PSKC:

http://thread.gmane.org/gmane.text.xml.xmlsec/4178/focus=4181
http://thread.gmane.org/gmane.text.xml.xmlsec/4178/focus=4185

This was brought up on the keyprov mailing list:

http://thread.gmane.org/gmane.ietf.keyprov/1011

/Simon


Errata ID: 2621

Status: Verified
Type: Editorial

Reported By: Simon Josefsson
Date Reported: 2010-11-10
Verifier Name: Tim Polk
Date Verified: 2011-03-26

Section 10.2 says:

The <Usage> element MAY be present, but no attribute of the <Usage> element is required.

It should say:

The <AlgorithmParameters> element MAY be present, but no attribute of the <AlgorithmParameters> element is required.

Notes:

The <Usage> field was renamed between draft -02 and -03 but this section was not updated.


Errata ID: 3364

Status: Verified
Type: Editorial

Reported By: Simon Josefsson
Date Reported: 2012-09-25
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section 3 says:

      ----------------        ----------------
      | KeyPackage   |    0..1| DeviceInfo   |
      |--------------|--------|--------------|
      |              |--      | SerialNumber |
      ----------------  |     | Manufacturer |
              |         |     | ....         |
              |         |     ----------------
 

It should say:

      ----------------        ----------------
      | KeyPackage   |    0..1| DeviceInfo   |
      |--------------|--------|--------------|
      |              |--      | SerialNo     |
      ----------------  |     | Manufacturer |
              |         |     | ....         |
              |         |     ----------------
 

Notes:

Figure 1 mentions a DeviceInfo field called "SerialNumber" however it should be "SerialNo".


Errata ID: 3370

Status: Verified
Type: Editorial

Reported By: Simon Josefsson
Date Reported: 2012-10-03
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section 6.3 says:

       id="KC0001"

It should say:

       Id="KC0001"

Notes:

The PSKC data in figure 8 does not pass a XML Schema validation -- the reason is a typo in the Id attribute name.


Status: Reported (1)

RFC6030, "Portable Symmetric Key Container (PSKC)", October 2010

Source of RFC: keyprov (sec)

Errata ID: 3811

Status: Reported
Type: Technical

Reported By: Ivan Micanovic
Date Reported: 2013-11-25

Section 4.1. says:

All the elements listed above (and those defined in the future)
      obey a simple structure in that they MUST support child elements
      to convey the data value in either plaintext or encrypted format:

      Plaintext:  The <PlainValue> element carries a plaintext value
         that is typed, for example, to xs:integer.

      Encrypted:  The <EncryptedValue> element carries an encrypted
         value.

Notes:

In case that <Counter>, <Time>, <TimeInterval> or <TimeDrift> are encrypted in the PSKC file, the standard doesn't say anything about how to interpret this encrypted data.
After decrypting those values we have byte array.

Example:
Counter plain text value: 10000 decimal

In the case that this value is encrypted and later decrypted what should we expect?
Byte content 0x27 0x10 or 0x01 0x00 0x00 or something else?

1. Byte content 0x27 0x10 is interpreted as 10000 decimal if this bytes are interpreted as binary data (Big endian).
2. Byte content 0x01 0x00 0x00 is interpreted as 10000 decimal if this bytes are interpreted as hex data (Big endian).
Each hex digit will be mapped to a resulting decimal digit. From my point of view this way is a bit confusing.

My proposal to solve this issue is described in 1.


Status: Rejected (1)

RFC6030, "Portable Symmetric Key Container (PSKC)", October 2010

Source of RFC: keyprov (sec)

Errata ID: 3369

Status: Rejected
Type: Technical

Reported By: Simon Josefsson
Date Reported: 2012-10-03
Rejected by: Sean Turner
Date Rejected: 2013-03-16

Section 4.3.1 says:

   <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]>").

It should say:

   <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
--VERIFIER NOTES--
Changing the requirement from MUST to MAY is not appropriate to do in an errata. Please produce a draft and we can see whether your change is acceptable to the rest of the IETF.


Report New Errata