Subject: Correct approach to certificate validation?

From: <[email-masked]>
Date: Sun, 4 Jun 2000 20:18:43 +0200

Now, based on my previous message, my question for this workgroup:

Which of these approaches is correct?
  - the approach of IE5 and Outlook, which, if an Authority Key Identifier
extension is present, does not perform a comparison of the issuer-DN in the
subject-cert to the subject-DN of the root-cert?
  - or the approach of Netscape and IIS4, which, even if an Authority Key
Identifier extension is present, DOES still perform a comparison of the
subject-cert-issuer-DN to the root-cert-subject-DN?

Regards,

denis bider

PS. I would like to thank Ace Swerling from Microsoft Consulting Services
for the fact that he bothered to look into my problem, and especially to
Peter Williams from Valicert who devoted much of his time to help me solve
this issue. I appreciate your feedback very much.

 -----Original Message-----
From: 	denis bider [mailto:[email-masked]]  On Behalf Of
[email-masked]
Sent:	Sunday, June 04, 2000 20:08
To:	[email-masked]'
Subject:	Report - certificate validation in IE5, Outlook, IIS4, Netscape
4.72

Hello,

a while ago I sent to this list an enquiry regarding Microsoft's certificate
validation code in IIS4. I have now resolved the problem that was the reason
for my enquiry. Since the solution to the problem produced some interesting
insight into how certificate chains are handled in IE5 and Outlook / IIS4
and Netscape, and since the behavior in question should be covered by
RFC2459, but does not seem to be, I am forwarding my findings to you.

I produced my own certificate generating utility, the intention of which was
to generate certificates which could be used by IE5 to login into an
SSL-protected web site running on IIS4. My problem was that, although IE5
claimed my root-cert/subject-cert certificate chain to be valid, and
although Outlook properly signed and verified messages signed by these
certificates, IIS4 rejected all attempts to use the subject certificate for
SSL client authentication. Also, when the subject certificate was imported
into Netscape, Netscape didn't even show it as an elligible choice for SSL
client authentication.

To sum it up, the problem was that there was a glitch in my code that caused
the subject-DN in root-cert to be slightly different from the issuer-DN in
the subject-cert. It seems that the certificate verification code in IE5 and
Outlook2000 is somewhat easy-going, since both of these products validated
the pair of certificates as valid (they performed cert-chain validation
solely on the grounds of the key identifier in the Authority Key Identifier
extension, they did not compare the sub-cert-issuerDN to the
root-cert-subjectDN). IIS4 and Netscape Communicator, on the other hand,
seem to have a more stringent policy, since they both rejected these
certificates.

denis bider

---

From: [email-masked]
Date: Tue, 6 Jun 2000 09:11:21 +0300

Trevor says,

> We have found that enforcing name chaining in path construction, causes
> more problems than it solves. We therefore have reverted to using the
> name as just a hint, rather than a critical factor and will as you have
<skip>
> I know this is at odds with RFC2459, but as this behaviour does not in
> our view cause a security problem, but does make the overall process
> more robust, we have and will continue to opt for the more robust

I agree. Names are just one of the potential attributes for the holder of
the secret key certified; they should not be used for chaining decisions.
Also the use of names for access control is dangerous, as the policy makers
may not realize that the names are not necessarily secure and they must
depend on the proper chain of trust.

Best, Amir Herzberg

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 6 Jun 2000 14:19:35 -0400 (EDT)

Trevor,

Could you describe a customer scenario which requires deliberate
non-chaining of names?  I can't envision any circumstance where a
CA 1) does not have a certificate containing the CA's signing key
and a subject name for the CA, or 2) cannot populate the issuer and
signature-value fields of certificates it issues with values matching
the subject name and public key from its own cert.

Enforcing name chaining during path construction does not cause
problems; it highlights existing problems.  When a system continues
to function in an environment with errors over which it has no control
(transmission bit errors, for example), it is called "robust".  But
when a system continues to function normally in the face of correctable
errors without providing any indication of a problem, "oblivious" is a
better term than "robust".  Like fixing an engine problem by removing
the offending indicator lamp from the dashboard.

