Subject: RE: Correct approach to certificate validation?

From: "Trevor Freeman" <[email-masked]>
Date: Thu, 8 Jun 2000 15:39:12 -0700

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:[email-masked]] 
Sent:	Thursday, June 08, 2000 8:35 AM
To:	[email-masked]
Subject:	RE: Correct approach to certificate validation?

Trevor,

> From: "Trevor Freeman" <[email-masked]>
> 
> 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.

---

From: Al Arsenault <[email-masked]>
Date: Thu, 08 Jun 2000 22:31:31 -0400

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:
> 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.
>

---

From: Ed Gerck <[email-masked]>
Date: Thu, 08 Jun 2000 20:03:36 -0700

List:

Why should we continue to confuse name validation with
certificate validation?  Name chaining should be optional IMO,
not expected behavior. 'Be liberal in what you expect' can be
applied here without  A N Y  decrease in cryptographic
authentication security.

Cheers,

Ed Gerck

---

From: Rich Salz <[email-masked]>
Date: Thu, 08 Jun 2000 23:10:42 -0400

Al,

You're saying that the current deployed base of CA's ensures that
the issuer DN of certs they issue is exactly the same as the subject
DN of its own signing cert?  If my understanding is correct, not
only do I strongly concur, but I don't know of any product that
works otherwise, in the course of normal operation/default config.
Does anyone know of a product that doesn't?

Even if there is one, it doesn't matter.  And if the standard is 20
years old, it doesn't matter (heck, TCP's older than that).

Generally speaking, "that's what everyone else does" is the kind
of argument that, in the IETF, generally trumps anything else.
Trevor, I thought you've been around long enough to know this.
	/r$

---

From: Oscar Jacobsson <[email-masked]>
Date: Fri, 09 Jun 2000 11:28:27 +0200

> applied here without  A N Y  decrease in cryptographic

My personal opinion, and humble one at that, is that the issue is of
greater importance than "simply" one of cryptographic security.

The principals of X.509, as has been previously stated in this thread,
are in the naming, and not in the cryptographic keys themselves.

The value of authentication, again IMHO, is in the degree of trust which
the Relying Party can hold as to the identity of the certificate subject
presented and not in the relative merits of the length and/or algorithm
employed for the cryptographic key.

My two crowns worth, anyway.

Cheers!

//oscar

---

From: Oscar Jacobsson <[email-masked]>
Date: Fri, 09 Jun 2000 14:12:42 +0200

> Ed Gerck wrote:
> > 'Be liberal in what you expect' can be

I wasn't particularly lucid in my earlier response, so feel I should
probably try again. A few nights' worth of heavy drinking works all but
wonders on one's faculties for reason.

Being liberal should certainly remain an option, since potential
customers will no doubt continue to insist that one's applications be
interoperable with broken, or non-conformant if you prefer that term,
Public Key Infrastructures and their components.

I feel that name constraints are a valuable tool for delegating trust to
external parties. Rather than my current behavior, which is to trust
whomever AOL tells me to trust, I would be much more comfortable using a
certificate issued by a local administrator here at Celo.

Such a certificate would, hopefully, hold more worth to the recipient
than merely the ability to send me encrypted e-mail, by virtue of being
issued by my employer, who should be able to vouch for my identity with
a reasonably high degree of certainty.

Rather than expecting all recipients to blindly trust the Celo-local
issuer for any and all extents, which I personally consider rather rude,
an rfc822Name constraint could be included in order to inform the
relying party that this issuer intends to issue certificates to Celo
employees exclusively, thus requiring far less blind faith from the
relying party.

To try to summarize:

Constraining one's intended certification is essential, since it will
allow for a much finer granularity in the delegation of trust than the
current model with it's childish boolean trusted/not trusted mechanism.

//oscar

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Jun 2000 09:48:17 -0400

Ed,
>applied here without  A N Y  decrease in cryptographic

Jon's protocol design advice is good in general, but inappropriate in 
security contexts, where liberal acceptance policies often lead to 
vulnerabilities.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Jun 2000 10:09:37 -0400

Oscar,

><snip>

Another way to state this is that use of name constraints allows one 
to recognize the authority of a CA for a portion of a name space, 
e.g., a company CA is responsible for issuing certs to employees, a 
university to faculty, staff and students, etc.  I prefer this 
phrasing because it emphasizes the difference between TTPs where one 
has to trust the CA, vs. various types of authoritative CAs, where 
the trust is implicit.

Steve

---

From: Paul Koning <[email-masked]>
Date: Fri, 9 Jun 2000 10:30:54 -0400 (EDT)

