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

[Richard Levitte]

In message <20160803142331.gd2...@nikhef.nl> on Wed, 3 Aug 2016 16:23:31 +0200, 
Mischa Salle  said:

msalle> On Wed, Aug 03, 2016 at 03:41:55PM +0200, Richard Levitte wrote:
msalle> > msalle> By the way, even for RFC proxies I still have the problem 
that setting
msalle> > msalle> the flag X509_V_FLAG_CRL_CHECK (and 
X509_V_FLAG_CRL_CHECK_ALL) to do CRL
msalle> > msalle> checking results in a failure. I haven't looked yet what 
causes it, but
msalle> > msalle> that flag should be ignored for proxy certificates in my 
opinion.
msalle> > msalle> Perhaps I'm doing something wrong...?
msalle> > 
msalle> > I believe you've found a bug!  Thanks.
msalle> Would you like me to open an issue? I haven't checked in great detail
msalle> though...

Nah, the two lines that were needed got reviewed quite quickly and are
already in master.  In fact, it will be part of the beta we're
releasing tomorrow.

Cheers,
Richard

-- 
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

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

[Richard Levitte]

In message <20160803.154155.2198714958292922881.levi...@openssl.org> on Wed, 03 
Aug 2016 15:41:55 +0200 (CEST), Richard Levitte  said:

levitte> In message <20160803131344.gb2...@nikhef.nl> on Wed, 3 Aug 2016 
15:13:44 +0200, Mischa Salle  said:
levitte> 
levitte> msalle> By the way, even for RFC proxies I still have the problem that 
setting
levitte> msalle> the flag X509_V_FLAG_CRL_CHECK (and X509_V_FLAG_CRL_CHECK_ALL) 
to do CRL
levitte> msalle> checking results in a failure. I haven't looked yet what 
causes it, but
levitte> msalle> that flag should be ignored for proxy certificates in my 
opinion.
levitte> msalle> Perhaps I'm doing something wrong...?
levitte> 
levitte> I believe you've found a bug!  Thanks.

I'm attaching the fix I came up with.  Please try it out and see if
things work better.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
commit 2a228d15d9e662e2d66c8af64997dbd3f2b8df2e
Author: Richard Levitte 
Date:   Wed Aug 3 16:02:20 2016 +0200

Don't check any revocation info on proxy certificates

Because proxy certificates typically come without any CRL information,
trying to check revocation on them will fail.  Better not to try
checking such information for them at all.

diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c
index 099a4d8..2874574 100644
--- a/crypto/x509/x509_vfy.c
+++ b/crypto/x509/x509_vfy.c
@@ -844,6 +844,9 @@ static int check_cert(X509_STORE_CTX *ctx)
 ctx->current_crl_score = 0;
 ctx->current_reasons = 0;
 
+if (x->ex_flags & EXFLAG_PROXY)
+return 1;
+
 while (ctx->current_reasons != CRLDP_ALL_REASONS) {
 unsigned int last_reasons = ctx->current_reasons;
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Levitte]

In message <20160803131344.gb2...@nikhef.nl> on Wed, 3 Aug 2016 15:13:44 +0200, 
Mischa Salle  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 

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

[Richard Levitte]

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

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

[Richard Levitte]

In message  on Mon, 25 
Jul 2016 15:51:47 +, "msa...@nikhef.nl via RT"  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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard Levitte]

In message  on Mon, 25 
Jul 2016 15:51:47 +, "msa...@nikhef.nl via RT"  said:

rt> On Mon, Jul 25, 2016 at 01:44:18PM +, 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 r...@openssl.org from your list of recipients ;-)
(I just did, btw)
I'm also taking away 829...@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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[msa...@nikhef.nl via RT]