I agree that ignoring name chaining errors during path construction
or validation does not cause a "security" problem, using a sufficiently
limited definition of security.  But the real security of a system
depends on (among other things) correct administration, and anything
which promotes sloppy administration promotes sloppy security.
I therefore disagree that applications should ignore the path
validation requirements of X.509:

  "a) Check that the signature verifies, that dates are valid, that
      the certificate subject and certificate issuer names chain
      correctly, and that the certificate has not been revoked."

This name chaining requirement wasn't inserted willy-nilly into RFC
2459, it has been a fundamental part of an International Standard for
twelve years. Saying "we don't like this requirement, so we are going
to ignore it" is undoubtedly an option for a company with the market
cap of MSFT.  But customers for whom standards conformance is a
checklist item should be fully informed that you have chosen not
to conform to either X.509 or RFC 2459.

Dave

> From: "Trevor Freeman" <[email-masked]>
> 
> Hi Denis, 
> found, use a certificate signed with the right key as a valid parent in
> that chain. This applies to intermediate as well as self signed
> certificates. We have seen customer scenarios where you need to
> deliberately build certificates which don't chain on names so enforcing
> name chaining would cause problems.

---

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 6 Jun 2000 20:00:24 -0700

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

 -----Original Message-----
From: 	David P. Kemp [mailto:[email-masked]] 
Sent:	Tuesday, June 06, 2000 11:20 AM
To:	[email-masked]
Subject:	RE: Correct approach to certificate validation?

Trevor,

Dave

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 7 Jun 2000 14:21:04 +1000

Trevor,
 
I don't think David was saying you can't go your own way. In fact, RFC 2459
has a funny statement in it where it recognises that vendors may produce
non-conforming products.
 
I think the point he is making is that customers should be made aware that
your product conforms neither to RFC 2459 nor to X.509. And I think you
agree that it doesn't.
 
Ron.
 
PS These are my views and not those of my employer.

-----Original Message-----
From: Trevor Freeman [mailto:[email-masked]]
Sent: Wednesday, 7 June 2000 13:00
To: David P. Kemp
Cc: [email-masked]
Subject: RE: Correct approach to certificate validation?

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

 -----Original Message-----
From:   David P. Kemp [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent:   Tuesday, June 06, 2000 11:20 AM
To:     [email-masked]
Subject:        RE: Correct approach to certificate validation?

Trevor,

Dave

---

From: Peter Williams <[email-masked]>
Date: Wed, 7 Jun 2000 13:45:25 -0700

David,

"But it is wrong in X.509 because X.509
certificates are identified by and stored under Distinguished Names,
not public keys or SubjectKeyIdentifiers."

X.509 does not require one to identify a storage
location for a cert at all, locate storage using a 
DN, nor does it require that the DN be used as the 
subject identity element bound to a key.

You should be aware, in further support of my
earlier statement, that PKIX certificates need contain no 
subject DN information. Nor need there be a DN name form populated
in the standard alternative name field for subjects,
as RFC 2459 authors and chairs declare to the Internet:

   "The subject alternative names extension allows additional identities
   to be bound to the subject of the certificate.  Defined options
   include an Internet electronic mail address, a DNS name, an IP
   address, and a uniform resource identifier (URI).  Other options
   exist, including completely local definitions [...]"

   "Further, if the only subject identity included in the certificate is
   an alternative name form (e.g., an electronic mail address), then the
   subject distinguished name MUST be empty (an empty sequence), and the
   subjectAltName extension MUST be present. If the subject field
   contains an empty sequence, the subjectAltName extension MUST be
   marked critical."

Do you assert that PKIX profile is not aligned
with X.509, when you make your various
claims concerning DNs?

Does a PKIX cert conform to X.509 literally
or in spirit, if the actual exampled option stated 
above in RFC 2459 is used?

PS.

The PKIX authors' name comparison rules already make
PKIX path processing non-conforming against
X.509 (i.e. the result of path processing
using the PKIX name chaining rule is not the same as
if one were to use the X.509 path
processing and name matching rule. X.509 conformance
is really not an issue in PKIX WG! 2459 already
built in the situation that even
two PKIX implementations may not process
paths the same! A cert chain can be
valid in one implementation, and invalid
in another; its not clear it the X.509
rules, though permitted by PKIX, make
for a conforming path processing implementation.

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Wednesday, June 07, 2000 7:00 AM
To: [email-masked]
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: "David P. Kemp" <[email-masked]>
Date: Wed, 7 Jun 2000 17:23:39 -0400 (EDT)

Peter,

Do you agree that:

1) path validation requirement "a" of X.509 requires name chaining?

2) if the subject of a certificate is a CA then the subject field
   MUST be populated with a non-empty distinguished name matching the
   contents of the issuer field in all certificates issued by the
   CA (RFC 2459 section 4.2.1.6)

