RE: Draft Charter

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

What is X.509 specific?

The term certificate or certification path or both.  Will PGP and others
not have a chain of keys/certificates?

Are not these concepts generic and is this not time to separate concepts
from X.509 format?

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxx] 
Sent: Friday, August 10, 2007 3:37 PM
To: Santosh Chokhani
Cc: ietf-trust-anchor@xxxxxxxx
Subject: Re: Draft Charter


That definition is x.509 specific ("certificate"). While that
may be what emerges as the consensus wrt scope for this proposed
work, we shouldn't decide that this way IMO.

S.

Santosh Chokhani wrote:
> Steve,
> 
>  
> 
> Would the following do?
> 
>  
> 
> A relying party uses the trust anchor and associated information to 
> verify signature on the first certificate in a certification path.  If

> there are no certificates (i.e., the trusted anchor has directly
signed 
> an object), the relying party uses the trust anchor and associated 
> information to verify signature on the signed object.
> 
>  
> 
>
------------------------------------------------------------------------
> 
> *From:* owner-ietf-trust-anchor@xxxxxxxxxxxxx 
> [mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] *On Behalf Of *Stephen
Kent
> *Sent:* Friday, August 10, 2007 12:10 PM
> *To:* turners@xxxxxxxx
> *Cc:* ietf-trust-anchor@xxxxxxxx
> *Subject:* Re: Draft Charter
> 
>  
> 
> Sean,
> 
>  
> 
> Some more comments on the charter text:
> 
>  
> 
> A trust anchor is a public key and associated data used by a relying 
> party to
> 
> begin the process of validating a signature on a signed object.
> 
>  
> 
> At least in the X.509 context, we often end to use the term "verify"
for 
> signatures, and validate for certs, although we are not absolutely 
> consistent in this usage.  RFC 2828 discusses this in the section 
> entitled "validate vs. verify" and I suggest we adopt the suggested 
> usage guidelines from there.
> 
>  
> 
> "begin" may still be problematic, e.g., because one might argue that
the 
> beginning of the signature validation process is path discovery. 
> Unfirtunately I don't have a good alternative suggestion right now.
> 
>  
> 
> Associated data is used to define the scope of the use of the trust 
> anchor for validating signatures. For example, associated data might 
> limit the types of identifiers in certificates that a_ public key is 
> used to validate, or the types of objects the signatures of which can
be 
> verified using a public key_.
> 
>  
> 
> The suggested rewording adheres to the validate vs. verify model in 
> 2828, avoids recursive use of the term TA in its own definition, and 
> extends the example to encompass non-cert signed data.
> 
>  
> 
> The scope section seems confusing to me:
> 
>  
> 
> - Supporting a single trust anchor administrator, such as in a typical
>   enterprise, who may be administering multiple trust anchors in her
domain,
> 
>   where those trust anchors can be either local or "foreign"
> 
>  
> 
> We have not defined "local" or "foreign" so it's hard to understand
the 
> importance of the distinction being drawn here.
> 
> 
> - Supporting multiple trust anchor administrators, such as is typical 
> for home
> 
>   users
> 
>  
> 
> Why do we believe it is common for a home user to need multiple TA 
> administrators?
> 
>  
> 
> - Supporting devices with limited or no user interface that may or may

> not have_ connectivity_ to the Internet
> 
>  
> 
> a simple typo fix, but if a deliverable is a TA management* protocol*,

> then why do we worry about devices that have no Internet connectivity?
> 
>  
> 
> Steve
>