RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (5)

RFC 6030, "Portable Symmetric Key Container (PSKC)", October 2010

Source of RFC: keyprov (sec)

Errata ID: 2759
Status: Verified
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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 (4)

RFC 6030, "Portable Symmetric Key Container (PSKC)", October 2010

Source of RFC: keyprov (sec)

Errata ID: 3811
Status: Reported
Type: Technical
Publication Format(s) : TEXT

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.

Errata ID: 4643
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Arthur de Jong
Date Reported: 2016-03-19

Section 4.3.4 says:

...
      'CheckDigit':  This attribute indicates whether a device needs to
         check the appended Luhn check digit, as defined in
         [ISOIEC7812], contained in a challenge.
...
      'CheckDigit':  This attribute indicates whether the device needs
         to append a Luhn check digit, as defined in [ISOIEC7812], to
         the response.
...

It should say:

...
      'CheckDigits':  This attribute indicates whether a device needs to
         check the appended Luhn check digit, as defined in
         [ISOIEC7812], contained in a challenge.
...
      'CheckDigits':  This attribute indicates whether the device needs
         to append a Luhn check digit, as defined in [ISOIEC7812], to
         the response.
...

Notes:

The text notes the singular CheckDigit while the schema specifies the plural CheckDigits. Either the text or the schema should be changed. Some implementations in the while seem to use the plural form.

Errata ID: 5034
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Arthur de Jong
Date Reported: 2017-06-08

Section 6.1 says:

 Camellia128    | http://www.w3.org/2001/04/xmldsig-more#camellia128
 Camellia192    | http://www.w3.org/2001/04/xmldsig-more#camellia192
 Camellia256    | http://www.w3.org/2001/04/xmldsig-more#camellia256

It should say:

 Camellia128-CBC| http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc
 Camellia192-CBC| http://www.w3.org/2001/04/xmldsig-more#camellia192-cbc
 Camellia256-CBC| http://www.w3.org/2001/04/xmldsig-more#camellia256-cbc

Notes:

The original URIs are not defined in RFC 4051 but the URIs with -cbc appended are which and those are what was probably meant.

Errata ID: 7006
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Flavio Poletti
Date Reported: 2022-06-26

Section 4.1 says:

      ValueMAC:  The <ValueMAC> element is populated with a Message
         Authentication Code (MAC) generated from the encrypted value in
         case the encryption algorithm does not support integrity
         checks.  The example shown in Figure 2 illustrates the usage of
         the <Data> element with two child elements, namely <Secret> and
         <Counter>.  Both elements carry a plaintext value within the
         <PlainValue> child element.

It should say:

      ValueMAC:  The <ValueMAC> element is populated with a Message
         Authentication Code (MAC) generated from the encrypted value in
         case the encryption algorithm does not support integrity
         checks.

      The example shown in Figure 2 illustrates the usage of the <Data>
      element with one child element <Secret>.  This element carries a
      plaintext value within the <PlainValue> child element.

Notes:

There are two issues:
- the comment about the example should be in a standalone paragraph and not as a continuation of the explanation for ValueMAC
- the example in Figure 2 does *not* include <Counter>. The correction might be done to Figure 2, adding an XML fragment for <Counter> inside <Data>.

Status: Rejected (1)

RFC 6030, "Portable Symmetric Key Container (PSKC)", October 2010

Source of RFC: keyprov (sec)

Errata ID: 3369
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

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



Advanced Search