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

Russ Housley <housley@vigilsec.com> Mon, 01 March 2010 15:47 UTC

Message-ID: <4B8BE1B3.2010601@vigilsec.com>
Date: Mon, 01 Mar 2010 10:48:03 -0500
From: Russ Housley <housley@vigilsec.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Glen Zorn <gwz@net-zen.net>
References: <00c101cab945$18bf9090$4a3eb1b0$@net>
In-Reply-To: <00c101cab945$18bf9090$4a3eb1b0$@net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: cwallace@cygnacom.com, secdir@ietf.org, srashmo@radium.ncsc.mil, iesg@ietf.org, pkix-chairs@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-pkix-tamp-05
Precedence: list

Glen:

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

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.

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

Thanks for catching that mistake.

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

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

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

That is a good improvement.

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

Thanks for catching that mistake.

> The Security Considerations section is remarkably clear and comprehensive.

Thanks.

Russ

[secdir] secdir review of draft-ietf-pkix-tamp-05 Glen Zorn
Re: [secdir] secdir review of draft-ietf-pkix-tam… Russ Housley