On Mon, Jul 25, 2016 at 01:44:18PM +, Salz, Rich via RT wrote:
> 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 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..


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

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[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.

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

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[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.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[msa...@nikhef.nl via RT]

On Mon, Jul 25, 2016 at 12:47:56PM +, Salz, Rich via RT wrote:
> 
> > 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 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..

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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[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?

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

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[msa...@nikhef.nl via RT]

On Mon, Jul 25, 2016 at 12:42:21PM +, Salz, Rich via RT wrote:
> 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 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..

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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Salz, Rich]

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



-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Salz, Rich via RT]

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




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

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[msa...@nikhef.nl via RT]

Hi Richard,

On Mon, Jul 25, 2016 at 11:46:50AM +, Richard Levitte via RT wrote:
> 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

> > 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)
> > >
> > > On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> > > > 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 +, Richard Levitte via RT
> > > > wrote:
> > > > > 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
> > > > > levi...@openssl.org
> > > > > --
> > > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > > Please log in as guest with password guest if prompted
> > > > >
> > > > > --
> > > > > To unsubscribe, send mail to 829272-unsubscr...@bugs.debian.org.
> > >
> > >
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> > >
> > > --
> > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > Please log in as guest with password guest if prompted
> > >
> 
> 
> --
> Richard Levitte
> levi...@openssl.org
> 
> -- 
> 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 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..

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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[msa...@nikhef.nl via RT]

On Sat, Jul 23, 2016 at 09:44:18AM +, Richard Levitte via RT wrote:
> 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.

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)
> 
> On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> > 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 +, Richard Levitte via RT
> > wrote:
> > > 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
> > > levi...@openssl.org
> > > --
> > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > Please log in as guest with password guest if prompted
> > >
> > > --
> > > To unsubscribe, send mail to 829272-unsubscr...@bugs.debian.org.
> 
> 
> --
> Richard Levitte
> levi...@openssl.org
> 
> -- 
> 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 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..

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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[msa...@nikhef.nl via RT]

On Fri, Jul 22, 2016 at 09:38:13AM +0200, Mattias Ellert wrote:
> tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> > On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > > 
> > > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > > > 
> > > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > > > > 
> > > > > 
> > > > > I guess having a more restrictive accessor that only sets the
> > > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > > solution
> > > > > of
> > > > > having set/clear accessors for arbitrary flags since it was -
> > > > > well
> > > > > more
> > > > > general.
> > > > 
> > > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > > not
> > > > set the
> > > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > > That may be
> > > > worth a bug report of its own.
> > > > 
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > > > 
> > > 
> > > The answer to this is related to Mischa's reply, which
> > > unfortunately
> > > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > > it
> > > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > > handling non-RFC proxies in OpenSSL.
> > > 
> > > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > > 
> > > > Hi Richard, Mattias, others,
> > > > 
> > > > I agree with you that it would be nice if OpenSSL could figure
> > > > out
> > > > itself whether a cert needs to be treated as a proxy, but
> > > > currently
> > > > that
> > > > doesn't work reliably as far as I know.
> > > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > > also
> > > > known as legacy proxies. Unfortunately these are still very
> > > > widely
> > > > used
> > > > (majority of the proxies actually) and hence our code must be
> > > > able to
> > > > handle them correctly.
> > > > 
> > > > Best wishes,
> > > > Mischa Sallé
> > > > 
> > 
> > Ok... From looking at the voms code that was linked to earlier, I can
> > see that
> > legacy proxy certs are recognised by an older OID (called
> > PROXYCERTINFO_V3 in
> > the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> > in that
> > version, whether they are critical or not and so on, that I can
> > reach? Or is
> > the OID the only actual difference? If it's easy enough (and it
> > currently does
> > look quite easy), I can certainly see adding some code in OpenSSL to
> > recognise
> > those...
> > 
> > --
> > Richard Levitte
> > levi...@openssl.org
> 
> As far as I know there are three different kinds of proxies, usually
> called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
> respectively.
> 
> For example see "grid-proxy-init -help":
> 
>     -draftCreates a draft (GSI-3) proxy
> -old  Creates a legacy globus proxy
> -rfc  Creates a RFC 3820 compliant proxy
> 
> The really tricky one is the old legacy version 2 proxy I think.

Hi,

there are 3 types of proxies, in chronological order:

- so called legacy proxies, which voms-proxy-init will call old and are
  also known as GT2 proxies.
  They have no special (critical) extension and can be recognized by:
1) being signed by an end-entity cert (i.e. a non-CA)
2) have the same subjectDN as the issuer with one extra CN RDN
   added, which can be either
