Portable Symmetric Key Container (PSKC)
draft-ietf-keyprov-pskc-09

[Ballot comment]
:  This element indicates the manufacturer of the
      device.  Values for Manufacturer SHOULD be taken from either
      [OATHMAN] prefixes (i.e., the left column) or they SHOULD be taken
      from IANA Private Enterprise Number Registry [IANAPENREG], using
      the Organisation value.

Having 2 SHOULDs is not quite correct, as this might be interpreted that a third registry can be used here.

      When the value is taken from [OATHMAN]
      "oath."  MUST be prepended to the value (e.g. "oath.").  When the value is taken from [IANAPENREG]
      "iana."  MUST be prepended to the value (e.g. "iana.").



Is the registry described by [OATHMAN] Open and contains stable information?

[Ballot discuss]
This is a fine document, however I have one remaining issue I would like to discuss before recommending approval of this document:

2)
4.2.1.  Element: Unique Device Identification

  :  This element indicates the manufacturer of the
      device.  Values for Manufacturer SHOULD be taken from either
      [OATHMAN] prefixes (i.e., the left column)

To double check - did you mean the two character alphanumeric codes?

      or they SHOULD be taken
      from IANA Private Enterprise Number Registry [IANAPENREG], using
      the Organisation value.

Having pointers to 2 registries which might contain clashing names is the worst combination possible. If you don't believe you can ever have a clash, this should be clarified in the document.
Otherwise I would advise you define a unique prefix for at least one of the registries. For example, you can use the following values in the  element:

iana.

and

oathman.

One prefix can be eliminated, if it can never occur in the other registry.

IANA comments:

The actions don't appear to have changed since the first Last Call, but
the document still needs to indicate that the PSKC Algorithm Profiles
registry should include both HOTP and KEYPROV-PIN.

[Ballot discuss]
1. [Addressed in -06.]

2. No guidance is provided about how to ensure that the 'Id' attribute is globally unique. To help ensure interoperability, a reference to RFC 4122 might be in order.

3. The syntax of the  element is unspecified. In general, the Internet Date/Time Format specified in RFC 3339 is preferred, but any profile of ISO 8601 is probably acceptable as long as it is clearly specified to ensure interoperability. The same considerations apply to the  and  elements.

4. [Clarified via email, no changes to spec.]

5. [Addressed in -06.]

6. No guidance is provided regarding when to increment the version number, nor regarding the significance of major and minor versions. You might be able to borrow some text from Section 4.4.1 of RFC 3920 or some other specification.

7. [Addressed in -06.]

8. [Addressed in -06.]

9. Section 13.1 refers to "transport layer security" but does not provide a reference to RFC5246 or alternate approaches. Also, is any technology that provides a secure channel between the source secure perimeter and the target perimeter acceptable?

[Ballot comment]
13.1.  Payload Confidentiality

  Practical implementations should use PBESalt and PBEIterationCount
  when PBE encryption is used.  Different PBESalt value per key
  container should be used for best protection.

This is the first time PBE is mentioned in the document, so the acronym needs expanding and a reference is needed.

[Ballot discuss]
This is a fine document, however I have a list of issues I would like to discuss before recommending approval of this document:

2)
4.2.1.  Element: Unique Device Identification

: This element indicates the manufacturer of the
device.  Values for Manufacturer SHOULD be taken from [OATHMAN]

DISCUSS DISCUSS:
I want to make sure that this registry is Open and contains stable information.

4)
12.4.  PSKC Algorithm Profile Registry

  Algorithm Definition:  A reference to the stable document in which
      the algorithm being used with the PSKC is defined.

Is this field required?
If yes, you should change the registration procedure to "Specification Required" (which implies "Expert Review").

Similar issue in Section 12.6.

6)
4.1.  : Embedding Keying Material and Key Related Information

  The  element has a number of optional child elements.  An
  initial set is described below:

  [...]

  :  A human readable name for the secret key for easier
      reference.  This element serves informational purposes only.