3) A certificate may use a null DN iff the subject/issuer alternative
   name extension is flagged critical *and* for every name form used
   in the GeneralName type, there shall be a name registration system
   that ensures that any name used unambiguously identifies one entity
   to both certificate issuer and certificate users.
   (X.509 section 12.3.2.1)

Dave

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 07 Jun 2000 17:26:01 -0600

At this point I am mightily confused, and would appreciate it if someone 
would clarify the issue, as I apparently tuned in late.

Trevor says that they enforce name constraints, but that they don't support
name chaining.  I must be missing something important here -- how
do the two differ, and/or how is one possible without the other?

Are we talking about CA names only, end-entity names, or what?

Some concrete examples pro and con would be very helpful.

Regards,

Bob

>>> "Trevor Freeman" <[email-masked]> 06/06/00 08:42PM >>>
We use AKI, but don't require it, as the field can be calculated on the
fly so to speak.
I am not linking the enforcement of name constrains with the enforcement
of name chaining in any. We will enforce name constraints as this is a
security issue, we don't enforce name chaining. 
We trust the CA because we have built a chain of certificate to a
trusted root, with valid policy and name constraints.

 -----Original Message-----
From: 	Denis Pinkas [mailto:[email-masked]] 
Sent:	Tuesday, June 06, 2000 1:33 AM
To:	Trevor Freeman
Cc:	[email-masked]; [email-masked] 
Subject:	Re: Correct approach to certificate validation?

> Hi Denis,

Now there are two Denis on the list. Don't be confused, the one
above is not me ! :-)

It seems that we are starting a very interesting threat.

> We have found that enforcing name chaining in path construction,
> causes more problems than it solves. We therefore have reverted to
> using the name as just a hint, rather than a critical factor and
> will as you have found, use a certificate signed with the right
> key as a valid parent in that chain. 

To be more precise, do you mean that you are using the authority key
identifier extension ?

This extension provides a means of identifying the public key
corresponding to the private key used to sign a certificate. The
keyIdentifier field of the authorityKeyIdentifier extension MUST be
included in all certificates generated by conforming CAs to
facilitate chain building. 

If this is what you use, this means that you use a field that must
be present but does not need to be understood, since this extension
is marked NON critical. If your implementation relies on that field,
which options of that field are you using (since this is a sequence
of three optional fields) ? If I misunderstood what you are using,
please clarify.

> This applies to intermediate
> as well as self signed certificates. We have seen customer
> scenarios where you need to deliberately build certificates which
> don't chain on names so enforcing name chaining would cause
> problems.

It is true that enforcing name constraints within certificates
themselves provides limitations and causes problems. Enforcing name
chaining outside the certificates is much morer flexible ... and
should be recognized as a valid additional check in the
"son-of-RFC2459". 

