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

RE: WG Last Call: Son-of-2459

Trevor,

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.

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