This field seems to be human readable, so I think BCP 18 (RFC 2277), Section 4.2 applies. So this would need ability to have a language tag, most likely using the xml:lang attribute. You should also specify the default language, if not specified (suggest "en").
(Note that if this field is an identifier, then no language tag is needed.)

You can find a bit more information on

<>

[Ballot comment]
13.1.  Payload Confidentiality

  Practical implementations should use PBESalt and PBEIterationCount
  when PBE encryption is used.  Different PBESalt value per key
  container should be used for best protection.

This is the first time PBE is mentioned in the document, so the acronym needs expanding and a reference is needed.

[Ballot discuss]
This is a fine document, however I have a list of issues I would like to discuss before recommending approval of this document:

2)
4.2.1.  Element: Unique Device Identification

  :  This element indicates the manufacturer of the
      device.

DISCUSS DISCUSS: Is there any IANA registry that can be recommended for use in this field?

4)
12.4.  PSKC Algorithm Profile Registry

  Algorithm Definition:  A reference to the stable document in which
      the algorithm being used with the PSKC is defined.

Is this field required?
If yes, you should change the registration procedure to "Specification Required"
(which implies "Expert Review").

Similar issue in Section 12.6.

  PSKC algorithm profile identifier registrations are to be subject to
  Expert Review as per RFC 5226 [RFC5226].  Updates can be provided
  based on expert approval only.  Based on expert approval, it is
  possible to mark entries as "deprecated".

(Comment) I would recommend adding this as a field to the registration template.

6)
4.1.  : Embedding Keying Material and Key Related Information

  The  element has a number of optional child elements.  An
  initial set is described below:

  [...]

  :  A human readable name for the secret key for easier
      reference.  This element serves informational purposes only.

This field seems to be human readable, so I think BCP 18 (RFC 2277), Section 4.2 applies. So this would need ability to have a language tag, most likely using the xml:lang attribute. You should also specify the default language, if not specified (suggest "en").
(Note that if this field is an identifier, then no language tag is needed.)

You can find a bit more information on

<>

[Ballot discuss]
It is not always obvious which elements are mandtory or optional,
  especially when optional elements have mandatory child elements.
  The examples and recommended values help, but something more crisp
  would be very helpful.

  In Section 3, what portions of this section are mandatory in the
  Container?

  In Figure 1, it is clear that  is optional; however; it is not
  clear if all the child elements are mandatory.

  In Section 4.2.1, says that "certain child elements of the
  element MUST be included in order to uniquely identify a device."  Yet
  it us not clear which elements are mandatory to included.

[Ballot comment]
I'm going to mutter about IPR again rom a feeling of disquiet rather than any evidence that there is something wrong.

This I-D seems to combine some of the IPR issues from draft-ietf-keyprov-dskpp and draft-ietf-keyprov-symmetrickeyformat

It looks from the proto-write-up that the filed disclosures were notified to the WG but resulted in no discussion. So maybe that's OK

The reference to the Luhn patent is probably covered by the fact that it is very old, but maybe should be a stable reference.

[Ballot comment]
13.1.  Payload Confidentiality

  Practical implementations should use PBESalt and PBEIterationCount
  when PBE encryption is used.  Different PBESalt value per key
  container should be used for best protection.

This is the first time PBE is mentioned in the document, so the acronym needs expanding and a reference is needed.

[Ballot discuss]
This is a fine document, however I have a list of issues I would like to discuss before recommending approval of this document:

1)
4.1.  : Embedding Keying Material and Key Related Information

      :  This element carries the time interval value for
        time based OTP algorithms.

What is the resolution for this element?

2)
4.2.1.  Element: Unique Device Identification

  :  This element indicates the manufacturer of the
      device.

DISCUSS DISCUSS: Is there any IANA registry that can be recommended for use in this field?

3)
4.2.4.  Element: Supplementary Information for OTP
        and CR Algorithms

      'Encoding':  This attribute, which MUST be included, defines the
        encoding of the challenge accepted by the device and MUST be
        one of the following values:

        BASE64  Base 64 encoded

This needs a proper reference, for example "Base 64 encoded as defined in
Section 4 of [RFC4648]".

