Dynamic Symmetric Key Provisioning Protocol (DSKPP)
draft-ietf-keyprov-dskpp-14

[Ballot discuss]
[This version is much better. I've updated my DISCUSS as per draft-ietf-keyprov-dskpp-12.txt. I might have missed some changes, please kindly point out any changes I've missed.]

I would like to discuss the following issues before recommending approval of this document:

14)
5.2.2.  KeyProvClientHello

      If user authentication passes, the DSKPP server generates a key
      K_PROV, which MUST consist of two parts of equal length, where the
      first half constitutes K_MAC and the second half constitutes
      K_TOKEN, i.e.,

K_PROV is defined in 4.1.2 as:

  K_PROV = DSKPP-PRF(k,s,dsLen), where

      k = R_C (i.e., the secret random value chosen by the DSKPP
      client)

      s = "Key generation" || K || R_S (where K is the key used to
      encrypt R_C and R_S is the random value chosen by the DSKPP
      server)

In the 2-pass mode the client doesn't have access to R_S, so is it omitted from "s" in this case? Please clarify the text if that is the case.

17)
In Section 10.3:

  Whenever the above is a concern, DSKPP SHOULD be run over a transport
  providing confidentiality.  If man-in-the-middle attacks for the
  purposes described above are a concern, the transport SHOULD also
  offer server-side authentication.

The last sentence: why only a SHOULD?

18)
What are the IANA registration procedures for the 2 new subregistries defined in sections:

12.6. PRF Algorithm ID Sub-Registry
12.7. Key Container Registration

?

21) The first mentioning of Unicode needs a normative reference.

[Ballot comment]
TLS should be an Informative reference, as it is mentioned in several places in the Security Considerations section.



4.2.4.  KeyProvClientNonce

      The particular
      realization of DSKPP-PRF (e.g., those defined in Appendix D

I think there is a missing ")" at the end of this line.

      depends on the MAC algorithm contained in the
      message.



12.3. MIME Media Type Registration

Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See
[RFC3203], Section 3.2. Implementations need to support both
                                                        ^^^^?
[RFC3629].

[Ballot discuss]
[This version is much better. I've updated my DISCUSS as per draft-ietf-keyprov-dskpp-12.txt. I might have missed some changes, please kindly point out any changes I've missed.]

I would like to discuss the following issues before recommending approval of this document:

14)
5.2.2.  KeyProvClientHello

      If user authentication passes, the DSKPP server generates a key
      K_PROV, which MUST consist of two parts of equal length, where the
      first half constitutes K_MAC and the second half constitutes
      K_TOKEN, i.e.,

K_PROV is defined in 4.1.2 as:

  K_PROV = DSKPP-PRF(k,s,dsLen), where

      k = R_C (i.e., the secret random value chosen by the DSKPP
      client)

      s = "Key generation" || K || R_S (where K is the key used to
      encrypt R_C and R_S is the random value chosen by the DSKPP
      server)

In the 2-pass mode the client doesn't have access to R_S, so is it omitted from "s" in this case? Please clarify the text if that is the case.

16)
5.2.3.  KeyProvServerFinished

          DSKPP Client                        DSKPP Server
          ------------                        ------------
                                  <---          KP, MAC, AD

[...]

      Finally, this message MUST include a MAC that the DSKPP client
      will use for key confirmation.  In addition, this message MUST
      also include a server authentication MAC (AD) if an existing key
      is being replaced.  These MACs are calculated as described in the
      previous section.

So I assume that "MAC" in the  message is the MAC
from Section 5.2.2 calculated using the "MAC 1 computation" constant.
Where is the the server authentication MAC (calculated using the "MAC 2 computation"
constant) is included in the  message?

<>

17)
In Section 10.3:

  Whenever the above is a concern, DSKPP SHOULD be run over a transport
  providing confidentiality.  If man-in-the-middle attacks for the
  purposes described above are a concern, the transport SHOULD also
  offer server-side authentication.

The last sentence: why only a SHOULD?

18)
What are the IANA registration procedures for the 2 new subregistries defined in sections:

12.6. PRF Algorithm ID Sub-Registry
12.7. Key Container Registration

?

21) The first mentioning of Unicode needs a normative reference.

[Ballot comment]
TLS should be an Informative reference, as it is mentioned in several places in the Security Considerations section.


3.2.2.  Protocol Initiated by the DSKPP Client

  o  The DSKPP client needs the URL of the DSKPP server (which is not

Informative reference to URI spec is needed here (RFC 3986)


4.2.1.  KeyProvTrigger

      6.  The web application passes AD, and possibly a DeviceID
          (identifies a particular device to which the key MUST be

I don't think this use of MUST is correct, as it doesn't describe a requirement on a compliant implementation. I suggest changing this to something like "to which the key is to be provisioned)"

          provisioned) and/or KeyID (identifies a key that will be
          replaced) to the DSKPP server

4.2.4.  KeyProvClientNonce

      The particular
      realization of DSKPP-PRF (e.g., those defined in Appendix D

I think there is a missing ")" at the end of this line.

      depends on the MAC algorithm contained in the
      message.



  [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998, .

This document was obsoleted, please reference RFC 3986.

  [UNICODE]  Davis, M. and M. Duerst, "Unicode Normalization Forms",
              March 2001,
              .

This reference is very old. You should reference something like  (dated 2009-09-03) instead.

[Ballot discuss]
[Updated as per draft-ietf-keyprov-dskpp-11.txt]

I would like to discuss the following issues before recommending approval of this document:

1)
3.2.3.  Protocol Triggered by the DSKPP Server

  The  message is sent in a HTTP response, and it is
  marked with MIME type "application/vnd.ietf.keyprov.dskpp+xml".  It

I think you meant application/dskpp+xml here.

Similarly:

7.2.1.  Identification of DSKPP Messages

  The MIME-type for all DSKPP messages MUST be

  application/vnd.ietf.keyprov.dskpp+xml

I think you meant application/dskpp+xml here.
(The same issue in examples in Section 7.2.7)

2)
3.3.  Status Codes

  NoProtocolVariants:  The DSKPP client only suggested a protocol
      variant (either 2-pass or 4-pass) that is not supported by the
      DSKPP server.  This error is only valid in the DSKPP server's
      first response message

According to Section 9, both variants are MUST implement for the server,
so this status code can never be returned.

3)
3.4.1.1.  Authentication Code Format

  Length (1 byte)          The length, in hexadecimal, of the value
                            field to follow.

1 byte length in hexadecimal? Do you mean the length is restricted to 15 bytes (one hexadecimal character)?
Or do you mean that the draft displays such values in hexadecimal, i.e. that that is only a display convention?

  Value (variable length)  A variable-length hexadecimal value
                            containing the instance-specific
                            information for this TLV.

As above.

  The Client ID is a mandatory TLV that represents the requester's
  identifier of maximum length 128.  The value is represented as an
  ASCII string that identifies the key request.  The ClientID MUST be
  HEX encoded.  For example, suppose ClientID is set to "AC00000A", the
  hexadecimal equivalent is 0x4143303030303041, resulting in a TLV of
  {0x1, 0x8, 0x4143303030303041}.

I am still confused about use of HEX here.

4)
3.4.1.1.  Authentication Code Format

  The Checksum is an OPTIONAL TLV, which is generated by the issuing
  server and sent to the user as part of the AC.  If the TLV is
  provided, the checksum value MUST be computed using the CRC16
  algorithm [ISO3309].

This reference must be Normative.

5)
4.2.5.  KeyProvServerFinished

      If status is Continue, then this message acts as a "commit"

Shouldn't this be Success, as this the final message from the server?

      When the Status attribute is not set to "Continue", this indicates
      failure and the DSKPP client MUST abort the protocol.

      After receiving a  message with Status =
      "Success", the DSKPP client MUST verify the key confirmation MAC

So, is it supposed to be "Continue" or "Success"?

5.2.2.  KeyProvClientHello

  How the DSKPP server uses this message:
      The DSKPP server will look for an acceptable combination of DSKPP
      version, variant (in this case, two-pass), key package format, key
      type, and cryptographic algorithms.  If the DSKPP Client's SAL
      does not match the capabilities of the DSKPP Server, or does not
      comply with key provisioning policy, then the DSKPP Server will
      set the Status attribute to something other than "Continue".
      Otherwise, Status will be set to "Continue".

"Continue" and not "Success"?

5.2.3.  KeyProvServerFinished

  What is contained in this message:
      A status attribute equivalent to the server's return code to
      .  If the server found an acceptable set of
      attributes from the client's SAL, then it sets status to Continue.

"Continue" and not "Success"?

6)

The normative reference to UTF-16 is a DOWNREF, as the document is Informational.

7)
12.4.  Status Code Registry

  Registration/Assignment Procedures:
      Following the policies outlined in [RFC3575], the IANA policy for
      assigning new values for the status codes for DSKPP MUST be
      "Specification Required" and their meanings MUST be documented in
      an RFC or in some other permanent and readily available reference,
      in sufficient detail that interoperability between independent
      implementations is possible.  No mechanism to mark entries as
      "deprecated" is envisioned.  It is possible to delete or update
      entries from the registry.

No, deletion of entries from the registry shouldn't be allowed. Otherwise there is a risk of redefining an earlier value in an incompatible way, which will lead to interoperability problems. This is one of the main reasons for having the registry.

8)
12.3.  MIME Media Type Registration

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

I believe the last sentence is in violation of MIME, which requires US-ASCII to be the default charset value.
This is also in violation of HTTP, which requires ISO-8859-1.

So I suggest removing the last quoted sentence.

9)
  [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
              .

This reference should be Normative, as the document is defining a normative mapping to HTTP.

  [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008,
              .

This reference looks Normative, due to a requirement to perform server identity verification.

11)
3.3.  Status Codes

  UnknownCriticalExtension:  A critical DSKPP extension (see below)
      used by the DSKPP client was not supported or recognized by the
      DSKPP server

Extension criticality is not discussed in the document (except for having
"Critical" attribute in the XML Schema).

12)
D.1.  Introduction

  This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES]
  and HMAC [RFC2104].  This appendix forms an informative part of the
  document.

Actually I disagree. I think this Appendix is Normative, considering that the two DSKPP-PRF functions are mandatory-to-implement.

D.2.  DSKPP-PRF-AES

D.2.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

Why MAY and not a MUST?

  http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128


D.3.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

As above: why MAY?

13)
5.1.2.  Key Wrap

  The DSKPP server and client MUST support one of the following key
  wrapping mechanisms:

If only one of the following is mandatory-to-implement, how can you achieve interoperability?

14)
5.2.2.  KeyProvClientHello

      If user authentication passes, the DSKPP server generates a key
      K_PROV, which MUST consist of two parts of equal length, where the
      first half constitutes K_MAC and the second half constitutes
      K_TOKEN, i.e.,

K_PROV is defined in 4.1.2 as:

  K_PROV = DSKPP-PRF(k,s,dsLen), where

      k = R_C (i.e., the secret random value chosen by the DSKPP
      client)

      s = "Key generation" || K || R_S (where K is the key used to
      encrypt R_C and R_S is the random value chosen by the DSKPP
      server)

In the 2-pass mode the client doesn't have access to R_S, so is it omitted from "s" in this case? Please clarify the text if that is the case.

15) In Section 5.2.2:

  The method the DSKPP server MUST use to calculate the server
  authentication MAC:
      The MAC MUST be computed on the (ASCII) string "MAC 2
      computation", the server identifier ServerID, and R, using a pre-
      existing MAC key K_MAC' (the MAC key that existed before this
      protocol run).  Note that the implementation may specify K_MAC' to
      be the value of the K_TOKEN that is being replaced, or a version
      of K_MAC from the previous protocol run.

The last sentence: why provide the choice and how can the other end know which K_MAC' was used for calculations?

Similar text in Section 4.2.3:

      This MAC MUST be computed using DSKPP-PRF (see
      Section 3.4.2), where the input parameter k MUST be set to the
      existing MAC key K_MAC' (i.e., the value of the MAC key that
      existed before this protocol run; the implementation MAY specify
      K_MAC' to be the value of the K_TOKEN that is being replaced, or a
      version of K_MAC from the previous protocol run), and input
      parameter dsLen MUST be set to the length of R_S.

16)
5.2.3.  KeyProvServerFinished

          DSKPP Client                        DSKPP Server
          ------------                        ------------
                                  <---          KP, MAC, AD

[...]

      Finally, this message MUST include a MAC that the DSKPP client
      will use for key confirmation.  In addition, this message MUST
      also include a server authentication MAC (AD) if an existing key
      is being replaced.  These MACs are calculated as described in the
      previous section.

