Life is complicated, but this is not so bad - Isaac Newton's rules where around a lot longer before they were found to be wrong.
I am still waiting to here further justification (beyond the old ground of "its in the spec"). and so far you are confirming my suspicions that there are none.
-----Original Message-----
From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]
Sent: Thursday, June 08, 2000 8:35 AM
To: ietf-pkix@imc.org
Subject: RE: Correct approach to certificate validation?
Trevor,
> From: "Trevor Freeman" <trevorf@Exchange.Microsoft.com>
>
> David,
> Interoperability is a primary goal, however that is often scarified by
> standards. It is very easy to produce a document with a set of do's and
> don'ts without any regard for the previous standard, the impact on the
> deployed products or how migration is achieved between the old and new
> standard. It is also unrealistic to think that all products deployed
> would conform to a single standard. Most products have a lifetime of
> years. The interoperability matrix is vast and getting worse every time
> a new version of a standard is released.
> So to return to the original point, besides citing a 20 year old clause
> in a standard, and saying we should do it because its in the standard,
> and requiring administrators to have a faultless record, I have still
> not hear any reasoned, argument as to what is actually achieved by this
> behavior.
> No standard or clause in a standard has a divine right of existence.
> Trevor
On the one hand, you seem to be decrying the ease of producing new
specifications without regard for previous standards and deployed
products.
On the other, you seem to support discarding a 20 year old clause
in a standard without regard for its impact on deployed products which
have been built according to the standard.
The "divine right" of any clause comes not from heaven or inheritance,
but from the fact that it has been vetted internationally (in the ISO
and the IETF) over a period of many years. Over that time (whether it's
12 or 20 years is immaterial), the requirement that certificates point
to the correct issuer has not only survived, it has not to my knowledge
been even mildly controversial. Now that there is discussion of
the topic, the requirement will either survive or be discarded based
on international consensus. There is no divine right, just the
stability (inertia?) of a consensus-based standard-setting
process.
You may present a case that the requirement should be removed from X.509
and then from the PKIX profile of X.509.
Or you may choose not to comply with X.509.
But you can't both ignore the requirement and claim compliance.
> Certificate discovery is not the issue here.
>
> For certificate discovery, we have a domain push mechanism as well as
> AIA. We are also adding a lookup by name, and a configurable URL search
> path i.e. a set of URLs to search (LDAP, HTTP, FTP)
Certificate discovery *is* the issue.
If you are adding a "lookup by name" function to your products,
how will that work if certificates do not have correct issuer
names? If I have someone's End Entity certificate, how do I find a
path of CA certs that leads to my trust point (not necessarily the
certificate subject's trust point), in the multi-vendor,
multi-administrative-domain environment of the Internet.
Products may support many certificate discovery mechanisms, both
standards-based and differentiating. But there needs to be at
least one "Internet" interoperability mode which all products
support. That mode is defined by PKIX: the certificate profile
and the LDAP schema.
One "Internet mode" mechanism which follows the current PKIX
specifications is for organizations to place public information,
including CA and EE certificates, in border directories, and to link
the border directories together using directory-to-directory chaining,
LDAP referrals, or both. If you propose to eliminate the X.509
requirement for correct issuer names, you will need to address the
impact on current applications built to the current standards,
as well as the feasability of future applications built to an
amended standard.
Dave
P.S. I don't understand why you keep referring to "punishing
administrators" and "requiring administrators to have a flawless
record" and "eliminating imperfection". A CA workstation has its own
signing key and certificate. If the workstation cannot correctly place
its own name in the issuer field of every certificate it signs, that is
a product flaw. This X.509 requirement does not hinge upon human
perfectability.