> I know this is at odds with RFC2459, but as this behaviour does
> not in our view cause a security problem, but does make the
> overall process more robust, we have and will continue to opt for
> the more robust solution.

It seems to early at this stage to conclude that there are no
security problems with such an approach (there are not enough
information at this stage to make any conclusion). Just a remainder.
The basic principle is the following: it is not because a CA
certificate exists that it should be trusted. 

Denis
 
> I have also posted previously on the list that mandating name
> chaining, in addition to signatures and policy chaining is a bad
> idea.
> 
> Trevor
> 
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Sunday, June 04, 2000 11:19 AM
> To: [email-masked] 
> Subject: Correct approach to certificate validation?
>

---

From: "Trevor Freeman" <[email-masked]>
Date: Wed, 7 Jun 2000 16:00:16 -0700

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
 -----Original Message-----
From: 	David P. Kemp [mailto:[email-masked]] 
Sent:	Wednesday, June 07, 2000 7:00 AM
To:	[email-masked]
Subject:	RE: Correct approach to certificate validation?

Trevor,

attributes attached to keys.  But it is wrong in X.509 because X.509

Regards,
Dave

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 8 Jun 2000 11:34:52 -0400 (EDT)

Trevor,

> No standard or clause in a standard has a divine right of existence.

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.

---

From: Peter Williams <[email-masked]>
Date: Thu, 08 Jun 2000 14:47:27 -0700

Dave,

I agree that (1), (2) and (3) are true assertions. Perhaps you
could be as clear for me...for the PKIX profile of X.509:

Do you realize, and agree, that
the way NIST/NSA designers deliberately constructed
RFC 2459's name matching process (during
path validation of an intermediate or
EE certificate) is such that implementations
of the X.509 path processing algorithm produce a different
validity result to the PKIX algorithm.

To keep your schema, I would suggest that it is not enough to 
ask Q1.  In fact, one can be easily deceived by considering
only Q1. You  must ask the PKIX-specific version of Q1,
and then consider the ramifications on testable
X.509 conformance. (Q3 seems irrelevant.)

Q1 refers to the rule:

"10.5	Certificate processing
...

The following checks are applied to a certificate:
a)	Check that the signature verifies, that dates are valid, that 
the certificate subject and certificate issuer names chain correctly, and 
that the certificate has not been revoked."

PKIX Q1 refers to a particular definition of what
chaining names "correctly" is. And the 2459 definition 
of name matching in *PKIX-conforming* systems is not compatible 
with systems tested/certified to be conforming to the X509 standard, by 
specific intent of the NIST/NSA authors, evidently. 

As Trevor said, its all a big mess that requires practical
treatment, not religious dogma, in today's products
that are "based on RFC 2459". The list will no doubt
diverge here between the paper-architects and product
builders.

Why we cannot just implement X.509 name matching defeats me.

Peter.

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Wednesday, June 07, 2000 2:24 PM
To: [email-masked]
Subject: RE: Correct approach to certificate validation?

Peter,

Do you agree that:

Dave

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 9 Jun 2000 09:32:00 -0400 (EDT)

Peter,

No, I didn't realize that RFC 2459's name matching process is
a subset of X.509's.  What I read is:

  (a) Verify the basic certificate information, including:
       ...
      (4) the subject and issuer names chain correctly (that is,
          the issuer of this certificate was the subject of the
          previous certificate.)

Although I could understand the motivation for PKIX profiling a binary
match (identical RDN tags and values - much simpler to implement than
forming equivalence classes for all possible values of DirectoryString),
I don't see that PKIX has, in fact, required exact comparison.

From reading requirement (4), I would assume that "X.509 name matching"
is permitted by RFC 2459.

What I object to, and what I am assuming Trevor is referring to, are
name chaining failures that would be failures under even the most
liberal and complex string matching rules.

The extent to which applications handle equivalent but not identical
names is an implementation detail, best handled by the "be conservative
in what you generate" rule - CA's should create certificates with
binary-exact chaining, and applications should do as much string matching
as the developer feels is appropriate for the targeted certificate
profiles.

