Does some one have any idea about this, it looks like it fell out
through the night.
On 1/27/06, Joe Gluck <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I have a certificate with dates represented as GMT time.
>
> I am trying to get those times as GMT in a time_t format, is this ok?
>
> ASN1_TIME * not
David Schwartz wrote:
Alright, there's a SEVERE disconnect here versus the description of an
integer as described in the thread "openssl can don' t handle 20 Octes
long Serial Numbers RFC 3280".
If you think there's a disconnect, you are confused.
This needs to be rectified soonest.
Kyle Hamilton wrote:
Alright, there's a SEVERE disconnect here versus the description of an
integer as described in the thread "openssl can don' t handle 20 Octes
long Serial Numbers RFC 3280".
If you substitute 296 with 80, the "SEVERE" disconnect will go away, right?
If so, please consider t
> Alright, there's a SEVERE disconnect here versus the description of an
> integer as described in the thread "openssl can don' t handle 20 Octes
> long Serial Numbers RFC 3280".
If you think there's a disconnect, you are confused.
> This needs to be rectified soonest.
There is
Alright, there's a SEVERE disconnect here versus the description of an
integer as described in the thread "openssl can don' t handle 20 Octes
long Serial Numbers RFC 3280".
This needs to be rectified soonest.
On 1/27/06, Lev Walkin <[EMAIL PROTECTED]> wrote:
>
> The ASN.1 INTEGER type may include
Joe Gluck wrote:
Hi,
I would like to know if there is a Isomorphism between a serial number
represented as a ASN1 and if I had that number in int?
If it is true than i can just use most of the times the original ASN1
as a unique id, instead of parsing it into a int value. (If I know
they are fr
Hi there,
attached are two new files which could replace their namesakes in
demo/easy_tls to get this demo working again. At least for some time... ;)
Ted
;)
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
a5:5a:80:ef:cc:b1:28:82
Signature Algorithm:
Hi,
I would like to know if there is a Isomorphism between a serial number
represented as a ASN1 and if I had that number in int?
If it is true than i can just use most of the times the original ASN1
as a unique id, instead of parsing it into a int value. (If I know
they are from the same issuer
Hi all,
I have a certificate with dates represented as GMT time.
I am trying to get those times as GMT in a time_t format, is this ok?
ASN1_TIME * not_after;
time_t expire;
not_after = X509_get_notAfter(cert); // cert is a X509 object
expire = ASN1_UTCTIME_get(not_after);
will the "expire" hol
Thank you guys for all those great points.
I think I am getting to a conclusion, although some of you were not
concerned about the hashing of the X509_check_purpose() because it
happens only once, I am because yes indeed the one in the cache after
the first time will not need to rehash but the oth
On Fri, Jan 27, 2006 at 03:23:32PM +0100, Stephen Henson via RT wrote:
> > This patch is adding support for TLS hello extensions and externally
> > generated pre-shared key material to OpenSSL 0.9.8.
> Note that some TLS extension code has recently been committed to the
> HEAD (0.9.9-dev). So if
On Fri, 2006-01-27 at 15:23 +0100, Stephen Henson via RT wrote:
> [EMAIL PROTECTED] - Fri Jan 27 15:01:56 2006]:
>
> >
> > This patch is adding support for TLS hello extensions and externally
> > generated pre-shared key material to OpenSSL 0.9.8. This is
> > based on the patch from Alexey Koboze
[EMAIL PROTECTED] - Fri Jan 27 15:01:56 2006]:
>
> This patch is adding support for TLS hello extensions and externally
> generated pre-shared key material to OpenSSL 0.9.8. This is
> based on the patch from Alexey Kobozev <[EMAIL PROTECTED]>
> (sent to openssl-dev mailing list on Tue, 07 Jun 20
Please excuse the previous HTML email. The following is the patch
included in wpa_supplicant.
---
This patch is adding support for TLS hello extensions and externally
generated pre-shared key material to OpenSSL 0.9.8. This is
based on the patch from
Please excuse the previous HTML email. The following is the patch
included in wpa_supplicant.
---
This patch is adding support for TLS hello extensions and externally
generated pre-shared key material to OpenSSL 0.9.8. This is
based on the patch from A
http://www.w3.org/TR/REC-html40/loose.dtd";>
CVS log for hostap/wpa_supplicant/openssl-tls-extensions.patch
CVS log for
hostap/wpa_supplicant/openssl-tls-extensions.patch
Help
Up to [HostAP] / hostap / wpa_supplicant
Request diff between arbitrary revisions
Default branch: MAIN
Boo
On Thu, 2006-01-26 at 16:23 -0700, Kyle Hamilton wrote:
> I'd really like to see this, as it allows for TLS 1.0/1.1 extensions
> (per RFC 3546) based on my initial reading of the patch.
I remailed the patch directly to the list with [PATCH] in the subject.
Maybe that will help :)
/Brian/
--
On Fri, Jan 27, 2006, Richard Salz wrote:
> > I'd consider an implementation of memcmp that doesn't early stop as soon
>
> > as it sees a difference as completely broken, performance wise. Memcmp
> > returns an ordered comparison but that can be done as soon as the first
> > bit difference is
> I'd consider an implementation of memcmp that doesn't early stop as soon
> as it sees a difference as completely broken, performance wise. Memcmp
> returns an ordered comparison but that can be done as soon as the first
> bit difference is seen.
Me too. But look at the ASN1 for a certificat
On Thu, Jan 26, 2006, Joe Gluck wrote:
> That attack is interesting, how can that be done, (sorry for bothering you
> :-) )
>
If you don't check the parameters its is possible with some algorithms to
generate a key pair with a given public key component using a carefully
derived set of paramete
Richard Salz wrote:
So now the question is, are there times when you can avoid the memcmp?
[...] compare some initial bytes. [...]
only call memcmp if they match.
[...]
I'd consider an implementation of memcmp that doesn't early stop as soon
as it sees a difference as completely broken, perfo
21 matches
Mail list logo
