On Mon, 9 Jun 2003 [EMAIL PROTECTED] wrote:
> Hi,
>
> It seems to me that the possibilty that spammers might harvest PGP
> keyservers for email addresses is a serious disincentive to using
> keyservers. Does anyone have any thoughts on this?
>
There are plenty of sources from which harvest email
On Tue, 24 Jun 2003, Ian Grigg wrote:
> http://sslbar.metropipe.net/
>
> Fantastic news: coders are starting to work
> on the failed security model of secure browsing
> and improve it where it matters, in the browser.
>
> This plugin for Mozilla shows the SSL certificate's
> fingerprint on the we
On Mon, 7 Jul 2003, Hack Hawk wrote:
> So what they're saying is that your PRIVATE key is stored on a server
> somewhere on the Internet?!?!
>
No, this (like Kerberos) works best in a federated model. Each
organization (or group of organizations that trust a common third
party and have mechanisms
On Sat, 6 Sep 2003, Perry E. Metzger wrote:
>
> For making things like IP fragmentation ids and other similar protocol
> elements unpredictable, it would be useful to have what I'll call a
> cryptographic ergodic sequence generator -- that is, a generator that
> will produce a sequence of n bit nu
file useless for fraud. slightly
> related discussion of the "security proportional to risk" and the
> vulnerability represented by the merchant transaction file
Is X9.59 actually in use for consumer retail transactions anywhere?
--
Victor Duchovni
IT
On Thu, 18 Sep 2003, edo wrote:
> Maybe it works as a very, very weak form of encryption, one which can
> be decrypted at a glance by humans but would evade the most simplistic
> computer recognition systems. But stego it ain't.
>
Steganography is in the eye of the beholder.
--
Viktor.
On Fri, 19 Sep 2003, martin f krafft wrote:
> But Newton gets more wrong the faster you go. So it's not F = m.a,
> that theory was only a good approximation, nothing more.
Actually it still is F = m.a, but the numbers depend on the observer.
F=m.a is a fundamental consequence of the conservation
inguish between "Run" and "View" all Graphical Shells will be
insecure.
--
Victor Duchovni
IT Security,
Morgan Stanley
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
iable, and is one of the pre-requisites for a more
secure UI, along with the previously discussed trusted path issues,
non-spoofing of the security interface, ...
--
Victor Duchovni
IT Security,
Morgan Stanley
--
omposition. Do you consider those
> systems to be trivial, or broken? What is the reason these systems
> cannot exist in theory or practice?
>
What fraction of "real" users will be able to use these systems? Will
users really understand
work done while a TLS negotiation
is in progress, or to gracefully time out the TLS negotiation if progress
is too slow. This means that the caller should be able to tear down the
state of a partially completed connection at any time without memory leaks
or other problems.
--
Victor Duc
On Sat, 6 Dec 2003, Will Rodger wrote:
> Steve Bellovin wrote:
> >http://edition.cnn.com/2003/TECH/internet/12/05/spam.yahoo.reut/
>
>
> Does anyone have details? How much overhead would this entail?
>
To avoid replay attacks one needs to sign a string that is tied to a
specific message or time
On Sun, 7 Dec 2003, Anton Stiglic wrote:
> But you should be sending mails via *your* SMTP server, and should be
> connecting to that SMTP server using SSL and authentication. Open relays
> encourage spam. People shouldn't be relaying mail via just any SMTP server.
>
This is misguided, but we s
ok & OE), so they have a better chance of getting their technology
adopted, but even Microsoft has a hard time getting users to upgrade from
Windows 98/Office 97 which continue to perform well enough for most users
(security flaws and all).
--
Victor Duchovni
On Thu, 1 Jan 2004, Ed Reed wrote:
> I'm curious, Victor - do you use any functions to verify that the
> sender's
> email address is "live" to insure that a valid "reply" is possible?
No, this is not known to scale well to large sites. Also widespread
adoption of sender verification encourages jo
On Thu, 1 Jan 2004, Amir Herzberg wrote:
> IMHO, your conclusion is wrong: cryptographic authentication could be a
> critical tool to stop spam; someone in our community should do this (write
> the software) already... How? E-mail (at least from new correspondents)
> must be signed by an `anti-spa
On Sat, 3 Apr 2004, Hadmut Danisch wrote:
> What if a cryptographer is found to intentionally have given a false
> expertise in cryptography and security just to do a colleague a favor,
> when he erroneously assumed the expertise would be kept secret? Would
> such a cryptographer be considered as
ing the
ills)?
We get too carried away with spam, as threats to our way of life there are
far more serious problems...
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender.
On Sun, 4 Jul 2004, Anne & Lynn Wheeler wrote:
>
>
> http://www.thisislondon.com/news/business/articles/timid80044?source=
> http://www.thisismoney.com/20040704/nm80044.html
>
> ONE of Britain's biggest banks is asking customers to use cash
> machines as little as possible to help combat soaring c
ary finite set theory, not computer science
(whatever that is :-). All proofs will involve some mathematics. The
above is I think simpler than your original argument and is the simplest
I can come up with...
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN
strings.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
text
the zeta function, suitably transformed so that the critical line is
mapped onto the reals, becomes a self-adjoint operator. To go from
this to the reported claim is at least premature and likely ludicrous.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAI
ng the trusted third party
> (currently the CA) out of the shadows and into the light.
>
RSA is useful for more than X.509... and of course the reporter is prone
to flights of fancy...
--
/"\ ASCII RIBBON
\ / CAMPAIGN Victor Du
rather puzzling... Does anyone know why Du Sautoy is making this claim
(if it is indeed reported correctly).
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sende
"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
nd DHE?
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
On Sun, Dec 19, 2004 at 05:24:59PM +0100, Florian Weimer wrote:
> * Victor Duchovni:
>
> > The third mode is quite common for STARTTLS with SMTP if I am not
> > mistaken. A one day sample of inbound TLS email has the following cipher
> > frequencies:
> >
> >
as an external entropy source.
I have not followed the debian issue, perhaps that really is just an
Exim+TLS design problem...
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security,
eived in error, \ /
CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
and use is prohi
On Fri, Feb 11, 2005 at 11:31:16AM -0500, Tim Dierks wrote:
> On Thu, 10 Feb 2005 15:59:04 -0500, Victor Duchovni
> <[EMAIL PROTECTED]> wrote:
> > If the symmetric cypher is fully re-keyed when sessions are resumed
> > while avoiding the fresh start PKI overhead, the
anything else? In what sense is the second public key
useful to the attacker?
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAIL
On Sat, Mar 05, 2005 at 09:23:11AM -0700, Anne & Lynn Wheeler wrote:
> Victor Duchovni wrote:
> >What is the significance of this? It seems I can get a certificate for
> >two public keys (chosen, not given) while only proving posession of the
> >first. Is there anything e
On Wed, Mar 16, 2005 at 02:23:49AM +1300, Peter Gutmann wrote:
> Certainly with UIXC it's not worth anything.
>
What is UIXC?
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST
ase
apply suitable prods to maintainers, as the code has been available for
some time).
The key obstacle was to allow Kerberos mutual auth to not only log the
user in, but to also authenticate the server despite any mismatch in the
(now ephemeral) RSA keys.
--
/"\ ASCII RIBBON
ror will be data dependent, and Dan's attack may apply.
This is speculative. Has anyone studied the applicability of Dan's
attack to a Kerberos 5 KDC with an AES TGS key?
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni
elations.
Quantizing the error response delay could solve this problem, though
I for one don't know how to do that portably in a way that guarantees
no leakage of timing information.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchov
TICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
ata correlation from all
"observables" other than the final output.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender do
relation with any any single intermediate result, is that strong
enough?
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ H
er with and should
accept only a single set of accounts (so that stolen pin numbers are not
portable)...
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not w
fraud in 1999, droped at $200M in 2003.
>
Whose loses do these numbers measure?
- Issuer Bank?
- Merchant?
- Consumer?
- Total?
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destro
ic, in Europe it was
the Comanches.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley
e (passing B's name and the url the user
wanted), and A redirects the user back to B's federated login verification
page passing back the authentication data and the original url, so the user
is taken to the right place after the credentials are verified.
--
/"\ ASCII RIBBON
given any automorphism group on the input strings, hashing
the lexicographically smallest member of the orbit of an input string
under the group gives a hash that is invariant under the group operation.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Vict
some. :-)
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privi
ossibly related:
http://www.redflex.com.au/traffic/pdfs/RedflexSpeed2V2.pdf
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MA
ted to make the pre-computation
feasible.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan St
uot;\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
CII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
;\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privil
>primitives.
>
> So wouldn't the world be a better place if we could all agree on a
> single such library? Or at least, a single API. Like the STL is for C++.
>
Yes, absolutely, but who is going to do it?
--
/"\ ASCII RIBBON NOTICE: If receiv
>
You could consider hashing Just all ... content,
the action URIs of all forms, and the targets of all links, ignoring
superficial content changes and changes in layout (sort the hashed
items).
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Vi
atrix requires increasingly prohitive quantities
of RAM. Read the DJB hardware GNFS proposal.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \
parties get random
numbers, and no-one feels cheated if they like the randomness of their
own contribution to the protocol.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender.
On Fri, Dec 02, 2005 at 10:13:21PM -0200, [EMAIL PROTECTED] wrote:
>
> Well, you just can't prove a PRNG is secure. It would be like proving that
> the AES
> is secure, or that factoring integers is hard. It just can't be done (aside
> theoretical
> discutions about P=NP).
>
Actually, this
On Sat, Dec 03, 2005 at 10:47:52PM -0600, Travis H. wrote:
> On 12/3/05, Victor Duchovni <[EMAIL PROTECTED]> wrote:
> > Actually, this is inaccurate, proving the strength of AES or factoring is
> > difficult, and may never happen, we may even prove AES to be not secure
> &
On Mon, Dec 05, 2005 at 02:21:02AM -0600, Travis H. wrote:
> On 12/4/05, Victor Duchovni <[EMAIL PROTECTED]> wrote:
> > Wrong threat model. The OP asked whether the system generating random
> > numbers can prove them to have been "randomly" generating to a passive
&
es not make the problem of key management go away.
My *personal* view is that patent encumbered technologies don't have a
major role to play in anything quite as ubiquitous as email.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovn
vate keys. If you must police the users, hand them their keys
on smart cards (or other suitable hardware) that you initialize.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security,
32.c: log_fatal ( "rndw32: failed to take a toolhelp snapshot\n" );
cipher/rndw32.c: log_fatal("can't run on a W32s platform\n" );
cipher/rsa.c: log_fatal("RSA operation: public, secret failed\n");
cipher/rsa.c: log_fatal("RSA operation: secret, public faile
IK common with HTTP servers, but the majority of TLS capable MTAs
negotiate EDH ciphers.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML
able to access a resource is not an "impossible"
state. Impossible states are corruption of internal data structures,
invalid function arguments, ... Failure to obtain seed data is an
error and needs to be reported as such.
--
/"\ ASCII RIBBON NOTICE: If received
)... The Postfix TLS functionality
is built over OpenSSL (not GnuTLS) and OpenSSL has an error stack, which
the application can process as it sees fit. The libgrypt approach to
error reporting is not acceptable.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAI
complete the process.
... [Geotrust] doubted that inserting a human into that process
would have flagged the account as suspicious.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST
caller.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
ferent functions and rea-
sons.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privile
not expect any controversy on this point, and don't
expect views to shift dramatically. If the developers were open to the
issue, the request might have been fruitful. If they dig in their heels,
I am free to use other libraries.
--
/"\ ASCII RIBBON NOTICE: If recei
ersonal real-world relationships...
I think that key management (while quite difficult) is not even the real
problem, the more intractable problem appears to be trust management:
how to distinguish a con from the real-thing... This problem is also
applicable to the real-world, but the digital manifes
Thunderbird to treat each of us as a trusted CA :-(
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confiden
zed and abuse
issues will be the same as for email. You can't fence the bad guys
out of the network.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Securi
olve
global federation of universally interoperable systems...
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMor
ust as bad as for email. The problem is intrinsic, is not
the result of lazy RFC writers.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/
nes of Goedel's
incompleteness theorem, any universally deployed federated communications
medium will exhibit spam.
Either it is not mature enough, or it has spam.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy an
that email is, and will escape the
problem by avoiding scope creep.
I am willing to speculate that people will continue to unfairly tarnish
the competence of the email RFC writers, without regard to the intrinsic
properties of the medium.
--
/"\ ASCII RIBBON NOTICE:
this is a popular viewpoint, but I suggest that it misses the
*intrinsic* difficulty of the problem.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not wa
gt; Depends on the trust model. May not work.
Indeed, but it looks to be the right security model for the mass market.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sende
s which is in principle available from
the distribution of the generator outputs and the deterministic functions
that create the sequence.
Actually calculating the entropy for real-world functions and generators
may be intractable...
--
/"\ ASCII RIBBON NOTICE: If received in err
is fashion...
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
On Wed, Mar 29, 2006 at 10:51:08AM +0200, [EMAIL PROTECTED] wrote:
> In am nearly sure that a preimage attack (MD5) will be found in the
> next two or three years.
Is there already evidence of progress in that direction?
--
Viktor.
--
e detail available?
As soon as data is stored, new key management issues come to the surface.
I for one would not want to lose my hard-drive if the CPU is fried...
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and not
ger) namespace, while subjects or users
in ACLs are often local system specific entities. This means that one
often needs a mapping from principals (global naming) to subjects/users
(local naming). So principal != account.
--
/"\ ASCII RIBBON NOTICE: If received in error,
lock device implementations that
are file system agnostic, cannot violate block update atomicity and so
MUST not offer integrity.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security,
pitfalls.
TLS (available via OpenSSL) provides integrity and authentication, any
reason to re-invent the wheel? It took multiple iterations of design
improvements to get TLS right, even though it was designed by experts.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN
On Sun, May 14, 2006 at 07:56:17PM -0500, Travis H. wrote:
> On 5/14/06, Victor Duchovni <[EMAIL PROTECTED]> wrote:
> >Security is fragile. Deviating from well understood primitives may be
> >good research, but is not good engineering. Especially fragile are:
>
> Poin
onses.
Ultimately, to close similar security issues in many other protocols,
we need a secure DNS, but I am somewhat pessimistic about the likelihood
of this happening soon.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please de
at work *together* "securely" in
a reasonable fashion, or are we still building the tower of Babel (now
in software). A more trustworthy DNS would IMHO be a good foundation.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please
NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
and use
NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \ HTML MAILMorgan Stanley confidentiality or privilege,
at least as trained today,
but it is not likely possible to design a training program that will
a preponderance all strong defensive programmers).
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
alf of the inputs outside a cycle and half
inside a cycle. None of this should lead to any apparent weakness after
a modest number of iterations.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST
On Wed, Oct 18, 2006 at 12:00:41AM -0400, Victor Duchovni wrote:
> Hash functions are supposed to be pseudo-random. For a 160 bit hash In
> an input set of 2^80 elements we should expect to find a collision...
>
> If we iterate from a random starting point we expect to enter a cycle
caches on both sides only does one SSL handshake per
cache TTL and then just bulk crypto for many deliveries that reuse the
cached SSL session.
So what is your load like?
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please des
On Wed, Jan 10, 2007 at 06:31:21PM -0500, Steven M. Bellovin wrote:
> I just stumbled on a web site that strongly believes in crypto --
> *everything* on the site is protected by https. If you go there via
> http, you receive a Redirect. The site? www.cia.gov:
>
> $ telnet www.cia.gov 80
> Try
at I can make sure that my code is a correct use of the interface,
that I am not making unfounded assumptions, and there are no obvious bugs
in the part of the library that I am reviewing.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovn
On Sat, Jan 20, 2007 at 10:10:47PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >It took reading the code to determine the following:
> >
> >- ASN.1 Strings extracted from X.509v3 certs are not validated for
> >con
r, ...) into a single file and set that as the Server
Cert file, not the CA file.
Please take any further questions to openssl-users@openssl.org (via
[EMAIL PROTECTED]).
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy a
t the factor 2^36, but it sure makes a big difference.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and notify
X AGAINST IT Security, sender. Sender does not waive
/ \
On Fri, Jan 26, 2007 at 07:06:00PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >Generally it is enough for a TLS server or client to present its own
> >certificate and all *intermediate* CA certificates, sending the root CA cert
> &
On Sat, Jan 27, 2007 at 02:12:34PM +1300, Peter Gutmann wrote:
> Victor Duchovni <[EMAIL PROTECTED]> writes:
>
> >Wouldn't the old root also (until it actually expires) verify any
> >certificates signed by the new root? If so, why does a server need to send
>
and is how
the old (finally expired) root helps to validate the new unexpired root,
when a verifier has the old root and the server presents the new root
in its trust chain.
--
/"\ ASCII RIBBON NOTICE: If received in error,
\ / CAMPAIGN Victor Duchovni please destroy and
1 - 100 of 182 matches
Mail list logo
