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

[Richard Levitte via RT]

BUT... I'm realising that when you do recognise a GT3 proxy (I think
I've seen
check_issued functions being used for that), there's no way for
external code
to set the proxy path length for the certificate in question. While
that's fine
for GT2 proxies (there's no pc path length there that I can see), it
does need
to be properly set for GT3 proxies.

For this, https://github.com/openssl/openssl/pull/1348

... and it got through our review process pretty quickly.

All github PRs that have been mentioned so far have now been merged into
master.

I'm closing this ticket on our side (this will hopefully happen on the Debian
side as well) as it seems to be covered by the code that has now been added.

As for everything else that has been discussed here, which also touches on
external methods of verification via the verification callback, I would say
it's out of scope for this ticket. I am interested in these talks, but then by
direct email.

--

Richard Levitte
***@openssl.org

[via RT]

I am not sure what to suggest. This conversation is bouncing across
two ticket systems and is all about a legacy certificate format that
is, what, outdated since 2002?
I am hard-pressed to see why OpenSSL 1.1 has to do anything other than
what Richard proposed.

The two ticket systems is indeed annoying and I don't know what to do
about that (I did not start this thread) other than removing one of
them.

The point is that if OpenSSL is providing a verification callback which
can be used to provide a custom verification of the cert chain, then it
should provide the necessary handles and the thing still missing from
what Richard proposed is a way to point to the failing certificate in
the chain. We can set the error, but not at which depth in the chain the
error occurred.
This in itself is not limited to our use-case but is a general API
request.

Mischa

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

--
Nikhef Room H155
Science Park 105 Tel. [phone]
1098 XG Amsterdam Fax [phone]
The Netherlands Email ***@nikhef.nl
__ .. ... _._. .... ._ ... ._ ._.. ._.. .._..

[Richard Levitte]

In message <rt-4.0.19-13376-1469461907-1144.4602-6-***@openssl.org> on Mon, 25 Jul 2016 15:51:47 +0000, "***@nikhef.nl via RT" <***@openssl.org> said:

rt> On Mon, Jul 25, 2016 at 01:44:18PM +0000, Salz, Rich via RT wrote:
rt> > I am not sure what to suggest. This conversation is bouncing across
rt> > two ticket systems and is all about a legacy certificate format that
rt> > is, what, outdated since 2002?
rt> > I am hard-pressed to see why OpenSSL 1.1 has to do anything other than
rt> > what Richard proposed.
rt>
rt> The two ticket systems is indeed annoying and I don't know what to do
rt> about that (I did not start this thread) other than removing one of
rt> them.

One way is to exclude ***@openssl.org from your list of recipients ;-)
(I just did, btw)
I'm also taking away ***@bugs.debian.org

rt> The point is that if OpenSSL is providing a verification callback which
rt> can be used to provide a custom verification of the cert chain, then it
rt> should provide the necessary handles and the thing still missing from
rt> what Richard proposed is a way to point to the failing certificate in
rt> the chain. We can set the error, but not at which depth in the chain the
rt> error occurred.
rt> This in itself is not limited to our use-case but is a general API
rt> request.

Just for clarity, when I talk about the verification callback, I'm
talking about verify_cb, settable with X509_STORE_CTX_set_verify_cb()
If you're talking about something else, please correct me.

By design, verify_cb is called for *each* certificate in the chain,
and to allow the verification result for that certificate alone to be
customized.

current_cert, current_issuer, etc are meant as input for verify_cb,
indicating which certificate in the chain the call of the callback is
about. Why one would need to tamper with them from inside the
verify_cb function escapes me...

Cheers,
Richard

[Richard Levitte]

In message <rt-4.0.19-13376-1469461907-1144.4602-6-***@openssl.org> on Mon, 25 Jul 2016 15:51:47 +0000, "***@nikhef.nl via RT" <***@openssl.org> said:

rt> The point is that if OpenSSL is providing a verification callback which
rt> can be used to provide a custom verification of the cert chain, then it
rt> should provide the necessary handles and the thing still missing from
rt> what Richard proposed is a way to point to the failing certificate in
rt> the chain. We can set the error, but not at which depth in the chain the
rt> error occurred.
rt> This in itself is not limited to our use-case but is a general API
rt> request.

Looking around, I just discovered that someone else has had the same
thoughts as you, back in April. These functions were added back then:

void X509_STORE_CTX_set_error_depth(X509_STORE_CTX *ctx, int depth);
void X509_STORE_CTX_set_current_cert(X509_STORE_CTX *ctx, X509 *x);

Cheers,
Richard

[Richard Levitte]

In message <***@nikhef.nl> on Tue, 26 Jul 2016 11:52:26 +0200, Mischa Salle <***@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!