RE: Draft Charter

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Steve,

It may be better if we agreed on how generic this definition needs to
be.  What communities are having trouble understanding these terms and
what their recommendations are.

I have been monitoring this list and I feel that most people on the list
know what trust anchor is.  Thus, rather than perfecting the definition,
we may be better served discussing the scope of TAMP, benefits of having
TAMP, and by generating implementers interest based on these benefits.

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxx] 
Sent: Friday, August 10, 2007 3:47 PM
To: Santosh Chokhani
Cc: ietf-trust-anchor@xxxxxxxx
Subject: 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
>>
> 
>