So I assume that "MAC" in the  message is the MAC
from Section 5.2.2 calculated using the "MAC 1 computation" constant.
Where is the the server authentication MAC (calculated using the "MAC 2 computation" constant) is included in the  message?

17)
In Section 10.3:

  Whenever the above is a concern, DSKPP SHOULD be run over a transport
  providing confidentiality.  If man-in-the-middle attacks for the
  purposes described above are a concern, the transport SHOULD also
  offer server-side authentication.

The last sentence: why only a SHOULD?

18)
5.1.  Key Protection Methods

  This section introduces three key protection methods for the two-pass
  variant.  Additional methods MAY be defined by external entities or
  through the IETF process.

Is a new IANA registry needed for these?

19)
8.1.  General Processing Requirements

  Implementations that compare values that are represented using
  different character encodings MUST use a comparison method that
  returns the same result as converting both values to the Unicode
  character encoding, Normalization Form C [UNICODE], and then

I am not sure why Normalization Form C is only required when different Unicode encodings are used? I think you either need to always require it, or never require it.

  performing an exact binary comparison.

20)
3.4.1.1.  Authentication Code Format

    The Password is a mandatory TLV the contains a one-time use shared
    secret known by the user and the Provisioning Server.  The password
    value is unique and SHOULD be a random string to make AC more
    difficult to guess.  The string MUST be UTF-8 encoded in accordance
    with [RFC3629].  For example, suppose password is set to "3582", then
    the TLV would be {0x2, 0x4, UTF-8("3582")}.

If the password is intended to be entered by a human in some sort of UI, then this is missing some text about disallowed Unicode characters and Unicode normalization to be used (e.g. Net-Unicode).

[Ballot discuss]
The authors gave been engaged in a discussion about the concerns
  raised by Brian Carpenter in his Gen-ART Review.  A revised I-D is
  needed to resolve the concerns that have been under discussion.

  The Gen-ART review can be found at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg05287.html

  I am especially concerns with the concern raised about Section 3.4.3.
  The DSKPP Message Hash Algorithm is rigidly bound to SHA-256, and
  algorithm agility is needed.

[Ballot comment]
TLS should be an Informative reference, as it is mentioned in several places in the Security Considerations section.


3.2.2.  Protocol Initiated by the DSKPP Client

  o  The DSKPP client needs the URL of the DSKPP server (which is not

Informative reference to URI spec is needed here (RFC 3986)


4.2.1.  KeyProvTrigger

      6.  The web application passes AD, and possibly a DeviceID
          (identifies a particular device to which the key MUST be

I don't think this use of MUST is correct, as it doesn't describe a requirement on a compliant implementation. I suggest changing this to something like "to which the key is to be provisioned)"

          provisioned) and/or KeyID (identifies a key that will be
          replaced) to the DSKPP server

4.2.4.  KeyProvClientNonce

      The particular
      realization of DSKPP-PRF (e.g., those defined in Appendix D

I think there is a missing ")" at the end of this line.

      depends on the MAC algorithm contained in the
      message.



  [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998, .

This document was obsoleted, please reference RFC 3986.

  [UNICODE]  Davis, M. and M. Duerst, "Unicode Normalization Forms",
              March 2001,
              .

This reference is very old. You should reference something like  (dated 2009-09-03) instead.

[Ballot discuss]
[Updated.]

I would like to discuss the following issues before recommending approval of this document:

1)
3.2.3.  Protocol Triggered by the DSKPP Server

  The  message is sent in a HTTP response, and it is
  marked with MIME type "application/vnd.ietf.keyprov.dskpp+xml".  It

I think you meant application/dskpp+xml here.

Similarly:

7.2.1.  Identification of DSKPP Messages

  The MIME-type for all DSKPP messages MUST be

  application/vnd.ietf.keyprov.dskpp+xml

I think you meant application/dskpp+xml here.
(The same issue in examples in Section 7.2.7)

2)
3.3.  Status Codes

  NoProtocolVariants:  The DSKPP client only suggested a protocol
      variant (either 2-pass or 4-pass) that is not supported by the
      DSKPP server.  This error is only valid in the DSKPP server's
      first response message

According to Section 9, both variants are MUST implement for the server,
so this status code can never be returned.

3)
3.4.1.1.  Authentication Code Format

  Length (1 byte)          The length, in hexadecimal, of the value
                            field to follow.

1 byte length in hexadecimal? Do you mean the length is restricted to 15 bytes (one hexadecimal character)?
Or do you mean that the draft displays such values in hexadecimal, i.e. that that is only a display convention?

  Value (variable length)  A variable-length hexadecimal value
                            containing the instance-specific
                            information for this TLV.

As above.

  The Client ID is a mandatory TLV that represents the requester's
  identifier of maximum length 128.  The value is represented as an
  ASCII string that identifies the key request.  The ClientID MUST be
  HEX encoded.  For example, suppose ClientID is set to "AC00000A", the
  hexadecimal equivalent is 0x4143303030303041, resulting in a TLV of
  {0x1, 0x8, 0x4143303030303041}.

I am still confused about use of HEX here.

4)
3.4.1.1.  Authentication Code Format

  The Checksum is an OPTIONAL TLV, which is generated by the issuing
  server and sent to the user as part of the AC.  If the TLV is
  provided, the checksum value MUST be computed using the CRC16
  algorithm [ISO3309].

This reference must be Normative.

5)
4.2.5.  KeyProvServerFinished

      If status is Continue, then this message acts as a "commit"

Shouldn't this be Success, as this the final message from the server?

      When the Status attribute is not set to "Continue", this indicates
      failure and the DSKPP client MUST abort the protocol.

      After receiving a  message with Status =
      "Success", the DSKPP client MUST verify the key confirmation MAC

So, is it supposed to be "Continue" or "Success"?

5.2.2.  KeyProvClientHello

  How the DSKPP server uses this message:
      The DSKPP server will look for an acceptable combination of DSKPP
      version, variant (in this case, two-pass), key package format, key
      type, and cryptographic algorithms.  If the DSKPP Client's SAL
      does not match the capabilities of the DSKPP Server, or does not
      comply with key provisioning policy, then the DSKPP Server will
      set the Status attribute to something other than "Continue".
      Otherwise, Status will be set to "Continue".

"Continue" and not "Success"?

5.2.3.  KeyProvServerFinished

  What is contained in this message:
      A status attribute equivalent to the server's return code to
      .  If the server found an acceptable set of
      attributes from the client's SAL, then it sets status to Continue.

"Continue" and not "Success"?

6)

The normative reference to UTF-16 is a DOWNREF, as the document is Informational.

7)
12.4.  Status Code Registry

  Registration/Assignment Procedures:
      Following the policies outlined in [RFC3575], the IANA policy for
      assigning new values for the status codes for DSKPP MUST be
      "Specification Required" and their meanings MUST be documented in
      an RFC or in some other permanent and readily available reference,
      in sufficient detail that interoperability between independent
      implementations is possible.  No mechanism to mark entries as
      "deprecated" is envisioned.  It is possible to delete or update
      entries from the registry.

No, deletion of entries from the registry shouldn't be allowed. Otherwise there is a risk of redefining an earlier value in an incompatible way, which will lead to interoperability problems. This is one of the main reasons for having the registry.

8)
12.3.  MIME Media Type Registration

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

I believe the last sentence is in violation of MIME, which requires US-ASCII to be the default charset value.
This is also in violation of HTTP, which requires ISO-8859-1.

So I suggest removing the last quoted sentence.

9)
  [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
              .

This reference should be Normative, as the document is defining a normative mapping to HTTP.

  [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008,
              .

This reference looks Normative, due to a requirement to perform server identity verification.

10)
3.4.1.1.  Authentication Code Format

  The following table summarizes the TLVs defined in this document.
  Optional TLVs are allowed for vendor-specific extensions with the
  constraint that the high bit MUST be set to indicate a vendor-
  specific type.  Other TLVs are left for later revisions of this
  protocol.

I think this needs an IANA registry, considering that the value space is only 1 byte.

11)
3.3.  Status Codes

  UnknownCriticalExtension:  A critical DSKPP extension (see below)
      used by the DSKPP client was not supported or recognized by the
      DSKPP server

Extension criticality is not discussed in the document (except for having
"Critical" attribute in the XML Schema).

12)
D.1.  Introduction

  This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES]
  and HMAC [RFC2104].  This appendix forms an informative part of the
  document.

Actually I disagree. I think this Appendix is Normative, considering that the two DSKPP-PRF functions are mandatory-to-implement.

D.2.  DSKPP-PRF-AES

D.2.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

Why MAY and not a MUST?

  http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128


D.3.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

As above: why MAY?

13)
5.1.2.  Key Wrap

  The DSKPP server and client MUST support one of the following key
  wrapping mechanisms:

If only one of the following is mandatory-to-implement, how can you achieve interoperability?

14)
5.2.2.  KeyProvClientHello

      If user authentication passes, the DSKPP server generates a key
      K_PROV, which MUST consist of two parts of equal length, where the
      first half constitutes K_MAC and the second half constitutes
      K_TOKEN, i.e.,

K_PROV is defined in 4.1.2 as:

  K_PROV = DSKPP-PRF(k,s,dsLen), where

      k = R_C (i.e., the secret random value chosen by the DSKPP
      client)

      s = "Key generation" || K || R_S (where K is the key used to
      encrypt R_C and R_S is the random value chosen by the DSKPP
      server)

In the 2-pass mode the client doesn't have access to R_S, so is it omitted from "s" in this case? Please clarify the text if that is the case.

15) In Section 5.2.2:

  The method the DSKPP server MUST use to calculate the server
  authentication MAC:
      The MAC MUST be computed on the (ASCII) string "MAC 2
      computation", the server identifier ServerID, and R, using a pre-
      existing MAC key K_MAC' (the MAC key that existed before this
      protocol run).  Note that the implementation may specify K_MAC' to
      be the value of the K_TOKEN that is being replaced, or a version
      of K_MAC from the previous protocol run.

The last sentence: why provide the choice and how can the other end know which K_MAC' was used for calculations?

Similar text in Section 4.2.3:

      This MAC MUST be computed using DSKPP-PRF (see
      Section 3.4.2), where the input parameter k MUST be set to the
      existing MAC key K_MAC' (i.e., the value of the MAC key that
      existed before this protocol run; the implementation MAY specify
      K_MAC' to be the value of the K_TOKEN that is being replaced, or a
      version of K_MAC from the previous protocol run), and input
      parameter dsLen MUST be set to the length of R_S.

16)
5.2.3.  KeyProvServerFinished

          DSKPP Client                        DSKPP Server
          ------------                        ------------
                                  <---          KP, MAC, AD

[...]

      Finally, this message MUST include a MAC that the DSKPP client
      will use for key confirmation.  In addition, this message MUST
      also include a server authentication MAC (AD) if an existing key
      is being replaced.  These MACs are calculated as described in the
      previous section.

So I assume that "MAC" in the  message is the MAC
from Section 5.2.2 calculated using the "MAC 1 computation" constant.
Where is the the server authentication MAC (calculated using the "MAC 2 computation" constant) is included in the  message?

17)
In Section 10.3:

  Whenever the above is a concern, DSKPP SHOULD be run over a transport
  providing confidentiality.  If man-in-the-middle attacks for the
  purposes described above are a concern, the transport SHOULD also
  offer server-side authentication.

The last sentence: why only a SHOULD?

18)
5.1.  Key Protection Methods

  This section introduces three key protection methods for the two-pass
  variant.  Additional methods MAY be defined by external entities or
  through the IETF process.

Is a new IANA registry needed for these?

19)
8.1.  General Processing Requirements

  Implementations that compare values that are represented using
  different character encodings MUST use a comparison method that
  returns the same result as converting both values to the Unicode
  character encoding, Normalization Form C [UNICODE], and then

I am not sure why Normalization Form C is only required when different Unicode encodings are used? I think you either need to always require it, or never require it.

  performing an exact binary comparison.

20)
3.4.1.1.  Authentication Code Format

    The Password is a mandatory TLV the contains a one-time use shared
    secret known by the user and the Provisioning Server.  The password
    value is unique and SHOULD be a random string to make AC more
    difficult to guess.  The string MUST be UTF-8 encoded in accordance
    with [RFC3629].  For example, suppose password is set to "3582", then
    the TLV would be {0x2, 0x4, UTF-8("3582")}.

If the password is intended to be entered by a human in some sort of UI, then this is missing some text about disallowed Unicode characters and Unicode normalization to be used (e.g. Net-Unicode).

[Ballot discuss]
I have no objection to this work, although at only 95 pages I feel a little cheated.

I am worried by the situation with respect to IPR.

The proto-write-up indicates that there are some on-going IPR issues, and the IETF IPR search reveals three separate disclosure filings (although they are possibly the same one three times?).