4)
12.4.  PSKC Algorithm Profile Registry

  Algorithm Definition:  A reference to the stable document in which
      the algorithm being used with the PSKC is defined.

Is this field required?
If yes, you should change the registration procedure to "Specification Required"
(which implies "Expert Review").

Similar issue in Section 12.6.

  PSKC algorithm profile identifier registrations are to be subject to
  Expert Review as per RFC 5226 [RFC5226].  Updates can be provided
  based on expert approval only.  Based on expert approval, it is
  possible to mark entries as "deprecated".

(Comment) I would recommend adding this as a field to the registration template.

5)
16.2.  Informative References

  [AESKWPAD]
              Housley, R. and M. Dworkin, "Advanced Encryption Standard
              (AES) Key Wrap with Padding Algorithm", March 2009, .

It looks like this reference is Normative (Referenced in a sentence using "RECOMMENDED" RFC 2119 keyword).

  [HOTP]    MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
              O. Ranen, "HOTP: An HMAC-Based One Time Password
              Algorithm", RFC 4226, December 2005.

This reference is Normative due to Section 10.1.

  [LUHN]    Luhn, H., "Luhn algorithm", US Patent 2950048,
              August 1960, .

This should be a Normative reference.
It also needs to be more stable. (See IETF LC discussion on draft-ietf-keyprov-symmetrickeyformat-08.txt)

6)
4.1.  : Embedding Keying Material and Key Related Information

  The  element has a number of optional child elements.  An
  initial set is described below:

  [...]

  :  A human readable name for the secret key for easier
      reference.  This element serves informational purposes only.

This field seems to be human readable, so I think BCP 18 (RFC 2277), Section 4.2 applies. So this would need ability to have a language tag, most likely using the xml:lang attribute. You should also specify the default language, if not specified (suggest "en").
(Note that if this field is an identifier, then no language tag is needed.)

You can find a bit more information on

<>

[Ballot comment]
1. I must be missing something, but where exactly in this specification is the KEYPROV-PIN algorithm defined? I see it mentioned only in the IANA considerations.

2. I have not yet had a chance to review the XML schema but will do so as soon as possible.

[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 PSKC is:

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

  References to qualified elements in the PSKC schema defined herein
  use the prefix "pskc".

The URI here is "urn:ietf:params:xml:ns:keyprov:pskc" without the "xmlns:pskc=" preceding the URI so to reduce confusion it would be best to include only the URI. Also, is the prefix "pskc" 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 "pskc" prefix is used in examples here but any prefix is allowed.

2. No guidance is provided about how to ensure that the 'Id' attribute is globally unique. To help ensure interoperability, a reference to RFC 4122 might be in order.

3. The syntax of the  element is unspecified. In general, the Internet Date/Time Format specified in RFC 3339 is preferred, but any profile of ISO 8601 is probably acceptable as long as it is clearly specified to ensure interoperability. The same considerations apply to the  and  elements.

4. Does the  child element apply to literally all children of the  element? How will implementations interoperate if, say, the  element or  element is encrypted? Will the need to decrypt such elements introduce additional processing requirements and the possibility of denial of service?

5. No guidance is provided regarding values for 'MaxFailedAttempts'; for example, a reasonable number of retries might be at least 2 and no more than 5.

6. No guidance is provided regarding when to increment the version number, nor regarding the significance of major and minor versions. You might be able to borrow some text from Section 4.4.1 of RFC 3920 or some other specification.

7. The security considerations in the content-type registration for 'application/pskc+xml' need to reference this specification because otherwise they are minimal at best.

8. The PSKC Algorithm Registry template says that algorithms are identified by URNs; are URIs not allowed? If not, why not?

9. Section 13.1 refers to "transport layer security" but does not provide a reference to RFC5246 or alternate approaches. Also, is any technology that provides a secure channel between the source secure perimeter and the target perimeter acceptable?

[Ballot comment]
It is not always obvious which elements are mandtory or optional,
  especially when optional elements have mandatory child elements.
  The examples and recommended values help, but something more crisp
  would be very helpful.

  In Section 3, what portions of this section are mandatory in the
  Container?

  In Figure 1, it is clear that  is optional; however; it is not
  clear if all the child elements are mandatory.

  In Section 4.2.1, says that "certain child elements of the
  element MUST be included in order to uniquely identify a device."  Yet
  it us not clear which elements are mandatory to included.

  Typo: s/MAC-Based One Time Password/HMAC-Based One Time Password/

[Ballot comment]
13.1.  Payload Confidentiality

  Practical implementations should use PBESalt and PBEIterationCount
  when PBE encryption is used.  Different PBESalt value per key
  container should be used for best protection.

This is the first time PBE is mentioned in the document, so the acronym needs expanding and a reference is needed.

[Ballot discuss]
This is a fine document, however I have a list of issues I would like to discuss before recommending approval of this document:

1)
4.1.  : Embedding Keying Material and Key Related Information

      :  This element carries the time interval value for
        time based OTP algorithms.

