RFC Errata
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>.