The IETF last call does not appear to have called out the IPR issues.

What is the actual state of affairs?

[Ballot comment]
1. Section 6 says that "the use of extensions SHOULD be carefully considered" but capitalized key words apply to protocols, not protocol designers. Suggested text: "protocol designers are advised to carefully consider the use of extensions".

Similar considerations apply to Section 10.4 "Implementers SHOULD also be aware that cryptographic algorithms become weaker with time."

2. Section 7.2 "presents a binding of the previous messages to HTTP/1.1" but it is not clear if the HTTP binding is mandatory-to-implement. This could be added to Section 9.

3. Section 1.2 makes provision for versioning, but no guidance is provided regarding when the major and minor versions shall be incremented, how to compare version numbers, etc. You might be able to borrow some text from Section 4.4.1 of RFC 3920 or some similar specification.

[Ballot discuss]
1. The defined and referenced identifiers are described as URIs of the form xmlns:foo="someUri" and each identifier specifies a prefix such as "foo". For example:

  The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is:

  xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"

  References to qualified elements in the DSKPP schema defined herein
  use the prefix "dskpp".

The URI here is "urn:ietf:params:xml:ns:keyprov:dskpp" without the "xmlns:dskpp=" preceding the URI so to reduce confusion it would be best to include only the URI. Also, is the prefix "dskpp" hardcoded, or are developers allowed to use any prefix? The point of XML namespaces was not to hardcode prefixes, so it would be best to say that the "dskpp" prefix is used in examples here but any prefix is allowed.

2. In Section 2.1, the Authentication Code is defined as follows:

  Authentication Code (AC):  User Authentication Code comprised of a
      string of numeric characters known to the device and the server
      and containing a client identifier and a password.  This
      ClientID/password combination is used only once, and then
      discarded.

However, in Section 3.4.1.1 the Authentication Code format does not seem to be strictly numeric, because it is a series of Type-Length-Value triads encoded as hexadecimal.

3. In Section 3.4.1.1, the Password TLV is defined as follows:

  The Password is a mandatory TLV the contains a one-time use shared
  secret known by the user and the Provisioning Server.  The password
  value is unique and SHOULD be a random string to make AC more
  difficult to guess.  The string MUST be UTF-8 encoded in accordance
  with [RFC3629].  For example, suppose password is set to "3582", then
  the TLV would be {0x2, 0x4, UTF-8("3582")}.

Does the Password really need to be UTF-8? Is it expected that characters outside the US-ASCII range will be used? Given that the next paragraph talks about "the typed password", this document seems to assume that a user will input this password using a keyboard. Can we safely assume that a user will be able to input any UTF-8 character, such as U+233B4 (from RFC 3629)? To ensure that the user-typed password matches what is on file at the Provisioning Server, this document might need to specify normalization of the typed password using Net-Unicode, SASLprep, or some other string preparation technology.

4. In Section 5.1.2, the key wrapping algorithms are confusingly identified, because it appears on a cursory reading that "KW-AES128 without padding" and "KW-AES128 with padding" have the same identifier, when in fact they are identified by id-aes128-wrap and id-aes128-wrap-pad respectively in draft-housley-aes-key-wrap-with-pad-02.

5. Appendices D.2.1 and D.3.1 define the following algorithm identifiers:

  http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
  http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256

It's not clear what the IETF policy is on the use of ietf.org URIs as identifiers, but these URIs appear to be used without authorization.

6. Section 5 mentions a URN of urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer as defined in [PSKC] but that URN is not to be found in draft-ietf-keyprov-portable-symmetric-key-container-03

7. Several URNs containing fragment identifiers are defined in Sections 5.1.1, 5.1.2, and 5.1.3:

urn:ietf:params:xml:schema:keyprov:dskpp#transport
urn:ietf:params:xml:schema:keyprov:dskpp#wrap
urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap

However, the "#" character is discouraged in URNs according to RFC 2141:

  RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
  purposes. The URN-WG has not yet debated the applicability and
  precise semantics of those purposes as applied to URNs. Therefore,
  these characters are RESERVED for future developments.  Namespace
  developers SHOULD NOT use these characters in unencoded form, but
  rather use the appropriate %-encoding for each character.

Therefore it seems preferable to change "#" to ":" (or some other non-reserved character) in these URNs.

8. Given that "the principal syntax is XML", a normative reference to http://www.w3.org/TR/2006/REC-xml-20060816 is needed.

9. Section 3.1 says that DSKPP "is layered on a transport mechanism such as HTTP" but Section 3.2.2 says that "DSKPP messages ... are sent over HTTPS", so a reference to RFC 2616 (probably along with RFC 2818) would be appropriate.

10. Section 3.2.2 states the following about certificate validation or server identity checking:

  In Step 1, the client establishes a TLS connection, and authenticates
  the server (that is, validates the certificate, and compares the host
  name in the URL with the certificate)

Section 4.2.3 states:

  If K is equivalent to K_SERVER, then the cryptographic
  module SHOULD verify the server's certificate before using it to
  encrypt R_C in accordance with [RFC5280].

However, no details are provided regarding certificate validation. Given that HTTPS is used, a reference to Section 3.1 of RFC 2818 is needed.

11. In Section 3.4.3, "the resultant string is hashed using SHA-256 in accordance with [FIPS180-SHA]"; has any thought been given to hash agility?

12. Section 4.2.1 states:

      3.  The web application processes the request and returns an
          authentication code to the user, e.g., in the form of an email
          message

Is it considered a best practice to send the authentication code via email? Nothing is said here about protection of this message (whether sent via email or some other method).

13. Section 10.1 says:

  DSKPP SHOULD, therefore, be run over a transport providing
  confidentiality and integrity, such as HTTP over Transport Layer
  Security (TLS) with a suitable ciphersuite, when such threats are a
  concern.

Why not MUST?

14. Section 10.6.3 says:

  DSKPP servers MUST authenticate themselves...

Does this mean that a DSKPP client MUST authenticate the server to which it connects?

15. Section 11 states:

  The DSKPP protocol is mostly meant for machine-to-machine
  communications; as such, most of its elements are tokens not meant
  for direct human consumption.  If these tokens are presented to the
  end user, some localization may need to occur.

Because localization methods are not specified, it is doubtful that developers will be able to produce interoperable implementations. More details are needed here.

16. Section 12.3 (MIME Media Type Registration) has the following deficiencies:

- the optional parameter field specifies "charset", but the default is "UTF-8", which is not a character set according to RFC 2277.

- the encoding considerations field needs to mention that implementations need to support both UTF-8 and UTF-16

- the security considerations field needs to reference this specification (especially Section 10), rather than trying to address all security issues in just a few words.

- the interoperability considerations field says "this content type provides a basis for a protocol" but that text is not helpful. Are there any actual or potential problems with interoperability? If not, say "None" here.

[Ballot comment]
1. Section 6 says that "the use of extensions SHOULD be carefully considered" but capitalized key words apply to protocols, not protocol designers. Suggested text: "protocol designers are advised to carefully consider the use of extensions".

Similar considerations apply to Section 10.4 "Implementers SHOULD also be aware that cryptographic algorithms become weaker with time."

2. Section 7.2 "presents a binding of the previous messages to HTTP/1.1" but it is not clear if the HTTP binding is mandatory-to-implement. This could be added to Section 9.

3. Section 1.2 makes provision for versioning, but no guidance is provided regarding when the major and minor versions shall be incremented, how to compare version numbers, etc. You might be able to borrow some text from Section 4.4.1 of RFC 3920 or some similar specification.

[Ballot discuss]
1. The defined and referenced identifiers are described as URIs of the form xmlns:foo="someUri" and each identifier specifies a prefix such as "foo". For example:

  The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is:

  xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"

  References to qualified elements in the DSKPP schema defined herein
  use the prefix "dskpp".

The URI here is "urn:ietf:params:xml:ns:keyprov:dskpp" without the "xmlns:dskpp=" preceding the URI so to reduce confusion it would be best to include only the URI. Also, is the prefix "dskpp" hardcoded, or are developers allowed to use any prefix? The point of XML namespaces was not to hardcode prefixes, so it would be best to say that the "dskpp" prefix is used in examples here but any prefix is allowed.

2. In Section 2.1, the Authentication Code is defined as follows:

  Authentication Code (AC):  User Authentication Code comprised of a
      string of numeric characters known to the device and the server
      and containing a client identifier and a password.  This
      ClientID/password combination is used only once, and then
      discarded.

However, in Section 3.4.1.1 the Authentication Code format does not seem to be strictly numeric, because it is a series of Type-Length-Value triads encoded as hexadecimal.

3. In Section 3.4.1.1, the Password TLV is defined as follows:

  The Password is a mandatory TLV the contains a one-time use shared
  secret known by the user and the Provisioning Server.  The password
  value is unique and SHOULD be a random string to make AC more
  difficult to guess.  The string MUST be UTF-8 encoded in accordance
  with [RFC3629].  For example, suppose password is set to "3582", then
  the TLV would be {0x2, 0x4, UTF-8("3582")}.

Does the Password really need to be UTF-8? Is it expected that characters outside the US-ASCII range will be used? Given that the next paragraph talks about "the typed password", this document seems to assume that a user will input this password using a keyboard. Can we safely assume that a user will be able to input any UTF-8 character, such as U+233B4 (from RFC 3629)? To ensure that the user-typed password matches what is on file at the Provisioning Server, this document might need to specify normalization of the typed password using Net-Unicode, SASLprep, or some other string preparation technology.

3. In Section 5.1.2, the key wrapping algorithms are confusingly identified, because it appears on a cursory reading that "KW-AES128 without padding" and "KW-AES128 with padding" have the same identifier, when in fact they are identified by id-aes128-wrap and id-aes128-wrap-pad respectively in draft-housley-aes-key-wrap-with-pad-02.

4. Appendices D.2.1 and D.3.1 define the following algorithm identifiers:

  http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
  http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256

It's not clear what the IETF policy is on the use of ietf.org URIs as identifiers, but these URIs appear to be used without authorization.

5. Section 5 mentions a URN of urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer as defined in [PSKC] but that URN is not to be found in draft-ietf-keyprov-portable-symmetric-key-container-03

6. Several URNs containing fragment identifiers are defined in Sections 5.1.1, 5.1.2, and 5.1.3:

urn:ietf:params:xml:schema:keyprov:dskpp#transport
urn:ietf:params:xml:schema:keyprov:dskpp#wrap
urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap

However, the "#" character is discouraged in URNs according to RFC 2141:

  RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
  purposes. The URN-WG has not yet debated the applicability and
  precise semantics of those purposes as applied to URNs. Therefore,
  these characters are RESERVED for future developments.  Namespace
  developers SHOULD NOT use these characters in unencoded form, but
  rather use the appropriate %-encoding for each character.

Therefore it seems preferable to change "#" to ":" (or some other non-reserved character) in these URNs.

7. Given that "the principal syntax is XML", a normative reference to http://www.w3.org/TR/2006/REC-xml-20060816 is needed.

8. Section 3.1 says that DSKPP "is layered on a transport mechanism such as HTTP" but Section 3.2.2 says that "DSKPP messages ... are sent over HTTPS", so a reference to RFC 2616 (probably along with RFC 2818) would be appropriate.

9. Section 3.2.2 states the following about certificate validation or server identity checking:

  In Step 1, the client establishes a TLS connection, and authenticates
  the server (that is, validates the certificate, and compares the host
  name in the URL with the certificate)

Section 4.2.3 states:

  If K is equivalent to K_SERVER, then the cryptographic
  module SHOULD verify the server's certificate before using it to
  encrypt R_C in accordance with [RFC5280].

However, no details are provided regarding certificate validation. Given that HTTPS is used, a reference to Section 3.1 of RFC 2818 is needed.

10. In Section 3.4.3, "the resultant string is hashed using SHA-256 in accordance with [FIPS180-SHA]"; has any thought been given to hash agility?

11. Section 4.2.1 states:

      3.  The web application processes the request and returns an
          authentication code to the user, e.g., in the form of an email
          message

Is it considered a best practice to send the authentication code via email? Nothing is said here about protection of this message (whether sent via email or some other method).

12. Section 10.1 says:

  DSKPP SHOULD, therefore, be run over a transport providing
  confidentiality and integrity, such as HTTP over Transport Layer
  Security (TLS) with a suitable ciphersuite, when such threats are a
  concern.

Why not MUST?

13. Section 10.6.3 says:

  DSKPP servers MUST authenticate themselves...

Does this mean that a DSKPP client MUST authenticate the server to which it connects?

14. Section 11 states:

  The DSKPP protocol is mostly meant for machine-to-machine
  communications; as such, most of its elements are tokens not meant
  for direct human consumption.  If these tokens are presented to the
  end user, some localization may need to occur.

