RE: Correct approach to certificate validation?

["Jim Schaad" <jimsch@xxxxxxxxxx>]

David,

My draft has nothing to do with the fact that the name chaining may be
incorrect but applies even in the cases where name chaining is present and
correct.

There are various cases where not going strictly on name chaining can be
benifitual.  For example, if a company changes names the CA certificate can
be updated without having to re-issue all subordiante certificates at the
same time.  (This may happen due to merges, splits, name changes or court
ordered actions.)

jim

-----Original Message-----
From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]
Sent: Wednesday, June 07, 2000 7:00 AM
To: ietf-pkix@imc.org
Subject: RE: Correct approach to certificate validation?


Trevor,

It isn't about punishing administrators for minor errors, it is
about achieving an overall system with the goals of being both
secure and non-intrusive to the end user.  That may well mean that
administrators have to do more thinking, planning, and quality control,
but that is what they (we, the providers of a PKI for our branch of
Govt) are paid to do.

The specific case I'm referring to is Jim Schaad's assertion that an
S/MIME-specific cert path attribute is needed because applications
can't find CA certificates.  I didn't realize until now that that was
because in your environment subject certificates are not required to
have a correct issuer name!  It seemed obvious to me that the PKI is
responsible for correctly binding names to keys.  But you are saying
that Issuer names don't really matter, they're just a hint to help
applications search for a cert with a signing key that validates the
subject cert signature.  Well no wonder applications can't find CA
certs in that environment!

That isn't necessarily a wrong theoretical approach - SPKI is based
on the premise that only keys are important, names are simply optional
attributes attached to keys.  But it is wrong in X.509 because X.509
certificates are identified by and stored under Distinguished Names,
not public keys or SubjectKeyIdentifiers.

Standards are about interworking in a multi-vendor environment; the
testable requirements contained in standards are covenants between
supplier and customer.  My goal is for a CMI purchased from vendor
X and operated by company A to work with applications purchased from
vendors Y and Z and operated by companies B and C.  I understand
that that is not your primary goal, but I expect you to acknowledge
that when as a result of non-conformance some applications work and
others don't, it is NOT the fault of the conforming applications even
when they are the ones that fail.  And that when someone from company
X proposes as a Standard a workaround for a problem created somewhere
else in company X, the IETF is entitled to disregard the
company-specific rationale for that workaround.

Regards,
Dave



> From: "Trevor Freeman" <trevorf@Exchange.Microsoft.com>
>
> Hi David,
> I am afraid I don't see it necessary to eradicate every little
> imperfection because it is there. To err is human, and people make
> mistakes. People also have a wide list of requires which you may or may
> not agree with, but it does not mean that it is less real to them.
> So I don't see this as an error, simple a different point of view, and
> we will obviously disagree on this point.
> At the end of the day it is up to any product vendor to make the call as
> to what is\is not in their product, regardless what is in the standard.
> It is up to the market place to decide. History certainly tells us that
> customers like robustness in a product.
> If you can cite a specific issue, then we will obviously reconsider, but
> I don't find punishing minor infractions of administrators a compelling
> case.
> Trevor