>>>>> "Trevor" == Trevor Freeman <[email-masked]> writes:

 Trevor> Life is complicated, but this is not so bad - Isaac Newton's
 Trevor> rules where around a lot longer before they were found to be
 Trevor> wrong.  I am still waiting to here further justification
 Trevor> (beyond the old ground of "its in the spec"). and so far you
 Trevor> are confirming my suspicions that there are none.

That's interesting.  It sounds to me like you're saying "Nothing in
any standard matters unless someone can come up with a specific
justification for each and every rule I've chosen to ignore".

That's comical.

In standardization, it often occurs that there are several
incompatible ways of doing something, and one has to be chosen.  And
it may well be that several of the alternatives are equally valid
technically.  In that case, when one is picked, you have to use that
one to interoperate, and the only justification for that one rather
than one of the alternatives is indeed "it's in the spec".

So are you now claiming that such a standards process is not
acceptable?  Bizarre.

Incidentally, your statement about Newton is incorrect, too.

      paul

---

From: Oscar Jacobsson <[email-masked]>
Date: Fri, 09 Jun 2000 16:44:41 +0200

Stephen Kent wrote:
> I prefer this phrasing because it emphasizes the difference between TTPs where one has to trust the CA, vs. various types of authoritative CAs, where the trust is implicit.

A very good point.

Besides, the notion of "authoritative CA" becomes a bit vague without
some in-band method of communicating precisely what said CA claims to be
an authority on.

//oscar

---

From: Oscar Jacobsson <[email-masked]>
Date: Fri, 09 Jun 2000 17:24:05 +0200

> some in-band method of communicating precisely what said CA claims to be

Oh dear.

I'm still not entirely lucid, I guess. What I was referring to, which
might not have been perfectly obvious, was the role of naming
constraints in defining exactly which Authority a given CA is claiming.

//oscar

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Jun 2000 11:36:43 -0400

Oscar,

>constraints in defining exactly which Authority a given CA is claiming.

Actually, the "local" CA issues a cross cert to the "foreign" CA, and 
thus the local CA asserts in the name constraints extension the part 
of the portion of the name space for which it considers the foreign 
CA to be authoritative.  So, the foreign CA does not make the claim 
in terms of the name constraints.  But you are right in asserting 
that some OOB mechanism is used by the local CA to decide what set of 
name constraints are appropriate re the foreign CA.

Steve

---

From: Oscar Jacobsson <[email-masked]>
Date: Fri, 09 Jun 2000 18:03:24 +0200

> name constraints are appropriate re the foreign CA.