Because localization methods are not specified, it is doubtful that developers will be able to produce interoperable implementations. More details are needed here.

15. Section 12.3 (MIME Media Type Registration) has the following deficiencies:

- the optional parameter field specifies "charset", but the default is "UTF-8", which is not a character set according to RFC 2277.

- the encoding considerations field needs to mention that implementations need to support both UTF-8 and UTF-16

- the security considerations field needs to reference this specification (especially Section 10), rather than trying to address all security issues in just a few words.

- the interoperability considerations field says "this content type provides a basis for a protocol" but that text is not helpful. Are there any actual or potential problems with interoperability? If not, say "None" here.

[Ballot comment]
1. Section 6 says that "the use of extensions SHOULD be carefully considered" but capitalized key words apply to protocols, not protocol designers. Suggested text: "protocol designers are advised to carefully consider the use of extensions".

[Ballot discuss]
1. The defined and referenced identifiers are described as URIs of the form xmlns:foo="someUri" and each identifier specifies a prefix such as "foo". For example:

  The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is:

  xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"

  References to qualified elements in the DSKPP schema defined herein
  use the prefix "dskpp".

The URI here is "urn:ietf:params:xml:ns:keyprov:dskpp" without the "xmlns:dskpp=" preceding the URI so to reduce confusion it would be best to include only the URI. Also, is the prefix "dskpp" hardcoded, or are developers allowed to use any prefix? The point of XML namespaces was not to hardcode prefixes, so it would be best to say that the "dskpp" prefix is used in examples here but any prefix is allowed.

2. In Section 2.1, the Authentication Code is defined as follows:

  Authentication Code (AC):  User Authentication Code comprised of a
      string of numeric characters known to the device and the server
      and containing a client identifier and a password.  This
      ClientID/password combination is used only once, and then
      discarded.

However, in Section 3.4.1.1 the Authentication Code format does not seem to be strictly numeric, because it is a series of Type-Length-Value triads encoded as hexadecimal.

3. In Section 3.4.1.1, the Password TLV is defined as follows:

  The Password is a mandatory TLV the contains a one-time use shared
  secret known by the user and the Provisioning Server.  The password
  value is unique and SHOULD be a random string to make AC more
  difficult to guess.  The string MUST be UTF-8 encoded in accordance
  with [RFC3629].  For example, suppose password is set to "3582", then
  the TLV would be {0x2, 0x4, UTF-8("3582")}.

Does the Password really need to be UTF-8? Is it expected that characters outside the US-ASCII range will be used? Given that the next paragraph talks about "the typed password", this document seems to assume that a user will input this password using a keyboard. Can we safely assume that a user will be able to input any UTF-8 character, such as U+233B4 (from RFC 3629)? To ensure that the user-typed password matches what is on file at the Provisioning Server, this document might need to specify normalization of the typed password using Net-Unicode, SASLprep, or some other string preparation technology.

3. In Section 5.1.2, the key wrapping algorithms are confusingly identified, because it appears on a cursory reading that "KW-AES128 without padding" and "KW-AES128 with padding" have the same identifier, when in fact they are identified by id-aes128-wrap and id-aes128-wrap-pad respectively in draft-housley-aes-key-wrap-with-pad-02.

4. Appendices D.2.1 and D.3.1 define the following algorithm identifiers:

  http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128
  http://www.ietf.org/keyprov/dskpp#dskpp-prf-sha256

It's not clear what the IETF policy is on the use of ietf.org URIs as identifiers, but these URIs appear to be used without authorization.

5. Section 5 mentions a URN of urn:ietf:params:xml:ns:keyprov:pskc#KeyContainer as defined in [PSKC] but that URN is not to be found in draft-ietf-keyprov-portable-symmetric-key-container-03

6. Several URNs containing fragment identifiers are defined in Sections 5.1.1, 5.1.2, and 5.1.3:

urn:ietf:params:xml:schema:keyprov:dskpp#transport
urn:ietf:params:xml:schema:keyprov:dskpp#wrap
urn:ietf:params:xml:schema:keyprov:dskpp#passphrase-wrap

However, the "#" character is discouraged in URNs according to RFC 2141:

  RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
  purposes. The URN-WG has not yet debated the applicability and
  precise semantics of those purposes as applied to URNs. Therefore,
  these characters are RESERVED for future developments.  Namespace
  developers SHOULD NOT use these characters in unencoded form, but
  rather use the appropriate %-encoding for each character.

Therefore it seems preferable to change "#" to ":" (or some other non-reserved character) in these URNs.

7. Given that "the principal syntax is XML", a normative reference to http://www.w3.org/TR/2006/REC-xml-20060816 is needed.

8. Section 3.1 says that DSKPP "is layered on a transport mechanism such as HTTP" but Section 3.2.2 says that "DSKPP messages ... are sent over HTTPS", so a reference to RFC 2616 (probably along with RFC 2818) would be appropriate.

9. Section 3.2.2 states the following about certificate validation or server identity checking:

  In Step 1, the client establishes a TLS connection, and authenticates
  the server (that is, validates the certificate, and compares the host
  name in the URL with the certificate)

Section 4.2.3 states:

  If K is equivalent to K_SERVER, then the cryptographic
  module SHOULD verify the server's certificate before using it to
  encrypt R_C in accordance with [RFC5280].

However, no details are provided regarding certificate validation. Given that HTTPS is used, a reference to Section 3.1 of RFC 2818 is needed.

10. In Section 3.4.3, "the resultant string is hashed using SHA-256 in accordance with [FIPS180-SHA]"; has any thought been given to hash agility?

11. Section 4.2.1 states:

      3.  The web application processes the request and returns an
          authentication code to the user, e.g., in the form of an email
          message

Is it considered a best practice to send the authentication code via email? Nothing is said here about protection of this message (whether sent via email or some other method).

[Ballot comment]
TLS should be an Informative reference, as it is mentioned in several places in the Security Considerations section.


3.2.2.  Protocol Initiated by the DSKPP Client

  o  The DSKPP client needs the URL of the DSKPP server (which is not

Informative reference to URI spec is needed here (RFC 3986)


4.2.1.  KeyProvTrigger

      6.  The web application passes AD, and possibly a DeviceID
          (identifies a particular device to which the key MUST be

I don't think this use of MUST is correct, as it doesn't describe a requirement on a compliant implementation. I suggest changing this to something like "to which the key is to be provisioned)"

          provisioned) and/or KeyID (identifies a key that will be
          replaced) to the DSKPP server

4.2.4.  KeyProvClientNonce

      The particular
      realization of DSKPP-PRF (e.g., those defined in Appendix D

I think there is a missing ")" at the end of this line.

      depends on the MAC algorithm contained in the
      message.



  [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998, .

This document was obsoleted, please reference RFC 3986.

  [UNICODE]  Davis, M. and M. Duerst, "Unicode Normalization Forms",
              March 2001,
              .

This reference is very old. You should reference something like  (dated 2009-09-03) instead.

[Ballot discuss]
[Updated. DISCUSS issues starting from # 17 are new. Comment section is unchanged.]

I would like to discuss the following issues before recommending approval of this document:

1)
3.2.3.  Protocol Triggered by the DSKPP Server

  The  message is sent in a HTTP response, and it is
  marked with MIME type "application/vnd.ietf.keyprov.dskpp+xml".  It

I think you meant application/dskpp+xml here.

Similarly:

7.2.1.  Identification of DSKPP Messages

  The MIME-type for all DSKPP messages MUST be

  application/vnd.ietf.keyprov.dskpp+xml

I think you meant application/dskpp+xml here.
(The same issue in examples in Section 7.2.7)

2)
3.3.  Status Codes

  NoProtocolVariants:  The DSKPP client only suggested a protocol
      variant (either 2-pass or 4-pass) that is not supported by the
      DSKPP server.  This error is only valid in the DSKPP server's
      first response message

According to Section 9, both variants are MUST implement for the server,
so this status code can never be returned.

3)
3.4.1.1.  Authentication Code Format

  Length (1 byte)          The length, in hexadecimal, of the value
                            field to follow.

1 byte length in hexadecimal? Do you mean the length is restricted to 15 bytes (one hexadecimal character)?
Or do you mean that the draft displays such values in hexadecimal, i.e. that that is only a display convention?

  Value (variable length)  A variable-length hexadecimal value
                            containing the instance-specific
                            information for this TLV.

As above.

  The Client ID is a mandatory TLV that represents the requester's
  identifier of maximum length 128.  The value is represented as an
  ASCII string that identifies the key request.  The ClientID MUST be
  HEX encoded.  For example, suppose ClientID is set to "AC00000A", the
  hexadecimal equivalent is 0x4143303030303041, resulting in a TLV of
  {0x1, 0x8, 0x4143303030303041}.

I am still confused about use of HEX here.

4)
3.4.1.1.  Authentication Code Format

  The Checksum is an OPTIONAL TLV, which is generated by the issuing
  server and sent to the user as part of the AC.  If the TLV is
  provided, the checksum value MUST be computed using the CRC16
  algorithm [ISO3309].

This reference must be Normative.

5)
4.2.5.  KeyProvServerFinished

      If status is Continue, then this message acts as a "commit"

Shouldn't this be Success, as this the final message from the server?

      When the Status attribute is not set to "Continue", this indicates
      failure and the DSKPP client MUST abort the protocol.

      After receiving a  message with Status =
      "Success", the DSKPP client MUST verify the key confirmation MAC

So, is it supposed to be "Continue" or "Success"?

5.2.2.  KeyProvClientHello

  How the DSKPP server uses this message:
      The DSKPP server will look for an acceptable combination of DSKPP
      version, variant (in this case, two-pass), key package format, key
      type, and cryptographic algorithms.  If the DSKPP Client's SAL
      does not match the capabilities of the DSKPP Server, or does not
      comply with key provisioning policy, then the DSKPP Server will
      set the Status attribute to something other than "Continue".
      Otherwise, Status will be set to "Continue".

"Continue" and not "Success"?

5.2.3.  KeyProvServerFinished

  What is contained in this message:
      A status attribute equivalent to the server's return code to
      .  If the server found an acceptable set of
      attributes from the client's SAL, then it sets status to Continue.

"Continue" and not "Success"?

6)
11.  Internationalization Considerations

  The DSKPP protocol is mostly meant for machine-to-machine
  communications; as such, most of its elements are tokens not meant
  for direct human consumption.  If these tokens are presented to the
  end user, some localization may need to occur.  DSKPP exchanges
  information using XML.  All XML processors are required to understand
  UTF-8 and UTF-16 encoding, and therefore all DSKPP clients and
  servers MUST understand UTF-8 and UTF-16 encoded XML.

This deserves a normative reference to UTF-16.
You can probably use RFC 2781 (Note: it is Informational, so this would be a DOWNREF)

7)
12.4.  Status Code Registry

  Registration/Assignment Procedures:
      Following the policies outlined in [RFC3575], the IANA policy for
      assigning new values for the status codes for DSKPP MUST be
      "Specification Required" and their meanings MUST be documented in
      an RFC or in some other permanent and readily available reference,
      in sufficient detail that interoperability between independent
      implementations is possible.  No mechanism to mark entries as
      "deprecated" is envisioned.  It is possible to delete or update
      entries from the registry.

No, deletion of entries from the registry shouldn't be allowed. Otherwise there is a risk of redefining an earlier value in an incompatible way, which will lead to interoperability problems. This is one of the main reasons for having the registry.

8)
12.3.  MIME Media Type Registration

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

I believe the last sentence is in violation of MIME, which requires US-ASCII to be the default charset value.
This is also in violation of HTTP, which requires ISO-8859-1.

So I suggest removing the last quoted sentence.

9)
  [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
              .

This reference should be Normative, as the document is defining a normative mapping to HTTP.

  [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008,
              .

This reference looks Normative, due to a requirement to perform server identity verification.

10)
3.4.1.1.  Authentication Code Format

  The following table summarizes the TLVs defined in this document.
  Optional TLVs are allowed for vendor-specific extensions with the
  constraint that the high bit MUST be set to indicate a vendor-
  specific type.  Other TLVs are left for later revisions of this
  protocol.

I think this needs an IANA registry, considering that the value space is only 1 byte.

11)
3.3.  Status Codes

  UnknownCriticalExtension:  A critical DSKPP extension (see below)
      used by the DSKPP client was not supported or recognized by the
      DSKPP server

Extension criticality is not discussed in the document (except for having
"Critical" attribute in the XML Schema).

12)
D.1.  Introduction

  This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES]
  and HMAC [RFC2104].  This appendix forms an informative part of the
  document.

Actually I disagree. I think this Appendix is Normative, considering that the two DSKPP-PRF functions are mandatory-to-implement.