Dave

> From: Peter Williams <[email-masked]>
> To: "'David P. Kemp'" <[email-masked]>
> Cc: [email-masked]
> 
> Dave,
>

---

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 09 Jun 2000 09:26:30 -0600

Trevor, putting aside for a moment the issue of what the standard says, 
doesn't say, or ought to say, I'm still not sure that I understand the issue 
that you are raising.

I thought that when you said that you were using the issuer name in a 
subordinate certificate as a "hint" in finding the correct certificate issuer,
you might referring to some kind of fancy heuristic algorithm that would try
to divine where the next certificate up the chain might actually be found -- 
something I would very much like to see.

But if Al's example is a correct presentation of what you are saying,
then I don't understand how or why the CA created the certificate 
in that manner in the first place.

I have a reasonable fertile imagination, and so I can imagine situations
where the issuer name might not match, deliberately -- for example
a merger or company name change, where the CA certificate is reissued 
with the new name, but all of the end-user certs haven't been rolled over yet.
(Why the old certificate with the old name would have been left in place 
escapes me, however.)

I tend to agree with the rest of the community -- if this is just the result of 
sloppy programming of the CA implementation in not enforcing reasonable
behavior when the certificates were created, then this is indefensible.

However, if you have a real reason or justification, I'd like to hear it.

It does disturb me just a little to be over-constraining the chaining relationship.
If name subordination really matters, then a constraint ought to be expressed.

If name subordination doesn't matter, then I suppose I could question why 
the reverse chaining issue is important, assuming the path can still be constructed 
somehow.

One example that might be interesting to consider would be a bilingual country
such as Canada, where the CA's certificate might be in English, and yet
the end-user's certificate might be in French, including the French version of 
the issuer's name.

Other multilingual examples might include certificates where the CA's DN
is written in one character set, and for reasons of national pride, local laws, 
custom, or merely comprehensibility by the consumer, the subject and issuer 
name are written in a different character set.

Generally speaking, accepted standards ought to be followed, unless there are
good reasons not to (not including programming bugs)..  If there is such a good 
reason, the standards ought to be revised.

I'm trying to understand where there is in fact a good reason.

Bob

<<<Al Arsenault <[email-masked]> 06/08/00 08:31PM >>>
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.
> 
> Sent:   Thursday, June 08, 2000 8:35 AM
> To:     [email-masked]

---

From: Frank Balluffi <[email-masked]>
Date: Fri, 09 Jun 2000 14:21:15 -0700

Regarding a company changing its name, it is difficult for me to imagine a
scenario in which a company would need to change the subject in its
certificate but not need to change the issuer in the certificates that it
has issued.

Frank

> From: Jim Schaad [mailto:[email-masked]]
> Sent: Thursday, June 08, 2000 9:36 PM
> To: 'David P. Kemp'; [email-masked]
> 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
>

---

From: "Trevor Freeman" <[email-masked]>
Date: Sun, 11 Jun 2000 18:36:53 -0700

Al,
There are two players in this piece. CA and relying parties. THE only
point where the name chaining rule can be enforced reliably is when
building a self signed root certificate. 
It you are asserting that if by some change a set of certificate was
built where the names did not chain, and that clients who enforced the
name chaining rule would consider the chain invalid, whereas clients
which did not enforce the rule would consider the chain as valid, then I
agree. 
What I don't see is justification of the rule as being necessary.
Why is this rule considered necessary in the standard?
Trevor

 -----Original Message-----
From: 	Al Arsenault [mailto:[email-masked]] 
Sent:	Thursday, June 08, 2000 7:32 PM
To:	Trevor Freeman
Cc:	David P. Kemp; [email-masked]
Subject:	Re: Correct approach to certificate validation?

Trevor,

	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

	Now, whenever a cert path is validated using the new CA, it will
be

	That's the reason:  by building your system this way, you cause
the

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.