Subject: [pkix] Certification path

From: "Erik Andersen" <[email-masked]>
Date: Thu, 14 Jul 2011 12:27:51 +0200

Does a certification path go from the end-entity to the trust anchor or does
it go from the trust anchor to the end-entity? What is forward and what is
reverse?

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: [email-masked]

Skype: andersen-erik

http://www.x500.eu/

http://www.x500standard.com/

 <http://dk.linkedin.com/in/andersenerik>
http://dk.linkedin.com/in/andersenerik

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 14 Jul 2011 22:39:51 +1200

"Erik Andersen" <[email-masked]> writes:

>it go from the trust anchor to the end-entity? 

Meant as a tongue-in-cheek comment: You really do like to ask the minefield
questions don't you?  This is a bit like asking whether we should be praying
to Allah, Jehovah, or the Christian God.  What's next, "what does the term
nonrepudiation signify"?

Peter.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 14 Jul 2011 06:50:05 -0400

> Does a certification path go from the end-entity to the trust anchor or
>does it go from the trust anchor to the end-entity? What is forward and
>what is reverse?

See RFC 4158, Section 1.3, Terminology:
http://tools.ietf.org/html/rfc4158.html#section-1.3.

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 14 Jul 2011 13:49:21 +0200

I would pray to the definite, absolute universal trust anchor, if we can
identify it.

Besides that, I like precise definitions, not wishy-washy ones subject to
interpretation.

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: Peter Gutmann [mailto:[email-masked]] 
Sendt: 14. juli 2011 12:40
Til: [email-masked]; [email-masked]
Emne: Re: [pkix] Certification path

>Does a certification path go from the end-entity to the trust anchor or
does

Peter.

---

From: Bruce Stephens <[email-masked]>
Date: Thu, 14 Jul 2011 12:55:54 +0100

> http://tools.ietf.org/html/rfc4158.html#section-1.3.

So a certification path is an ordered list of certificates starting from
one signed by a trust anchor to the end entity itself.  And building in
the forward direction is building the path starting with the end entity
(i.e., building it backwards).

And X.509 (2005) offers three data types for representing certification
paths, only one of which (PkiPath) is a SEQUENCE OF Certificate.  (I
don't find the other two to have entirely clear meaning; in particular
Certificates seems non-obvious as a representation for a certification
path.)

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 15 Jul 2011 00:07:40 +1200

>Besides that, I like precise definitions, not wishy-washy ones subject to

In PKI?  It's nothing *but* wishy-washy definitions.  Try getting any group of
more than about two people to agree on what "recognise an extension" means, or
what nonrepudiation means, or what a signature indicates, or what's meant by
"trust", or what anything with the word "policy" in it really means...

Peter.

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 14 Jul 2011 14:20:32 +0200

At least there seems to be agreement on what a certification path is and
what is forward and what is reverse. That is propress.

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: Peter Gutmann [mailto:[email-masked]] 
Sendt: 14. juli 2011 14:08
Til: [email-masked]; [email-masked]
Emne: Re: [pkix] Certification path

>Besides that, I like precise definitions, not wishy-washy ones subject to

In PKI?  It's nothing *but* wishy-washy definitions.  Try getting any group
of
more than about two people to agree on what "recognise an extension" means,
or
what nonrepudiation means, or what a signature indicates, or what's meant by
"trust", or what anything with the word "policy" in it really means...

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 14 Jul 2011 09:52:32 -0400

At 12:27 PM +0200 7/14/11, Erik Andersen wrote:
>Content-Type: multipart/alternative;
>	boundary="----=_NextPart_000_0041_01CC4221.77540210"
>Content-Language: da
>
>Does a certification path go from the end-entity to the trust anchor 
>or does it go from the trust anchor to the end-entity? What is 
>forward and what is reverse?
>

paths generally are built bottom up, always verified top down. So, in 
part, it's a question  of which activity one is performing.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Jul 2011 08:12:58 -0700

> what is forward and what is reverse. That is propress.

You sound like an optimist. Note the definition that was posted:
   Certification Path:  An ordered list of certificates starting with a
      certificate signed by a trust anchor and ending with the target
      certificate.
In fact, many people assume that the certification path includes the trust anchor. Thus, Peter's skepticism is warranted, even in this case.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Thu, 14 Jul 2011 19:14:21 +0200 (MEST)

> In fact, many people assume that the certification path includes the
> trust anchor. Thus, Peter's skepticism is warranted, even in this case.

But including the trust anchor in the certification path is extremely
reasonable, and it is the X.something specs that are seriously flawed
in this detail.