What is the resolution for this element?

2)
4.2.1.  Element: Unique Device Identification

  :  This element indicates the manufacturer of the
      device.

DISCUSS DISCUSS: Is there any IANA registry that can be recommended for use in this field?

3)
4.2.4.  Element: Supplementary Information for OTP
        and CR Algorithms

      'Encoding':  This attribute, which MUST be included, defines the
        encoding of the challenge accepted by the device and MUST be
        one of the following values:

        BASE64  Base 64 encoded

This needs a proper reference, for example "Base 64 encoded as defined in
Section 4 of [RFC4648]".

4)
12.4.  PSKC Algorithm Profile Registry

  Algorithm Definition:  A reference to the stable document in which
      the algorithm being used with the PSKC is defined.

Is this field required?
If yes, you should change the registration procedure to "Specification Required"
(which implies "Expert Review").

Similar issue in Section 12.6.

  PSKC algorithm profile identifier registrations are to be subject to
  Expert Review as per RFC 5226 [RFC5226].  Updates can be provided
  based on expert approval only.  Based on expert approval, it is
  possible to mark entries as "deprecated".

(Comment) I would recommend adding this as a field to the registration template.

5)
16.2.  Informative References

  [AESKWPAD]
              Housley, R. and M. Dworkin, "Advanced Encryption Standard
              (AES) Key Wrap with Padding Algorithm", March 2009, .

It looks like this reference is Normative (Referenced in a sentence using "RECOMMENDED" RFC 2119 keyword).

  [HOTP]    MRaihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
              O. Ranen, "HOTP: An HMAC-Based One Time Password
              Algorithm", RFC 4226, December 2005.

This reference is Normative due to Section 10.1.

  [LUHN]    Luhn, H., "Luhn algorithm", US Patent 2950048,
              August 1960, .

This should be a Normative reference.
It also needs to be more stable. (See IETF LC discussion on draft-ietf-keyprov-symmetrickeyformat-08.txt)

IANA comments:

ACTION 1:

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

Type Reference
-------- ---------------------
pskc+xml [RFC-keyprov-pskc-05]


ACTION 2:

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

ID URI Filename Reference
------------ --------------------------------------- ------------
---------------------
keyprov:pskc urn:ietf:params:xml:schema:keyprov:pskc keyprov:pskc
[RFC-keyprov-pskc-05]


ACTION 3:

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

ID URI Filename Reference
------------ ----------------------------------- ------------
---------------------
keyprov:pskc urn:ietf:params:xml:ns:keyprov:pskc keyprov:pskc
[RFC-keyprov-pskc-05]


ACTION 4:

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

Registry Name: PSKC Algorithm Profiles
Registration policy: Expert Review
Reference: [RFC-keyprov-pskc-05]

As specified in section 12.4, the columns of the registry will be:
- Common Name: The name by which the PSKC algorithm profile is
generally referred.
- Class: The type of PSKC algorithm profile registry entry being
created, such as encryption, Message Authentication Code (MAC),
One Time Password (OTP), Digest.
- URN: The URN to be used to identify the profile.
- Identifier Definition: IANA will be asked to add a pointer to the
specification containing information about the PSKC algorithm
profile registration.
- Algorithm Definition: A reference to the stable document in which
the algorithm being used with the PSKC is defined.
- Registrant Contact: Contact information about the party submitting
the registration request.
- PSKC Profiling: Information about PSKC XML elements and attributes
being used (or not used) with this specific profile of PSKC.
- Reference

