Thanks for your thoughts Nelson.
There's one big problem with this idea of a certificate extension for
additional signatures, which I hadn't thought of before (Thanks to Paul H for
spotting it!)...
For the additional signature(s) to become especially useful, the primary
signature on the
Rob Stradling wrote, On 2009-01-14 03:24 PST:
To the NSS developers: If there existed a standardized certificate
extension in which a CA could put additional signatures using different
algorithms, do you think you'd consider adding support for it to NSS?
Yes, I think the NSS team would
On Tuesday 13 January 2009 15:47:22 Paul Hoffman wrote:
At 3:31 PM + 1/13/09, Rob Stradling wrote:
Why almost every piece of PKIX validating software ?
I think it would be worth it if, at a minimum...
- the majority of CAs added the extension to the certificates they
issue, and...
Rob,
Rob Stradling wrote:
If there existed a standardized certificate extension in which a CA could put
additional signatures using different algorithms, do you think you'd consider
adding support for it to NSS? If yes, might you do this before it was widely
supported by CAs, or do you think
On Friday 09 January 2009 02:04:59 Julien R Pierre - Sun Microsystems wrote:
On Friday 09 January 2009 04:32:41 Ben Bucksch wrote:
snip
Can we create another extension? The signature itself is a shell around
the certified bits. Add the second signature around that first signature.
There
On 13.01.2009 09:48, Rob Stradling wrote:
I made a similar suggestion to ietf.pkix in October 2006. See...
http://www.imc.org/ietf-pkix/mail-archive/msg01964.html
...and the rest of that thread, including...
http://www.imc.org/ietf-pkix/mail-archive/msg01984.html
...
Ben, I agree that having
Thanks Ben. Perhaps it's time to have another go at canvassing support for
the idea. In 2006, the PKIX WG didn't seem interested in tackling the
problem I was trying to solve.
Paul, do you think it's worth re-raising this idea with the PKIX WG ?
On Tuesday 13 January 2009 09:39:06 Ben
At 9:55 AM + 1/13/09, Rob Stradling wrote:
Thanks Ben. Perhaps it's time to have another go at canvassing support for
the idea. In 2006, the PKIX WG didn't seem interested in tackling the
problem I was trying to solve.
Paul, do you think it's worth re-raising this idea with the PKIX WG ?
Why almost every piece of PKIX validating software ?
I think it would be worth it if, at a minimum...
- the majority of CAs added the extension to the certificates they issue,
and...
- Mozilla implemented support for the extension in NSS.
This would allow Mozilla to disable a weak algorithm
Julien R Pierre - Sun Microsystems wrote:
[...]
I think many CAs will keep the serial numbers of expired certs on
their CRLs for a few years after expiration. But I don't think most
do that indefinitely. One big problem is that there is currently no
way to tell which CAs do and do not.
[...]
Eddy Nigg wrote:
[...] No exception can be added for revoked certificates, but for
expired ones it's possible - hence it suggests that revocation is more
severe than expired (if one can think in those terms). Or how would you
explain that?
As I have already found myself in the situation of
On 01/12/2009 11:56 AM, Jean-Marc Desperrier:
Eddy Nigg wrote:
[...] No exception can be added for revoked certificates, but for
expired ones it's possible - hence it suggests that revocation is more
severe than expired (if one can think in those terms). Or how would you
explain that?
As I
and required by EV ?
Eddy, the EV Guidelines impose certain requirements on Intermediate CAs *when*
they are used, but AFAIK they don't mandate that Intermediate CAs MUST be
used.
Visit https://www.securetrust.com in FF3 for an example of an EV-enabled Root
Certificate (CN = SecureTrust CA)
On 01/12/2009 12:45 PM, Rob Stradling:
and required by EV ?
Eddy, the EV Guidelines impose certain requirements on Intermediate CAs *when*
they are used, but AFAIK they don't mandate that Intermediate CAs MUST be
used.
Visit https://www.securetrust.com in FF3 for an example of an EV-enabled
On Monday 12 January 2009 11:00:59 Eddy Nigg wrote:
On 01/12/2009 12:45 PM, Rob Stradling:
and required by EV ?
Eddy, the EV Guidelines impose certain requirements on Intermediate CAs
*when* they are used, but AFAIK they don't mandate that Intermediate CAs
MUST be used.
Visit
On 01/12/2009 01:20 PM, Rob Stradling:
The Entrust.net Secure Server Certification Authority is used for legacy
ubiquity only. Entrust and SecureTrust (aka Trustwave) have different EV
Certificate Policy OIDs. https://www.securetrust.com only gets the EV UI in
FF3 (and other EV-capable
On 12/1/09 10:56, Jean-Marc Desperrier wrote:
Eddy Nigg wrote:
[...] No exception can be added for revoked certificates, but for
expired ones it's possible - hence it suggests that revocation is more
severe than expired (if one can think in those terms). Or how would you
explain that?
As I
On Monday 12 January 2009 12:10:17 Eddy Nigg wrote:
On 01/12/2009 01:20 PM, Rob Stradling:
The Entrust.net Secure Server Certification Authority is used for
legacy ubiquity only. Entrust and SecureTrust (aka Trustwave) have
different EV Certificate Policy OIDs. https://www.securetrust.com
On 01/12/2009 02:56 PM, Rob Stradling:
I can't find the SecureTrust CA request for enabling EV. It's not on the
pending list, not on the included list, nor could I find bug for it...
anybody know where the paper trail is for this CA?
https://bugzilla.mozilla.org/show_bug.cgi?id=409837
It's
On Monday 12 January 2009 13:07:17 Eddy Nigg wrote:
snip
I would go as far and require it, simple as that.
You are entitled to your opinion.
That should be really an issue for the CAB forum however.
So why don't you join the CA/Browser Forum and share your opinion?
BTW, my point wasn't
On 01/12/2009 03:17 PM, Rob Stradling:
So why don't you join the CA/Browser Forum and share your opinion?
Patience is one of the ingredients for success... getting there!
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog: https://blog.startcom.org
Jean-Marc,
Jean-Marc Desperrier wrote:
Julien R Pierre - Sun Microsystems wrote:
[...]
I think many CAs will keep the serial numbers of expired certs on
their CRLs for a few years after expiration. But I don't think most
do that indefinitely. One big problem is that there is currently no
way
Ian G wrote, On 2009-01-08 16:42:
On 9/1/09 00:46, Ben Bucksch wrote:
Certs expire for the same reason that credit cards do. Do you
understand why that is?
No, quite frankly, I do not.
First off, my credit cards (VISA, MasterCard) are valid until Jan 1, 2013.
I had to think about it too
Julien R Pierre - Sun Microsystems wrote:
[...]
As for case b, if I understand correctly, you are saying CRLs growing
unbounded is not a problem in a world without CRLs. Right :) ?
The fact is that both CRLs and OCSP have their uses, in different places.
[...]
Also the problem is that if only
On 01/09/2009 06:40 AM, Ben Bucksch:
Obviously I trust the software I run, out of necessity. I do not trust
the CA operations. If there was minimal hope that they'd do a decent
job, that has been destroyed over last Christmas.
I anticipated comments like this one, but the good thing is that
Robert Relyea wrote:
[...]
KCM is good for a single pipe between to fixed and seldom changing
computers, [...]. In the many to many or the one to many case, KCM
trains the user to ignore the warning messages. [...]
Mozilla is the same. Users are making lots of connections, often to new
sites
At 12:42 AM +0200 1/9/09, Eddy Nigg wrote:
On 01/09/2009 12:15 AM, Nelson B Bolyard:
It requires that CAs NEVER forget about any certs they previously
issued, not even after they expire. It means that a CA's list of revoked
certs will grow boundlessly. It makes CRLs become impractically big.
Eddy,
Eddy Nigg wrote:
On 01/09/2009 03:41 AM, Julien R Pierre - Sun Microsystems:
FYI, if a certificate is expired, NSS won't even bother performing a
revocation check on it, either CRL or OCSP.
Are you sure?
Yes. The validity check is one of the earliest ones that happens on the
cert.
Ben,
Ben Bucksch wrote:
Our CAs would not be allowed to do that. It's fairly trivial to keep the
whole list.
It's not going to grew over a Gigabyte, any MySQL could do that.
Including the replication to have it redundant.
Certainly it's trivial, but not inexpensive especially on large
On 01/09/2009 10:20 PM, Julien R Pierre - Sun Microsystems:
Well, we'll just have to agree to disagree :) IMO revocation really
doesn't matter if you already know the certificate is invalid at the
time you are checking it. It's like trying to check a dead person's pulse.
Then there isn't
Eddy,
Eddy Nigg wrote:
On 01/09/2009 10:20 PM, Julien R Pierre - Sun Microsystems:
Well, we'll just have to agree to disagree :) IMO revocation really
doesn't matter if you already know the certificate is invalid at the
time you are checking it. It's like trying to check a dead person's
On 01/10/2009 01:35 AM, Julien R Pierre - Sun Microsystems:
Then there isn't perhaps much logic in disallowing any override
capability for revocations, whereas expiration can be overridden via
exception. No exception can be added for revoked certificates, but for
expired ones it's possible -
On 08.01.2009 22:09, Ben Bucksch wrote:
* How to deal with cert expiry
A possible solution (already posted in comment 18 in the bug):
* Require website owners to continue using the same private key.
* A fingerprint of that private key is put in the certificate.
* We store on first
Ben,
Thank you for starting this thread. This is a MUCH better place than
in bugzilla for such a discussion to take place.
A possible solution (already posted in comment 18 in the bug):
I encourage people to read through that bug, especially the early
comments, before contributing here. (The
On 01/09/2009 12:15 AM, Nelson B Bolyard:
It requires that CAs NEVER forget about any certs they previously
issued, not even after they expire. It means that a CA's list of revoked
certs will grow boundlessly. It makes CRLs become impractically big.
Well...StartCom NEVER removes a
On 08.01.2009 23:15, Nelson B Bolyard wrote:
I encourage people to read through that bug, especially the early
comments, before contributing here. (The later comments are mostly me
too)
Esp. because the first are from you (and are dissenting, and therefore
important, while agreeing comments
On 9/1/09 00:46, Ben Bucksch wrote:
Certs expire for the same reason that credit cards do. Do you
understand why that is?
No, quite frankly, I do not.
First off, my credit cards (VISA, MasterCard) are valid until Jan 1, 2013.
I had to think about it too ... I think it is because in the old
Advocacy:
One of the core assumptions of the x.509 world is ONE SIGNATURE, and
ONE AUTHORITY.
Thing is: There is no one authority :-). God doesn't issue SSL
certificates. Apart from him, I trust only me and my friends.
Different school of thought.
Yes, definitely.
It's the reason why
Ben Bucksch wrote:
On 08.01.2009 23:15, Nelson B Bolyard wrote:
I encourage people to read through that bug, especially the early
comments, before contributing here. (The later comments are mostly
me too)
Esp. because the first are from you (and are dissenting, and therefore
important, while
Ben Bucksch wrote:
Advocacy:
One of the core assumptions of the x.509 world is ONE SIGNATURE, and
ONE AUTHORITY.
Thing is: There is no one authority :-). God doesn't issue SSL
certificates. Apart from him, I trust only me and my friends.
That's clearly not the case. You have admitted to
Eddy,
Eddy Nigg wrote:
On 01/09/2009 12:15 AM, Nelson B Bolyard:
It requires that CAs NEVER forget about any certs they previously
issued, not even after they expire. It means that a CA's list of revoked
certs will grow boundlessly. It makes CRLs become impractically big.
Well...StartCom
Ben,
Ben Bucksch wrote:
With OCSP, it's not a problem anymore, because the question is is
*this* cert still valid? not tell me all revoked certs.
No, the question OCSP asks is not that . It is is this cert revoked, as
of the current date ?
Note that OCSP does not allow revocation checks
Ian,
Ian G wrote:
Nelson's point was that CRLs become unbounded; but that's not a problem
(a) if there are no disputes or (b) in an OCSP world. Pick (a) or (b).
Uh ?
In case a, even if there are no disputes, the CRL consumers all have to
update the ever-growing CRLs. This can consume
First off, please note that this is a proposed *change* to the PKI
system. A small change, but nevertheless a change, yes. We're trying to
make it more secure. So, That goes against current definitions is not
an argument, it's inherent.
No, the question OCSP asks is ... is this cert
On 09.01.2009 05:32, Ben Bucksch wrote:
The OCSP responder is also allowed to forget about the revocation
status of any cert that's outside its validity period.
Our CAs would not be allowed to do that. It's fairly trivial to keep
the whole list.
P.S. That wouldn't even be strictly
On 09.01.2009 02:15, Robert Relyea wrote:
Ben Bucksch wrote:
Advocacy:
One of the core assumptions of the x.509 world is ONE SIGNATURE, and
ONE AUTHORITY.
Thing is: There is no one authority :-). God doesn't issue SSL
certificates. Apart from him, I trust only me and my friends.
That's
46 matches
Mail list logo