(actually, only X509PKIPathv1 suffers from this brain damage, there are
 no restrictions in PKCS#7 precluding the presence of a trust anchor
 certificate in this unsorted bag of certificates).

Personally, I find it extremely reasonable and useful that Microsoft's
Certificate Export Wizard will include the trust anchor certificate when
you ask it to export a certificate as PKCS#7 and checkmark the option
"Include all certificates in the certification path if possible"

In contrast to that, PKCS#7 chains available from some commercial CAs
are often usability-impaired, because they lack the trust anchor
certificate.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Jul 2011 10:48:59 -0700

> reasonable, and it is the X.something specs that are seriously flawed

What if the trust anchor is not a certificate? (Cue the TAMP music....)

If you want a certification path to only include certificates, you cannot say that it must include the trust anchor. 

If you want to allow a certification path to optionally include a trust anchor certificate, you probably need some magic marking to say that the initial certificate is a trust anchor, not something that is chained to a trust anchor.

The current definition is simpler than either of those, at the cost of not including any definitive indication of the trust anchor. (And before anyone says "the trust anchor is obviously the thing that signed the first certificate!", that's not always true. It could also be a policy that has nothing to do the actual signer, for example "the entity that has at various times been represented by these four different signing keys".)

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Thu, 14 Jul 2011 21:07:57 +0200 (MEST)

Paul Hoffman wrote:
> If you want a certification path to only include certificates,
> you cannot say that it must include the trust anchor. 

In theory, you are quite right.

There exists a whole lot of wild fantasy about non-X.509 TrustAnchors
(and their management) that creates a shitload of needless complexity.

But there seems to (quite reasonably) exist PKI software, where you
must supply all trust anchors as X.509 certs, and the most common
occurance of TAs are self-signed X.509 certs.

As in "In god we trust, all others must submit an X.509 certificate."

> 
> If you want to allow a certification path to optionally include a trust
> anchor certificate, you probably need some magic marking to say that the
> initial certificate is a trust anchor, not something that is chained
> to a trust anchor.

Nope, that is irrelevant.  "Trust Anchor" status is a purely individual
perception.  A receipient of a multi-certificate certification path
may have declared an arbitrary certificate from that path as trust anchor,
so reasonably dealing with the situation is always unavoidable.

Certifications paths should always be composed to end (looking forward)
with a self-signed certificate (or start with a self-signed certificate
if using formats like X509PKIPathv1).  Making assumptions about whether
and which of the certificates in the path are a trust anchor for the RP,
is IMHO inappropriate.

> 
> The current definition is simpler than either of those, at the cost
> of not including any definitive indication of the trust anchor.

Things would be simple if TrustAnchors had been defined
as "X.509 certificate PLUS something", so that adding a TA cert
(or prepending it for the Bigendian X509PKIPathv1) to a certification
path would be easy and straightforward.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Jul 2011 12:14:55 -0700

> (and their management) that creates a shitload of needless complexity.

There are plenty of deployed examples of it as well.

> occurance of TAs are self-signed X.509 certs.

If you want to define certification paths as only existing for paths where the trust anchor is a certificate, that certainly works for the common case. The definition we have today does not have that restriction

A new definition might add such a restriction. Such a new definition might then also create a second definition for something like "non-originated certification path" that could accommodate folks who use non-certificate TAs.

--Paul Hoffman

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 15 Jul 2011 12:16:27 +0200

Not including the trust anchor in the certification path implies that trust
anchor information, e.g., validity, is not checked. 

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: Paul Hoffman [mailto:[email-masked]] 
Sendt: 14. juli 2011 17:13
Til: Erik Andersen
Cc: [email-masked]
Emne: Re: [pkix] Certification path

You sound like an optimist. Note the definition that was posted:
   Certification Path:  An ordered list of certificates starting with a
      certificate signed by a trust anchor and ending with the target
      certificate.
In fact, many people assume that the certification path includes the trust
anchor. Thus, Peter's skepticism is warranted, even in this case.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Sat, 16 Jul 2011 10:06:55 -0400

>reasonable, and it is the X.something specs that are seriously flawed

I'm in favor of having the checks that we apply to certs along a path,
be applied to the cert immediately below the TA, which would include applying
name constraints, policy constraints, etc.  However, that is not the 
same as transmitting a TA as part of a path. Because a TA has to be 
verified OOB, it makes less sense to include it in a transmitted 
path.  The first cert (below
the TA) contains enough info to select a TA from among a set that an 
RP holds, i.e., the Issuer name and the AKI.

also, as Paul noted, we do not mandate that a TA be a self-signed cert. So,
it's not clear what set of formats one would have to support to 
enable including
a TA in a cert path. If I have a TA in some non-cert form, I cannot create a
self-signed cert for it, so ...

Steve

---

From: Stephen Kent <[email-masked]>
Date: Sun, 17 Jul 2011 11:16:38 -0400

>occurance of TAs are self-signed X.509 certs.

Yes, there is a ,lot of software that requires a TA to be supplied
as an SS cert. Much of that software is also non-complaint with X.509
and 3280/56280. The fact that many folks believe that every TA MUST be
provided as an SS cert is an illustration of widespread ignorance (re 
these standards), not a motivation to change standards :-).

