In message <20160803131344.gb2...@nikhef.nl> on Wed, 3 Aug 2016 15:13:44 +0200, Mischa Salle <msa...@nikhef.nl> said:
msalle> Hi Richard, msalle> msalle> apologies for the delayed answer, I was caught up in work... msalle> msalle> On Tue, Jul 26, 2016 at 05:50:14PM +0200, Richard Levitte wrote: msalle> > msalle> Just for completeness, there are a number of things we need to verify or msalle> > msalle> adapt by hand: msalle> > msalle> - for non-RFC proxies, we need to be able to verify the issuer by hand msalle> > msalle> and override the X509_check_issued(). For GT3 it could be that this is msalle> > msalle> automatically solved by setting the EXFLAG_PROXY, I will need to check msalle> > msalle> that, for legacy /GT2 it cannot be since we need to check for the msalle> > msalle> /CN=proxy or /CN=limited proxy. msalle> > msalle> > You need to set the proxy path length as well for GT3. For GT2, the msalle> > initial value -1 is exactly right. msalle> > msalle> > msalle> - for GT3 proxies we need to verify the pathlength constraint. If your msalle> > msalle> pullrequest https://github.com/openssl/openssl/pull/1348 allows me to msalle> > msalle> set a proxy pathlength constraint for a GT3 proxy which combined with msalle> > msalle> the EXFLAG_PROXY would allow using standard verification, then that msalle> > msalle> would probably indeed solve that problem too. msalle> > msalle> > That's what I'm hoping. Please try it out, for example by disabling msalle> > these lines and seeing if what should verify does verify: msalle> > msalle> > https://github.com/globus/globus-toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L876-L884 msalle> msalle> The problem with these two points is that I will still have to go msalle> through the chain and set both the pathlength and the proxy flag for msalle> each cert in case of GT3 proxies. In the end I've decided to leave this msalle> part of at least my code as much as it is for now. At some point I will msalle> try to rewrite it. The better idea is to have globus_gsi_callback_check_issued() check for GT2 and GT3 proxies and set the flag and pathlen accordingly. Insert such code before calling X509_check_issued(), i.e. here: https://github.com/globus/globus-toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L582 That would be a much better use of CPU cycles and already existing OpenSSL code. (also should work for pre-1.1 OpenSSLs) msalle> By the way, even for RFC proxies I still have the problem that setting msalle> the flag X509_V_FLAG_CRL_CHECK (and X509_V_FLAG_CRL_CHECK_ALL) to do CRL msalle> checking results in a failure. I haven't looked yet what causes it, but msalle> that flag should be ignored for proxy certificates in my opinion. msalle> Perhaps I'm doing something wrong...? I believe you've found a bug! Thanks. msalle> > msalle> - for GT3 proxies we also need to be able to set (as you mention) the msalle> > msalle> policy. I need to check that we have the necessary getters/setters for msalle> > msalle> that now. I'll check with your new example. msalle> > msalle> > I've updated the example, it compiles. We don't have that in the ssl msalle> > test any more (or well, we have it in pre-1.1 source), I'm thinking I msalle> > should create a demo... msalle> msalle> I've managed to fix all *my* (that's not VOMS or Globus) code. That also msalle> compiles and works again! msalle> msalle> > msalle> - The errata of the RFC specify actually 3 OIDs, also the msalle> > msalle> id-ppl-anyLanguage / 1.3.6.1.5.5.7.21.0 which is not understood by msalle> > msalle> OpenSSL. I don't think they are used in practice, but I like to have msalle> > msalle> code to verify them. msalle> > msalle> > You can easily do that in verify_cb, per certificate. I think you msalle> > already do? Also, I'm not sure what you mean with "not understood by msalle> > OpenSSL", what is OpenSSL itself supposed to do with it? msalle> Actually, upon looking again at the master branch, I agree that the msalle> id-ppl-anyLanguage is there. I think I accidentally looked at your msalle> example code, which doesn't have it in the switch(). Sorry for the noise. Maybe the example should be expanded, although I've no idea why it must care... msalle> > msalle> More importantly however, in Grid, the so-called limited proxies with msalle> > msalle> globus-owned OID 1.3.6.1.4.1.3536.1.1.1.9 are widely used, they msalle> > msalle> indicate that the proxy may not be used for job submission, only for msalle> > msalle> data access. So we need to have ways to verify that. For legacy/GT2 msalle> > msalle> this is indicated using /CN=limited proxy instead. msalle> > msalle> > 1.3.6.1.4.1.3536.1.1.1.9? That's a policy OID, right? OpenSSL leaves msalle> > it entirely up to verify_cb to check these policies. That would msalle> > correspond to the check_needed_rights() call at the bottom of msalle> > doc/HOWTO/proxy_certificates.txt, right? msalle> msalle> Yes, it's a policy OID, same level as the other three. msalle> I agree we can check them ourselves, but in order to check them, one msalle> needs to go through the whole chain (a non-limited proxy is not allowed msalle> to follow a limited proxy) and that's a tricky thing. In principle one msalle> can do that with cert plus issuer-cert, which is available in the msalle> callback, but that's not very efficient, which was my next point below. I truly don't understand why you need to walk the chain every time verify_cb is called. msalle> > msalle> - Related to the previous point, the chain may not be built up from msalle> > msalle> arbitrary language proxies: for example after a limited proxy, only msalle> > msalle> limited proxies are allowed. msalle> > msalle> > That corresponds to the "rights" idea in msalle> > doc/HOWTO/proxy_certificates.txt msalle> > msalle> > msalle> Also, we need to make sure that the chain is something like msalle> > msalle> CA -> [ subCA ... -> ] EEC -> proxy [ -> proxy ... ] msalle> > msalle> This can of course be done in a chain-local callback (cert+issuer). msalle> > msalle> > The OpenSSL code already ensures that, and works as long as the proxy msalle> > certs are appropriately marked with X509_set_proxy_flag() beforehand msalle> > (for example via the check_issued X509_STORE function for non-RFC msalle> > proxies). If you look in crypto/x509/x509_vfy.c, check msalle> > check_chain_extensions(). You may notice the variable 'must_be_ca', msalle> > which is a tri-state, and controls what kind of cert is expected the msalle> > next step "up". msalle> > msalle> > If you find a bug in that mechanism, we're interested! msalle> msalle> This indeed looks like the right way to go. I guess it would also be the msalle> right place to make sure the proxy pathlength for GT3 proxies is being msalle> set. msalle> msalle> I'm currently rather out of time, but will try to have a look at some msalle> point how we can improve and simplify our code. msalle> msalle> Many thanks for the detailed instructions! msalle> msalle> Mischa msalle> msalle> msalle> > msalle> > msalle> > current_cert, current_issuer, etc are meant as input for verify_cb, msalle> > msalle> > indicating which certificate in the chain the call of the callback is msalle> > msalle> > about. Why one would need to tamper with them from inside the msalle> > msalle> > verify_cb function escapes me... msalle> > msalle> It's true that it's not really what you want to do *if* you can do msalle> > msalle> local-only checks, but that's not possible for the pathlength constraint msalle> > msalle> check (without keeping some global state or by manually setting the msalle> > msalle> effective pathlength inside each cert), hence a renewed walking the msalle> > msalle> chain is typically done upon reaching the last cert. msalle> > msalle> > Like I said, please check what OpenSSL does. There was a bug, so I msalle> > perfectly understand why you needed to override that check. I've msalle> > fixed what I found. If you find a bug in that mechanism, we're msalle> > interested! msalle> > msalle> > -- msalle> > Richard Levitte levi...@openssl.org msalle> > OpenSSL Project http://www.openssl.org/~levitte/ msalle> msalle> -- msalle> Nikhef Room H155 msalle> Science Park 105 Tel. +31-20-592 5102 msalle> 1098 XG Amsterdam Fax +31-20-592 5155 msalle> The Netherlands Email msa...@nikhef.nl msalle> __ .. ... _._. .... ._ ... ._ ._.. ._.. .._.. msalle> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
