errata logo graphic

Found 4 records.

Status: Verified (2)

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

Source of RFC: keyprov (sec)

Errata ID: 2948

Status: Verified
Type: Technical

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

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: Held for Document Update (2)

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

Source of RFC: keyprov (sec)

Errata ID: 2697

Status: Held for Document Update
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2011-01-31
Held for Document Update by: Tim Polk

Section 3.4.1.1 says:

   Assume that the raw Client ID value or the value entered by the use
   is: myclient!ID

It should say:

   Assume that the raw Client ID value or the value entered by the use
   is: myclient!D

Notes:

Erroneously entered an extra character "I" into Client ID value.


Errata ID: 2725

Status: Held for Document Update
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2011-02-18
Held for Document Update by: Tim Polk

Section 7.2.2 says:

   To handle content negotiation, HTTP requests MAY include an HTTP
   Accept header field.  This header field SHOULD should be identified
   using the MIME type specified in Section 7.2.1.  The Accept header
   MAY include additional content types defined by future versions of
   this protocol.

It should say:

   To handle content negotiation, HTTP requests MAY include an HTTP
   Accept header field.  This header field SHOULD be identified
   using the MIME type specified in Section 7.2.1.  The Accept header
   MAY include additional content types defined by future versions of
   this protocol.

Notes:

Double "should"


Report New Errata