Re: [openssl-dev] [openssl.org #4602] Missing accessors
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
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
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
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
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
[openssl-dev] [openssl.org #4624] Re: Bug#829272: Missing accessors
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. -- 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=4624 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
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
