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

[Richard Levitte via RT]

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

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.

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

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

Ok, so after doing quite a bit of searching, I found some references to GT2
(old) in a 3.0 document:

http://toolkit.globus.org/toolkit/docs/3.0/gsi/GSI-message-specification-02.doc
(section 5)

As I understand it, the GT2 format is a simple EE cert, with just two
differences:

1. the issuer is also a EE (so it has the basic constraint CA set to false)...
or it's another GT2 proxy, which amounts to the same thing.
2. the subject name is the issuer name plus an appended 'CN=Proxy' or
'CN=LimitedProxy'

Good so far?

My main problem here is GT3 (draft) proxy certs. If I look at
https://tools.ietf.org/html/draft-ietf-pkix-proxy-10, they look exactly the
same as RFC3820 proxy certs, down to the extension OID. If I look at a really
old draft
(http://sigillum.pl/upload/pdf/Internet%20X.509%20Public%20Key%20Infrastructure.%20Proxy%20Certificate%20Profile.pdf),
the difference is *wild*, and if look at a random shell script
(https://www.nikhef.nl/~janjust/proxy-verify/genproxy) I found while searching
for OID 1.3.6.1.4.1.3536.1.222, I find a third variant that has a slightly
different proycertinfo extension...

Btw, this should really become a new ticket, along the lines of "OpenSSL
doesn't recognise earlier proxy certs".

--
Richard Levitte
***@openssl.org

[via RT]

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

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.

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

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.
    -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. [phone]
1098 XG Amsterdam Fax [phone]
The Netherlands Email ***@nikhef.nl
__ .. ... _._. .... ._ ... ._ ._.. ._.. .._..