[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft Charter




Santosh Chokhani wrote:

What is X.509 specific?
The term certificate or certification path or both. 

Yes. For me anyway, particularly the latter term.

> Will PGP and others

not have a chain of keys/certificates?


Who knows? (Can't recall off the top of my head what the
PGP things are called - not keyrings was it?)


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


That would be a worthwhile activity. But not one that it'd be wise
to build in as a precondition on this proposed activity. So I'd rather
see a definition use more neutral terms.

S.



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