Jean-Daniel wrote, On 2009-01-22 14:06:
> Everything is green.
>
> The new asm file does not try to determine at runtime if SSE2 is
> present, but it does it at compile time.
> By default the Apple GCC version define __SSE2__, so the default is to
> use it on Mac.
> And as mention before, all sup
Jean-Marc Desperrier wrote, On 2009-01-30 03:25:
> Paul Hoffman wrote:
>> [...]
>> That feels insufficient to me. I also disagree that there are
>> "practical problems of revoking a very large number of certificates".
>> The worst problem is that the CRL will grow; that's no big deal, it
>> is supp
The PKIX standard can deal with problems of this extent.
If an implementation of the standard cannot, then the implementation
is nonconforming, and cannot be expected to interoperate.
in other words, it's the implementation's fault, not the standard's.
(Yes, a standard has the responsibility to m
This is very much akin to needing to authenticate that a machine used
to perform the transaction submission was, indeed, configured by the
information technology staff. This is a very important concept that
cannot be discounted or ignored.
Essentially, what you need is a two-stage authentication
Denis McCarthy wrote:
> On Fri, Jan 30, 2009 at 2:15 PM, Michael Ströder wrote:
>> Ian G wrote:
>>> X.509 is a user concept, not a transaction concept.
>> Hmm, X.509 certs are simply a strong binding between a name of an entity
>> and a public key. Machines can be entities too like with server cer
On Fri, Jan 30, 2009 at 9:32 AM, Glen Beasley wrote:
>
> For recommend ciphersuites, how about:
>
> TLS_RSA_WITH_AES_128_CBC_SHA
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA
I concur. Note that TLS_RSA_WITH_AES_128_CBC_SHA is the
mandatory cipher suite in TLS 1.2 (http://www.ietf.org/rfc/rfc5246.txt,
Sect
+1
This is primarily an architecture question.
/anders
- Original Message -
From: "Ian G"
To: "mozilla's crypto code discussion list"
Sent: Friday, January 30, 2009 18:28
Subject: Re: X509 per machine (not per user) - or equivalent needed
On 30/1/09 17:07, Denis McCarthy wrote:
>>
Nelson B Bolyard wrote:
Sreedhar Kamishetti wrote on 2009-01-29 16:28 PST:
I just started to use JSS/NSS. So, if hope some one will reply to this
post.
We use SSL_DH_anon_WITH_3DES_EDE_CBC_SHA” as cipher suite for
communication between SSL Peers. Client is in Java and Server is in C
(uses
On 30/1/09 17:07, Denis McCarthy wrote:
Is there a reason why you want certificates involved? Why can't the
machine's website just have a drop-down or cookie or something that says
what store it is in?
The reason why we want certificates involved is because in general we
don't trust the user
After reading the other postings on this thread, I think I
see what you're getting at. You need a combination of two
items and a 2-phase authentication process to get the
assurance you're seeking:
1) A token-based credential per user, using a smartcard and
a digital certificate for Client-Aut
A better solution would be to authenticate the user as well
as is possible. After successful authentication through
a web ID portal (which would identify itself through an
non-personal) org-cert the user would be redirected to the
actual app using SAML. If the user has a personal certificate
it
It is kind of sad that this discussion has become "CAs should not revoke
certificates when the private keys are exposed because Java cannot handle CRLs
reliably". That says more about the failures of Java than it does failures in
PKIX.
--Paul Hoffman
--
dev-tech-crypto mailing list
dev-tech-cry
>
> Getting back to your question. You want the server to also collect the
> browser's machine location ... Presumably you have already looked at all
> the browser headers and decided that the IP address isn't good enough.
>
The problem with the IP address is that it does not necessarily
identify
On 30/1/09 15:07, Denis McCarthy wrote:
One thing we are investigating is the possibility of writing an
ActiveX component to access the computer account to pull the
certificate information from there for a browser (we'd probably need
to glue the ActiveX component together with some sort of Firefo
Hi Michael,
While I agree that it would make sense for us to not be swimming
upstream regarding our usage of X.509 certs, alas we are not in a
position to change the fundamental model, as this is the way our
customer does its business.
Denis
On Fri, Jan 30, 2009 at 2:15 PM, Michael Ströder wrote
Ian G wrote:
> X.509 is a user concept, not a transaction concept.
Hmm, X.509 certs are simply a strong binding between a name of an entity
and a public key. Machines can be entities too like with server certs.
Still I'd agree that the original poster should rethink his concept. I'd
probably pref
One thing we are investigating is the possibility of writing an
ActiveX component to access the computer account to pull the
certificate information from there for a browser (we'd probably need
to glue the ActiveX component together with some sort of Firefox
plugin to get this to work in Firefox, b
On 01/30/2009 02:31 PM, Denis McCarthy:
Actually, one other thing. While I agree with you on the thin clients
issue, many of our applications use their own PC's to run our
application (they have other applications they use on their PC besides
ours)
Typically server certificates are issued to s
Florian Weimer wrote:
> * Michael Ströder:
>
>> Florian Weimer wrote:
>>> What about requiring that all certificates must be published by the CA
>>> (including sub-CAs)?
>> No, this might lead to also revealing internal DNS names never meant to
>> be public.
>
> Huh? Typical CA policies
Whateve
On 01/30/2009 01:25 PM, Jean-Marc Desperrier:
Paul Hoffman wrote:
[...]
That feels insufficient to me. I also disagree that there are
"practical problems of revoking a very large number of certificates".
The worst problem is that the CRL will grow; that's no big deal, it
is supposed to grow.
Y
Jean-Marc Desperrier wrote:
You *obviously* never had to handle this CRL :
http://onsitecrl.certplus.com/DIRECTIONGENERALEDESIMPOTSDIRECTIONGENERALEDESIMPOTSUSAGER/LatestCRL
Java programs just can't take it up. And J2EE is by far the most popular
application server architecture nowadays. 64 bi
On 30/1/09 13:25, Jean-Marc Desperrier wrote:
Ian G wrote:
Ian G wrote, On 2009-01-29 10:01:
[...] when firefox trips
over a cert, it could show something like that.
| There is a problem with this cert!
|
| ==> *The cert was not issued by a known CA*<==
| The cert has expired or is not yet v
On 30/1/09 13:24, Denis McCarthy wrote:
Hi Anders,
I think this gets to the nub of the point at issue. Our customers
often have several stores. We do not want our X509 certificates to be
'per user' because what is critical for us is in which *store* the
transaction
Oh, I see! You have an a
Actually, one other thing. While I agree with you on the thin clients
issue, many of our applications use their own PC's to run our
application (they have other applications they use on their PC besides
ours)
On Fri, Jan 30, 2009 at 12:24 PM, Denis McCarthy
wrote:
> Hi Anders,
> Good question.
>
Ian G wrote:
On 29/1/09 19:24, Nelson B Bolyard wrote:
Ian G wrote, On 2009-01-29 10:01:
[...] when firefox trips
over a cert, it could show something like that.
| There is a problem with this cert!
|
| ==> *The cert was not issued by a known CA*<==
| The cert has expired or is not yet vali
Hi Anders,
Good question.
> If the computers OTOH are just ordinary but shared office computers,
> critical data should be server-based and protected by user access control.
> Thin clients is the most common solution to this fairly standard
> problem. Then it would be X.509 per user rather.
>
I t
Paul Hoffman wrote:
[...]
That feels insufficient to me. I also disagree that there are
"practical problems of revoking a very large number of certificates".
The worst problem is that the CRL will grow; that's no big deal, it
is supposed to grow.
You *obviously* never had to handle this CRL :
h
I guess what's puzzling some people like me, is what the security
concept behind this arrangement really brings to the table.
Authenticating machines connecting to the network is indeed useful
but in general only has the function to prove that the device has been
accepted and possibly configured by
Hello Arshad,
Thanks for the email. I suppose the one thing I'd like to stress again
is that we wish to authenticate a machine, not a user. Many users may
log in to a certain machine (via a username and password that we would
issue). What we need to do on our system is to ensure that the user
loggi
29 matches
Mail list logo