Steve

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 18 Jul 2011 15:27:06 -0400

WARNING: contains banned part

Subject: RE: [pkix] Certification path
From: "Kemp, David P." <[email-masked]>
To: "PKIX" <[email-masked]>
Date: Mon, 18 Jul 2011 15:27:06 -0400

Does Interstate 95 go from north to south, or from south to north?  It
hardly matters whether one starts paving in Miami FL or in Houlton ME,
or start at both ends and meet in the middle - the end result after
construction is done is a path.

This sounds less like a minefield question (c.f. non-repudiation) and
more like a meaningless question.

Even for validation, RFC 5280 says:

   This section describes an algorithm for validating certification
   paths.  Conforming implementations of this specification are not
   required to implement this algorithm, but MUST provide functionality
   equivalent to the external behavior resulting from this procedure.
   Any algorithm may be used by a particular implementation so long as
   it derives the correct result.

Whoever decided to flip a coin and assign Forward and Reverse to a
particular direction along a cert path did PKI a great disservice, about
as silly as labeling the northbound lanes of I-95 as forward and
southbound as reverse.  But now that the coin has landed, the standard
PKI assignment of forward is rootward, and reverse is leafward:

   Building in the Forward direction: The process of building a
      certification path from the target certificate to a trust anchor.
      'Forward' is the former name of the crossCertificatePair element
      'issuedToThisCA'.

Dave

-----Original Message-----
From: Stephen Kent

---

From: Martin Rex <[email-masked]>
Date: Mon, 18 Jul 2011 22:09:35 +0200 (MEST)

Stephen Kent wrote:
> Martin Rex wrote:

rfc3280 and rfc5280 are documents with probably the highest number
of questionable bells-and-whistles in the RFC series.  But both documents
are at "Proposed Standard" level, meaning that they can be expected to
overdo in what the recommend and require, and that exploring less
is perfectly sufficient and reasonable, so that during eventual progression
of these document on the maturity ladder, many of the current recommendations
and requirements will have to be cut down to more reasonable levels,
bringing the complexity of the technology down to useful levels.

The purpose of IETF standards should be about what is generally useful,
and not be focusing as much on what is desired by some small niches,
but completely irrelevant for >90% of the consumers of the technology.

Wrapping keys and relevant attributes of TAs into X.509 certificates
is a trivial no-brainer for the creator of the keying material.
And it would be perfectly reasonable for the IETF to require
TAs to be created as "X.509 plus X" as mandatory for interoperability.

As mentioned, a lot of PKI software requires you to supply TAs as
X.509 certs for performing X.509 certificate path validation.
And for interop, mandating TAs to be distributed as X.509 certs
make a whole lot of sense and simplifies a lot of things.
It fits into PKCS#7 and PKCS#12 nicely, works with the TLS certificate_list,
could even be used with the X509PKIPathv1 data type, where none of
the non-X.509 certs fits.

-Martin

---

From: Carl Wallace <[email-masked]>
Date: Mon, 18 Jul 2011 16:48:01 -0400

><snip>

You have used the term "X.509 plus X" a couple of times now.  What do you
mean and how does it differ from RFC 5914, which permits X.509, X.509
minus signature and X.509 plus X (where X is TrustAnchorInfo) to represent
a trust anchor?

>the non-X.509 certs fits.

It's fine to carry TAs in these containers as long as you don't use them
from there without some additional checks.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Jul 2011 17:11:49 -0400

Martin,

Thansk for your input.  5280 has been ready to progress from proposed 
to draft, except for a couple of obscure issues that are not related 
to any of the topics you cited.

It's not that a self-signed cert is a bad format for a TA, it's that 
it is not the only good format, and thus will not be mandated as THE 
format. We have other PKIX RFCs that address this issue.

Steve

---

From: Martin Rex <[email-masked]>
Date: Wed, 20 Jul 2011 02:07:43 +0200 (MEST)

Stephen Kent wrote:
> 
> Thanks for your input.  5280 has been ready to progress from proposed 

There are few things in rfc5280 that IMO need fixing, even
when not ripping out and not downgrading requirements.

> format. We have other PKIX RFCs that address this issue.