D.2.  DSKPP-PRF-AES

D.2.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

Why MAY and not a MUST?

  http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128


D.3.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

As above: why MAY?

13)
5.1.2.  Key Wrap

  The DSKPP server and client MUST support one of the following key
  wrapping mechanisms:

If only one of the following is mandatory-to-implement, how can you achieve interoperability?

14)
5.2.2.  KeyProvClientHello

      If user authentication passes, the DSKPP server generates a key
      K_PROV, which MUST consist of two parts of equal length, where the
      first half constitutes K_MAC and the second half constitutes
      K_TOKEN, i.e.,

K_PROV is defined in 4.1.2 as:

  K_PROV = DSKPP-PRF(k,s,dsLen), where

      k = R_C (i.e., the secret random value chosen by the DSKPP
      client)

      s = "Key generation" || K || R_S (where K is the key used to
      encrypt R_C and R_S is the random value chosen by the DSKPP
      server)

In the 2-pass mode the client doesn't have access to R_S, so is it omitted from "s" in this case? Please clarify the text if that is the case.

15) In Section 5.2.2:

  The method the DSKPP server MUST use to calculate the server
  authentication MAC:
      The MAC MUST be computed on the (ASCII) string "MAC 2
      computation", the server identifier ServerID, and R, using a pre-
      existing MAC key K_MAC' (the MAC key that existed before this
      protocol run).  Note that the implementation may specify K_MAC' to
      be the value of the K_TOKEN that is being replaced, or a version
      of K_MAC from the previous protocol run.

The last sentence: why provide the choice and how can the other end know which K_MAC' was used for calculations?

Similar text in Section 4.2.3:

      This MAC MUST be computed using DSKPP-PRF (see
      Section 3.4.2), where the input parameter k MUST be set to the
      existing MAC key K_MAC' (i.e., the value of the MAC key that
      existed before this protocol run; the implementation MAY specify
      K_MAC' to be the value of the K_TOKEN that is being replaced, or a
      version of K_MAC from the previous protocol run), and input
      parameter dsLen MUST be set to the length of R_S.

16)
5.2.3.  KeyProvServerFinished

          DSKPP Client                        DSKPP Server
          ------------                        ------------
                                  <---          KP, MAC, AD

[...]

      Finally, this message MUST include a MAC that the DSKPP client
      will use for key confirmation.  In addition, this message MUST
      also include a server authentication MAC (AD) if an existing key
      is being replaced.  These MACs are calculated as described in the
      previous section.

So I assume that "MAC" in the  message is the MAC
from Section 5.2.2 calculated using the "MAC 1 computation" constant.
Where is the the server authentication MAC (calculated using the "MAC 2 computation" constant) is included in the  message?

17)
In Section 10.3:

  Whenever the above is a concern, DSKPP SHOULD be run over a transport
  providing confidentiality.  If man-in-the-middle attacks for the
  purposes described above are a concern, the transport SHOULD also
  offer server-side authentication.

The last sentence: why only a SHOULD?

18)
5.1.  Key Protection Methods

  This section introduces three key protection methods for the two-pass
  variant.  Additional methods MAY be defined by external entities or
  through the IETF process.

Is a new IANA registry needed for these?

19)
8.1.  General Processing Requirements

  Implementations that compare values that are represented using
  different character encodings MUST use a comparison method that
  returns the same result as converting both values to the Unicode
  character encoding, Normalization Form C [UNICODE], and then

I am not sure why Normalization Form C is only required when different Unicode encodings are used? I think you either need to always require it, or never require it.

  performing an exact binary comparison.

20)
3.4.1.1.  Authentication Code Format

    The Password is a mandatory TLV the contains a one-time use shared
    secret known by the user and the Provisioning Server.  The password
    value is unique and SHOULD be a random string to make AC more
    difficult to guess.  The string MUST be UTF-8 encoded in accordance
    with [RFC3629].  For example, suppose password is set to "3582", then
    the TLV would be {0x2, 0x4, UTF-8("3582")}.

If the password is intended to be entered by a human in some sort of UI, then this is missing some text about disallowed Unicode characters and Unicode normalization to be used (e.g. Net-Unicode).

[Ballot comment]
TLS should be an Informative reference, as it is mentioned in several places in the Security Considerations section.


3.2.2.  Protocol Initiated by the DSKPP Client

  o  The DSKPP client needs the URL of the DSKPP server (which is not

Informative reference to URI spec is needed here (RFC 3986)


4.2.1.  KeyProvTrigger

      6.  The web application passes AD, and possibly a DeviceID
          (identifies a particular device to which the key MUST be

I don't think this use of MUST is correct, as it doesn't describe a requirement on a compliant implementation. I suggest changing this to something like "to which the key is to be provisioned)"

          provisioned) and/or KeyID (identifies a key that will be
          replaced) to the DSKPP server

4.2.4.  KeyProvClientNonce

      The particular
      realization of DSKPP-PRF (e.g., those defined in Appendix D

I think there is a missing ")" at the end of this line.

      depends on the MAC algorithm contained in the
      message.



  [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998, .

This document was obsoleted, please reference RFC 3986.

  [UNICODE]  Davis, M. and M. Duerst, "Unicode Normalization Forms",
              March 2001,
              .

This reference is very old. You should reference something like  (dated 2009-09-03) instead.

[Ballot discuss]
[Updated. DISCUSS issues starting from # 17 are new. Comment section is unchanged.]

While I think this is an important document I generally feel disappointed about the number of minor bugs and clarity issues in the document. Please work with me to address them and/or to clarify my confusions:

1)
3.2.3.  Protocol Triggered by the DSKPP Server

  The  message is sent in a HTTP response, and it is
  marked with MIME type "application/vnd.ietf.keyprov.dskpp+xml".  It

I think you meant application/dskpp+xml here.

Similarly:

7.2.1.  Identification of DSKPP Messages

  The MIME-type for all DSKPP messages MUST be

  application/vnd.ietf.keyprov.dskpp+xml

I think you meant application/dskpp+xml here.
(The same issue in examples in Section 7.2.7)

2)
3.3.  Status Codes

  NoProtocolVariants:  The DSKPP client only suggested a protocol
      variant (either 2-pass or 4-pass) that is not supported by the
      DSKPP server.  This error is only valid in the DSKPP server's
      first response message

According to Section 9, both variants are MUST implement for the server,
so this status code can never be returned.

3)
3.4.1.1.  Authentication Code Format

  Length (1 byte)          The length, in hexadecimal, of the value
                            field to follow.

1 byte length in hexadecimal? Do you mean the length is restricted to 15 bytes (one hexadecimal character)?
Or do you mean that the draft displays such values in hexadecimal, i.e. that that is only a display convention?

  Value (variable length)  A variable-length hexadecimal value
                            containing the instance-specific
                            information for this TLV.

As above.

  The Client ID is a mandatory TLV that represents the requester's
  identifier of maximum length 128.  The value is represented as an
  ASCII string that identifies the key request.  The ClientID MUST be
  HEX encoded.  For example, suppose ClientID is set to "AC00000A", the
  hexadecimal equivalent is 0x4143303030303041, resulting in a TLV of
  {0x1, 0x8, 0x4143303030303041}.

I am still confused about use of HEX here.

4)
3.4.1.1.  Authentication Code Format

  The Checksum is an OPTIONAL TLV, which is generated by the issuing
  server and sent to the user as part of the AC.  If the TLV is
  provided, the checksum value MUST be computed using the CRC16
  algorithm [ISO3309].

This reference must be Normative.

5)
4.2.5.  KeyProvServerFinished

      If status is Continue, then this message acts as a "commit"

Shouldn't this be Success, as this the final message from the server?

      When the Status attribute is not set to "Continue", this indicates
      failure and the DSKPP client MUST abort the protocol.

      After receiving a  message with Status =
      "Success", the DSKPP client MUST verify the key confirmation MAC

So, is it supposed to be "Continue" or "Success"?

5.2.2.  KeyProvClientHello

  How the DSKPP server uses this message:
      The DSKPP server will look for an acceptable combination of DSKPP
      version, variant (in this case, two-pass), key package format, key
      type, and cryptographic algorithms.  If the DSKPP Client's SAL
      does not match the capabilities of the DSKPP Server, or does not
      comply with key provisioning policy, then the DSKPP Server will
      set the Status attribute to something other than "Continue".
      Otherwise, Status will be set to "Continue".

"Continue" and not "Success"?

5.2.3.  KeyProvServerFinished

  What is contained in this message:
      A status attribute equivalent to the server's return code to
      .  If the server found an acceptable set of
      attributes from the client's SAL, then it sets status to Continue.

"Continue" and not "Success"?

6)
11.  Internationalization Considerations

  The DSKPP protocol is mostly meant for machine-to-machine
  communications; as such, most of its elements are tokens not meant
  for direct human consumption.  If these tokens are presented to the
  end user, some localization may need to occur.  DSKPP exchanges
  information using XML.  All XML processors are required to understand
  UTF-8 and UTF-16 encoding, and therefore all DSKPP clients and
  servers MUST understand UTF-8 and UTF-16 encoded XML.

This deserves a normative reference to UTF-16.
You can probably use RFC 2781 (Note: it is Informational, so this would be a DOWNREF)

7)
12.4.  Status Code Registry

  Registration/Assignment Procedures:
      Following the policies outlined in [RFC3575], the IANA policy for
      assigning new values for the status codes for DSKPP MUST be
      "Specification Required" and their meanings MUST be documented in
      an RFC or in some other permanent and readily available reference,
      in sufficient detail that interoperability between independent
      implementations is possible.  No mechanism to mark entries as
      "deprecated" is envisioned.  It is possible to delete or update
      entries from the registry.

No, deletion of entries from the registry shouldn't be allowed. Otherwise there is a risk of redefining an earlier value in an incompatible way, which will lead to interoperability problems. This is one of the main reasons for having the registry.

8)
12.3.  MIME Media Type Registration

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

I believe the last sentence is in violation of MIME, which requires US-ASCII to be the default charset value.
This is also in violation of HTTP, which requires ISO-8859-1.

So I suggest removing the last quoted sentence.

9)
  [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
              .

This reference should be Normative, as the document is defining a normative mapping to HTTP.

  [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008,
              .

This reference looks Normative, due to a requirement to perform server identity verification.

10)
3.4.1.1.  Authentication Code Format

  The following table summarizes the TLVs defined in this document.
  Optional TLVs are allowed for vendor-specific extensions with the
  constraint that the high bit MUST be set to indicate a vendor-
  specific type.  Other TLVs are left for later revisions of this
  protocol.

I think this needs an IANA registry, considering that the value space is only 1 byte.

11)
3.3.  Status Codes

  UnknownCriticalExtension:  A critical DSKPP extension (see below)
      used by the DSKPP client was not supported or recognized by the
      DSKPP server

Extension criticality is not discussed in the document (except for having
"Critical" attribute in the XML Schema).

12)
D.1.  Introduction

  This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES]
  and HMAC [RFC2104].  This appendix forms an informative part of the
  document.

Actually I disagree. I think this Appendix is Normative, considering that the two DSKPP-PRF functions are mandatory-to-implement.

D.2.  DSKPP-PRF-AES

D.2.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

Why MAY and not a MUST?

  http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128


D.3.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

As above: why MAY?

13)
5.1.2.  Key Wrap

  The DSKPP server and client MUST support one of the following key
  wrapping mechanisms:

If only one of the following is mandatory-to-implement, how can you achieve interoperability?

14)
5.2.2.  KeyProvClientHello

      If user authentication passes, the DSKPP server generates a key
      K_PROV, which MUST consist of two parts of equal length, where the
      first half constitutes K_MAC and the second half constitutes
      K_TOKEN, i.e.,

K_PROV is defined in 4.1.2 as:

  K_PROV = DSKPP-PRF(k,s,dsLen), where

      k = R_C (i.e., the secret random value chosen by the DSKPP
      client)

      s = "Key generation" || K || R_S (where K is the key used to
      encrypt R_C and R_S is the random value chosen by the DSKPP
      server)

In the 2-pass mode the client doesn't have access to R_S, so is it omitted from "s" in this case? Please clarify the text if that is the case.

15) In Section 5.2.2:

  The method the DSKPP server MUST use to calculate the server
  authentication MAC:
      The MAC MUST be computed on the (ASCII) string "MAC 2
      computation", the server identifier ServerID, and R, using a pre-
      existing MAC key K_MAC' (the MAC key that existed before this
      protocol run).  Note that the implementation may specify K_MAC' to
      be the value of the K_TOKEN that is being replaced, or a version
      of K_MAC from the previous protocol run.

The last sentence: why provide the choice and how can the other end know which K_MAC' was used for calculations?

