Re: OCSP nonce was: RE: cvs commit: openssl/ssls3_lib.cssl.hssl_algs.cssl_ciph.cssl_locl.h tls1.h
Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] (Peter Gutmann)
pgut001 Given that (statistically speaking) the client will be a
pgut001 Windoze box with a time which is more or less random, the use
pgut001 of absolute timestamps doesn't add much, it would have been
pgut001 better to use nonces+relative times ("The next update is 5
pgut001 minutes from when you got this response", with an implied "If
pgut001 this response took more than a minute or so to get to you, be
pgut001 suspicuous").
Sounds fine, except for the little detail that it's usually hard to know how
long it took a packet to come from A to B, let alone an OCSP response that
might (think of the really small ATM packets :-)) be broken into pieces.
Uhh... I can tell exactly how long it took to get from A to B by measuring the
response time for a query. If it's longer than (say) a minute, I regard it as
suspect. That's the one time measure which is useful, the local system can
determine whether a response is fresh (assuming the use of a nonce) no matter
how bogus its own time setting is, and if it knows it has a fresh response it
can use the relative time in there to determine when (again, relative to its
own idea of the time) an update will be available.
we might see time syncronisity (sp?) as a standard in windows and whatnot in a
couple of years.
I'm sure Microsoft will add that right after they get ActiveX security sorted
out and finish making Outlook immune to trojans :-).
Peter.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: OCSP nonce was: RE: cvs commit: openssl/ssls3_lib.cssl.hssl_algs.cssl_ciph.cssl_locl.h tls1.h
"Florian Oelmaier" [EMAIL PROTECTED] writes:
We do the same, as we directly connect to the CA-database, but we set
thisUpdate to the actual time as this seems to make more sense. It would be
fine to have an option within OpenSSL that says: "Trust only responses with a
thisUpdate not more than x minutes old". As the RFC for states for the field
thisUpdate: "The time at which the status being indicated is known to be
correct". Most security policies will include some requirements for OCSP-
Clients regarding this point.
There was a comment on the PKIX list a while back to the effect that the time
on the average peecee is usually out by anything from minutes to days (I've
never seen one that's that far out, but being off by a few hours seems fairly
common). Because of this I wouldn't place too much reliance on timestamps
unless the client and server negotiate a common time, which OCSP doesn't do
because there's no provision for allowing the client to indicate what time it
thinks it is. Given that (statistically speaking) the client will be a Windoze
box with a time which is more or less random, the use of absolute timestamps
doesn't add much, it would have been better to use nonces+relative times ("The
next update is 5 minutes from when you got this response", with an implied "If
this response took more than a minute or so to get to you, be suspicuous").
(Insert standard grumble about the fact that if you want to break a number of
cert management protocols which carefully sign/MAC/whatever everything, all
you need is a client running Windows or Unix without NTP or some equivalent,
or the ability to spoof NTP et al if they are. My code generally ignores
timestamps because of all the problems I found with false rejections on
systems with the time set wrong. If anyone else has any feedback from the
real world on this I'd be interested in hearing it).
Peter.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: test rsa values -- format?
Rodney Thayer [EMAIL PROTECTED] writes: by the way, dumpasn1 doesn't quite parse this correctly, it's got n, d, p, q, dmp1, dmq1, and iqmp. The display of 'n' is missing the last byte. Can you send me the file? (I assume that's my dumpasn1 you're referring to). Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OCSP responder addresses?
Michael StrM-vder [EMAIL PROTECTED] writes: Dr S N Henson wrote: So does anyone have some responder addresses I can test this stuff against? http://www.valicert.com/ocsp/ - you might already know this... Isn't that the one where all the certs (on the interop web page anyway) have expired? Can you let me know your test OCSP responders in case they are public? If there are any more they're pretty well hidden, the ones I know of all seem to be either undocumented or by invitation only. There must be some in operation somewhere in Europe because they're required by things like ISIS, but I've never been able to discover them. Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OCSP responder addresses?
Rich Salz [EMAIL PROTECTED] writes: You might look at Identrus, www.identrus.com, since their requirement for OCSP drove many vendors, and see what partners and vendors they list. That's one of the by-invitation-only ones (they were nice enough to let me use it for interop testing, but I don't think you can do that normally). Finding vendors who want to sell you their OCSP toolkit isn't that hard, but finding someone who's actually running the stuff (and who will give you access) is a bit trickier. Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OCSP responder addresses?
Dr S N Henson [EMAIL PROTECTED] writes: So does anyone have some responder addresses I can test this stuff against? I currently know of two and there must be several more out there. That may be all there are, I was testing this a while back and had a hell of a time finding any responders which were still operational (some have expired certs, some are there but not publicly available, and most seem to have either shut down or just gone away). I'll send a private reply with more info about a private one which let me do some testing. In the meantime if anyone knows of an active, publicly available, fully functional OCSP responder I'd be interested to hear about it. Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CRLs and self-signed root certs.
Goetz Babin-Ebell [EMAIL PROTECTED] writes: Everybody can issue a CRL. Only a CA with CRL signing enabled can issue a CRL. A CA can issue a CRL with own revokated certificates but it can issue a CRL with revoked certificates of other CAs (at least in X509v3...) A CA can't revoke another CA's certificates, only certificates which it has issued. Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CRLs and self-signed root certs.
Goetz Babin-Ebell [EMAIL PROTECTED] writes: Peter Gutmann wrote: Goetz Babin-Ebell [EMAIL PROTECTED] writes: Everybody can issue a CRL. Only a CA with CRL signing enabled can issue a CRL. Everybody who can generate a certificate with the propper flags can generate a CRL. Sure, but this presupposes: A CA can issue a CRL with own revokated certificates but it can issue a CRL with revoked certificates of other CAs (at least in X509v3...) A CA can't revoke another CA's certificates, only certificates which it has issued. [...] But in the definition of a CRL I didn't find anything saying that it can only revoke own certificates... The standard can say pretty much anything it wants on the topic, but given that most current apps barely support any kind of CRL checking I'd say the usefulness of issuing one of these cross-CRLs is slightly lower than that of opening your window and shouting "Certificate 1234 from CA xyz is now revoked" out into the wind (at least one or two people will take notice of that, if only to shout back at you to shut up :-). Look at the way Sun revoked their CA cert a while back for an example of how far CRL functionality is trusted in the real world, and then extrapolate from normal CRLs to cross-CRLs... Does anyone know of any generally-available (non-special-case, single-vendor, customised, etc etc) application which will handle one of these cross-CRLs? Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CRLs and self-signed root certs.
Mats Nilsson [EMAIL PROTECTED] writes: Should a self-signed root certificate ever need to be revoked, shall it list itself in its usual CRL(s), as the last thing it does before it is thrown away, or is it sufficient (from its users' standpoint) that it simply ceases to issue more CRLs? Noone knows (and I don't just mean that as a shoulder-shrug response, I mean that noone, at least on the PKIX list, actually knows what's supposed to happen in this situation). The behaviour from current apps is that some will accept a self-revocation, some will reject it, and a small number will crash or fail in some other way. Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: iis certificate renewal woes
nagendra [EMAIL PROTECTED] writes: I've appended the PKCS#7 request generated by IIS to the end of this email. IIS creates the header "BEGIN NEW CERTIFICATE REQUEST", which is interpreted as an old X509 request (see pem.h). Ohgodohgod what a mess! That's PKCS #7 signed data containing a data payload within which is a cert request with MS's gratuitously-incompatible CRMF extensions which aren't CRMF extensions, one of which is a certificate which is used to sign the PKCS #7 data. I think non-MS applications should contain code to specifically reject this type of stuff on the grounds that working with it probably violates portions of the Geneva convention. Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: 0.9.6 incompatible with 0.9.5a on Win32
Jeffrey Altman [EMAIL PROTECTED] writes: Quoting from Peter Gutmann's paper when he describes the use of the ToolHelp library: "Since even a moderately loaded system can contain over 500 heap objects and 50 modules, we need to limit the duration of the poll to a second or two, which is enough to get information on several hundred objects without halting the calling program for an unacceptable amount of time ..." Note that that's for Win16 on a 386/486, where the poll really will freeze the system. For Win95 et al this isn't an issue, both because it won't stop every other process and because systems running '95 have to be a little bit faster than a '386. BTW, the reference to Mr. Gutmann's paper in the code should be updated. The list reference no longer exists. This reference looks like it may stay around for a while: http://www.usenix.org/publications/library/proceedings/sec98/gutmann.html The paper will always be available via my home page, http://www.cs.auckland.ac.nz/~pgut001, which isn't going away any time soon, you can also get an much expanded and updated version from there which is newer than the Usenix paper. BTW (as a comment on a later thread) you could save yourselves a lot of effort by just pulling the necessary code out of cryptlib (it's available under the GPL, BSD license, or whatever else you want), since there are a number of further bugs in Windows which you haven't run into yet but probably will in the future (look for the long text block comments in rndwin32.c :-). Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Outlook certs - bug in MS or OpenSSL?
PaweM-3 Krawczyk [EMAIL PROTECTED] writes: My question is if this is a bug in MS software (it shouldn't be generating such certs), or OpenSSL is getting this wrong as a signed number? AFAIK it's bugs in both. MS have always got the sign bit wrong in their encoding, but it's not that much of a problem because all the vendors know this (or just expect it from MS without even bothering to check :-) so they treat ints as unsigned (actually there's nowhere in any cert-relevant code which uses signed ints, I expect most implementations always treat them as unsigned). From the OpenSSL side, it looks like it's doing something with the sign bit, so the integer gets transformed into a completely different value. This may be due to recent changes, ISTR that SSLeay always assumed the numbers were unsigned. As for the size in bits, that's normal, you don't always get exactly what you asked for (check your PGP keyring for examples). Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL win32 build settings
Borland has made its command-line compiler tools freely available: http://www.borland.com/bcppbuilder/freecompiler It's not quite free, they make you run a serious gauntlet of registation and logging and cookies and javascript before you can finally get a copy. It'd be less painful if they just let you grab it for $19.95, no questions asked. Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Adding BF to tls WIN32 static linking of ssl libraries.
Dr Stephen Henson [EMAIL PROTECTED] writes: It would be possible to add BF cipher suites giving them experimental numbers but ideally some "official" numbers should be used. There's an infintely-delayed informational RFC for BF which I have sitting on a machine somewhere, if it's required (to have something to refer to) I can resuscitate that. Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PERL Module Problem...
Dr Stephen Henson [EMAIL PROTECTED] writes: Is there any circumstances where the environment isn't safe? I believe extra privs are normally needed to read another users processes environment. Under DEC Unixen you can read anyone's environment without any extra privs (ps -wwae or a variant thereof, depending on which vintage of OS you're on). Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: X9.42 DH test vectors.
Dr Stephen Henson [EMAIL PROTECTED] writes: One problem with X9.42 DH. I haven't seen any examples of the domain parameter generation (the one based on DSA) that have m 160 (Other then the S/MIME examples stuff which so far I can't reproduce and which no one says they've independently verified). They all have m = 160. Certain parts of the algorithm aren't used unless m 160. So has anyone got any examples or can generate some I can independently verify? Its just the domain parameter stuff I'm after, I've lots of test data for the other parts of the algorithm. Sure, what form do you want it in? DSA-signed DH cert? Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: HELP
"Sean O'Dell" [EMAIL PROTECTED] writes: HELP "What was the name of the Beatles film released in July 1965?". That's correct, and it looks like he's won a chance to read the FAQ... Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: DN formats
Chris Ridd [EMAIL PROTECTED] writes: I read Peter Guttmann's screed on X.509 and char sets last night - interesting, though he does fall into the trap of discussing all the myriad of drafts, and forgetting that these are just drafts. The standards themselves are less ambiguous. The reason I have to cover what's in drafts is because most of what's out there is implemented from drafts rather than final standards (leading to problems like the one where the policy qualifiers display text in RFC 2459 was quietly changed from what it had been in every draft version, so everything which implemented it based on the draft got it wrong using the final version, and vice versa). Because of the incredibly long time it takes to get these things finished and the fact that the typical product development cycle is a small fraction of the standard development cycle, what's being shipped is based on drafts, not on final standards. The most extreme cases I've seen of this is comments like "We know this is a version 0.01 draft and full of bugs, but we already have products shipping based on it and so it's too late to change it" (I'll leave the vendors/drafts anonymous, and it's not just PFX either :-). Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: References: where ?
Ben Laurie [EMAIL PROTECTED] writes: I am in search of the following references. Does anybody know where them can be found? ISO/IEC 8824-1:1995: Information technology - Abstract Syntax Notation One (ASN.1) -- Specification of basic notation. 1995 Haha. Prepare to be thoroughly amused, and at vast expense. Once you have these (having paid through the nose for someone to press "print" [and in my case having to reprint because they then punched holes through the text]), you'll find that they refer to yet other expensive documents. Probably until you've bought every piece of nonsense ever written by ITU. This is one characteristic which the ISO shares with the FSF (to use GNU foo you first need to install GNU everything-else). In any case there's a fairly good chance that when/if you do get the standard, you'll find it almost incomprehensible, particularly all the extras beyond the basic notation. A much easier way to learn ASN.1 is to get the introduction to ASN.1 written by Burt Kaliski, which is available (for free) from RSA's web site. By buying the standard you tend to lose twice, once by having to pay a lot of money for it and again by ending up with something which you can't make head or tail of. Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Image or voice extension.
"Qin, Xiangping" [EMAIL PROTECTED] writes: I wish to add some image or voice to the certificate. Can you give me some advice on how to do it? Just define an OID and put it in the altName as an otherName. I did this about a year ago for the MPEG-of-cat certificate, which you can get from http://www.cs.auckland.ac.nz/~pgut001/pubs/dave.der, with the CA cert at http://www.cs.auckland.ac.nz/~pgut001/pubs/dave_ca.der. I was pleasantly surprised to see that neither Netscape nor MSIE crashed when fed this cert, NT didn't bluescreen, and no smoke came from my hard drive. That covers the "how", now the "why": It doesn't make any sense to do this because nothing will be able to handle it (unless you write the code for it yourself). If it's for a specialised application (or to make a point and for a laugh, which is what the MPEG cert was intended for) then it's OK, but you wouldn't in general want to do this - if you're putting data like this in a cert then it's a sign that there's something wrong in the overall design. Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug in d2i_X509_CRL_INFO ?
"Paul Keogh" [EMAIL PROTECTED] writes: I have a problem decoding a CRL which is missing the VERSION field but which has extensions present. This is a known problem with CRL's, to accomodate these things you have to ignore the version number and be prepared to handle extensions regardless of what the version tells you. Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: UNSUBSCRIBE
Is it still illegal to kill people who post unsubscribe messages to mailing lists? Normally I'd let it pass, but since he posted the same thing multiple times after having mixed in a bucketful of HTML and passed it through a blender set on "frappe", I think the application of http://dazed.slacker.com/lists/clueless.html is in order. Anyone want to do the honours? Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl STATUS
The best way is to talk Peter Gutmann into donating his randomness-gathering code (or to implement something similar). For efficiency that should probably be combined with a seed file. This has already been done so it could be used with GPG (actually it's always been available for the asking, but recently I made it more official). Grab the latest beta from http://www.cs.auckland.ac.nz/~pgut001/cryptlib/download.html and start with lib_rand.c, which contains the following (RMS-approved :-) usage notice: /* This module and the misc/rnd*.c modules represent the cryptlib continuously seeded pseudorandom number generator (CSPRNG) as described in my 1998 Usenix Security Symposium paper "The generation of random numbers for cryptographic purposes". The CSPRNG code is copyright Peter Gutmann (and various others) 1996, 1997, 1998, 1999, all rights reserved. Redistribution of the CSPRNG modules and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice and this permission notice in its entirety. 2. Redistributions in binary form must reproduce the copyright notice in the documentation and/or other materials provided with the distribution. 3. A copy of any bugfixes or enhancements made must be provided to the author, [EMAIL PROTECTED] to allow them to be added to the baseline version of the code. ALTERNATIVELY, the code may be distributed under the terms of the GNU General Public License, version 2 or any later version published by the Free Software Foundation, in which case the provisions of the GNU GPL are required INSTEAD OF the above restrictions. Although not required under the terms of the GPL, it would still be nice if you could make any changes available to the author to allow a consistent code base to be maintained */ Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FW: Color me Stupid...
"Chad C. Mulligan" [EMAIL PROTECTED] writes: As far as I know El-Gammal has everything you want from PKC and it's used in GNU's GPG, the PGP replacement. It's unpatented, too, and free for use anywhere. So why hasn't anyone ever put an El-Gammal cipher suite in an SSL implementation? Is it something that's been just missed, or am I missing something VERY obvious? The problem is that you're relying on draft-rfced-info-gutmann-elgamal-01.txt for the X.509 profile for Elgamal, which isn't very widely accepted (in fact I know of only one piece of software which implements it). If it was in OpenSSL, you'd be limited to communicating with other OpenSSL implementations. Peter. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