The initial content will be as described in section 10.1 and 10.2


ACTION 5:

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

Registry Name: PSKC Versions
Registration policy: Standards Action.
Reference: [RFC-keyprov-pskc-05]

Initial content of the registry:

PSKC Version Reference
------------ ---------
1.0 [RFC-keyprov-pskc-05]


ACTION 6:

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

Registry Name: PSKC Key Usage
Registration policy: Expert review
Reference: [RFC-keyprov-pskc-05]

Initial content of the registry:

Key Usage Token Reference
--------------- ---------------------
OTP [RFC-keyprov-pskc-05]
CR [RFC-keyprov-pskc-05]
Encrypt [RFC-keyprov-pskc-05]
Integrity [RFC-keyprov-pskc-05]
Verify [RFC-keyprov-pskc-05]
Unlock [RFC-keyprov-pskc-05]
Decrypt [RFC-keyprov-pskc-05]
KeyWrap [RFC-keyprov-pskc-05]
Unwrap [RFC-keyprov-pskc-05]
Derive [RFC-keyprov-pskc-05]
Generate [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?

The document shepherd is Hannes Tschofenig (Hannes.Tschofenig@gmx.net).
I have personally reviewed the document and I believe it is ready 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 was reviewed by working group members. There are no concerns
regarding the depth or breadth of the review.


  (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?

There are no concerns with this document. The document contains XML
examples
and an XML schema but the working group feels comfortable that those are
correct.

  (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.

There are no concerns with this document. An IPR disclosure has been
filed but did not lead to discussions within the working group.

  (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?

There is consensus in the WG behind the document.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize 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.)

There is no opposition to this document.

  (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?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The document does not contain nits.

The document contains a URN sub-namespace registration,
XML schema registration, and a content-type registration.


  (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].


The document has been split into normative and informative references.

There are references to non-IETF documents that need to be indicated during
IETF last call:

  [PKCS5]    RSA Laboratories, "PKCS #5: Password-Based Cryptography
              Standard", Version 2.0,
              URL: http://www.rsasecurity.com/rsalabs/pkcs/, March 1999.

  [XMLDSIG]  Eastlake, D., "XML-Signature Syntax and Processing",
              URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/,
              W3C Recommendation, February 2002.

  [XMLENC]  Eastlake, D., "XML Encryption Syntax and Processing.",
              URL: http://www.w3.org/TR/xmlenc-core/,
              W3C Recommendation, December 2002.

  [XMLENC11]
              Eastlake, D., "XML Encryption Syntax and Processing
              Version 1.1.",
              URL: http://www.w3.org/TR/2009/WD-xmlenc-core1-20090730,
              W3C Recommendation, July 2009.

             
  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations 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 the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?


The document has an IANA considerations section that is consistent with
the body.
This document defines new registries and the allocation of new entries
into these registries is based on expert review. 


  (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?

The XML code has been validated. Some examples contain cryptographically
generated material and it was created by one of the reference
implementations. 

  (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

  This document specifies an XML-based key format for transport and
  provisioning of symmetric keys to different types of crypto modules.
  For example, One Time Password (OTP) shared secrets or symmetric
  cryptographic keys to strong authentication devices.  A standard key
  transport format enables enterprises to deploy best-of-breed
  solutions combining components from different vendors into the same
  infrastructure.
 
  Working Group Summary

    There was consensus in the WG to publish the document.

  Document Quality

    The document is a product of the KEYPROV working group
    and the group has spend a fair amount of time working on
    this specification to ensure high quality output.
   
    Two independent implementations have been created by the
    document authors. A third implementation has been created
    by a student of Tim Polk. The code is, however, not
    available as open source.
   
  Personnel

    Hannes Tschofenig is the document shepherd for this document.