Hi Patrick,
sorry for the bad line-breaking, but I'm stuck here with a poor msa.
> -----Original Message-----
> From: Patrick Patterson
>
> On February 22, 2010 09:18:25 am Eisenacher, Patrick wrote:
> > > -----Original Message-----
> > > From: Patrick Patterson
> > >
> > > On 12/02/10 8:51 AM, skillz...@gmail.com wrote:
> > > > Is there a way (via the API rather than the tool) to tell
> > >
> > > OpenSSL that
> > >
> > > > the sub-CA certificate is trusted and it doesn't need to
> > >
> > > walk further
> > >
> > > > up the chain? For my case, I embed the sub-CA
> certificate in my code
> > > > and I'm space constrained so I'd prefer to not include
> the entire
> > > > certificate chain.
> > >
> > > According to RFC5280 this is not allowed (See section 6).
> > > Given that if
> > > the Root revokes the Sub-CA, the EE cert is invalid, you
> have to check
> > > the entire chain to ensure that all parts are still
> valid. As a rule,
> > > you can only use self-signed certificates as trust anchors.
> >
> > This is not true. You only have to do path validation up to
> your trust
> > anchor, whatever that is, be it a root-ca, an
> subordinate-ca or even an ee.
> > Only if you check for revocation you have to walk up the
> whole chain from
> > ee to root-ca.
> >
> According to RFC5280 (Section 6.1) - the following is the
> basic requirement
> for Path Validation:
>
> "The primary goal of path validation is to verify the binding between
> a subject distinguished name or a subject alternative name and
> subject public key, as represented in the target certificate, based
> on the public key of the trust anchor. In most cases, the target
> certificate will be an end entity certificate, but the target
> certificate may be a CA certificate as long as the subject
> public key
> is to be used for a purpose other than verifying the signature on a
> public key certificate. Verifying the binding between the name and
> subject public key requires obtaining a sequence of
> certificates that
> support that binding. The procedure performed to obtain this
> sequence of certificates is outside the scope of this
> specification.
>
> To meet this goal, the path validation process verifies, among other
> things, that a prospective certification path (a sequence of n
> certificates) satisfies the following conditions:
>
> (a) for all x in {1, ..., n-1}, the subject of certificate x is
> the issuer of certificate x+1;
>
> (b) certificate 1 is issued by the trust anchor;
>
> (c) certificate n is the certificate to be validated (i.e., the
> target certificate); and
>
> (d) for all x in {1, ..., n}, the certificate was valid at the
> time in question.
> "
>
> If you DON'T use a self signed trust anchor, then you have to
> have special
> processing instructions, and/or have a certificate store that
> is able to
> absolutely treat a certificate differently when it is part of
> a chain, or when
> it is a trust anchor (for, and the reason why most Root CA
> profiles don't have
> CRL DP or OCSP info in them, a trust anchor is NOT checked
> for validity - it
> is assumed by its continued presence as a Trust Anchor to be valid).
The section you quote says absolutely nothing about self signed trust anchors.
This seems to be your own interpretation. Where did you get it from? If you
scroll just a few paragraphs further up you will see that a trust anchor can be
any entitiy in your PKI:
"The selection of a trust anchor is a matter of policy: it could be
the top CA in a hierarchical PKI, the CA that issued the verifier's
own certificate(s), or any other CA in a network PKI."
And no, I don't need a separate truststore for subordinate-CAs. I have one
truststore into which I put those certs that I trust. I only have to build up
and verify a path up to a cert in my truststore. After all, a trust anchor is
just that: an anchor of trust. I don't need to verify further, when I trust
that entity.
Things get differently of course, if you do revocation checking, in which case
you always have to build up the whole path from ee to root-ca. But I stated
that before and we both agree on that.
> Yes, it is probably a limitation to OpenSSL that it doesn't
> really have a
> "Trust Anchor only" store, but if you take a look at most major
> implementations (US DoD, FBCA, CertiPath, SAFE, etc.) then
> they pretty much
> always use self signed "root" certs as the trust anchor.
openssl has a truststore. It just doesn't allow to trust subordinate-cas that I
intentionally put in there to be trusted. And that's what I consider a
limitation. And I don't understand what Eric's intention was when he originally
coded that algorithm. Of course, path construction and verification is a beast
to code and there are many pitfalls to fall into.
There are other sdks around that do not have this limitation. I worked for one
of their manufacturers long time ago.
> > Unfortunately, the perceived verification algorithm is a
> limitation in
> > openssl, which always wants to do path validation up to a
> self signed cert,
> > even if no revocation checking is requested. And no,
> there's no way to
> > modify its verification algorithm besides from changing the code.
> >
> > This also has consequences for applications using openssl
> for ssl support
> > like apache, where you can not easily configure to
> authenticate only those
> > clients presenting a cert that was issued by a specific
> subordinate-ca.
> >
> From a design point of view - why not use a self signed Root
> CA as the trust
> anchor, but policy or name constrain the sub CA, and then
> issue EE certs with
> the appropriate Policy or Name space? This accomplishes the
> same thing as what
> you want to do, is probably better PKI (why do you only trust
> that one CA -
> probably because of the policy it is issuing the certs
> under), and is fully
> supportable today.
Well, many roads lead to Rome :o) I can also explicitly check for the name of
the subordinate-ca and then rewrite that condition whenever the subordinate-ca
changes its dname... But all those quirks wouldn't be necessary if I was
allowed to trust whatever I want to trust. And usually, I as the end user, have
no influence on what extensions a ca puts into its issued certs. So suppose,
verisign has 2 subordinate-cas, one for securely registered ees, and one for
not so securely registered ees, both subordinate-cas have a common verisign
root-ca, and both have the same policy identifier or none at all in their
certs. How would I achieve my goal to only accept ees certified by the secure
registration ca? This should be a common scenario after all.
Checking for revocation is at the sole decision and risk of the verifying
entity. So is choosing a proper trust anchor. No ca's cps can enforce that and
I would be surprised if there is any around that tries to do so. Do you have
one at hand to show your point? I don't understand your reasoning about the
relationship of cps/ca-policy, path construction and revocation checking. The
first is defined by the ca, the latter two are defined by the verification
profile (eg. PKIX) and the application's needs.
Cheers,
Patrick Eisenacher
Besuchen Sie die Bundesdruckerei auf der CeBIT 2010 vom 2.-6.3.2010, Halle 9,
Stand D80
Visit Bundesdruckerei at CeBIT, exhibition centre, hall 9 / stand D80
weitere Informationen unter:
http://www.bundesdruckerei.de/de/unternehmen/untern_cebit2010/index.html
find more information here
http://www.bundesdruckerei.de/en/company/comp_cebit2010/index.html
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