Similar text in Section 4.2.3:

      This MAC MUST be computed using DSKPP-PRF (see
      Section 3.4.2), where the input parameter k MUST be set to the
      existing MAC key K_MAC' (i.e., the value of the MAC key that
      existed before this protocol run; the implementation MAY specify
      K_MAC' to be the value of the K_TOKEN that is being replaced, or a
      version of K_MAC from the previous protocol run), and input
      parameter dsLen MUST be set to the length of R_S.

16)
5.2.3.  KeyProvServerFinished

          DSKPP Client                        DSKPP Server
          ------------                        ------------
                                  <---          KP, MAC, AD

[...]

      Finally, this message MUST include a MAC that the DSKPP client
      will use for key confirmation.  In addition, this message MUST
      also include a server authentication MAC (AD) if an existing key
      is being replaced.  These MACs are calculated as described in the
      previous section.

So I assume that "MAC" in the  message is the MAC
from Section 5.2.2 calculated using the "MAC 1 computation" constant.
Where is the the server authentication MAC (calculated using the "MAC 2 computation" constant) is included in the  message?

17)
In Section 10.3:

  Whenever the above is a concern, DSKPP SHOULD be run over a transport
  providing confidentiality.  If man-in-the-middle attacks for the
  purposes described above are a concern, the transport SHOULD also
  offer server-side authentication.

The last sentence: why only a SHOULD?

18)
5.1.  Key Protection Methods

  This section introduces three key protection methods for the two-pass
  variant.  Additional methods MAY be defined by external entities or
  through the IETF process.

Is a new IANA registry needed for these?

19)
8.1.  General Processing Requirements

  Implementations that compare values that are represented using
  different character encodings MUST use a comparison method that
  returns the same result as converting both values to the Unicode
  character encoding, Normalization Form C [UNICODE], and then

I am not sure why Normalization Form C is only required when different Unicode encodings are used? I think you either need to always require it, or never require it.

  performing an exact binary comparison.

20)
3.4.1.1.  Authentication Code Format

    The Password is a mandatory TLV the contains a one-time use shared
    secret known by the user and the Provisioning Server.  The password
    value is unique and SHOULD be a random string to make AC more
    difficult to guess.  The string MUST be UTF-8 encoded in accordance
    with [RFC3629].  For example, suppose password is set to "3582", then
    the TLV would be {0x2, 0x4, UTF-8("3582")}.

If the password is intended to be entered by a human in some sort of UI, then this is missing some text about disallowed Unicode characters and Unicode normalization to be used (e.g. Net-Unicode).

[Ballot discuss]
The authors gave been engaged in a discussion about the concerns
  raised by Brian Carpenter in his Gen-ART Review.  A revised I-D is
  needed to resolve the concerns that have been under discussion.

  The Gen-ART review can be found at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg05287.html

  I am especially concerns with the concern raised about Section 3.4.3.
  The DSKPP Message Hash Algorithm is rigidly bound to SHA-256, and
  algorithm agility is needed.

[Ballot comment]
TLS should be an Informative reference, as it is mentioned in several places in the Security Considerations section.


3.2.2.  Protocol Initiated by the DSKPP Client

  o  The DSKPP client needs the URL of the DSKPP server (which is not

Informative reference to URI spec is needed here (RFC 3986)


4.2.1.  KeyProvTrigger

      6.  The web application passes AD, and possibly a DeviceID
          (identifies a particular device to which the key MUST be

I don't think this use of MUST is correct, as it doesn't describe a requirement on a compliant implementation. I suggest changing this to something like "to which the key is to be provisioned)"

          provisioned) and/or KeyID (identifies a key that will be
          replaced) to the DSKPP server

4.2.4.  KeyProvClientNonce

      The particular
      realization of DSKPP-PRF (e.g., those defined in Appendix D

I think there is a missing ")" at the end of this line.

      depends on the MAC algorithm contained in the
      message.



  [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998, .

This document was obsoleted, please reference RFC 3986.

  [UNICODE]  Davis, M. and M. Duerst, "Unicode Normalization Forms",
              March 2001,
              .

This reference is very old. You should reference something like  (dated 2009-09-03) instead.

[Ballot discuss]
While I think this is an important document I generally feel disappointed about the number of minor bugs and clarity issues in the document. Please work with me to address them and/or to clarify my confusions:

1)
3.2.3.  Protocol Triggered by the DSKPP Server

  The  message is sent in a HTTP response, and it is
  marked with MIME type "application/vnd.ietf.keyprov.dskpp+xml".  It

I think you meant application/dskpp+xml here.

Similarly:

7.2.1.  Identification of DSKPP Messages

  The MIME-type for all DSKPP messages MUST be

  application/vnd.ietf.keyprov.dskpp+xml

I think you meant application/dskpp+xml here.
(The same issue in examples in Section 7.2.7)

2)
3.3.  Status Codes

  NoProtocolVariants:  The DSKPP client only suggested a protocol
      variant (either 2-pass or 4-pass) that is not supported by the
      DSKPP server.  This error is only valid in the DSKPP server's
      first response message

According to Section 9, both variants are MUST implement for the server,
so this status code can never be returned.

3)
3.4.1.1.  Authentication Code Format

  Length (1 byte)          The length, in hexadecimal, of the value
                            field to follow.

1 byte length in hexadecimal? Do you mean the length is restricted to 15 bytes (one hexadecimal character)?
Or do you mean that the draft displays such values in hexadecimal, i.e. that that is only a display convention?

  Value (variable length)  A variable-length hexadecimal value
                            containing the instance-specific
                            information for this TLV.

As above.

  The Client ID is a mandatory TLV that represents the requester's
  identifier of maximum length 128.  The value is represented as an
  ASCII string that identifies the key request.  The ClientID MUST be
  HEX encoded.  For example, suppose ClientID is set to "AC00000A", the
  hexadecimal equivalent is 0x4143303030303041, resulting in a TLV of
  {0x1, 0x8, 0x4143303030303041}.

I am still confused about use of HEX here.

4)
3.4.1.1.  Authentication Code Format

  The Checksum is an OPTIONAL TLV, which is generated by the issuing
  server and sent to the user as part of the AC.  If the TLV is
  provided, the checksum value MUST be computed using the CRC16
  algorithm [ISO3309].

This reference must be Normative.

5)
4.2.5.  KeyProvServerFinished

      If status is Continue, then this message acts as a "commit"

Shouldn't this be Success, as this the final message from the server?

      When the Status attribute is not set to "Continue", this indicates
      failure and the DSKPP client MUST abort the protocol.

      After receiving a  message with Status =
      "Success", the DSKPP client MUST verify the key confirmation MAC

So, is it supposed to be "Continue" or "Success"?

5.2.2.  KeyProvClientHello

  How the DSKPP server uses this message:
      The DSKPP server will look for an acceptable combination of DSKPP
      version, variant (in this case, two-pass), key package format, key
      type, and cryptographic algorithms.  If the DSKPP Client's SAL
      does not match the capabilities of the DSKPP Server, or does not
      comply with key provisioning policy, then the DSKPP Server will
      set the Status attribute to something other than "Continue".
      Otherwise, Status will be set to "Continue".

"Continue" and not "Success"?

5.2.3.  KeyProvServerFinished

  What is contained in this message:
      A status attribute equivalent to the server's return code to
      .  If the server found an acceptable set of
      attributes from the client's SAL, then it sets status to Continue.

"Continue" and not "Success"?

6)
11.  Internationalization Considerations

  The DSKPP protocol is mostly meant for machine-to-machine
  communications; as such, most of its elements are tokens not meant
  for direct human consumption.  If these tokens are presented to the
  end user, some localization may need to occur.  DSKPP exchanges
  information using XML.  All XML processors are required to understand
  UTF-8 and UTF-16 encoding, and therefore all DSKPP clients and
  servers MUST understand UTF-8 and UTF-16 encoded XML.

This deserves a normative reference to UTF-16.
You can probably use RFC 2781 (Note: it is Informational, so this would be a DOWNREF)

7)
12.4.  Status Code Registry

  Registration/Assignment Procedures:
      Following the policies outlined in [RFC3575], the IANA policy for
      assigning new values for the status codes for DSKPP MUST be
      "Specification Required" and their meanings MUST be documented in
      an RFC or in some other permanent and readily available reference,
      in sufficient detail that interoperability between independent
      implementations is possible.  No mechanism to mark entries as
      "deprecated" is envisioned.  It is possible to delete or update
      entries from the registry.

No, deletion of entries from the registry shouldn't be allowed. Otherwise there is a risk of redefining an earlier value in an incompatible way, which will lead to interoperability problems. This is one of the main reasons for having the registry.

8)
12.3.  MIME Media Type Registration

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

I believe the last sentence is in violation of MIME, which requires US-ASCII to be the default charset value.
This is also in violation of HTTP, which requires ISO-8859-1.

So I suggest removing the last quoted sentence.

9)
  [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
              .

This reference should be Normative, as the document is defining a normative mapping to HTTP.

  [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008,
              .

This reference looks Normative, due to a requirement to perform server identity verification.

10)
3.4.1.1.  Authentication Code Format

  The following table summarizes the TLVs defined in this document.
  Optional TLVs are allowed for vendor-specific extensions with the
  constraint that the high bit MUST be set to indicate a vendor-
  specific type.  Other TLVs are left for later revisions of this
  protocol.

I think this needs an IANA registry, considering that the value space is only 1 byte.

11)
3.3.  Status Codes

  UnknownCriticalExtension:  A critical DSKPP extension (see below)
      used by the DSKPP client was not supported or recognized by the
      DSKPP server

Extension criticality is not discussed in the document (except for having
"Critical" attribute in the XML Schema).

12)
D.1.  Introduction

  This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES]
  and HMAC [RFC2104].  This appendix forms an informative part of the
  document.

Actually I disagree. I think this Appendix is Normative, considering that the two DSKPP-PRF functions are mandatory-to-implement.

D.2.  DSKPP-PRF-AES

D.2.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

Why MAY and not a MUST?

  http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128


D.3.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

As above: why MAY?

13)
5.1.2.  Key Wrap

  The DSKPP server and client MUST support one of the following key
  wrapping mechanisms:

If only one of the following is mandatory-to-implement, how can you achieve interoperability?

14)
5.2.2.  KeyProvClientHello

      If user authentication passes, the DSKPP server generates a key
      K_PROV, which MUST consist of two parts of equal length, where the
      first half constitutes K_MAC and the second half constitutes
      K_TOKEN, i.e.,

K_PROV is defined in 4.1.2 as:

  K_PROV = DSKPP-PRF(k,s,dsLen), where

      k = R_C (i.e., the secret random value chosen by the DSKPP
      client)

      s = "Key generation" || K || R_S (where K is the key used to
      encrypt R_C and R_S is the random value chosen by the DSKPP
      server)

In the 2-pass mode the client doesn't have access to R_S, so is it omitted from "s" in this case? Please clarify the text if that is the case.

15) In Section 5.2.2:

  The method the DSKPP server MUST use to calculate the server
  authentication MAC:
      The MAC MUST be computed on the (ASCII) string "MAC 2
      computation", the server identifier ServerID, and R, using a pre-
      existing MAC key K_MAC' (the MAC key that existed before this
      protocol run).  Note that the implementation may specify K_MAC' to
      be the value of the K_TOKEN that is being replaced, or a version
      of K_MAC from the previous protocol run.

The last sentence: why provide the choice and how can the other end know which K_MAC' was used for calculations?

Similar text in Section 4.2.3:

      This MAC MUST be computed using DSKPP-PRF (see
      Section 3.4.2), where the input parameter k MUST be set to the
      existing MAC key K_MAC' (i.e., the value of the MAC key that
      existed before this protocol run; the implementation MAY specify
      K_MAC' to be the value of the K_TOKEN that is being replaced, or a
      version of K_MAC from the previous protocol run), and input
      parameter dsLen MUST be set to the length of R_S.

16)
5.2.3.  KeyProvServerFinished

          DSKPP Client                        DSKPP Server
          ------------                        ------------
                                  <---          KP, MAC, AD

[...]

      Finally, this message MUST include a MAC that the DSKPP client
      will use for key confirmation.  In addition, this message MUST
      also include a server authentication MAC (AD) if an existing key
      is being replaced.  These MACs are calculated as described in the
      previous section.

So I assume that "MAC" in the  message is the MAC
from Section 5.2.2 calculated using the "MAC 1 computation" constant.
Where is the the server authentication MAC (calculated using the "MAC 2 computation" constant) is included in the  message?

[Ballot comment]
TLS should be an Informative reference, as it is mentioned in several places in the Security Considerations section.


