RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 9 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>.

Report New Errata



Advanced Search