a) "CN=proxy" for a 'inherit all' proxy
b) "CN=limited proxy" for a limited proxy (as in OID
   1.3.6.1.4.1.3536.1.1.1.9)
  These are widely used and we have therefore code in many places to
  handle them.

- the draft RFC proxies, also known as GT3 proxies.
  They contain an extension 1.3.6.1.4.1.3536.1.222
  At least voms-proxy-init does not mark it as critical. They are
  rarely used. The ordering in the extension is different in the sense
  that they usually put the proxyPolicy before the proxyPathlength (when
  finite, i.e. present) inside the extension, but RFC-style extensions
  also occur. In openssl.cnf style a GT3 extension would be something
  like this:
[ gt3_proxy ]
keyUsage = critical,digitalSignature,keyEncipherment
1.3.6.1.4.1.3536.1.222=critical,ASN1:SEQUENCE:gt3_seq_sect

# For a proxy pathlength of 42, leave out field2 for inf.
[ gt3_seq_sect ]
field1 = SEQUENCE:normal_policy
field2 = EXPLICIT:1C,INTEGER:42

# similarly for limited policy
[ normal_policy ]
p1 = OID:1.3.6.1.5.5.7.21.1

- RFC3820 compliant proxies, also known as GT4 proxies.
  They contain the standard critical extension 1.3.6.1.5.5.7.1.14

The default for at least voms-proxy-init (both from the voms-clients2
and voms-clients3) is to make the GT2 proxies, and this is why they are
still very-widely used (I think vast majority of proxies).

Mischa
-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   

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

[Mattias Ellert via RT]

tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > 
> > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > > 
> > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > > > 
> > > > 
> > > > I guess having a more restrictive accessor that only sets the
> > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > solution
> > > > of
> > > > having set/clear accessors for arbitrary flags since it was -
> > > > well
> > > > more
> > > > general.
> > > 
> > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > not
> > > set the
> > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > That may be
> > > worth a bug report of its own.
> > > 
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> > > 
> > 
> > The answer to this is related to Mischa's reply, which
> > unfortunately
> > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > it
> > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > handling non-RFC proxies in OpenSSL.
> > 
> > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > 
> > > Hi Richard, Mattias, others,
> > > 
> > > I agree with you that it would be nice if OpenSSL could figure
> > > out
> > > itself whether a cert needs to be treated as a proxy, but
> > > currently
> > > that
> > > doesn't work reliably as far as I know.
> > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > also
> > > known as legacy proxies. Unfortunately these are still very
> > > widely
> > > used
> > > (majority of the proxies actually) and hence our code must be
> > > able to
> > > handle them correctly.
> > > 
> > > Best wishes,
> > > Mischa Sallé
> > > 
> 
> Ok... From looking at the voms code that was linked to earlier, I can
> see that
> legacy proxy certs are recognised by an older OID (called
> PROXYCERTINFO_V3 in
> the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> in that
> version, whether they are critical or not and so on, that I can
> reach? Or is
> the OID the only actual difference? If it's easy enough (and it
> currently does
> look quite easy), I can certainly see adding some code in OpenSSL to
> recognise
> those...
> 
> --
> Richard Levitte
> levi...@openssl.org

As far as I know there are three different kinds of proxies, usually
called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
respectively.

For example see "grid-proxy-init -help":

    -draftCreates a draft (GSI-3) proxy
-old  Creates a legacy globus proxy
-rfc  Creates a RFC 3820 compliant proxy

The really tricky one is the old legacy version 2 proxy I think.

Mattias

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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[David Woodhouse via RT]

(Dropping the Debian bug from Cc)

On Wed, 2016-07-20 at 15:11 +, Richard Levitte via RT wrote:
> On Mon Jul 11 14:04:22 2016, dw...@infradead.org wrote:
> > I was using store.get_issuer() in OpenConnect too, because I need to
> > manually build the trust chain to include it on the wire — because
> > even today the server might *still* suffer RT#1942 and fail to trust
> > our client cert unless we help it by providing the *right* chain.
> 
> Is this still true with OpenSSL 1.1? If so, please file a report.

No, I fixed it years ago in OpenSSL. But it took many years for Cisco
to actually start *using* a fixed version of OpenSSL.