I think that there should be a mandatory to support TA format for PKIX,
and that should be X.509.  Support for attributes beyond X.509 are
just fine being optional.  I definitely see that as a prerequisite
for going to Draft Standard.

SSLv3 (defined by Netscape) did not have any mandatory cipher suites.  

TLSv1.0 did have one single mandatory cipher suite (but a very bad
choice for crypto-policital-reasons that did not match the installed
base at all).  TLSv1.1 fixed that to mandate the best ciphersuite
defined by SSLv3 (and what everyone had implemented).

Not mandating one particular solution is fine when you're still
at proposed, the technology is young and you have no idea about
which format will succeed in the marketplace.

PKIX is 10+ years down the road, so when going to Draft Standard,
there really ought to be a requirement for a mandatory TA format.
The marketplace has long decided that the common denominator is X.509.

The only reason that there ever was "less than X.509" is expensive
small-storage hardware tokens 15+ years ago, where dropping the
signature of a certificate did help slightly.  That is no longer
a valid excuse, just as the "size of an IPv4+IPv6 dual-stack
vs. IPv4-only" should no longer be a valid excuse for not
supporting IPv6 today.

-Martin

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 20 Jul 2011 02:02:46 -0700 (Pacific Daylight Time)

> when not ripping out and not downgrading requirements.

Such as "permitted subtrees" being limited to CA certificates.

What exactly is the CA:false flag?  What's its precise semantic?  It appears to say is only that the certifier does not trust the holder of that certified key to operate as an authoritative certifier within its own business domain  That is, the CA doesn't trust the person for anything at all other than responsibly managing its own private key.

The way the MUST (RFC5280: 4.2.1.10, “The name constraints extension, which MUST be used only in a CA certificate[...]”) is structured, it cannot be used to bind a public key to authority to use and issue certificates in its own domains.  It makes no sense that the holder of the certified key has no autonomy; otherwise, there'd be no need for the certificate.  It is poor policy encoded into a technical standard which is actively harming useful application.

[ more on this after signature ]

As for those who bemoan the lack of trusted storage: we'll never have it until we actually have a reason to keep things secure.

> and that should be X.509.

There are additional ways that trust anchors can be encoded, such as OpenPGP.  I'm also wary of MUST-encoding policies into technical standards, as I suggest above.

You can't know what the next generation of protocol improvements is going to entail, and after 3 or 4 iterations still being required to support the legacy X.509 format when there were alternative, preferable ways of encoding the same information in common use.  (also, there's the concept of "how much and for what do we have to trust the CA?"  I think it's 'authoritative identity'.)

-Kyle H

[ continued from above ]

The only thing that is really necessary is that the authoritatively-held identities (the claims to state-held identities, such as "legal name" and "citizenship" and "domain names") are correctly asserted by someone the root has delegated permission to operate as part of its trust hierarchy.  Browsers have infinitely more processing power than was ever contemplated could exist in the civilian world (once-export-controlled supercomputers in every desk and briefcase, much less in every server), and we know that people refuse to use their keys as simple, universal police-state devices.

Once end-entities start getting that particular happens, the EV certificate that every large corporation currently has can have its key removed from the webserver, and it can authorize its own machines with useful and correct key management systems (such as "5-minute validity certificates with regular rekeying") finally put in place.  The person is correctly identified (as it chains down from the identity cert), and it can be restricted to only permitting operations under a given set of domains.  This prevents forgery, and doesn't require us to be wary of issuing unrestricted CA certificates to corporations.

Also, corporations have an interest in reducing the exposure of their employees from harassment.  This suggests that they should be able to issue their own certificates -- not as "trusted to provide authoritative information", but as "trusted to be able to perform internal governance and prevent certificates from being issued to non-affiliated entities".  The corporation knows who and what it issued the certificate to (it keeps logs), and it can maintain that key with the security traditionally afforded the corporate seal -- or not, as its needs dictate.  The key and certificate are assets of the company, and the company will take reasonable efforts to protect its identity -- certainly more-reasonable than "an EV key on every webserver with long-term certificates", which is what currently exists.

In addition, we know that application vendors and CAs will move to counter identified security issues.  As evidence, we have the EV certificate: created as a way to strongly identify particular high-volume sites, to prevent DNS hijacking attacks from being used with a corrupt CA to steal large numbers of transactions.  This specification was created by the "CA/Browser Forum", which specified what the CA had to do and what standards it had to meet to be given green-bar treatment by the browsers.

We've been assuming that the user can never be taught to take good control of his identity, much less his privacy.  I'm convinced that the user never will until he has good tools to do so.

Please, can we get rid of the MUSTs which prevent things from being used differently than they currently are?