In message <20160726095226.gc2...@nikhef.nl> on Tue, 26 Jul 2016 11:52:26 +0200, Mischa Salle <msa...@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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev