All,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.


1- section 13: about the use of the reserved keywords...
   On many places I have the feeling that the authors are not
   sufficiently directive. Two examples (others will follow):

   * introduction: must => MUST in sentence:
"This means that special care must be taken to ensure the
confidentiality..."

   * 13.1: before the last paragraph of the first solution, add:
"Additionally, it is strongly RECOMMENDED that practical
 implementations use PBESalt and PBEIterationCount when PBE
 encryption is used."


2- section 13, about the use of the term "payload" in titles:
   After reading the introduction of section 13, I understand that
   "payload" refers to "the information contained within [a PSKC
   container]".

   However I have the feeling that the three desired security
   services are for the whole PSKC container, not only "the
   information contained within". The titles are therefore a
   little bit misleading IMHO.


3- section 13.1: rather than "one of the password-based encryption
   methods provided above", I suggest the authors add an explicit
   reference to section 6.2.


4- section 13.1: it is said:
"Different PBESalt value per key container should be used for best
protection."

   It's rather ambiguous. It's not clear to me whether it is
   recommended to use a different PBESalt for each PSKC container,
   or whether it is recommended to use a different PBESalt when a
   given PSKC container carries several keys, one PBESalt per key.

   Also: "should" => "SHOULD"


5- section 13.1:
   why isn't the IPsec/ESP not considered also as a third
   solution to provide the confidentiality, integrity and sender
   authentication services? Why do the authors only focus
   on PCKS integrated or TLS solutions? It's not clear.


6- section 13.1, last but one paragraph:
   The authors say that TLS offers extra security measures,
   especially when the digital signature does not encompass
   the entire payload. I agree, but section 13.1 is dedicated
   to confidentiality, not to integrity/authenticity verifications.
   Referring to digital signatures is meaningless in this section.


7- section 13.1, last paragraph:
   Instead of: "Validating the secure channel end-points"
   I'd rather say: "Authenticating".


8- sections 13.1, 13.2 and 13.3:
   It is mentioned on several places that TLS can be useful in
   situations where "the signature of the payload does not
   encompass the entire payload".

   Shouldn't the authors RECOMMEND that the digital signature
   encompass the whole payload instead? It would clarify...
   This is all the more true if TLS is not used, in which case
   this is strongly RECOMMENDED.


9- section 13.3: it is said:
"A weaker payload authenticity guarantee may be provided by the
 transport layer if it is configured to digest each message it
 transports."

   Why is this feature necessarily weaker? The source can be
   authenticated with the same level of security as if it was
   done by the recipient end.


Typos:

* section 13.1 (also section 3):
   Rather than saying "the portable key container", I suggest
   the authors either write everything in extenso, or use the
   PSKC acronym.

* section 6.3, first sentence: a comma is missing between
  "element information", making the sentence difficult to
  understand.


Regards,

   Vincent