RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

RFC 6063, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", December 2010

Source of RFC: keyprov (sec)

Errata ID: 2948
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2011-08-28
Verifier Name: Stephen Farrell
Date Verified: 2011-11-13

Section 12.2 says: 

URI:  urn:ietf:params:xml:ns:keyprov:dskpp

It should say:

URI:  urn:ietf:params:xml:schema:keyprov:dskpp

Notes:

Section 12.2 is the registration for the schema not the namespace, which is in Section 12.1. The URI for the schema ought to point to :schema: and not :ns:. It's in the IANA registry it just needs to be updated here.

Errata ID: 2999
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gareth Richards
Date Reported: 2011-10-17
Verifier Name: Sean Turner
Date Verified: 2011-11-13

Section 4.2.4 says: 

           DSKPP Client                         DSKPP Server
           ------------                         ------------
           E(K,R_C), AD          --->


   When this message is sent:
      The DSKPP Client will send this message immediately following a
      <KeyProvServerHello> message whose status was set to "Continue".

It should say:

           DSKPP Client                         DSKPP Server
           ------------                         ------------
           E(K,R_C), [AD]          --->

   When this message is sent:
      The DSKPP Client will send this message immediately following a
      <KeyProvServerHello> message whose status was set to "Continue".
      The AD element MUST be sent unless it was already sent in the
      KeyProvClientHello message.

Notes:

The AD is carried in the <KeyProvClientHello> if sent as a result of a trigger and so is optional in the <ekyProvClientNonce>.

Status: Reported (1)

RFC 6063, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", December 2010

Source of RFC: keyprov (sec)

Errata ID: 5314
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Walter Summonte
Date Reported: 2018-03-29

Section 3.4.1.1. says: 

checksum of 0x356, resulting in a Checksum TLV of "334D5"

It should say:

checksum of 0xEA4C, resulting in a Checksum TLV of "304EA4C"

Notes:

The ALG_ISO3309_CRC16 should be based on polynomial : x^16+x^12+x^5+1

width=16 poly=0x1021 init=0x0000 refin=false refout=false xorout=0xffff

It should it be zero left padded

Report New Errata



Advanced Search