for a standard is actually pretty good.
regards
Anders Rundgren
RSA Security
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Other (with the subject associated) views on the usability of TLS:
http://www.openoces.org/pipermail/developer/2004-December/000582.html
I think they may be on to something here.
==
We seem to need another browser-based PKI client-auth mechanism.
in the case there is no NR cert
with the same ID? This comparison is a bit ugly but may be needed for PIV.
Anders Rundgren
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
://www.openoces.org for a more capable
signature solution that BTW works with IE as well as FF.
Anders Rundgren
- Original Message -
From: eloy_iv [EMAIL PROTECTED]
Newsgroups: mozilla.dev.tech.crypto
To: dev-tech-crypto@lists.mozilla.org
Sent: Thursday, July 06, 2006 18:00
Subject: Signtext unicode data
http://www.w3.org/2006/02/axalto-paper.html
This paper says that we can soon forget about P11 and such
and rely on AJAX-like access to crypto.
Anybody who knows more about the finer details?
AR
___
dev-tech-crypto mailing list
Anders Rundgren wrote:
http://www.w3.org/2006/02/axalto-paper.html
This paper says that we can soon forget about P11 and such
and rely on AJAX-like access to crypto.
We wouldn't have to worry about vendor-independent crypto device
interface standards if everyone in the world would agree
Nelson Bolyard wrote:
Erik
Let me try asking my question another way.
You're trying to solve some problem with encryption.
Can it be solved through the use of SSL (through https) ?
Alternatively, Can it be solved through the use of something like S/MIME ?
Indeed very valid questions.
Let me
Thanx for the super quick response!
c-i-l
Nelson B wrote:
I created a certificate path consisting of root CA, sub CA and EE cert and
put it in a PKCS 12 file including the private key to the EE cert.
When I import it in MSIE 6 I get the question if I want to install the root
CA.
In FF I
Have you ever tried that phrase on consumers? They don't know what a
CA is and I hope they never will.
Ah, then apparently you hope consumers will never get certs.
Maybe you are not familiar with consumer/citizen PKIs in the EU? They
are mostly designed for on-line services. For such
Have I gotten this right?
1. Mozilla PKI client support (FF's TLS-client-auth, FF's signText and
TB's S/MIME), requires that the CA certificate is known and trusted
by the local client software?
If that is true I would consider it a major bug or at least a major nuisance
because there is no
. That is forbidden.
AFAIK each CA has its own serial number space. This should make it OK
to reuse a serial number even within a CA hierachy. I would be an error if
I let the root sign another CA and used serial = 1 for that one as well.
Anders
Anders Rundgren wrote:
The following 3-level certificate
Any two certs with the same issuer must have different serial numbers.
I have never claimed anything else.
This is a basic X509 requirement, violating this will cause you
interoperability problems. If you reissue your CA cert, it must have a
new number. If you spin up another CA with the
Nelson wrote:
NSS (and therefor mozilla products) do not do automatic fetching of
certificates at this point in time.
Currently all protocols have a way of transmitting the necessary
intermediate certificates, and mozilla products depends on these protocols.
In theory yes, in practice no.
Jean-Marc Desperrier wrote:
[...]. That Root is actually signed by the
same key and having the same issuer as Sub does not put it in the same level
as Sub since Root is selfsigned.
I think you should rethink about the meaning of *self*-signed.
I don't claim to be the world's biggest expert on
tend to believe that Mozilla uses a somewhat simplified
certificate database model, where issuer names are assumed to be
*globally* unique.
Anders
- Original Message -
From: Kyle Hamilton [EMAIL PROTECTED]
To: Anders Rundgren [EMAIL PROTECTED]
Cc: Mozilla Crypto dev-tech-crypto
but the current schemes are simply too variant to
support that . Particularly when the container for such deployments will be a
mobile
phone. None of the leading handset makers AFAIK have selected Mozilla's
or Microsoft's provisioning schemes so there is a lot to do here.
Anders Rundgren
http
be in there in some way. There are
*many* ways to do that. All of them quite different :-(
regards
Anders Rundgren
- Original Message -
From: j.fabre [EMAIL PROTECTED]
Cc: dev-tech-crypto@lists.mozilla.org
Sent: Tuesday, December 05, 2006 20:04
Subject: Re: Problem with crypto.Signtext and A PKCS #9
http://ussi.sourceforge.net
Another Java Applet solution and more.
Exactly what it does is a bit hard to deduct from the code but it has been
adopted by Phizer, AstanaZeneca and some other of the largest BioPharma
companies in the world.
Anders R
Ben,
If you take a closer look on the attacks that is costing most, they are based
on e-mail. The problem with e-mail is that there is no credible authentication
structure in place at all. If there was such a structure it would much be less
tempting sending spam from fake addresses, infecting
itself. I intend to look closely
into the many CardSpace projects that should be pretty related
although they do not build on the MIME-trigger mechanism that is
the common denominator for the mentioned standards proposals.
thanx
Anders Rundgren
___
dev
Thanx Peter,
It seems that I will get some problems with this since the
described work builds heavily on the use of XML schemas
which does not seem to be supported in Mozilla. A workaround
would be using Java but then JRE would be a requirement.
Anders
- Original Message -
From: Peter
for this. It will be built on XML rather than ASN.1.
Here comes something related:
- Original Message -
From: Anders Rundgren [EMAIL PROTECTED]
To: ietf-pkix@imc.org
Sent: Saturday, March 31, 2007 08:32
Subject: netscape-cert-renewal-url beyond
Although the netscape-cert-renewal-url
Hamilton [EMAIL PROTECTED]
To: Anders Rundgren [EMAIL PROTECTED]
Cc: dev-tech-crypto@lists.mozilla.org
Sent: Saturday, March 31, 2007 09:35
Subject: Re: Announcement: Firefox Extension for Key Generation and
CertificateEnrollment
Not XER?
-Kyle H
On 3/30/07, Anders Rundgren [EMAIL PROTECTED
The HTTP protocol does not affect content so if there is a problem
it is likely to be in the browser, either in DOM or in security.
Since signText seems to be built on e-mail security it may even
be S/MIME canonicalization involved.
Anders
- Original Message -
From: eloy_iv [EMAIL
-crypto@lists.mozilla.org
Sent: Monday, May 14, 2007 18:46
Subject: Re: Can't find JSS 4.x
Glen Beasley wrote:
Anders Rundgren wrote:
http://www.mozilla.org/projects/security/pki/jss/
The links to the newer releases appear dead.
ftp://ftp.mozilla.org/pub/mozilla.org/security/jss/releases
ohh! it seems I have to import the CAs cert to my trusted CA list.
Thanks so much firefox for the informative error!
I believe this has been filed as an error. It is the relying party that
needs to to import a CA certificate, not the owner of the certificate.
Anders R
- Original Message
I don't know if it makes you happier but I succeeded using the following config
without copying any mozilla files at all:
name=NSS
library=c:\Program Files\Mozilla Firefox\softokn3.dll
description=NSS PKCS11
nssArgs=configdir='c:/Documents and Settings/Administrator/Application
TPMs will become the likely replacement for smart cards when
generally available in mobile phones. The silicon cost is extremely low.
Together with NFC and similar low-range RF technologies you get
a very simple cable/reader/card emulator with the advantage that
you run the security GUI in a
Nelson,
I don't have any success story to bring unfortunately.
However, I feel that there is a problem with PKCS #11 and the
associated generateCRMFrequest and that is that issuers have (as
far as I can see) no information that the keys actually reside in a
secure container. This makes parties
Eddy,
You are right in hat NSS is really needed. At least 10M people use
PKI in the EU.
What doesn't work is the concept of you own universal security device
outside of an elite of developers and security geeks. For that concept
to scale you need something else like:
the primary reason for not using PKI is that many of these systems
have their user database for reasons that it is hard managing small
groups in a delegated fashion using Active Directory. For integrated
applications it seems that Kerberos is a better way than making all
applications talk PKI.
Anders
A cryptographic subsysten based on C and not having a registration
facility is not a solution for the 21st century.
AR
- Original Message -
From: Jean-Marc Desperrier [EMAIL PROTECTED]
Newsgroups: mozilla.dev.tech.crypto
To: dev-tech-crypto@lists.mozilla.org
Sent: Wednesday, September 12,
as well.
Anders
- Original Message -
From: Anders Rundgren [EMAIL PROTECTED]
To: dev-tech-crypto@lists.mozilla.org
Sent: Thursday, September 06, 2007 23:42
Subject: KeyGen2 - Replacement for [KeyGen/generateCRMFrequest/Xenroll]
Hi All,
I don't know if any of you following this list
The following is the most recent [very preliminary]
addition to: http://webpki.org/keygen2.pdf
Since I couldn't find any other key-provisioning standard dealing
with PIN policies this may not be perfect but it is a least a try.
Comments are very welcome!
The following is sent down to the client
any number of documents.
Anders
- Original Message -
From: Alberto Hernandez [EMAIL PROTECTED]
To: 'Anders Rundgren' [EMAIL PROTECTED]; dev-tech-crypto@lists.mozilla.org
Cc: [EMAIL PROTECTED]
Sent: Monday, September 24, 2007 19:03
Subject: RE: Signing multiple times. Was: About Firefox
I doubt that many people would like to develop using C++.
Maybe you will some day need to bundle JRE to get a better
foundation for security apps not to mention and rich web apps?
Anders
- Original Message -
From: Wan-Teh Chang [EMAIL PROTECTED]
To: dev-tech-crypto@lists.mozilla.org
The issue as expressed by somebody else:
http://www.jroller.com/whoami/entry/browser_generated_certificate_requests
But don't despair! A solution is in the wings that in addition to supporting
PKI also supports OTP (symmetric key) provisioning.
It will initially emerge on Google's Android
to IE + .NET. This is of
course not at all limited to security extensions!
Google's Android shows a nifty integration of java and
browser:
http://davanum.wordpress.com/2007/11/21/twitter-client-for-android-how-to-make-xml-over-http-calls/
Sincerely
Anders Rundgren
forum but unfortunately
Robert 's signature facility is incompatible with most form archives [as well as
with Outlook Express] :-(
Can you just download a public key cert and it will dock properly
rather than using the esoteric importUserCertificates method?
br
Anders Rundgren
I want people to finally realize that signed and encrypted e-mail has a
much more limited scope than originally envisioned and there is
no policy or technical solution that can change that. Due to the
limited scope of S/MIME the problems associated with CAs do
not really exist. The only public
on the URL http://demo.webpki.org/mozkeygen
you can get yourself a certificate by clicking a single button.
What is a bit hard to understand is why the test-service at
https://www.apache-ssl.org/cgi/cert-export
often (but not always!) asks the user multiple times to OK the
certificate selection
shelved TLS client certificate authentication for CardSpace
in favor of an application-level authentication protocol.
Anders
- Original Message -
From: Robert Relyea [EMAIL PROTECTED]
To: Anders Rundgren [EMAIL PROTECTED]
Cc: dev-tech-crypto@lists.mozilla.org
Sent: Tuesday, April 01, 2008 22
-critical extension, NIST requires the
support of this in PIV, and IMO for very good
reasons.
Anders Rundgren
- Original Message -
From: Eddy Nigg [EMAIL PROTECTED]
Newsgroups: mozilla.dev.tech.crypto
To: dev-tech-crypto@lists.mozilla.org
Sent: Wednesday, July 23, 2008 18:26
Subject: Re
vital features. Such an effort is also in
an advanced state in case anyone on the distribution list is interested.
Sincerely
Anders Rundgren
- Original Message -
From: Ian Hickson [EMAIL PROTECTED]
To: Anders Rundgren [EMAIL PROTECTED]; Michael(tm) Smith [EMAIL
PROTECTED]; [EMAIL
Although the following document was written for the support of schemes
like KeyGen2 (Universal Provisioning) and WASP (WebForm Signing),
I believe it could probably work equally well for Information Card
selelctors, IETF's DSKPP, and similar.
I have decided to give FF crypto programming a try.
I have a few initial questions that this list hopefully knows about.
Pointers to the associated rather difficult-to-find Mozilla docs
would be much appreciated.
Q1. Does the built-in soft token provider offer the ability to
programmatically set
keys, right?
Anders
- Original Message -
From: Nelson B Bolyard [EMAIL PROTECTED]
To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org
Sent: Saturday, August 23, 2008 23:02
Subject: Re: Soft token provider capabilities
Anders Rundgren wrote, On 2008-08-23 01:21
GoDaddy probably uses generateCRFMrequest
Try it: http://demo.webpki.org/mozkeygen
Read about it: http://developer.mozilla.org/en/generateCRMFRequest
anders
- Original Message -
From: Peter Djalaliev [EMAIL PROTECTED]
Newsgroups: mozilla.dev.tech.crypto
To:
Today I was in a meeting with Swedish bank-people. They
told me that they are planning exodus from TLS-client-cert-auth
because it (in their opinion) works really bad. The banks will
replace TLS-client-cert-auth with a proprietary auth client that
is very similar to their current signature
Collective answer to Jean-Marc and Michael.
Green messaging :-)
Before going too deep into this you should be aware of the
fact that Microsoft's recently introduced Information Card
scheme also when using a local X.509 certificate to authenticate
to the IdP does not specify TLS-client-cert-auth
It appears that the word branding in a PKI GUI sent
some bad vibes around but it is really about switching from
unintelligible textual data such as
CN=John Smith, serialNumber=554544
to a card metaphor like you already use in the physical world;
not about annoying the user with Vista-like
.
Anders
- Original Message -
From: Michael Ströder [EMAIL PROTECTED]
Newsgroups: mozilla.dev.tech.crypto
To: dev-tech-crypto@lists.mozilla.org
Sent: Friday, August 29, 2008 14:07
Subject: Re: The branding stuff. Was: TLS-client-cert-auth in .SE
Anders Rundgren wrote:
It appears that the word
, 2008 16:54
Subject: Re: TLS-client-cert-auth in .SE
Anders Rundgren wrote:
it matches poorly with web sessions including logout
Why should it match application sessions? Because the web application
developers are too dumb to get the session handling right for
themselves? Because the logout
This is probably due to the fact that these efforts are not based on what
the US government needs but what the Internet community needs.
I fail to see who exactly the Internet community is. Maybe that's the
reason I don't understand the problem.
I don't claim to be the definer of this term so
for Information Cards to Firefox. Unfortunately it won't be able
to support TLS-client-cert-auth but there is a replacement for that as well
which is more in line with Information Cards; in fact the GUI is identical.
In case you are interested in this work, just drop me a line.
Anders Rundgren
of KeyGen and generateCRMFRequest (
http://demo.webpki.org/mozkeygen )
However, I believe it would be a mistake to add this to HTML5 because key
generation is really an external application that has nothing to
do with HTML except that it is typically launched from an HTML page.
Anders Rundgren
Robert Relyea wrote:
What I was referring to is the inability for an issuer specifying that
generated keys should be PIN-protected and what constraints
there should be on the PIN while still optionally letting the user
specify the actual PIN.
snip
In general we have been reluctant to add
thwart possible future IPR claims includes myself.
I.e. this is meant to be in public domain.
- Original Message -
From: Anders Rundgren [EMAIL PROTECTED]
To: dev-tech-crypto@lists.mozilla.org
Sent: Friday, September 19, 2008 09:46
Subject: Subject Key Attestation Evidence light
http://fedoraproject.org/wiki/FedoraCryptoConsolidation
It is understandable that the Linux community is looking with a
certain envy on Microsoft's and Apple's united crypto architectures.
I'm personally unconvinced that there is much point in trying to
mimic these schemes due to the fact that
chance of a high adoption rate.
But, the ISO has Spoken, which is where we got the abomination that is
X.500/X.509 and also the abomination that is the Smart Card Interface.
-Kyle H
On Wed, Oct 1, 2008 at 3:44 AM, Anders Rundgren
[EMAIL PROTECTED] wrote:
http://fedoraproject.org/wiki
According to the Directive, qualified signatures are equivalent with
handwritten ones, so only natural persons were meant to have qualified
certificates. However, in certain countries, electronic invoices have
to be signed with qualified certificates. This led to the situation
where - in some
How come that S/MIME-signed messages are unreadable using Microsoft Mail and
Outlook Express?
Anders
- Original Message -
From: Ian G [EMAIL PROTECTED]
To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org
Sent: Saturday, October 18, 2008 12:49
Subject: Re:
I haven't followed this lengthy discussion in detail but I have for a long time
wondered how DNSSEC
and SSL-CA-Certs should coexist.
Which one will be the most authoritative?
Could DNSSEC (if it finally succeeds) be the end of SSL-CA-certs?
Anders
IM[NS]HO, S/MIME encryption using PKI is one of the biggest security
farces ever. Even the use-case is often wrong. Somebody representing
e-Health
once described for a big audience how S/MIME encryption could be used
to exchange private medical information between a doctor and a patient.
But
:13
Subject: Re: How-to guide for email encryption
Anders Rundgren wrote:
IM[NS]HO, S/MIME encryption using PKI is one of the biggest security
farces ever.
I don't see why.
Regarding the guide, I believe that e-mail encryption would be fairly common
if it had been (generally) based on using
Robert,
Pardon me. I did indeed not intended to slam Paul's guide.
I changed the thread but I don't expect a fruitful debate since the difficulties
are mostly unrelated to NSS. I feel sorry for those who feel that S/MIME
encryption needs to become mainstream because that will never happen
Graham Leggett wrote:
Anders Rundgren wrote:
Secure e-mail should have been put at the server-level, then we would have
had some base-level security that would cover 99% of all uses. But it
didn't and therefore 80% of all messages are not even coming from the
domain they claim. How very
suggestions on how to
proceed to make it a built-in feature of Firefox? Although it would be nice
just
contributing some code, I believe that a useful solution must be architected
a bit, and I'm not a Mozilla architect.
Best regards
Anders Rundgren
be an over-specified (German influences...) monstrosity that
it will die
under its own weight.
Sincerely
Anders Rundgren
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
PIN 1234 :-)
- Original Message -
From: Nelson Bolyard [EMAIL PROTECTED]
To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org
Sent: Thursday, November 20, 2008 00:07
Subject: Web signing?
Eddy Nigg wrote:
On 11/19/2008 05:52 PM, Anders Rundgren:
In the meantime
Have you looked into this paper?
http://webpki.org/papers/wasp/wasp-faq.html
Unfortunately I believe there are too many uncoordinated views on this matter
to return a fruitful discussion but let me tell you how it works in Sweden: In
Sweden all the banks supply proprietary signature clients
Ian G wrote:
That wasn't my question. Here's my question again: How do you show any
person afterwards that the person signed it?
I mean: how does Alice look tomorrow in this system to see what she
signed? Next year? How does Bob look next year to see what Alice
signed? How does Trent,
What *user* could need is a copy of what was requested to be signed
but that is useless unless the request is also signed since a user can
fabricate whatever data he/she wants and sign it.
But seriously (as Graham Legget wrote), the real use-case needs a
receipt (hotel booking, patent filing,
a bunch of
other hot-shots as well :-)
Enrolment issues? Skype does this without the user having to know what a
certificate is.
Applications include all kinds of interactive communication with mobile phones
as a really interesting target unless it gets outlawed.
Anders Rundgren
crypto code discussion list dev-tech-crypto@lists.mozilla.org
Sent: Saturday, November 22, 2008 12:11
Subject: Re: Creating a Global User-level CA/Trust Infrastructure for
SecureMessaging
Anders Rundgren wrote, On 2008-11-22 02:12:
The following is related to the S/MIME discussions.
Anders, here
Ian,
I hope you don't mind but I limit my response to a single core topic.
snip
So from this, I gather you want: scalability + distribution.
Absolutely.
Do you want no center(s) at all?
I want each organization/domain entity that can afford an SSL certificate to
become a virtual CA and run
-
From: Ian G [EMAIL PROTECTED]
To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org
Sent: Saturday, November 22, 2008 17:54
Subject: Re: Creating a Global User-level CA/Trust Infrastructurefor
SecureMessaging
Anders Rundgren wrote:
Ian,
I hope you don't mind but I limit
Nelson B Bolyard wrote.
I want each organization/domain entity that can afford an SSL certificate
to become a virtual CA and run their own secure messaging center.
Why SSL certs? why not email certs?
Could it be the fact that the SSL PKI exists?
Email certs is a nice idea that requires that
to
participate in login/logout activity.
This is already possible with forms authentication, so I don't see much
point adding stuff to HTML to make it possible with HTTP auth too.
On Thu, 7 Sep 2006, Anders Rundgren wrote:
As you probably have noticed, practically every site offers
CA/Trust Infrastructure
forSecureMessaging
Anders Rundgren wrote:
I want each organization/domain entity that can afford an SSL certificate to
become a virtual CA and run their own secure messaging center. Based on
the SSL certificate they can use whatever issuance policies they feel
Ian G wrote:
= Encrypting/signing must be made a business requirement in contracts.
That's the whole point. And there's no technical solution for it.
That's as close to a perfect dilemma as I've come across! It's not a
business requirement, so we must make it a business requirement ...
Infrastructure
forSecureMessaging
Anders Rundgren wrote:
Ian G wrote:
= Encrypting/signing must be made a business requirement in contracts.
That's the whole point. And there's no technical solution for it.
That's as close to a perfect dilemma as I've come across! It's not a
business
Michael Ströder wrote:
Let me comment on a few things. We do not disagree with all but we look from
different angles.
But crypto tokens are not suitable for S/MIME encryption keys because of
the growing key history needed. So one has to distinguish PKI-enabled
applications.
Authentication
Michael Ströder wrote:
Ian G wrote:
* it has no open + effective key distribution mechanism. (I exclude
the LDAP stuff as that is generally for internal / corporates, and is
not a general solution for the users.)
Just exchanging signed S/MIME e-mails is quite easy for most users. The
case
http://www.mozilla.org/projects/security/certs/policy
From what I have seen on this list there has been a lot of talk about
inclusion of various CA root certificates in the Mozilla distributions.
IMO, most of these CAs are insignificant except for SSL certs.
Why? Because the vast majority of
discussion list dev-tech-crypto@lists.mozilla.org
Sent: Sunday, November 30, 2008 02:19
Subject: Re: Creating a Global User-level CA/Trust Infrastructurefor
SecureMessaging
Anders Rundgren wrote:
Nelson B Bolyard wrote:
I have contacts in the former Soviet Union who claim that Russian banks
now
plug-in a new protocol into the framework.
That Microsoft's Information Cards specify 2 completely different methods for
invocation is an indication that it is about time creating something generic.
Anders Rundgren
http://WebPKI.org
___
dev-tech
Nelson wrote:
For me, the purpose of this debate is finding out what users can expect from
Mozilla by way of security.
The answers to that quest probably include these properties:
- open, openly specified, not secret,
- inner workings subjected to public scrutiny.
- security claims
: Re: Creating a Global User-level CA/Trust Infrastructurefor
SecureMessaging
Anders Rundgren wrote:
This is BTW not too different to PayPal which I guess works so well
because it owns the entire customer-base and doesn't have to mess
with other competing/collaborating partners.
Ahhh
Eddy Nigg wrote:
Nelson wrote:
Now, in contrast to that, I have been led to believe that Skype's:
- protocols, security designs and parameters are proprietary, secret, have
not been openly published, and thus not subjected to public scrutiny
- components are all proprietary. Their clients
Michael Ströder wrote:
That there should be as you claim mainly a UI problem is an opinion
that has some support in the literature (Jonny can't encrypt),
but I feel that it is much deeper than that; security should probably
as in the case of Skype be transparent, not needing any UI at all.
I
Michael Stroder wrote:
I'm often working while traveling by train. I'm off-line then. I want
the encrypted e-mail ready to be in the [Outgoing] folder - protected
right from the beginning.
This does not appear to be a general requirement. Presumably
most people have other documents that would
Michael Ströder wrote:
Secure e-mail must be destroyed, or to be more correct;
replaced by something that actually works for ordinary people.
Oh, come on! You simply want to sell something new. That's not something
I can take serious.
I'm not selling anything except maybe a vision of a
snip
Now, if the discussion can be steered to how Mozilla's crypto can succeed at
becoming as popular as Skype may be, WITHOUT it having to resort to
- closed source,
- proprietary designs (restricted intellectual property),
- being a closed system with no interoperability,
that may be worthwhile
Hi Guys,
Thank you for taking on the p2 challenge!
Although the responses were rather different, AFAICT, they all required new
security infrastructure
beyond what is offered by the enterprise (employee) PKI which is (from my
perspective)
the interesting part since the consultants that for
snip
Eddy Nigg wrote:
So, My advice is: just say no. Don't take on the burden of adding a
new root CA cert every year when there is no good need. Please consider
this an objection to including those roots in the root CA list.
As indicated earlier, I think it unreasonable as well. And this
@lists.mozilla.org
Sent: Thursday, December 18, 2008 17:00
Subject: Re: Publishing CA information documents in PDF format
On 18/12/08 13:20, Anders Rundgren wrote:
Kyle,
I fully agree with your conclusions.
IMO a signature's primary function is to provide a mark of authenticity
to something
I wouldn't spend much work on keygen and crypto.generateCRMFRequest
because they don't match today's needs anyway. You cannot even as an
issuer control PIN code settings (policy) unless you have a pre-configured
crypto
container, i.e. these mechanisms are tools for toy PKIs.
Serious PKIs use
Michael Ströder wrote:
Anders Rundgren wrote:
I wouldn't spend much work on keygen and crypto.generateCRMFRequest
because they don't match today's needs anyway.
Anders, does the word keygen trigger an automatic response in your
news bot? ;-}
Well, some 1000h into its successor have left some
Kyle Hamilton wrote:
I don't completely get this. If we are talking about soft tokens of
the kind implemented in Mozilla, PKI-using services rely on keys stored
in containers using obfuscation and optional weak passwords as
the only protection. IMO, this trust in client code is above the
1 - 100 of 282 matches
Mail list logo