3.2.2.  Protocol Initiated by the DSKPP Client

  o  The DSKPP client needs the URL of the DSKPP server (which is not

Informative reference to URI spec is needed here (RFC 3986)


4.2.1.  KeyProvTrigger

      6.  The web application passes AD, and possibly a DeviceID
          (identifies a particular device to which the key MUST be

I don't think this use of MUST is correct, as it doesn't describe a requirement on a compliant implementation. I suggest changing this to something like "to which the key is to be provisioned)"

          provisioned) and/or KeyID (identifies a key that will be
          replaced) to the DSKPP server

4.2.4.  KeyProvClientNonce

      The particular
      realization of DSKPP-PRF (e.g., those defined in Appendix D

I think there is a missing ")" at the end of this line.

      depends on the MAC algorithm contained in the
      message.



  [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998, .

This document was obsoleted, please reference RFC 3986.

  [UNICODE]  Davis, M. and M. Duerst, "Unicode Normalization Forms",
              March 2001,
              .

This reference is very old. You should reference something like  (dated 2009-09-03) instead.

[Ballot discuss]
While I think this is an important document I generally feel disappointed about the number of minor bugs and clarity issues in the document. Please work with me to address them and/or to clarify my confusions:

1)
3.2.3.  Protocol Triggered by the DSKPP Server

  The  message is sent in a HTTP response, and it is
  marked with MIME type "application/vnd.ietf.keyprov.dskpp+xml".  It

I think you meant application/dskpp+xml here.

Similarly:

7.2.1.  Identification of DSKPP Messages

  The MIME-type for all DSKPP messages MUST be

  application/vnd.ietf.keyprov.dskpp+xml

I think you meant application/dskpp+xml here.
(The same issue in examples in Section 7.2.7)

2)
3.3.  Status Codes

  NoProtocolVariants:  The DSKPP client only suggested a protocol
      variant (either 2-pass or 4-pass) that is not supported by the
      DSKPP server.  This error is only valid in the DSKPP server's
      first response message

According to Section 9, both variants are MUST implement for the server,
so this status code can never be returned.

3)
3.4.1.1.  Authentication Code Format

  Length (1 byte)          The length, in hexadecimal, of the value
                            field to follow.

1 byte length in hexadecimal? Do you mean the length is restricted to 15 bytes (one hexadecimal character)?
Or do you mean that the draft displays such values in hexadecimal, i.e. that that is only a display convention?

  Value (variable length)  A variable-length hexadecimal value
                            containing the instance-specific
                            information for this TLV.

As above.

  The Client ID is a mandatory TLV that represents the requester's
  identifier of maximum length 128.  The value is represented as an
  ASCII string that identifies the key request.  The ClientID MUST be
  HEX encoded.  For example, suppose ClientID is set to "AC00000A", the
  hexadecimal equivalent is 0x4143303030303041, resulting in a TLV of
  {0x1, 0x8, 0x4143303030303041}.

I am still confused about use of HEX here.

4)
3.4.1.1.  Authentication Code Format

  The Checksum is an OPTIONAL TLV, which is generated by the issuing
  server and sent to the user as part of the AC.  If the TLV is
  provided, the checksum value MUST be computed using the CRC16
  algorithm [ISO3309].

This reference must be Normative.

5)
4.2.5.  KeyProvServerFinished

      If status is Continue, then this message acts as a "commit"

Shouldn't this be Success, as this the final message from the server?

      When the Status attribute is not set to "Continue", this indicates
      failure and the DSKPP client MUST abort the protocol.

      After receiving a  message with Status =
      "Success", the DSKPP client MUST verify the key confirmation MAC

So, is it supposed to be "Continue" or "Success"?

5.2.2.  KeyProvClientHello

  How the DSKPP server uses this message:
      The DSKPP server will look for an acceptable combination of DSKPP
      version, variant (in this case, two-pass), key package format, key
      type, and cryptographic algorithms.  If the DSKPP Client's SAL
      does not match the capabilities of the DSKPP Server, or does not
      comply with key provisioning policy, then the DSKPP Server will
      set the Status attribute to something other than "Continue".
      Otherwise, Status will be set to "Continue".

"Continue" and not "Success"?

5.2.3.  KeyProvServerFinished

  What is contained in this message:
      A status attribute equivalent to the server's return code to
      .  If the server found an acceptable set of
      attributes from the client's SAL, then it sets status to Continue.

"Continue" and not "Success"?

6)
11.  Internationalization Considerations

  The DSKPP protocol is mostly meant for machine-to-machine
  communications; as such, most of its elements are tokens not meant
  for direct human consumption.  If these tokens are presented to the
  end user, some localization may need to occur.  DSKPP exchanges
  information using XML.  All XML processors are required to understand
  UTF-8 and UTF-16 encoding, and therefore all DSKPP clients and
  servers MUST understand UTF-8 and UTF-16 encoded XML.

This deserves a normative reference to UTF-16.
You can probably use RFC 2781 (Note: it is Informational, so this would be a DOWNREF)

7)
12.4.  Status Code Registry

  Registration/Assignment Procedures:
      Following the policies outlined in [RFC3575], the IANA policy for
      assigning new values for the status codes for DSKPP MUST be
      "Specification Required" and their meanings MUST be documented in
      an RFC or in some other permanent and readily available reference,
      in sufficient detail that interoperability between independent
      implementations is possible.  No mechanism to mark entries as
      "deprecated" is envisioned.  It is possible to delete or update
      entries from the registry.

No, deletion of entries from the registry shouldn't be allowed. This is one of the main reasons for having the registry.

8)
12.3.  MIME Media Type Registration

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

I believe the last sentence is in violation of MIME, which requires US-ASCII to be the default charset.
This is also in violation of HTTP, which requires ISO-8859-1.

So I suggest removing the last quoted sentence.

9)
  [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
              .

This reference should be Normative.

  [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008,
              .

This reference looks Normative.

10)
3.4.1.1.  Authentication Code Format

  The following table summarizes the TLVs defined in this document.
  Optional TLVs are allowed for vendor-specific extensions with the
  constraint that the high bit MUST be set to indicate a vendor-
  specific type.  Other TLVs are left for later revisions of this
  protocol.

I think this needs an IANA registry, considering that the value space is only 1 byte.

11)
3.3.  Status Codes

  UnknownCriticalExtension:  A critical DSKPP extension (see below)
      used by the DSKPP client was not supported or recognized by the
      DSKPP server

Extension criticality is not discussed in the document (except for having
"Critical" attribute in the XML Schema).

12)
D.1.  Introduction

  This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES]
  and HMAC [RFC2104].  This appendix forms an informative part of the
  document.

Actually I disagree. I think this Appendix is Normative, considering that the two DSKPP-PRF functions are mandatory-to-implement.

D.2.  DSKPP-PRF-AES

D.2.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

Why MAY and not a MUST?

  http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128


D.3.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

As above: why MAY?

13)
5.1.2.  Key Wrap

  The DSKPP server and client MUST support one of the following key
  wrapping mechanisms:

If only one of the following is mandatory-to-implement, how can you achieve interoperability?

14)
5.2.2.  KeyProvClientHello

      If user authentication passes, the DSKPP server generates a key
      K_PROV, which MUST consist of two parts of equal length, where the
      first half constitutes K_MAC and the second half constitutes
      K_TOKEN, i.e.,

K_PROV is defined in 4.1.2 as:

  K_PROV = DSKPP-PRF(k,s,dsLen), where

      k = R_C (i.e., the secret random value chosen by the DSKPP
      client)

      s = "Key generation" || K || R_S (where K is the key used to
      encrypt R_C and R_S is the random value chosen by the DSKPP
      server)

The client doesn't have access to R_S, so is it omitted from "s" in this case? Please clarify the text if that is the case.

15) In Section 5.2.2:

  The method the DSKPP server MUST use to calculate the server
  authentication MAC:
      The MAC MUST be computed on the (ASCII) string "MAC 2
      computation", the server identifier ServerID, and R, using a pre-
      existing MAC key K_MAC' (the MAC key that existed before this
      protocol run).  Note that the implementation may specify K_MAC' to
      be the value of the K_TOKEN that is being replaced, or a version
      of K_MAC from the previous protocol run.

The last sentence: why provide the choice and how can the other end know which K_MAC' was used for calculations?

Similar text in Section 4.2.3:

      This MAC MUST be computed using DSKPP-PRF (see
      Section 3.4.2), where the input parameter k MUST be set to the
      existing MAC key K_MAC' (i.e., the value of the MAC key that
      existed before this protocol run; the implementation MAY specify
      K_MAC' to be the value of the K_TOKEN that is being replaced, or a
      version of K_MAC from the previous protocol run), and input
      parameter dsLen MUST be set to the length of R_S.

16)
5.2.3.  KeyProvServerFinished

          DSKPP Client                        DSKPP Server
          ------------                        ------------
                                  <---          KP, MAC, AD

[...]

      Finally, this message MUST include a MAC that the DSKPP client
      will use for key confirmation.  In addition, this message MUST
      also include a server authentication MAC (AD) if an existing key
      is being replaced.  These MACs are calculated as described in the
      previous section.

So I assume that "MAC" in the  message is the MAC
from Section 5.2.2 calculated using the "MAC 1 computation" constant.
Where is the the server authentication MAC (calculated using the "MAC 2 computation" constant) is included in the  message?

[Ballot comment]
3.2.2.  Protocol Initiated by the DSKPP Client

  o  The DSKPP client needs the URL of the DSKPP server (which is not

Informative reference to URI spec is needed here (RFC 3986)


4.2.1.  KeyProvTrigger

      6.  The web application passes AD, and possibly a DeviceID
          (identifies a particular device to which the key MUST be

I don't think this use of MUST is correct, as it doesn't describe a requirement on a compliant implementation. I suggest changing this to something like "to which the key is to be provisioned)"

          provisioned) and/or KeyID (identifies a key that will be
          replaced) to the DSKPP server

4.2.4.  KeyProvClientNonce

      The particular
      realization of DSKPP-PRF (e.g., those defined in Appendix D

I think there is a missing ")" at the end of this line.

      depends on the MAC algorithm contained in the
      message.



  [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998, .

This document was obsoleted, please reference RFC 3986.

  [UNICODE]  Davis, M. and M. Duerst, "Unicode Normalization Forms",
              March 2001,
              .

This reference is very old. You should reference something like  (dated 2009-09-03) instead.

[Ballot discuss]
I would like to discuss the following issues before recommending approval of this document:

1)
3.2.3.  Protocol Triggered by the DSKPP Server

  The  message is sent in a HTTP response, and it is
  marked with MIME type "application/vnd.ietf.keyprov.dskpp+xml".  It

I think you meant application/dskpp+xml here.

Similarly:

7.2.1.  Identification of DSKPP Messages

  The MIME-type for all DSKPP messages MUST be

  application/vnd.ietf.keyprov.dskpp+xml

I think you meant application/dskpp+xml here.
(The same issue in examples in Section 7.2.7)


2)
3.3.  Status Codes

  NoProtocolVariants:  The DSKPP client only suggested a protocol
      variant (either 2-pass or 4-pass) that is not supported by the
      DSKPP server.  This error is only valid in the DSKPP server's
      first response message

According to Section 9, both variants are MUST implement for the server,
so this status code can never be returned.

3)
3.4.1.1.  Authentication Code Format

  Length (1 byte)          The length, in hexadecimal, of the value
                            field to follow.

1 byte length in hexadecimal? Do you mean the length is restricted to 15 bytes (one hexadecimal character)?
Or do you mean that the draft displays such values in hexadecimal, i.e. that that is only a display convention?

  Value (variable length)  A variable-length hexadecimal value
                            containing the instance-specific
                            information for this TLV.

As above.

  The Client ID is a mandatory TLV that represents the requester's
  identifier of maximum length 128.  The value is represented as an
  ASCII string that identifies the key request.  The ClientID MUST be
  HEX encoded.  For example, suppose ClientID is set to "AC00000A", the
  hexadecimal equivalent is 0x4143303030303041, resulting in a TLV of
  {0x1, 0x8, 0x4143303030303041}.

I am still confused about use of HEX here.

4)
3.4.1.1.  Authentication Code Format

  The Checksum is an OPTIONAL TLV, which is generated by the issuing
  server and sent to the user as part of the AC.  If the TLV is
  provided, the checksum value MUST be computed using the CRC16
  algorithm [ISO3309].

This reference must be Normative.

5)
4.2.5.  KeyProvServerFinished

      If status is Continue, then this message acts as a "commit"

Shouldn't this be Success?

      When the Status attribute is not set to "Continue", this indicates
      failure and the DSKPP client MUST abort the protocol.

      After receiving a  message with Status =
      "Success", the DSKPP client MUST verify the key confirmation MAC

So, is it supposed to be "Continue" or "Success"?

