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

RE: Does the problem need solving?



I think there is some confusion in interpreting what I "thought" I said
because I agree with you. I guess it all depends on your definition of a
TA (historically I've considered it a trusted public key and DN that are
used as the root for trust decisions). Using that definition, the TA and
the initialized path validation variables are both inputs to the path
validation process. The comment I sent was only that there are
environments out there today that do configure those path validation
variables. It was meant as a response to the last point Paul made in his
message:

-----------
Paul's point: "There is a large difference between "initialize the path
validation parameters" and "can initialize the path validation
parameters". I know of no popularly-used system that relies on PKIX
certs that allows any initialization of the path validation parameters.
I assume that you may know of one or two, but that does not negate what
I said above."
---------------------

I was not trying to tie them to the trusted public key - in fact I
believe it makes more sense to enable them to be tailored on a per user
or a per application basis regardless of the trusted key (or at least
allow variations on the set of variable settings for the same key for
different users/apps. I thought others wanted to tie them to the key,
not me. Sorry if I confused folks with what I tried to say (I really
hate email as a communication tool!). 

Cheers,
Sharon 

-----Original Message-----
From: Santosh Chokhani [mailto:chokhani@xxxxxxxxxxxx] 
Sent: Thursday, June 28, 2007 12:52 PM
To: Sharon Boeyen; Paul Hoffman; Stephen Kent
Cc: ietf-trust-anchor@xxxxxxxx
Subject: RE: Does the problem need solving?

Steve and Sharon,

I am firmly with Paul.  3280 does not require (albeit does not prohibit)
to associate initial values with a trust anchor which is different from
associating these with a path validation process.

It is one thing to initialize path validation based on application need
and another to associated shades of gray with different TAs used by the
RP.

-----Original Message-----
From: Sharon Boeyen [mailto:sharon.boeyen@xxxxxxxxxxx]
Sent: Thursday, June 28, 2007 10:53 AM
To: Paul Hoffman; Stephen Kent
Cc: Santosh Chokhani; ietf-trust-anchor@xxxxxxxx
Subject: RE: Does the problem need solving?

Paul, fyi there are several such systems in wide deployment today that
DO initialize path validation variables as cited in RFC 3280. 

-----Original Message-----
From: owner-ietf-trust-anchor@xxxxxxxxxxxxx
[mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of Paul Hoffman
Sent: Thursday, June 28, 2007 10:46 AM
To: Stephen Kent
Cc: Santosh Chokhani; ietf-trust-anchor@xxxxxxxx
Subject: RE: Does the problem need solving?


At 9:45 AM -0400 6/28/07, Stephen Kent wrote:
>At 10:46 AM -0700 6/27/07, Paul Hoffman wrote:
>>At 10:28 AM -0700 6/27/07, Santosh Chokhani wrote:
>>>I am talking about associating certificate policies with a TA.  I am 
>>>not talking about managing the certificate policies for a CA or PKI.
>>>
>>>Associating certificate policies with a TA is very much relying party

>>>decision.  The relying party can choose to trust a TA for subset of 
>>>the policies for a PKI domain.
>>
>>Quite right. It's hard for those of us who have been swimming in the 
>>PKIX waters for so long to remember that the relying party gets to 
>>make his/her own decisions and don't have to rely only on what is in a

>>certificate.
>
>I'm surprised to hear you say that.
>
>PKIX has always operated in the space where RPs select TAs, and 
>initialize the path validation parameters. What aspects of PKIX 
>standards do you believe leads folks to think otherwise?

There is a large difference between "initialize the path validation
parameters" and "can initialize the path validation parameters". I know
of no popularly-used system that relies on PKIX certs that allows any
initialization of the path validation parameters. I assume that you may
know of one or two, but that does not negate what I said above.

--Paul Hoffman, Director
--VPN Consortium