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

From: Peter Sylvester <[email-masked]>
Date: Wed, 7 Mar 2001 12:09:57 +0100 (MET)

I think that I am in full support of Steve Hanna's point of
view about implementing path constraints just by using
"cross" certificats. 

If an administrator need to configure in a static way
the input constraints, then it seems sufficient to
me to do this via a standard method, i.e. by providing
a certificate. 
 
Denis wrote:

> I am a little bit puzzled with your suggestion. Usually a given application
> trusts an anchor to isssue names for some organizations. But another
> application may chooose to apply different rules. So this is not a pure
> decision from the CA, otherwise the application would have to evaluate these
> name constraints before accepting them. 

If the other application has different rules, then this is not the same
'trust anchor'. Or, the restriction of names inposed to some 'anchor' 
(if this is statique for the application)
can be expressed easily as a cross certificate 'against' that 'anchor'. 

> So I have difficulties to see how the original name contraints could be
> handled by using the cross certificates you mention. Whatever, this seems to
> be only a suggestion. :-)

This doesn't sound like a suggestion, it seems to me rather
a description of what can be done with the existing mechanisms.

Regards
Peter

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 07 Mar 2001 08:24:45 -0700

>Steve:
>
>->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.
>
>I would strongly disagree against allowing name constraints to be a user
>configurable parameter.  This defeats the administrative value and assurance
>that name constraints provide.
>
>David B. Cross

David, I'm not sure that I understand your point.  Name constraints only 
constrain, they can't "unconstrain".  So if the user (or the MIS department)
can specify a name constraint as a configurable parameter, that can only
tighten the noose, not loosen it.

So how does this defeat the administrative value name constraints provide?
Maybe I'm missing something, but I've always liked the idea of the user 
acting as the root CA of last resort, since as the relying party it is the user,
and normally not some third-party CA, that has to make the decision as to 
whether or not to honor a digital signature and certificate chain.

I believe the same logic applies to policy OID constraints, by the way.

Bob

---

From: David Cross <[email-masked]>
Date: Sat, 10 Mar 2001 12:45:40 -0800

I think we are in agreement.  I just did not want us to do down the path of
unconstraining name and policy constraints when cross certificates are
generated.

David B. Cross

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2001 7:25 AM
To: David Cross; [email-masked]
Cc: [email-masked]
Subject: RE: WG Last Call: Son-of-2459

>I would strongly disagree against allowing name constraints to be a 
>user configurable parameter.  This defeats the administrative value and 
>assurance that name constraints provide.
>
>David B. Cross

So how does this defeat the administrative value name constraints provide?
Maybe I'm missing something, but I've always liked the idea of the user 
acting as the root CA of last resort, since as the relying party it is the
user, and normally not some third-party CA, that has to make the decision as
to 
whether or not to honor a digital signature and certificate chain.

Bob