Naming constraints in cross-certificates hadn't even begun to occur to
me. I seem to have missed the actual point. Again. :-(

My reasoning was along the line that it would not only be polite of a
Certification Authority to clearly define the limits of its intended
certification, both generally as in its Certification Practise Statement
and specifically as in its naming constraints, but would also, IMHO,
make the decision of the relying party to trust that CA less "critical".

I can't really see the current on/off trust mechanisms usually employed
as one that even attempts to approximate reality. There are completely
different levels of trust involved between, as an example, allowing
somone to fix your car and allowing someone to baby-sit (sp?) your
children. Even if the level of trust were the same, the level of
authority would differ. One would not necessarily expect one person to
be suitable to perform both roles, trusted or not.

Note to self: or am I just not a very trusting person?

//oscar

---

From: Ed Gerck <[email-masked]>
Date: Fri, 09 Jun 2000 09:36:44 -0700

> are in the naming, and not in the cryptographic keys themselves.

But X.509 is moot on how to verify such names [1,2], which task it delegates
to the CA (and NA).  The ONLY verification procedure that X.509
specifies [2] is on the subject's key pair by requiring nonce authentication
-- the subject must prove possession of the private-key.

So, in X.509 (and PKIX) what we have are *two* pieces of data with
different validity levels:

1. the public-key was positively verified
2. the name was hearsay.

So, now the name should trump the key? The tail wants to wag the
dog, we may as well say.

Of course, I agree that an additional function COULD provide for
name validation according to chaining rules but satisfying such
a function should be optional, not expected.

Cheers,

Ed Gerck

[1] Section 11.2 of X.509v3, "Management of certificates", states that the
certificate allows an association between a name called "unique distinguished
name" or DN for the user and the user's public-key: "A  certificate  associates
the public key and unique distinguished name of the user it describes.", while
Section 7 explains that such DNs are essential to the security design of X.509:
"Authentication relies on each user possessing a unique distinguished name."
But, how are such DNs assigned? Where are they unique? The DN is denoted
by a NA (Naming Authority) and accepted by a CA (Certification Authority) as
unique within the CA's domain, where the CA can double as a NA. HOWEVER,
note that the same user can have different DNs in different CAs, or can use
the same DN in different CAs even if it is not the first one to use it in a CA --
so that different DNs for different CAs do not necessarily mean different users and
vice-versa. Further, a DN does not have to contain the user's real-world name or
location. Thus, semantically, the CA certificate refers to a name; however it does
not denote it.

[2] X.509 is moot on validation procedures for data included in a certificate such as
the user's name, with the exception of validation procedures for the user's public-key
which are suggested (not mandated) in Section 10 of X.509v3. For example, regarding
validation procedures for the user's identity, Section 11.2.a states that: "a certification
authority shall be satisfied of the identity of a user before creating a certificate for it",
which means that identity validation procedures are to be satisfied in the CA's frame of
reference by  following the CA's own self-defined rules (CPS), which are declared outside
the scope of X.509 and can be entirely different for different CAs.

---

From: Ed Gerck <[email-masked]>
Date: Fri, 09 Jun 2000 09:54:30 -0700

> security contexts, where liberal acceptance policies often lead to

In this case, however, I see no vulnerability in what X.509/PKIX
intend to provide -- a cryptographic authentication protocol.  In
regard to name assignment vulnerabilities, I note that this is also
declared out of scope in X.509/PKIX  and delegated to the CA/NA
+ CPS.

So, why should that which is declared out of scope trump that
which is the only thing that the protocol verifies?  Logic would
indicate that since name validation by name chaining verification
is a weaker concept than the one it is blocking, then this should
not be mandatory behavior.  Making it mandatory is what is
confusing, IMO.

Cheers,

Ed Gerck

---

From: "Martin Szotkowski" <[email-masked]>
Date: Fri, 9 Jun 2000 19:00:10 +0200

In draft is written that TSA cert must be used exclusively for time stamp.
Why TSA certificate cann't be same as CA certificate?

thanks Martin

---

From: Oscar Jacobsson <[email-masked]>
Date: Fri, 09 Jun 2000 20:06:02 +0200

> So, now the name should trump the key? The tail wants to wag the

Neither name nor key would amount to much on their own, IMHO.

I agree that there is a great deal of ambiguity regarding how
certificate subjects are named. Naming conventions are decided on a
per-issuer basis, IIRC, which has confused quite a few of my countrymen,
being used to having access to a government-issued personal
identification number.

However: if constraints are placed on subject names, they are most
probably placed there for a reason. Ignoring said constraints, having
been deemed important enough to distribute signed and in-band, could
surely hardly be considered prudent?

//oscar

---

From: Ed Gerck <[email-masked]>
Date: Fri, 09 Jun 2000 14:05:04 -0700

> surely hardly be considered prudent?

A checkbox with "Enforce name chaining" could take care of all cases
where name chaining is desired, much in the same way that the depth
of certificate signing can also be chosen by the user in Apache SSL for
example (or, do you really must trust a CA you don't trust just because it
chains with a CA you  trust?  -- maybe, possibly not).

Making name chaining mandatory, OTOH, still does not mean that
the name is: (i) correct, (ii) valid, (iii) legal, (iv) unique, etc.  So,
if constraints are placed on names this is still much weaker than the
nonce authentication constraints placed on keys -- where a principal
must have had use of the private-key in order to sign a nonce.  They
are like apples and speedboats, names and keys.  Why then should we
not differentiate between name validation and certificate validation?
Cert validation may include name validation but not necessarily and
there is no cryptographic value to be gained thereby.

Of course, some years ago everything was quite undifferentiated and
there was no distinction between different functions which we now
perceive as distinct. For example, the CA and the NA roles -- as well as
the CA and the TTP roles.

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Mon, 12 Jun 2000 16:17:56 -0400

Ed,

>declared out of scope in X.509/PKIX  and delegated to the CA/NA

My observation about the applicability of Jon's admonition to 
security protocols in general is true.  So far we don't have a killer 
example of a new vulnerability created by this deviation from the 
standards, just user confusion.
Someone suggested to me that if a user is examining the CA names in a 
path to make a trust judgement, then this inconsistency might cause 
the user to make a wrong trust decision.  I don't know if this is 
critical, because I doubt that many users would be so diligent, but 
it is an example of what might happen.  You state that our standards 
do not address name assignment vulnerabilities; we'll PKIX is trying 
to do this to some extent. There was already some text about a CA's 
responsibility to verify name data in  a cert, although that must be 
qualified by the CPS/policy.  As others have pointed out, there is a 
fine line here.  We don't want to usurp the CA's options here, yet we 
want to make a general statement about what an RP can expect in a 
cert.

>not be mandatory behavior.  Making it mandatory is what is

We disagree on fundamentals here.  Name verification in the context 
of chaining is what one would expect from reading ANY description of 
X.509 certificates for over a decade and a half.  There should be a 
very good reason to NOT do it before such a deviation from the 
standards is considered reasonable.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 12 Jun 2000 17:44:58 -0400

Ed,

>chains with a CA you  trust?  -- maybe, possibly not).

