[Pkg-openssl-devel] Bug#829272: Missing accessors
msalle@nikhef.nl via RT
rt at openssl.org
Fri Jul 22 11:36:32 UTC 2016
On Fri, Jul 22, 2016 at 09:38:13AM +0200, Mattias Ellert wrote:
> tor 2016-07-21 klockan 09:51 +0000 skrev Richard Levitte via RT:
> > On Thu Jul 21 08:18:30 2016, mattias.ellert at physics.uu.se wrote:
> > >
> > > ons 2016-07-20 klockan 15:14 +0000 skrev Richard Levitte via RT:
> > > >
> > > > On Mon Jul 11 11:34:35 2016, mattias.ellert at 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
> > > > levitte at 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
> > levitte at 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":
>
> -draft Creates 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 105 Tel. +31-20-592 5102
1098 XG Amsterdam Fax +31-20-592 5155
The Netherlands Email msalle at nikhef.nl
__ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3382 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-openssl-devel/attachments/20160722/35166e5e/attachment.bin>
More information about the Pkg-openssl-devel
mailing list