Re: Correct approach to certificate validation?

[Al Arsenault <awa1@xxxxxxxx>]

Trevor,

	Here's the justification:

	Suppose that a CA system (by, e.g., Netscape, Entrust, VeriSign,
whomever) has been built to conform to existing/understood X.509/RFC2459
name chaining rules.  Suppose that such a system has been deployed for,
oh, say, a large Government department, or a large corporation, or...

	Now, suppose that a CA from some other corporation that follows the
rules you suggest - i.e., name chaining doesn't matter.  We want to
integrate that CA into the existing PKI.  

	Now, for whatever reason - human frailty, whatever - that new CA is
used to create a certificate whose distinguish name is "C=AW,
O=Government, OU= Computers, CN= CA1", and then that CA creates user
certs where the issuer name is "C=AW, O=Government, OU=Computer,
CN=CA1".  Note that these names are not equivalent.*

	Suppose that all other information - AKI, AIA, etc. - is set up
properly.

	Now, whenever a cert path is validated using the new CA, it will be
validated, because the fact that the end entity cert's issuer name and
the CA cert's subject name aren't the same doesn't matter.  However,
whenever that same cert path is validated by a node in the existing PKI,
validation will fail, because of the name chaining failure. The notion
of obtaining different results by different points in the system is
disconcerting, to say the least.

	That's the reason:  by building your system this way, you cause the
multi-vendor interoperable PKI to fail.  If you were building your
system to not interoperate with any other existing products, then I
think we could probably agree that you were right; there is no real
reason that names have to chain.  However, lots of people do want your
system to interoperate with other products.  I'm fairly confident that
Dave wants them to.  I know that in some of the cases I'm dealing with
now, I need them to.  And they don't.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

*And yes, I have seen cases where name chaining failed - and thus
certificate validation failed when it shouldn't have - because of a
misplaced comma in a CN field.  I've also seen it fail because of an
extra space in an OU field, and several other situations.


> Trevor Freeman wrote:
> 
> 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.