Based on this approach we could make all aspects of cert processing 
user selectable options.  But, that's not what we have done. We have 
divided processing rules into those that are uniformly enforced (in 
principle), those under CA control, and those under user control. 
Given the difficulty of getting local configuration info right, it's 
preferable to minimize this last set.

>there is no cryptographic value to be gained thereby.

Nonce?  What syntax are you referring to?  Ed, we've all had the 
pleasure of your efforts to redefine X.509 on an ab initio basis. 
Please spare us a repeat of such efforts again.

>the CA and the TTP roles.

the concept of a naming authority (vs. a CA or a directory service 
provider) have been recognized in the directory community that begat 
X.509, probably for about 15 years.  But, some of the names spaces we 
use, including DNs, don't have  universally recognized NAs, so the 
concept is not universally applicable.  CAs vs. TTPs?  I still think 
that a TTP is just one form of CA, so what's the issue here?

Steve

---

From: Ed Gerck <[email-masked]>
Date: Mon, 12 Jun 2000 17:58:20 -0700

Stephen Kent wrote:

> user selectable options.

No, this is not what I say -- this would be using my words to an extreme
limit where they are obviously false and never intended  to apply, with the
intent to "prove them wrong."  However, anything is wrong if taken out of
context. If we stay with the case at hand and don' try to outwit the
argument by such tricks, then we could recognize that there are cases
where a "one size fits all" does not apply.  Name chaining is, I suggest,
one such case.

Again, this does NOT mean that ALL cases are like it.  The name PKIX,
for example, should not be optional ;-)

> Please spare us a repeat of such efforts again.

I recall much of my efforts have been in the direction of avoding that some,
including oftentimes you, would needlessly redefine X.509. For example, as I
showed in my analysis of "non-repudiation" as it occurs in the X.509 text itself,
in contrast to what was being defined in PKIX.

Now, if that discussion left some sour tones as I see between the lines in your
text above, please recall that this is an open group based on consensus and that
there are no "winners" or "losers" here -- except our loss of time to go back to that
which is already closed. Unless, of course, you think that there was something in
your arguments then which were not clearly understood by this WG.

Regarding the term "nonce" --  in cryptography, "nonce" is a value used no more
than once for the same purpose.  In X.509, you will find it under the designation
"a non-repeating number" when "strong authentication" is defined.  To avoid
confusion and nitpicking, this what I said above:

 ...if constraints are placed on names this is still much weaker than the
 strong authentication constraints placed on keys -- where a principal
 must have had use of the private-key in order to sign the non-repeating
 number.  They are like apples and speedboats, names and keys.  Why then
 should we not differentiate between name validation and certificate validation?
 Cert validation may include name validation but not necessarily and there is no
 cryptographic value to be gained thereby.

> that a TTP is just one form of CA, so what's the issue here?

As you have shown with your own words, some issues do have more than
one universally recognized answer. Thus, where there is no bad security
consequence the standard must recognize them.

Cheers,

Ed Gerck

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 13 Jun 2000 17:14:40 +0200

Martin,

I guess that they are several arguments for that. Let me give one.

This allows you to build a black box, to place the TSA private key
in it and then to close the box, only making sure that the clock
inside is still synchronized with UTC (with respect to the accuracy
that is guaranted by the TSA). If not, the box shall stop working.
The private key will not be used for signing anything else which
would require a management interface. If the implementation is poor,
this  management interface could possibly be used to sign, e.g. a
wrong token. :-(

Denis

---

From: Paul Koning <[email-masked]>
Date: Tue, 13 Jun 2000 11:24:04 -0400 (EDT)

>>>>> "Denis" == Denis Pinkas <[email-masked]> writes:

 Denis> Martin,

 Denis> I guess that they are several arguments for that. Let me give
 Denis> one.

 Denis> This allows you to build a black box, to place the TSA private
 Denis> key in it and then to close the box, only making sure that the
 Denis> clock inside is still synchronized with UTC (with respect to
 Denis> the accuracy that is guaranted by the TSA). If not, the box
 Denis> shall stop working.  The private key will not be used for
 Denis> signing anything else which would require a management
 Denis> interface. If the implementation is poor, this management
 Denis> interface could possibly be used to sign, e.g. a wrong
 Denis> token. :-(
 
 >> In draft is written that TSA cert must be used exclusively for
 >> time stamp.  Why TSA certificate cann't be same as CA certificate?

If the intent is that the *key* should not be used for other purposes,
it should say that -- restricting the cert doesn't necessarily
constrain the use of the key.

	  paul

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 13 Jun 2000 17:39:28 +0200

Paul,

Please, before answering, take a look at the document:

     10. to sign each time stamp token using a key generated 
         exclusively for this purpose and have this property of the 
         key indicated on the corresponding certificate.

Denis