By the way, I think the hostname matching provisions of 2818 (which
is, after all, only an informational RFC, not a standard) are poorly
thought out. Many machines have more hostnames than you can shake a
stick at, and often provide certs with the wrong hostname in them
(usually because
On Thu, Sep 06, 2007, Bill Janssen wrote:
By the way, I think the hostname matching provisions of 2818 (which
is, after all, only an informational RFC, not a standard) are poorly
thought out. Many machines have more hostnames than you can shake a
stick at, and often provide certs with the
It's actually easier to do all or nothing. I'm tempted to just report
'critical' extensions.
Simpler to provide them all
I very much doubt that, at least if you want to report decoded
information. Conceptually, there is an infinite number of extensions,
and when you are done, I can show you
I very much doubt that, at least if you want to report decoded
information. Conceptually, there is an infinite number of extensions,
and when you are done, I can show you lots of certificates that
have extensions that you don't support.
I'm not going to decode anything; I'm just using the
On 9/5/07, Bill Janssen [EMAIL PROTECTED] wrote:
It's actually easier to do all or nothing. I'm tempted to just report
'critical' extensions.
Simpler to provide them all, though I should note that the purpose of
the information provided here is mainly for authorization/accounting
I really don't understand why you would not expose all data in the
certificate.
You mean, providing the entire certificate as a blob? That is planned
(although perhaps not implemented).
Or do you mean expose all data in a structured manner. BECAUSE
IT'S NOT POSSIBLE. Sorry for shouting, but
RFC 2818
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
By the way, I think the hostname matching provisions of 2818 (which
is, after all, only an informational RFC, not a standard) are poorly
thought out. Many machines have more hostnames than you can shake a
stick at, and often provide certs with the wrong hostname in them
(usually because they have
On 05:03 pm, [EMAIL PROTECTED] wrote:
I really don't understand why you would not expose all data in the
certificate.
You mean, providing the entire certificate as a blob? That is planned
(although perhaps not implemented).
Or do you mean expose all data in a structured manner. BECAUSE
IT'S NOT
On 05:15 pm, [EMAIL PROTECTED] wrote:
RFC 2818
If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing
When you say the full DER form, are you simply referring to the full
blob, or a broken-down representation by key and by extension?
The full blob.
This begs the question: M2Crypto and PyOpenSSL already do what you're
proposing to do, as far as I can tell, and are, as you say, more
On 9/6/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
You mean, providing the entire certificate as a blob? That is planned
(although perhaps not implemented).
Or do you mean expose all data in a structured manner. BECAUSE
IT'S NOT POSSIBLE. Sorry for shouting, but people don't ever get the
In any case, it certainly sounds to me as if there can be multiple
instances of AttributeTypeAndValue with the same type field in a
single Name. So I'll represent them as tuples, which will preserve
the order in which they occur in the certificate, and make the value
immutable.
Ok. I
The DNs of these are structurally different, one being
/DC=org/DC=python/CN=foo/CN=bar and the other
/DC=org/DC=python/CN=foo2+CN=bar2
Ah, I see what you're driving at.
You can inspect them yourself by looking at the certs with openssl:
% openssl x509 -text -in attachment-0002.crt
Certificate:
More succinctly:
% openssl x509 -subject -noout -in attachment-0002.crt
subject= /DC=org/DC=python/CN=foo/CN=bar
% openssl x509 -subject -noout -in attachment-0003.crt
subject= /DC=org/DC=python/CN=bar2/CN=foo2
%
Bill
___
Python-Dev mailing list
Ok. I think this will still not support multi-valued RDNs properly, but
those are uncommon in PKI.
I'm not sure why not... Can you say more?
See the example certificates. If you get (('cn','a'),('email','b')),
you can't tell whether that's two single-valued RDNs in a DN,
or one multi-valued
The hierarchy information does not appear to be preserved.
But it only appears so. OpenSSL does not know how to render it
properly (hence I say it is not very common in PKI), but they
started supporting that when generating certificates, with the
-multivalue-rdn option for req, and if you do
% openssl x509 -subject -noout -in attachment-0002.crt
subject= /DC=org/DC=python/CN=foo/CN=bar
% openssl x509 -subject -noout -in attachment-0003.crt
subject= /DC=org/DC=python/CN=bar2/CN=foo2
Well, that's the same bug that John Nagle complains about.
This output is incorrect.
Regards,
See the example certificates. If you get (('cn','a'),('email','b')),
you can't tell whether that's two single-valued RDNs in a DN,
or one multi-valued RDN with two attribute/value pairs.
Yup, got it. I don't see a way in the OpenSSL library functions I'm
using (X509_NAME_ENTRY_get_object,
Yup, got it. I don't see a way in the OpenSSL library functions I'm
using (X509_NAME_ENTRY_get_object, X509_NAME_ENTRY_get_data) to
distinguish between different RDNs, but I'll take a look at the source
for X509_NAME_print_ex, which does seem to be able to do this.
There's a field on the
Well, that's the same bug that John Nagle complains about.
Yes, I agree.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
There's a field on the X509_NAME_ENTRY struct which gives the level.
OK, I can make it a tuple (list of RDNs) of tuples (one for each RDN)
of tuples (one for each attribute in the RDN). And maybe add a
flatten function to the ssl.py module :-).
See my other proposal as well. As nobody
OK, I can make it a tuple (list of RDNs) of tuples (one for each RDN)
of tuples (one for each attribute in the RDN).
Which gets us to this:
{'issuer': ((('countryName', u'US'),),
(('stateOrProvinceName', u'Delaware'),),
(('localityName', u'Wilmington'),),
'subject': ((('serialNumber', u'2497886'),),
(('1.3.6.1.4.1.311.60.2.1.3', u'US'),),
(('1.3.6.1.4.1.311.60.2.1.2', u'Delaware'),),
(('countryName', u'US'),),
(('postalCode', u'94043'),),
(('stateOrProvinceName',
All of this makes me think that some folks may want to do more
processing on certificates with more advanced tools, and for that they
will need access to the full bits of the certificate. I'll add the
ability to retrieve that as well.
I'm wondering if I should try to pull some extension
I'm wondering if I should try to pull some extension attributes out of
the cert, and add them to the dict, as well. Like subjectAltName, for
instance. Or should we just wait till someone wants it and files a
bug report?
If you have the time and inclination to do that, feel free to. Covering
I'm wondering if I should try to pull some extension attributes out of
the cert, and add them to the dict, as well. Like subjectAltName, for
instance. Or should we just wait till someone wants it and files a
bug report?
If you have the time and inclination to do that, feel free to.
I'm wondering if I should try to pull some extension attributes out of
the cert, and add them to the dict, as well. Like subjectAltName, for
instance. Or should we just wait till someone wants it and files a
bug report?
If you have the time and inclination to do that, feel free
I'm looking at building a frozenset instance as a return value from
a C function, and the C API seems ridiculously clumsy. Maybe I'm
misunderstanding it. Apparently, I need to create a list object, then
pass that to PyFrozenSet_New(), then decref the list object.
Is that correct?
What I'd like
I guess nobody has tried to create frozenset instances from C code
before. Almost everyone uses set anyway. What are you trying to do?
On 9/4/07, Bill Janssen [EMAIL PROTECTED] wrote:
I'm looking at building a frozenset instance as a return value from
a C function, and the C API seems
Bill Janssen schrieb:
I'm looking at building a frozenset instance as a return value from
a C function, and the C API seems ridiculously clumsy. Maybe I'm
misunderstanding it. Apparently, I need to create a list object, then
pass that to PyFrozenSet_New(), then decref the list object.
Is
:[Python-Dev] frozenset C API?
To:python-dev@python.org
I'm looking at building a frozenset instance as a return value from
a C function, and the C API seems ridiculously clumsy. Maybe I'm
misunderstanding it. Apparently, I need to create a list object, then
pass that to PyFrozenSet_New(), then decref
I'm working on issue 1583946. Nagle pointed out that each DN (the
subject and issuer fields in a certificate) may have multiple
values for the same attribute name, and I haven't been able to rule
this out yet. X.509 DNs are sets of X.500 attributes, and X.500
attributes may be either
Raymond, thanks for the note.
You can create a frozenset from any iterable using PyFrozenSet_New().
If you don't have an iterable and want to build-up the frozenset one element
at a time, the approach is to create a regular set (or some other mutable
container), add to it, then convert it
But your point is still well taken. How about this one, though:
PyDict_NEW(int) = PySetObject *
PyDict_ADD(s, value)
ADD would just stick value in the next empty slot (and steal its
reference).
Sorry, I meant to say
PyFrozenSet_NEW(int) = PySetObject *
[Bill Janssen]
How about this one, though:
PyDict_NEW(int) = PySetObject *
PyDict_ADD(s, value)
ADD would just stick value in the next
empty slot (and steal its reference).
Dicts, sets and frozenset are implemented as hash tables, not as arrays, so the
above suggestion doesn't
I'm working on issue 1583946. Nagle pointed out that each DN (the
subject and issuer fields in a certificate) may have multiple
values for the same attribute name, and I haven't been able to rule
this out yet.
This is indeed common. In particular, DN= and OU= often occur multiple
times.
X.509 DNs are sets of X.500 attributes, and X.500
attributes may be either single-valued or multiple-valued.
Conceptually perhaps (although I doubt that).
I got that from David Chadwick's book at http://sec.cs.kent.ac.uk/x500book/.
``An attribute comprises an attribute type and one or
Dicts, sets and frozenset are implemented as hash tables, not as arrays,
I see, thanks.
The location of the next empty slot depends on a the key
associated with the value being added (btw, where is the key handled
in your proposed API?).
What key? It's a set, not a mapping. The value is
In any case, it certainly sounds to me as if there can be multiple
instances of AttributeTypeAndValue with the same type field in a
single Name. So I'll represent them as tuples, which will preserve
the order in which they occur in the certificate, and make the value
immutable. Applications
X.509 DNs are sets of X.500 attributes, and X.500
attributes may be either single-valued or multiple-valued.
Conceptually perhaps (although I doubt that).
I got that from David Chadwick's book at http://sec.cs.kent.ac.uk/x500book/.
``An attribute comprises an attribute type and one or
Here's an example of the new format:
{'issuer': (('countryName', u'US'),
('organizationName', u'VeriSign, Inc.'),
('organizationalUnitName', u'VeriSign Trust Network'),
('organizationalUnitName',
u'Terms of use at
42 matches
Mail list logo
