Subject: [secdir] secdir review of draft-ietf-pkix-tamp-05

From: "Glen Zorn" <[email-masked]>
Date: Mon, 1 Mar 2010 20:42:49 +0700

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.

EDITORIAL COMMENTS

Section 1.2.2 says:
   Management trust anchors are used in the management of cryptographic
   modules.  For example, the TAMP messages specified in this document
   are validated to a management trust anchor.  Likewise, a signed
   firmware package as specified in [RFC4108] is validated to a
   management trust anchor.
This might be better put as    
   Management trust anchors are used in the management of cryptographic
   modules.  For example, the TAMP messages specified in this document
   are validated by a management trust anchor.  Likewise, a signed
   firmware package as specified in [RFC4108] is validated by a
   management trust anchor.

In Section 1.3.4, s/The application-specific protocol processing MUST be
provided the/The application-specific protocol processing MUST provide the/

Section 3, paragraph 3 says "Certificates include a signature, which removes
the ability for relying parties to".  Just a question: should "relying" in
the sentence actually be "relaying"?  In any case, "ability for" should
probably be changed to "ability of".

Suggestion: Section 4.4 says in two places "The status codes appear in the
same order as the TrustAnchorUpdate structures to which they apply"; maybe
"The status codes MUST appear in the same order as the TrustAnchorUpdate
structures to which they apply" would be clearer.

In Section 7, s/if the signer is not representated/if the signer is not
represented/.

The Security Considerations section is remarkably clear and comprehensive.

---

From: Russ Housley <[email-masked]>
Date: Mon, 01 Mar 2010 10:48:03 -0500

>    firmware package as specified in [RFC4108] is validated by a

The point is that the certification path must terminate at the
management trust anchor.  This is accomplished when the signature can be
validated directly with the management trust anchor public key, but it
is also accomplished when the top-level certificate in a valid
certification path is the management trust anchor.  The phrase
"validated to" is intended to reflect this situation.

> provided the/The application-specific protocol processing MUST provide the/

Thanks for catching that mistake.

> probably be changed to "ability of".

No, this is correct.  Parties that validate certificates and then depend
upon the stuff in the certificate are called "relying parties."

> structures to which they apply" would be clearer.

That is a good improvement.

> In Section 7, s/if the signer is not representated/if the signer is not

Thanks for catching that mistake.

> The Security Considerations section is remarkably clear and comprehensive.

Thanks.

Russ