Brett Cannon wrote:
> Neal, Anthony, Thomas W., and I have a spreadsheet that was started to
> keep track of what needs to be done in what needs to be done in 2.6
> for Py3K transitioning:
> http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg . I am
> opening the spreadsheet up to every
Neal Becker over on python-3000 said that the Boost people could use
this. Figured it was time to present it officially to the list to see
if I can get it added for 2.6/3.0.
The implementation in the sandbox works in both 2.6 and 3.0 out of the
box (no 2to3 necessary) so feel free to play with it
After a great deal of discussion, under the Subject line of "frozenset
C API?" (you may have missed it :-), I'm coming to the conclusion that
in revealing the fields of an SSL certificate, less is more.
>From one of the messages in that thread:
I'm trying to give the application the ability to
I've transferred everything from my spreadsheet to Neal's.
On 9/5/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Neal, Anthony, Thomas W., and I have a spreadsheet that was started to
> keep track of what needs to be done in what needs to be done in 2.6
> for Py3K transitioning:
> http://spreadshee
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 g
> 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 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 e
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
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
> 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
> 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
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 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
13 matches
Mail list logo