6)
11.  Internationalization Considerations

  The DSKPP protocol is mostly meant for machine-to-machine
  communications; as such, most of its elements are tokens not meant
  for direct human consumption.  If these tokens are presented to the
  end user, some localization may need to occur.  DSKPP exchanges
  information using XML.  All XML processors are required to understand
  UTF-8 and UTF-16 encoding, and therefore all DSKPP clients and
  servers MUST understand UTF-8 and UTF-16 encoded XML.

This deserves a normative reference to UTF-16.
You can probably use RFC 2781 (Note: it is Informational, so this would be a DOWNREF)

7)
12.4.  Status Code Registry

  Registration/Assignment Procedures:
      Following the policies outlined in [RFC3575], the IANA policy for
      assigning new values for the status codes for DSKPP MUST be
      "Specification Required" and their meanings MUST be documented in
      an RFC or in some other permanent and readily available reference,
      in sufficient detail that interoperability between independent
      implementations is possible.  No mechanism to mark entries as
      "deprecated" is envisioned.  It is possible to delete or update
      entries from the registry.

No, deletion of entries from the registry shouldn't be allowed. This is one of the main reasons for having the registry.

8)
12.3.  MIME Media Type Registration

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

I believe the last sentence is in violation of MIME, which requires US-ASCII to be the default charset.
This is also in violation of HTTP, which requires ISO-8859-1.

So I suggest removing the last quoted sentence.

9)
  [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
              .

This reference should be Normative.

  [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008,
              .

This reference looks Normative.

10)
3.4.1.1.  Authentication Code Format

  The following table summarizes the TLVs defined in this document.
  Optional TLVs are allowed for vendor-specific extensions with the
  constraint that the high bit MUST be set to indicate a vendor-
  specific type.  Other TLVs are left for later revisions of this
  protocol.

I think this needs an IANA registry, considering that the value space is only 1 byte.

11)
3.3.  Status Codes

  UnknownCriticalExtension:  A critical DSKPP extension (see below)
      used by the DSKPP client was not supported or recognized by the
      DSKPP server

Extension criticality is not discussed in the document (except for having
"Critical" attribute in the XML Schema).

12)
D.1.  Introduction

  This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES]
  and HMAC [RFC2104].  This appendix forms an informative part of the
  document.

Actually I disagree. I think this Appendix is Normative, considering that the two DSKPP-PRF functions are mandatory-to-implement.

D.2.  DSKPP-PRF-AES

D.2.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

Why MAY and not a MUST?

  http://www.ietf.org/keyprov/dskpp#dskpp-prf-aes-128


D.3.1.  Identification

  For cryptographic modules supporting this realization of DSKPP-PRF,
  the following URL MAY be used to identify this algorithm in DSKPP:

As above: why MAY?

[Ballot comment]
3.2.2.  Protocol Initiated by the DSKPP Client

  o  The DSKPP client needs the URL of the DSKPP server (which is not

Informative reference to URI spec is needed here (RFC 3986)


4.2.1.  KeyProvTrigger

      6.  The web application passes AD, and possibly a DeviceID
          (identifies a particular device to which the key MUST be

I don't think this use of MUST is correct, as it doesn't describe a requirement on a compliant implementation. I suggest changing this to something like "to which the key is to be provisioned)"

          provisioned) and/or KeyID (identifies a key that will be
          replaced) to the DSKPP server

4.2.4.  KeyProvClientNonce

      The particular
      realization of DSKPP-PRF (e.g., those defined in Appendix D

I think there is a missing ")" at the end of this line.

      depends on the MAC algorithm contained in the
      message.



  [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998, .

This document was obsoleted, please reference RFC 3986.

[Ballot discuss]
I would like to discuss the following issues before recommending approval of this document:

1)
3.2.3.  Protocol Triggered by the DSKPP Server

  The  message is sent in a HTTP response, and it is
  marked with MIME type "application/vnd.ietf.keyprov.dskpp+xml".  It

I think you meant application/dskpp+xml here.

Similarly:

7.2.1.  Identification of DSKPP Messages

  The MIME-type for all DSKPP messages MUST be

  application/vnd.ietf.keyprov.dskpp+xml

I think you meant application/dskpp+xml here.
(The same issue in examples in Section 7.2.7)


2)
3.3.  Status Codes

  NoProtocolVariants:  The DSKPP client only suggested a protocol
      variant (either 2-pass or 4-pass) that is not supported by the
      DSKPP server.  This error is only valid in the DSKPP server's
      first response message

According to Section 9, both variants are MUST implement for the server,
so this status code can never be returned.

3)
3.4.1.1.  Authentication Code Format

  Length (1 byte)          The length, in hexadecimal, of the value
                            field to follow.

1 byte length in hexadecimal? Do you mean the length is restricted to 15 bytes (one hexadecimal character)?
Or do you mean that the draft displays such values in hexadecimal, i.e. that that is only a display convention?

  Value (variable length)  A variable-length hexadecimal value
                            containing the instance-specific
                            information for this TLV.

As above.

  The Client ID is a mandatory TLV that represents the requester's
  identifier of maximum length 128.  The value is represented as an
  ASCII string that identifies the key request.  The ClientID MUST be
  HEX encoded.  For example, suppose ClientID is set to "AC00000A", the
  hexadecimal equivalent is 0x4143303030303041, resulting in a TLV of
  {0x1, 0x8, 0x4143303030303041}.

I am still confused about use of HEX here.

4)
3.4.1.1.  Authentication Code Format

  The Checksum is an OPTIONAL TLV, which is generated by the issuing
  server and sent to the user as part of the AC.  If the TLV is
  provided, the checksum value MUST be computed using the CRC16
  algorithm [ISO3309].

This reference must be Normative.

5)
4.2.5.  KeyProvServerFinished

      If status is Continue, then this message acts as a "commit"

Shouldn't this be Success?

      When the Status attribute is not set to "Continue", this indicates
      failure and the DSKPP client MUST abort the protocol.

      After receiving a  message with Status =
      "Success", the DSKPP client MUST verify the key confirmation MAC

So, is it supposed to be "Continue" or "Success"?

6)
11.  Internationalization Considerations

  The DSKPP protocol is mostly meant for machine-to-machine
  communications; as such, most of its elements are tokens not meant
  for direct human consumption.  If these tokens are presented to the
  end user, some localization may need to occur.  DSKPP exchanges
  information using XML.  All XML processors are required to understand
  UTF-8 and UTF-16 encoding, and therefore all DSKPP clients and
  servers MUST understand UTF-8 and UTF-16 encoded XML.

This deserves a normative reference to UTF-16.
You can probably use RFC 2781 (Note: it is Informational, so this would be a DOWNREF)

7)
12.4.  Status Code Registry

  Registration/Assignment Procedures:
      Following the policies outlined in [RFC3575], the IANA policy for
      assigning new values for the status codes for DSKPP MUST be
      "Specification Required" and their meanings MUST be documented in
      an RFC or in some other permanent and readily available reference,
      in sufficient detail that interoperability between independent
      implementations is possible.  No mechanism to mark entries as
      "deprecated" is envisioned.  It is possible to delete or update
      entries from the registry.

No, deletion of entries from the registry shouldn't be allowed. This is one of the main reasons for having the registry.

8)
12.3.  MIME Media Type Registration

  Optional parameters:  charset
      Indicates the character encoding of enclosed XML.  Default is
      UTF-8.

I believe the last sentence is in violation of MIME, which requires US-ASCII to be the default charset.
This is also in violation of HTTP, which requires ISO-8859-1.

So I suggest removing the last quoted sentence.

9)
  [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999,
              .

This reference should be Normative.

  [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008,
              .

This reference looks Normative.

IANA comments:

Upon approval of this document, IANA will perform the following actions:

ACTION 1:

make the following assignment in the "IETF XML schema" registry at
http://www.iana.org/assignments/xml-registry/schema.html

ID URI Filename
Reference
------------- ---------------------------------------- ------------
---------------------
keyprov:dskpp urn:ietf:params:xml:schema:keyprov:dskpp keyprov:dskpp
[RFC-keyprov-dskpp-10]


ACTION 2:

make the following assignment in the "IETF XML ns" registry at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Filename Reference
------------- ------------------------------------ -------------
---------------------
keyprov:dskpp urn:ietf:params:xml:ns:keyprov:dskpp keyprov:dskpp
[RFC-keyprov-dskpp-10]


ACTION 3:

make the following assignment in the "Application Media Types" registry at
http://www.iana.org/assignments/media-types/application/

Type Reference
--------- ---------------------
dskpp+xml [RFC-keyprov-dskpp-10]


ACTION 4:

create the following registry at
http://www.iana.org/assignments/TBD

Registry Name: DSKPP Response Message Status Codes
Registration policy: Specification Required
Reference: [RFC-keyprov-pskc-05]

Code Reference
------------------------------- ---------------------
Continue [RFC-keyprov-pskc-05]
Success [RFC-keyprov-pskc-05]
Abort [RFC-keyprov-pskc-05]
AccessDenied [RFC-keyprov-pskc-05]
MalformedRequest [RFC-keyprov-pskc-05]
UnknownRequest [RFC-keyprov-pskc-05]
UnknownCriticalExtension [RFC-keyprov-pskc-05]
UnsupportedVersion [RFC-keyprov-pskc-05]
NoSupportedKeyTypes [RFC-keyprov-pskc-05]
NoSupportedEncryptionAlgorithms [RFC-keyprov-pskc-05]
NoSupportedMacAlgorithms [RFC-keyprov-pskc-05]
NoProtocolVariants [RFC-keyprov-pskc-05]
NoSupportedKeyPackages [RFC-keyprov-pskc-05]
AuthenticationDataMissing [RFC-keyprov-pskc-05]
AuthenticationDataInvalid [RFC-keyprov-pskc-05]
InitializationFailed [RFC-keyprov-pskc-05]
ProvisioningPeriodExpired [RFC-keyprov-pskc-05]

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Document Shepherd is Phillip Hallam Baker
Shepherd has personally reviewed this version of the document and believes
that it is ready for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?
         
The document has been extensively reviewed by working group members
including experts in the field of cryptographic protocol design and
implementers of cryptographic protocols.

These reviews are in my view more than adequate.         

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?
         
No.         

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

Yes, a company called TecSec has asserted rights in respect of all uses
of XML Encryption technology.

https://datatracker.ietf.org/ipr/332/

Document Shepherd is currently a participant in litigation connected
with this patent and is unable to comment on the applicability to KEYPROV.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

Pretty much unanimous. Some people would like to do other stuff in
addition, but no issues identified with the document.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

Checked and fixed

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes

there are references to the following non-IETF documents:

NIST Standards        'FIPS180-SHA' 'FIPS197-AES'
PKCS Specifications  'PKCS-1' 'PKCS-5' 'PKCS-5-XML'
ISO Standard          'UNICODE'
W3C Standards        'XMLDSIG' 'XMLENC'

None of these should cause downref issues in my view.


  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?
         
Yes       

There are four sets of registration instructions. Of these the first
three are standard registration of XML type namespace and schema data.

A status code registry is created for the protocol. This has a
'specification required' constraint and is thus not requiring ongoing
maintenance associated with an open registry.
         

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Yes.
[Currently working on an XML issue here]

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

Technical Summary
         
  DSKPP is a client-server protocol for initialization (and
  configuration) of symmetric keys to locally and remotely accessible
  cryptographic modules.  The protocol can be run with or without
  private-key capabilities in the cryptographic modules, and with or
  without an established public-key infrastructure.

  Two variations of the protocol support multiple usage scenarios.
  With the four-pass variant, keys are mutually generated by the
  provisioning server and cryptographic module; provisioned keys are
  not transferred over-the-wire or over-the-air.  The two-pass variant
  enables secure and efficient download and installation of pre-
  generated symmetric keys to a cryptographic module.

Working Group Summary

  I would note that we seem to have had more discussion of issues
  connected with XML style and semantics than on the problem. In
  particular there does not seem to be a perfect answer to the
  problem of how to manage versioning of XML protocols.

Document Quality

  The document is a product of the KEYPROV working group.
 
Personnel
  Document Shepherd is Phillip Hallam-Baker
 


  The Document Shepherd MUST send the Document Shepherd Write-Up to the
  Responsible Area Director and iesg-secretary@ietf.org together with
  the request to publish the document.  The Document Shepherd SHOULD
  also send the entire Document Shepherd Write-Up to the working group
  mailing list.  If the Document Shepherd feels that information which
  may prove to be sensitive, lead to possible appeals or is personal
  information needs to be written up, it SHOULD be sent in direct email
  to the Responsible Area Director, because the Document Shepherd
  Write-Up is published openly in the ID Tracker.  Question (1.f) of
  the Write-Up covers any material of this nature and specifies this
  more confidential handling.