So we still try really hard, on the client side, to put the *right*
intermediate CAs on the wire if we can find them. Because that way it
doesn't matter so much if the server can't.

> > I've worked around the lack of access to get_issuer() by doing a dummy
> > call to X509_verify_cert(), throwing away its result and then hoping
> > that we have something useful in store.chain (which we *can* still
> > access). That seems to work but I'm not stunningly happy with it; if
> > we
> > can have an accessor I'd much rather go back to doing it the old way.
> > 
> > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
> > (in workaround_openssl_certchain_bug() in the hunk around line 1306)
> 
> https://github.com/openssl/openssl/pull/1294 currently provides a setter for
> get_issuer in X509_STORE.

OK, thanks. Once it lands, I may go back to using that.

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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[David Woodhouse]

(Dropping the Debian bug from Cc)

On Wed, 2016-07-20 at 15:11 +, Richard Levitte via RT wrote:
> On Mon Jul 11 14:04:22 2016, dw...@infradead.org wrote:
> > I was using store.get_issuer() in OpenConnect too, because I need to
> > manually build the trust chain to include it on the wire — because
> > even today the server might *still* suffer RT#1942 and fail to trust
> > our client cert unless we help it by providing the *right* chain.
> 
> Is this still true with OpenSSL 1.1? If so, please file a report.

No, I fixed it years ago in OpenSSL. But it took many years for Cisco
to actually start *using* a fixed version of OpenSSL.

So we still try really hard, on the client side, to put the *right*
intermediate CAs on the wire if we can find them. Because that way it
doesn't matter so much if the server can't.

> > I've worked around the lack of access to get_issuer() by doing a dummy
> > call to X509_verify_cert(), throwing away its result and then hoping
> > that we have something useful in store.chain (which we *can* still
> > access). That seems to work but I'm not stunningly happy with it; if
> > we
> > can have an accessor I'd much rather go back to doing it the old way.
> > 
> > http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
> > (in workaround_openssl_certchain_bug() in the hunk around line 1306)
> 
> https://github.com/openssl/openssl/pull/1294 currently provides a setter for
> get_issuer in X509_STORE.

OK, thanks. Once it lands, I may go back to using that.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Mattias Ellert via RT]

ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > 
> > I guess having a more restrictive accessor that only sets the
> > EXFLAG_PROXY bit could work. I suggested the more general solution of
> > having set/clear accessors for arbitrary flags since it was - well
> > more
> > general.
> 
> So let me ask this in a different manner, does OpenSSL 1.1 still not set the
> EXFLAG_PROXY flag correctly? In what situations does that happen? That may be
> worth a bug report of its own.
> 
> --
> Richard Levitte
> levi...@openssl.org
> 

The answer to this is related to Mischa's reply, which unfortunately
was only sent to the Debian BTS and not the the OpenSSL RT. I quote it
below. As indicated in the answer, setting the EXFLAG_PROXY allows
handling non-RFC proxies in OpenSSL.

mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> Hi Richard, Mattias, others,
> 
> I agree with you that it would be nice if OpenSSL could figure out
> itself whether a cert needs to be treated as a proxy, but currently that
> doesn't work reliably as far as I know.
> The flag is certainly needed in the case of non-RFC3820 proxies, also
> known as legacy proxies. Unfortunately these are still very widely used
> (majority of the proxies actually) and hence our code must be able to
> handle them correctly.
> 
> Best wishes,
> Mischa Sallé
> 

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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Jan Just Keijser via RT]

Hi Richard,

On 20/07/16 17:14, Richard Levitte via RT wrote:
> On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
>> I guess having a more restrictive accessor that only sets the
>> EXFLAG_PROXY bit could work. I suggested the more general solution of
>> having set/clear accessors for arbitrary flags since it was - well
>> more
>> general.
> So let me ask this in a different manner, does OpenSSL 1.1 still not set the
> EXFLAG_PROXY flag correctly? In what situations does that happen? That may be
> worth a bug report of its own.
>
this ties into my earlier question and example of verifying proxy 
certificates. What if I want to explicitly *set* the EXFLAG_PROXY for a 
stack of certificates? how would I do that? how can I ensure that 
OpenSSL 1.1 will automagically trigger this flag for me? Is there a 
'get_*' function to determine which flags were set during certificate 
verification?

