I thought this was generally already done but will review the in-progress -02 draft for outliers and try to make the distinction clearer. I don't think we should remove the language since supporting RFC3280 is important.
Two examples equate validation of certification paths with RFC3280. Maybe it'd be clearer if those were made more explicit. For example, instead of "When the public key is used to validate certification paths, a distinguished name must also be included." could be "When the public key is used to validate certification paths in accordance with [RFC3280], a distinguished name must also be included."
With regard to the specific examples you gave, the first reference (in the introduction) is qualified with "For example, if a trust anchor is used to verify signatures on X.509 certificates...". That seems OK to me. The other reference (last paragraph in section 3) is one of the places that may benefit from not equating path validation with 3280.
> -----Original Message-----
> From: owner-ietf-trust-anchor@xxxxxxxxxxxxx
> [mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of
> Paul Hoffman
> Sent: Thursday, August 09, 2007 6:29 PM
> To: ietf-trust-anchor@xxxxxxxx
> Subject: Issue with the requirements document: PKIX-centric
> Greetings again.
> draft-wallace-ta-mgmt-problem-statement-01.txt does a good
> job of listing the problems we need to deal with, but some
> parts use PKIX language in places they don't need to. It's
> fine if these places are marked off with "for example, in
> PKIX ...", but in many places that is not included.
> To help make it clearer that the requirements are for
> management of all public keys, I propose that the following
> topics be removed or delimited as PKIXy examples:
> - Name constraints
> - Key usage
> - Expiration dates of keys
> - Possibly others that I have missed
> --Paul Hoffman, Director
> --VPN Consortium