Re: Policy: revoke on private key exposure

2009-01-31 Thread Kyle Hamilton
An implementation should be able to deal with a CRL of any size, that is indeed what I'm saying. CRLs are also the ONLY revocation mechanism specified by X.509. (As well, they're also still specified in RFC 5280, which means that a fully-conforming implementation of the Internet PKI must handle C

Re: Policy: revoke on private key exposure

2009-01-31 Thread Eddy Nigg
On 01/31/2009 06:08 PM, Paul Hoffman: On 31/1/09 03:56, Kyle Hamilton wrote: 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. Do you mean, an implementation s

Re: X509 per machine (not per user) - or equivalent needed

2009-01-31 Thread Anders Rundgren
wrote: >Nothing I've heard thus far has made me think that this is an >inherently bad idea, I suppose what I need is help in accomplishing it >(and preferably accomplish it in Mozilla - our application is quite >AJAXy and the Javascript speedup in Firefox 3.1 is a godsend) Since I don't have a

Re: Policy: revoke on private key exposure

2009-01-31 Thread Paul Hoffman
>On 31/1/09 03:56, Kyle Hamilton wrote: >>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. > > >Do you mean, an implementation should be able to deal with a

Re: X509 per machine (not per user) - or equivalent needed

2009-01-31 Thread Ian G
On 31/1/09 15:57, Denis McCarthy wrote: Hi Kyle, You seem to understand my situation. Unfortunately, I think using a hardware based TPM is out, given the heterogeneous nature of our customer's network (and the costs involved). I'd really like to have a machine based, password protected X509 cert

Re: X509 per machine (not per user) - or equivalent needed

2009-01-31 Thread Denis McCarthy
Hi Kyle, You seem to understand my situation. Unfortunately, I think using a hardware based TPM is out, given the heterogeneous nature of our customer's network (and the costs involved). I'd really like to have a machine based, password protected X509 certificate solution, as this would be relativ

Re: Policy: revoke on private key exposure

2009-01-31 Thread Ian G
On 31/1/09 03:56, Kyle Hamilton wrote: 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. Do you mean, an implementation should be able to deal with a CRL of an

Re: X509 per machine (not per user) - or equivalent needed

2009-01-31 Thread Ian G
On 31/1/09 03:50, Kyle Hamilton wrote: 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. Or, failed to

Re: X509 per machine (not per user) - or equivalent needed

2009-01-31 Thread Anders Rundgren
The originator of this thread has left out what the entities are, apps, orgs, machines, users, roles etc. In order to come up with a useful advice, I would start by doing that because then we also know where the different entities are administered (and certified). Keeping machine-certs in TPM