On 23.01.2009 12:14, Rob Stradling wrote:
For the additional signature(s) to become especially useful, the primary
signature on the certificate would need to be substantially broken (e.g. by a
pre-image attack on the hash algorithm). But if this happened, it is likely
that the CA would revoke th
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 certifi
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 co
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 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
> > issu
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...
> - Mozilla implemented support for the extension in NSS.
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 algorith
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
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 Bucksch
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 m
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:
> >
> > Can we create another extension? The signature itself is a shell around
> > the certified bits. Add the second signature around that first signature.
> >
> >
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 thi
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 to
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
On Monday 12 January 2009 13:07:17 Eddy Nigg wrote:
> 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 *becau
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 ev
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.securet
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 hav
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 browse
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.
> >
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 R
"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 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 hav
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 rea
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.
[...]
Th
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 - henc
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
pulse.
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 perha
On 01/09/2009 07:11 PM, Paul Hoffman:
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.
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 scales
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.
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
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 tha
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
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
Hi Robert,
thanks for the reply.
I think there are two major misconceptions, at least one of them my fault:
* I am not proposing to mandate that the private key stays the same
(contrary to what my original bullet list said). I am merely
proposing that the new key is signed by the
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 clearl
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 revok
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 necessary,
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?
Ie. the expiration of the cert is more critical information than its
revocation status
I think that's w
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 gigan
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 chec
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 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 owni
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
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 S/
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
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 a
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 certifica
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
50 matches
Mail list logo
