On February 22, 2010 09:18:25 am Eisenacher, Patrick wrote:
> > -----Original Message-----
> > From: Patrick Patterson
> >
> > On 12/02/10 8:51 AM, [email protected] 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).
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.
> 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.
as an example:
Root CA --- SubCA1 (Policy 1.2.3.4, - EE (Policy 1.2.3.4)
| Namespace email = foo.com) (email
[email protected])
\
\ -- SubCA2 (Policy 2.3.4.5, - EE (policy 2.3.4.5)
Namespace bar.com) (email
[email protected])
Then, you could configure Apache to accept the Root CA, and, either using your
application on that server, or some tool (like Pathfinder), to constrain on
Policy.
To do otherwise is probably against the Relying Party provisions of the PKI
provider policy (who, at the end of the day, is the one who says which of its
certificates can be used as a Trust Anchor) - most policies that I know of
basically say that if the PKI has revoked any certificate in that PKI, and the
Relying Party doesn't check for that, then any use of the certs is at the
RP's own risk.
Which means that if an RP says that they only want to trust certs coming from
a particular Subordinate CA in a given PKI, and that PKI publishes revocation
information for that CA (they only handle out-of-band trust anchor management
for their Roots), then it is at the RP's own risk, if they do NOT check for
the revocation of that SubCA. It's probably to stop people from shooting
themselves in the foot in this way that the OpenSSL folks DON'T have special
handling rules for SubCA revocation checking.
Now, if TAMP ever makes it to a full standard at the IETF, then there may have
to be some re-thinking of this, but for now, for, I would say, a good portion
of PKIs in place and deployed, the policies of those PKIs frown upon an RP
making a trust decision using only a SubCA.
If you know of any policy that is currently operational that DOES allow this
(Trust Anchor on a SubCA explicitly allowed by PKI policy), I'd be curious to
see how they manage the issues involved, and what their profiles indicate.
Best Regards,
--
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