thanks for any pointers or advice,

JJK / Jan Just Keijser



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

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Jan Just Keijser]

Hi Richard,

On 20/07/16 17:14, Richard Levitte via RT wrote:

On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:

I guess having a more restrictive accessor that only sets the
EXFLAG_PROXY bit could work. I suggested the more general solution of
having set/clear accessors for arbitrary flags since it was - well
more
general.

So let me ask this in a different manner, does OpenSSL 1.1 still not set the
EXFLAG_PROXY flag correctly? In what situations does that happen? That may be
worth a bug report of its own.

this ties into my earlier question and example of verifying proxy 
certificates. What if I want to explicitly *set* the EXFLAG_PROXY for a 
stack of certificates? how would I do that? how can I ensure that 
OpenSSL 1.1 will automagically trigger this flag for me? Is there a 
'get_*' function to determine which flags were set during certificate 
verification?


thanks for any pointers or advice,

JJK / Jan Just Keijser


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[David Woodhouse via RT]

On Mon, 2016-07-11 at 13:08 +, Mattias Ellert via RT wrote:
> 
> 
> Looking at the various places in the code where get_issuer
> and check_issued are accessed, they mostly use the context rather than
> the store. Here are the places I have found:
> 
> https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71
> 
> https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581
> 
> https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588
> 
> https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367
> 
> https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059
> 
> https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997
> 
> And the following one actually uses the store and not the context:
> 
> https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448

I was using store.get_issuer() in OpenConnect too, because I need to
manually build the trust chain to include it on the wire — because
even today the server might *still* suffer RT#1942 and fail to trust
our client cert unless we help it by providing the *right* chain.

I've worked around the lack of access to get_issuer() by doing a dummy
call to X509_verify_cert(), throwing away its result and then hoping
that we have something useful in store.chain (which we *can* still
access). That seems to work but I'm not stunningly happy with it; if we
can have an accessor I'd much rather go back to doing it the old way.

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
(in workaround_openssl_certchain_bug() in the hunk around line 1306)


-- 
dwmw2


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

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[David Woodhouse]

On Mon, 2016-07-11 at 13:08 +, Mattias Ellert via RT wrote:
> 
> 
> Looking at the various places in the code where get_issuer
> and check_issued are accessed, they mostly use the context rather than
> the store. Here are the places I have found:
> 
> https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71
> 
> https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581
> 
> https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588
> 
> https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367
> 
> https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059
> 
> https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997
> 
> And the following one actually uses the store and not the context:
> 
> https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448

I was using store.get_issuer() in OpenConnect too, because I need to
manually build the trust chain to include it on the wire — because
even today the server might *still* suffer RT#1942 and fail to trust
our client cert unless we help it by providing the *right* chain.

I've worked around the lack of access to get_issuer() by doing a dummy
call to X509_verify_cert(), throwing away its result and then hoping
that we have something useful in store.chain (which we *can* still
access). That seems to work but I'm not stunningly happy with it; if we
can have an accessor I'd much rather go back to doing it the old way.

http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
(in workaround_openssl_certchain_bug() in the hunk around line 1306)


-- 
dwmw2
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Mattias Ellert via RT]

fre 2016-07-08 klockan 06:08 + skrev Richard Levitte via RT:
> On Thu Jul 07 21:29:09 2016, levitte wrote:
> > On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > > /* Add to include/openssl/x509_vfy.h : */
> > > 
> > > typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer,
> > > X509_STORE_CTX
> > > *ctx, X509 *x);
> > > typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx,
> > > X509
> > > *x, X509 *issuer);
> > > 
> > > void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
> > > X509_STORE_CTX_get_issuer
> > > get_issuer);
> > > X509_STORE_CTX_get_issuer
> > > X509_STORE_CTX_get_get_issuer(X509_STORE_CTX
> > > *ctx);
> > > void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
> > > X509_STORE_CTX_check_issued
> > > check_issued);
> > > X509_STORE_CTX_check_issued
> > > X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx);
> > 
> > For this part, https://github.com/openssl/openssl/pull/1294
> 
> So, looking at this again after some sleep, there's a part of this
> solution
> that I'm unsure of, and it all comes back to X509_STORE_CTX_init(),
> where the
> X509_STORE context gets initialised from the X509_STORE, including
> all the
> function pointers. This has me wonder if the X509_STORE_CTX setters
> should
> really be made available (perhaps with the exception of the verify
> and
> verify_cb ones). Doesn't it make more sense to set those function
> pointers when
> creating the X509_STORE itself? Why would those functions need to be
> changed in
> the context?
> 
> Cheers,
> Richard
> 
> --
> Richard Levitte
> levi...@openssl.org
> 

