[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte]

In message <20160726095226.GC2457 at nikhef.nl> on Tue, 26 Jul 2016 11:52:26 +0200, Mischa Salle <msalle at nikhef.nl> said:

msalle> Hi Richard,
msalle> 
msalle> Although I haven't looked at all our code in detail (there is quite a
msalle> lot and it is old code which we mostly inherited from others and
msalle> maintained with a handful of people on best-effort basis) but I think we
msalle> now indeed have all we need. Thank you!
msalle> 
msalle> Just for completeness, there are a number of things we need to verify or
msalle> adapt by hand:
msalle> - for non-RFC proxies, we need to be able to verify the issuer by hand
msalle>   and override the X509_check_issued(). For GT3 it could be that this is
msalle>   automatically solved by setting the EXFLAG_PROXY, I will need to check
msalle>   that, for legacy /GT2 it cannot be since we need to check for the
msalle>   /CN=proxy or /CN=limited proxy.

You need to set the proxy path length as well for GT3.  For GT2, the
initial value -1 is exactly right.

msalle> - for GT3 proxies we need to verify the pathlength constraint. If your
msalle>   pullrequest https://github.com/openssl/openssl/pull/1348 allows me to
msalle>   set a proxy pathlength constraint for a GT3 proxy which combined with
msalle>   the EXFLAG_PROXY would allow using standard verification, then that
msalle>   would probably indeed solve that problem too.

That's what I'm hoping.  Please try it out, for example by disabling
these lines and seeing if what should verify does verify:

    https://github.com/globus/globus-toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L876-L884

msalle> - for GT3 proxies we also need to be able to set (as you mention) the
msalle>   policy. I need to check that we have the necessary getters/setters for
msalle>   that now. I'll check with your new example.

I've updated the example, it compiles.  We don't have that in the ssl
test any more (or well, we have it in pre-1.1 source), I'm thinking I
should create a demo...

msalle> - The errata of the RFC specify actually 3 OIDs, also the
msalle>   id-ppl-anyLanguage / 1.3.6.1.5.5.7.21.0 which is not understood by
msalle>   OpenSSL. I don't think they are used in practice, but I like to have
msalle>   code to verify them.

You can easily do that in verify_cb, per certificate.  I think you
already do?  Also, I'm not sure what you mean with "not understood by
OpenSSL", what is OpenSSL itself supposed to do with it?

msalle>   More importantly however, in Grid, the so-called limited proxies with
msalle>   globus-owned OID 1.3.6.1.4.1.3536.1.1.1.9 are widely used, they
msalle>   indicate that the proxy may not be used for job submission, only for
msalle>   data access. So we need to have ways to verify that. For legacy/GT2
msalle>   this is indicated using /CN=limited proxy instead.

1.3.6.1.4.1.3536.1.1.1.9?  That's a policy OID, right?  OpenSSL leaves
it entirely up to verify_cb to check these policies.  That would
correspond to the check_needed_rights() call at the bottom of
doc/HOWTO/proxy_certificates.txt, right?

msalle> - Related to the previous point, the chain may not be built up from
msalle>   arbitrary language proxies: for example after a limited proxy, only
msalle>   limited proxies are allowed.

That corresponds to the "rights" idea in
doc/HOWTO/proxy_certificates.txt

msalle>   Also, we need to make sure that the chain is something like
msalle>   CA -> [ subCA ... -> ] EEC -> proxy [ -> proxy ... ]
msalle>   This can of course be done in a chain-local callback (cert+issuer).

The OpenSSL code already ensures that, and works as long as the proxy
certs are appropriately marked with X509_set_proxy_flag() beforehand
(for example via the check_issued X509_STORE function for non-RFC
proxies).  If you look in crypto/x509/x509_vfy.c, check
check_chain_extensions().  You may notice the variable 'must_be_ca',
which is a tri-state, and controls what kind of cert is expected the
next step "up".

If you find a bug in that mechanism, we're interested!

msalle> > current_cert, current_issuer, etc are meant as input for verify_cb,
msalle> > indicating which certificate in the chain the call of the callback is
msalle> > about.  Why one would need to tamper with them from inside the
msalle> > verify_cb function escapes me...
msalle> It's true that it's not really what you want to do *if* you can do
msalle> local-only checks, but that's not possible for the pathlength constraint
msalle> check (without keeping some global state or by manually setting the
msalle> effective pathlength inside each cert), hence a renewed walking the
msalle> chain is typically done upon reaching the last cert.

Like I said, please check what OpenSSL does.  There was a bug, so I
perfectly understand why you needed to override that check.  I've
fixed what I found.  If you find a bug in that mechanism, we're
interested!

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/