Subject: RE: WG Last Call: Son-of-2459

From: "Trevor Freeman" <[email-masked]>
Date: Mon, 5 Mar 2001 13:23:49 -0800

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:[email-masked]]
Sent: Friday, March 02, 2001 1:39 PM
To: Steve Hanna
Cc: [email-masked]
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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Mar 2001 14:52:23 -0500

Trevor,

>the complexity of the trust relationships required by organisations.

I appreciate the support, but I fear that we may be arguing for 
different models. I would want to see an organizational CA issue 
cross certs with name constraints, and that CA (or a subordinate of 
it) would certainly issue certs to end users. I am not fond of the 
"bridge CA" model that the U.S. federal PKI adopted, because none of 
its subscriber organizations can issue cross certs to the bridge 
containing other than simple, prohibited subtree name constraints. 
I'd be happier if the bridge CA subscriber organizations took the 
certs issued by the bridge CA and used them as a basis for issuing 
direct cross certs with name constraints. But I've been told that the 
complexity of doing that would be too great for the subscriber 
organizations, so ...

Anyway, since it is clear that not all folks will issue cross certs 
as I suggested, I have to admit to liking the fallback position of 
allowing specification of name constraints as part of the validation 
procedure, on a per trust anchor basis. The main argument I've seen 
is the one that questions whether this should be a user configurable 
parameter, or an administrative parameter, or whether this is a MAY 
(vs. SHOULD/MUST), which allows vendors to ignore the facility 
entirely.

Steve