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

[Richard Levitte via RT]

On Sat, Jul 23, 2016 at 09:44:18AM +0000, Richard Levitte via RT

To get current_cert, it's X509_STORE_CTX_get_current_cert().
To get current_issuer, it's X509_STORE_CTX_get0_current_issuer()

Hi Richard,
yes, those I know, but the problem is the *setting* of the failing
cert.
Since we need to walk the whole chain for the proxy pathlength
verification, we need to be able to indicate which cert is failing.
See
e.g.
https://github.com/globus/globus-

toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L1691

and further, in particular line 1731.
VOMS is basically using the same code
https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c#L2236
and further, in particular line 2255.

Is that code to cope with pathlen checking bugs? That's what it looks to me. In
that case, it might no longer be needed with OpenSSL 1.1, along with some other
stuff (the subject checking stuff comes to mind). Quite frankly, I think the
grid source needs a good and hard look over, quite a bit of it shouldn't be
needed any more. The exception is recognising pre-3820 proxy certs.

Jan Just also sets the current_issuer in his grid-proxy-verify.c,
http://www.nikhef.nl/~janjust/proxy-verify/
line 346, but I'm not sure that's necessary.
Mischa

Those functions are already present in pre-1.1 OpenSSL (at least in
the 1.0.2
series)

Hi,
unless I didn't look careful enough I think we might still be
missing
the current_cert (and current_issuer) from the X509_STORE_CTX, as
advertised in

https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204

and used in e.g.
https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
and many other places for verifying the proxy chain or is there a
better/other solution for that?
Best wishes,
Mischa
On Fri, Jul 22, 2016 at 03:26:26PM +0000, Richard Levitte via RT

In addition to github PR 1294, there's now also PR 1339 which
adds
the function to set the EXFLAG_PROXY flag on a given certificate.
Also, PR 1295 has been updated. Instead of a function that
returns a
lock, there is now a lock and an unlock function.
To me, it seems that that covers what's being asked for. Perhaps
not
exactly (the setters are for X509_STORE only), but should be
workable.
(writing this from my mobile, sorry for the lack of github links)
--
Richard Levitte
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted
--

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

--
Richard Levitte
***@openssl.org

[via RT]

Hi Richard,

Post by Richard Levitte via RT
Is that code to cope with pathlen checking bugs? That's what it looks to me. In
that case, it might no longer be needed with OpenSSL 1.1, along with some other
stuff (the subject checking stuff comes to mind). Quite frankly, I think the
grid source needs a good and hard look over, quite a bit of it shouldn't be
needed any more. The exception is recognising pre-3820 proxy certs.

Yes it is, and although it's true that it's probably not needed for
RFC3820 proxy certs (although I haven't checked that) but we will need
to be able to verify GT3 proxies and we will need to be able to do the
whole chain verification there with the callback...

Mischa

Post by Richard Levitte via RT

Jan Just also sets the current_issuer in his grid-proxy-verify.c,
http://www.nikhef.nl/~janjust/proxy-verify/
line 346, but I'm not sure that's necessary.
Mischa

Those functions are already present in pre-1.1 OpenSSL (at least in
the 1.0.2
series)

Hi,
unless I didn't look careful enough I think we might still be
missing
the current_cert (and current_issuer) from the X509_STORE_CTX, as
advertised in

https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204

and used in e.g.
https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
and many other places for verifying the proxy chain or is there a
better/other solution for that?
Best wishes,
Mischa
On Fri, Jul 22, 2016 at 03:26:26PM +0000, Richard Levitte via RT

In addition to github PR 1294, there's now also PR 1339 which
adds
the function to set the EXFLAG_PROXY flag on a given certificate.
Also, PR 1295 has been updated. Instead of a function that
returns a
lock, there is now a lock and an unlock function.
To me, it seems that that covers what's being asked for. Perhaps
not
exactly (the setters are for X509_STORE only), but should be
workable.
(writing this from my mobile, sorry for the lack of github links)
--
Richard Levitte
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted
--

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

--
Richard Levitte
--
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
__ .. ... _._. .... ._ ... ._ ._.. ._.. .._..

[Salz, Rich]

That's exactly what we currently do, we provide a verification callback, but
we do need to be able to set the failing cert in a chain for that.

Stick it in EXDAT?

[Salz, Rich via RT]

That's exactly what we currently do, we provide a verification callback, but
we do need to be able to set the failing cert in a chain for that.

Stick it in EXDAT?

[via RT]

Post by Salz, Rich

That's exactly what we currently do, we provide a verification callback, but
we do need to be able to set the failing cert in a chain for that.

Stick it in EXDAT?

I don't think I understand what you mean...
For a proper callback, we need to be able to indicate which cert in the
chain has failed. This used to be done by setting the 'current_cert'
field in the CTX. I'm perfectly happy if we need to do this differently
e.g. by using something like a
X509_STORE_CTX_set_error_depth(X509_STORE_CTX *ctx,int depth);
similar to the existing X509_STORE_CTX_get_error_depth()
That actually would make the most sense in any case I would think,
although I would mean that for properly handling proxy chains it would
have negative values according to the man-page...

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

[via RT]

Perhaps the GRID folks can just write their own validation routine completely?

That's exactly what we currently do, we provide a verification callback,
but we do need to be able to set the failing cert in a chain for that.

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
__ .. ... _._. .... ._ ... ._ ._.. ._.. .._..

[Salz, Rich via RT]

Perhaps the GRID folks can just write their own validation routine completely?

[Salz, Rich]

Perhaps the GRID folks can just write their own validation routine completely?

[Salz, Rich]

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.

[Salz, Rich 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.