RE: WG Last Call: Son-of-2459

["Trevor Freeman" <trevorf@xxxxxxxxxxxxxxxxxxxxxx>]

Steve,
I think your original idea is the right one. I am sure that products
will appear which will support the features contained in son of RFC2459,
so I think it premature to introduce another mechanism. I also agree
with your premise that there will be a drive for the use of CAs who's
job is the issuance of cross certificates to other CAs with a view to
managing the trust relationships for a set of resources, and may never
in their lifetime issue a certificate to a end user. I have seen this as
an increasing trend with deployment planning due to the realisation of
the complexity of the trust relationships required by organisations.
Trevor

-----Original Message-----
From: Stephen Kent [mailto:kent@xxxxxxx]
Sent: Friday, March 02, 2001 1:39 PM
To: Steve Hanna
Cc: ietf-pkix@xxxxxxx
Subject: Re: WG Last Call: Son-of-2459


Steve,

I agree with most of the comments you have made re revisions to 2459, 
but I do disagree with the discussion if name constraints and its use 
in the validation algorithm.  I think that name constraints are 
critically important in PKIs that make extensive use of cross 
certification. Yet, as you note, they are no commonly used so far. I 
think that making provision to associate name constraints with trust 
anchors is a good way to let users (or administrators) locally manage 
the concerns that this extension addresses, without having to 
persuade CAs to issue cross certs with such constraints.  In fact, I 
was persuaded to drop my proposal for local issuance of such cross 
certs because of the inclusion of this facility as a control measure 
on the validation process.

This will become more than a local implementation issue, as we 
continue with the DPV/DPD work.  My current draft of the message 
syntax for requests calls for inclusion of name constraints as a 
validation control parameter, a protocol feature motivated by the 
notion that name constraints would become a standard part of the 
validation algorithm.

Steve