,
--David Shambroom
--
W. David Shambroom, Ph.D.
Security Architect, InterSystems Corporation
w...@intersystems.com; 617.551.2143; fax: 617.494.1631
__
OpenSSL Project http://www.openssl.org
Development
Thank you for the correction. Obviously the the authorityCertIssuer
must correspond to the authorityCertSerialNumber. Please close this ticket.
On 9/13/2012 4:40 AM, Erwann Abalea via RT wrote:
Bonjour,
The goal of this function is to determine if a given
authorityKeyIdentifier extension
Thank you for the correction. Obviously the the authorityCertIssuer
must correspond to the authorityCertSerialNumber. Please close this ticket.
On 9/13/2012 4:40 AM, Erwann Abalea via RT wrote:
Bonjour,
The goal of this function is to determine if a given
authorityKeyIdentifier extension
this should be:
if(nm X509_NAME_cmp(nm, X509_get_subject_name(issuer)))
^^^
I have tested and verified this fix.
Best regards,
--David Shambroom
__
OpenSSL Project
ABALEA wrote:
Hodie VII Id. Aug. MMX, David Shambroom scripsit:
See:
http://www.ietf.org/rfc/rfc5280.txt
RFC5280 is only a profile for X.509 certificates and CRLs, just were
RFC3280 and RFC2459 before it. Hopefully, RFC5280 is of better quality
than its predecessors, but doesn't replace
See:
http://www.ietf.org/rfc/rfc5280.txt
Kyle Hamilton wrote:
I was asked this morning where to find the X.509 specification, since
http://itu.int/ is such a messy website.
I'll point you to the general location, because it's a better piece of
information to have than the exact location.
What are the thoughts of the core development team about the prospects
for adding full RFC 5246 (TLS 1.2) support to the libraries? (I looked
in the archives and didn't find much, although that doesn't necessarily
mean it's not in there.) Very roughly speaking, what do you think the
resource
Actually, a TLS/SSLv3 ClientHello message begins with the byte sequence:
offset value
0x000x16content type Handshake
0x010x03major version
0x020x00-0x03 minor version
0x030x length
0x050x01handshake type ClientHello
RFC5246, Appendix A.
at 2:13 AM, David Schwartz [EMAIL PROTECTED] wrote:
David Shambroom wrote:
You're right: You are completely wrong. /dev/urandom never blocks.
See the man page.
Is this is the excerpt from the man page you are referring to?
A read from the /dev/urandom device will not block waiting
You're right: You are completely wrong. /dev/urandom never blocks.
See the man page.
David Schwartz wrote:
Tried many many times, even two running at the same time
or poll timeout set to zero, not one instance of blocking
even with
od -x /dev/urandom
and
od -x /dev/random
running
In util\pl\VC-32.pl, all instances of $dbg_cflags need to include the
switch /Zi. Tested successfully with 0.9.8d and Visual C++ 8.
__
OpenSSL Project http://www.openssl.org
Development Mailing
openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
W. David Shambroom, Ph.D.
Security Architect 617.551.2143
InterSystems Corporation[EMAIL PROTECTED
Try
openssl speed rsa
Private key (large exponent) operations are 1-2 orders of magnitude
slower than public key (small exponent), easily observed. Depending on
key length and traffic volume this can be very important.
--David
Annie Yousar via RT wrote:
Small exponents give the advantage
b4 c5 5a
I will be opening a support case with Sun.
--David
--
W. David Shambroom, Ph.D.
Security Architect 617.551.2143
InterSystems Corporation[EMAIL PROTECTED
14 matches
Mail list logo