Looking at the various places in the code where get_issuer
and check_issued are accessed, they mostly use the context rather than
the store. Here are the places I have found:

https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71

https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581

https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588

https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367

https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059

https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997

And the following one actually uses the store and not the context:

https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448

Mattias


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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Mattias Ellert via RT]

fre 2016-07-08 klockan 00:42 +0200 skrev Kurt Roeckx:
> On Thu, Jul 07, 2016 at 09:40:24PM +, Richard Levitte via RT
> wrote:
> > On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > > /* Add to include/openssl/x509v3.h */
> > > 
> > > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> > > 
> > > 
> > > /* Add to crypto/x509v3/v3_purp.c */
> > > 
> > > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > > {
> > > x->ex_flags |= ex_flags;
> > > }
> > > 
> > > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > > {
> > > x->ex_flags &= ~ex_flags;
> > > }
> > 
> > This gives me the heebie jeebies. ex_flags is used a lot
> > internally, and I
> > can't begin to imagine the consequences of letting external code
> > manipulate
> > this. I understand that in some cases, it seems easy and quick,
> > but...
> > 
> > So, if someone else wants to have a go at this and can make
> > something sensible,
> > please be my guest. Me, I'm backing off from this particular idea.
> 
> Mattias,
> 
> Can you explain why this is needed, what the code is trying to do?
> 
> 
> Kurt
> 

Hi!

The modification of the extension flags happens in at least four
different packages. The modification they do is to add the EXFLAG_PROXY
bit to the flags.

https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L692

https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1665
https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1740

https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1655
https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1719

https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L184

I guess having a more restrictive accessor that only sets the
EXFLAG_PROXY bit could work. I suggested the more general solution of
having set/clear accessors for arbitrary flags since it was - well more
general.

Mattias Ellert

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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Kurt Roeckx via RT]

On Thu, Jul 07, 2016 at 09:40:24PM +, Richard Levitte via RT wrote:
> On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > /* Add to include/openssl/x509v3.h */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> >
> >
> > /* Add to crypto/x509v3/v3_purp.c */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags |= ex_flags;
> > }
> >
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags &= ~ex_flags;
> > }
> 
> This gives me the heebie jeebies. ex_flags is used a lot internally, and I
> can't begin to imagine the consequences of letting external code manipulate
> this. I understand that in some cases, it seems easy and quick, but...
> 
> So, if someone else wants to have a go at this and can make something 
> sensible,
> please be my guest. Me, I'm backing off from this particular idea.

Mattias,

Can you explain why this is needed, what the code is trying to do?


Kurt


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

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Kurt Roeckx]

On Thu, Jul 07, 2016 at 09:40:24PM +, Richard Levitte via RT wrote:
> On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > /* Add to include/openssl/x509v3.h */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> >
> >
> > /* Add to crypto/x509v3/v3_purp.c */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags |= ex_flags;
> > }
> >
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags &= ~ex_flags;
> > }
> 
> This gives me the heebie jeebies. ex_flags is used a lot internally, and I
> can't begin to imagine the consequences of letting external code manipulate
> this. I understand that in some cases, it seems easy and quick, but...
> 
> So, if someone else wants to have a go at this and can make something 
> sensible,
> please be my guest. Me, I'm backing off from this particular idea.

Mattias,

Can you explain why this is needed, what the code is trying to do?


Kurt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Salz, Rich via RT]

I think we should ask kurt to ask the original reporter what they need to do.


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

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev