On Aug 17, 2010, at 4:20 AM, Peter Gutmann wrote:
Your code-signing system should create a tamper-resistant audit
trail [0] of
every signature applied and what it's applied to.
Peter.
[0] By this I don't mean the usual cryptographic Rube-Goldbergery,
just log
the details to a separate
A quick followup note on this, I was reading Microsoft's code-signing best
practices document and one comment caught my eye:
If code is signed automatically as part of a build process, it is highly
recommended that any code that is submitted to that build process be
strongly authenticated.
Thor Lancelot Simon writes:
>If you want to see a PKI tragedy in the making, have a look at the CRLs used
>by the US DoD.
Only "in the making"?
Actually it's all relative, in Japan the Docomo folks turned off CRLs because
they found that even a relatively modest CRL (not just the DoD monsters)
On Wed, Aug 04, 2010 at 10:46:44PM -0700, Jon Callas wrote:
>
> I think you'll have to agree that unlike history, which starts out as
> tragedy and replays itself as farce, PKI has always been farce over the
> centuries. It might actually end up as tragedy, but so far so good. I'm
> sure that if w
> And what else should Windows say? "We put this through our time machine and
> noticed that at some time in the past it was signed and now it isn't"?
Absolutely, on initial install there's no way to know it was originally
signed (if you're smart about it). But in another architecture
Microsoft
On 2010-08-05 11:30 AM, David-Sarah Hopwood wrote:
> Signatures are largely a distraction from the real problem: that software
> is (unnecessarily) run with the full privileges of the invoking user.
> By all means authenticate software, but that's not going to prevent
malware.
A lot of devices
Zeus malware used pilfered digital certificate
http://www.computerworld.com/s/article/9180259/Zeus_malware_used_pilfered_digital_certificate
Zeus Malware Used Pilfered Digital Certificate
http://www.pcworld.com/businesscenter/article/202720/zeus_malware_used_pilfered_digital_certificate.html
&
Z
On Aug 4, 2010, at 11:29 PM, Peter Gutmann wrote:
> Jon Callas writes:
>
>> But S.J. Perleman's "Three Shares in a Boat"
>
> Uhh. minor nitpick, it was Jerome K.Jerome who wrote "Three Shares in a
> Boat".
> He followed it up with "Three Certificates on the Bummel", a reference to the
> sha
Jon Callas writes:
>But S.J. Perleman's "Three Shares in a Boat"
Uhh. minor nitpick, it was Jerome K.Jerome who wrote "Three Shares in a Boat".
He followed it up with "Three Certificates on the Bummel", a reference to the
sharing of commercial vendors' code-signing keys with malware authors.
On Jul 30, 2010, at 4:58 AM, Peter Gutmann wrote:
>
> [0] I've never understood why this is a comedy of errors, it seems more like
>a tragedy of errors to me.
That is because a tragedy involves someone dying. Strictly speaking, a tragedy
involves a Great Person who is brought to their undoi
David-Sarah Hopwood writes:
>Huh? I don't understand the argument being made here.
It's a bogus argument, the text says:
He took a legitimate software package and removed the signature of the
digital certificate it contained, then installed the package on his
computer. The Installer appli
Anne & Lynn Wheeler wrote:
> Kaspersky: Sham Certificates Pose Big Problem for Windows Security
> http://www.ecommercetimes.com/story/70553.html
>
> from above ..
>
> Windows fails to clearly indicate when digital security certificates
> have been tampered with, according to Kaspersky Lab's Roel
Kaspersky: Sham Certificates Pose Big Problem for Windows Security
http://www.ecommercetimes.com/story/70553.html
from above ..
Windows fails to clearly indicate when digital security certificates have been
tampered with, according to Kaspersky Lab's Roel Schouwenberg, and that
opens a door for
On 7/28/10 at 8:52 PM, pfarr...@pfarrell.com (Pat Farrell) wrote:
When was the last time you used a paper Yellow Pages?
Err, umm, this last week. I'm in a place where cell coverage
(AT&T, Verizon has a better reputation) is spotty and internet
is a dream due to a noisy land line. I needed to
At 07:16 AM 7/28/2010, Ben Laurie wrote:
SSH does appear to have got away without revocation, though the nature
of the system is s.t. if I really wanted to revoke I could almost
always contact the users and tell them in person. This doesn't scale
very well to SSL-style systems.
Unfortunately, t
On 07/28/2010 11:52 PM, Pat Farrell wrote:
A lot of the smart card development in the mid-90s and beyond was based
on the idea that the smart card, in itself, was the sole authorization
token/algorithm/implementation.
some ssl, payment, smartcard trivia ...
those smartcards were used for the o
Steven Bellovin writes:
>When I look at this, though, little of the problem is inherent to PKI.
>Rather, there are faulty communications paths.
"Oh no my Lord, I assure you that parts of it are excellent!" :-).
>[...] how should the CA or Realtek know about the problem? [...]
That was the whol
On Thu, Jul 29, 2010 at 10:50:10AM +0200, Alexandre Dulaunoy wrote:
> On Thu, Jul 29, 2010 at 3:09 AM, Nicolas Williams
> wrote:
> > This is a rather astounding misunderstanding of the protocol. [...]
>
> I agree on this and but the implementation of OCSP has to deal with
> all "non definitive"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jerry Leichter writes:
> The only conceivable purpose for using a signature is that you can
> check it *offline*. If you assume you can connect to the network,
> and that you can trust what you get from the network - why bother
> with a signature?
On 07/28/2010 11:52 PM, Pat Farrell wrote:
I'd like to build on this and make a more fundamental change. The
concept of a revocation cert/message was based on the standard practices
for things like stolen credit cards in the early 1990s. At the time, the
credit card companies published telephone
On 2010-07-29 12:18 AM, Peter Gutmann wrote:
This does away with the need for a CA,
because the link itself authenticates the cert that's used.
Then there are other variations, cryptographically generated addresses, ...
all sorts of things have been proposed.
The killer, again, is the refusal o
On Thu, Jul 29, 2010 at 3:09 AM, Nicolas Williams
wrote:
> This is a rather astounding misunderstanding of the protocol. An
> OCSPResponse does contain unauthenticated plaintext[*], but that
> plaintext says nothing about the status of the given certificates -- it
> only says whether the OCSP Re
On 07/28/2010 08:44 PM, Steven Bellovin wrote:
> When I look at this, though, little of the problem is inherent to
> PKI. Rather, there are faulty communications paths.
>
> You note that at t+2-3 days, the CA read the news. Apart from the
> question of whether or not "2-3 days" is "shortly after
On 2010-07-28, Jerry Leichter wrote:
There is, of course, the problem of knowing when a signature was
stolen!
Or in economic terms, asymmetric information. Can we for example learn
something from the way insurers and the like who've been dealing with
that for centuries solve the problem? And
On Wed, Jul 28, 2010 at 10:03:08PM +0200, Alexandre Dulaunoy wrote:
> On Wed, Jul 28, 2010 at 5:51 PM, Peter Gutmann
> wrote:
> > Nicolas Williams writes:
> >
> >>Exactly. OCSP can work in that manner. CRLs cannot.
> >
> > OCSP only appears to work in that manner. Since OCSP was designed to be
On Jul 28, 2010, at 9:22 29AM, Peter Gutmann wrote:
> Steven Bellovin writes:
>
>> For the last issue, I'd note that using pki instead of PKI (i.e., many
>> different per-realm roots, authorization certificates rather than identity
>> certificates, etc.) doesn't help: Realtek et al. still hav
On Wed, 28 Jul 2010 15:30:08 -0600 Paul Tiemann
wrote:
> > However, in discussing this at a high level, as though we could
> > improve things, we shouldn't kid ourselves about the current
> > model. It is fatally broken. Hanging garlands from the corpse's
> > ears will not convince anyone that it
On Wed, 28 Jul 2010 14:40:14 -0600 Paul Tiemann
wrote:
>
> On Jul 28, 2010, at 11:25 AM, Perry E. Metzger wrote:
>
> > On Wed, 28 Jul 2010 11:20:52 -0500 Nicolas Williams
> > wrote:
> >> On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
> >>> Again, I understand that in a techno
On Jul 28, 2010, at 10:37 AM, Perry E. Metzger wrote:
> As to OCSP being a reasonable solution because it can be deployed
> easily, it clearly will not solve the browser security problem. So
> long as security depends on reliance on the lowest common denominator
> among the policies of hundreds o
On Jul 28, 2010, at 11:25 AM, Perry E. Metzger wrote:
> On Wed, 28 Jul 2010 11:20:52 -0500 Nicolas Williams
> wrote:
>> On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
>>> Again, I understand that in a technological sense, in an ideal
>>> world, they would be equivalent. Howeve
On Jul 28, 2010, at 10:23 AM, Peter Gutmann wrote:
> Nicolas Williams writes:
>
>> Sorry, but this is wrong. The OCSP protocol itself really is an online
>> certificate status protocol.
>
> It's not an online certificate status protocol because it can provide neither
> a yes or a no respons
On Jul 28, 2010, at 9:51 AM, Peter Gutmann wrote:
> Nicolas Williams writes:
>
>> Exactly. OCSP can work in that manner. CRLs cannot.
>
> OCSP only appears to work in that manner. Since OCSP was designed to be 100%
> bug-compatible with CRLs, it's really an OCQP (online CRL query protocol)
On Wed, Jul 28, 2010 at 5:51 PM, Peter Gutmann
wrote:
> Nicolas Williams writes:
>
>>Exactly. OCSP can work in that manner. CRLs cannot.
>
> OCSP only appears to work in that manner. Since OCSP was designed to be 100%
> bug-compatible with CRLs, it's really an OCQP (online CRL query protocol)
On Wed, Jul 28, 2010 at 02:41:35PM -0400, Perry E. Metzger wrote:
> On the other edge of the spectrum, many people now use quite secure
> protocols (though I won't claim the full systems are secure --
> implementation bugs are ubiquitous) for handling things like remote
> login and file transfer, a
On Wed, 28 Jul 2010 12:38:10 -0500 Nicolas Williams
wrote:
> Again, if everything is too hard, why do we bother even talking
> about any of this? ETOOHARD cannot usefully be a retort to every
> suggestion.
Well, not everything is too hard. In fact, one of the important
characteristics of systems
On Wed, Jul 28, 2010 at 01:25:21PM -0400, Perry E. Metzger wrote:
> My mother relies on many certificates. Can she make a decision on
> whether or not her browser uses OCSP for all its transactions?
>
> I mention this only because your language here is quite sticky.
> Saying it is "up to the relyi
On Wed, 28 Jul 2010 11:20:52 -0500 Nicolas Williams
wrote:
> On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
> > Again, I understand that in a technological sense, in an ideal
> > world, they would be equivalent. However, the big difference,
> > again, is that you can't run Kerbe
On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
> Again, I understand that in a technological sense, in an ideal world,
> they would be equivalent. However, the big difference, again, is that
> you can't run Kerberos with no KDC, but you can run a PKI without an
> OCSP server. The
On Thu, Jul 29, 2010 at 04:23:52AM +1200, Peter Gutmann wrote:
> Nicolas Williams writes:
> >Sorry, but this is wrong. The OCSP protocol itself really is an online
> >certificate status protocol.
>
> It's not an online certificate status protocol because it can provide neither
> a yes or a no
On 07/28/2010 12:02 PM, Nicolas Williams wrote:
Sorry, but this is wrong. The OCSP protocol itself really is an online
certificate status protocol. Responder implementations may well be
based on checking CRLs, but they aren't required to be.
Don't be confused by the fact that OCSP borrows some
On Wed, 28 Jul 2010 11:23:16 -0500 Nicolas Williams
wrote:
> On Wed, Jul 28, 2010 at 11:20:51AM -0500, Nicolas Williams wrote:
> > On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
> > > Again, I understand that in a technological sense, in an ideal
> > > world, they would be equiv
Nicolas Williams writes:
>Sorry, but this is wrong. The OCSP protocol itself really is an online
>certificate status protocol.
It's not an online certificate status protocol because it can provide neither
a yes or a no response to a query about the validity of a certificate.
(For an online s
On Wed, Jul 28, 2010 at 11:20:51AM -0500, Nicolas Williams wrote:
> On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
> > Again, I understand that in a technological sense, in an ideal world,
> > they would be equivalent. However, the big difference, again, is that
> > you can't run
On Wed, 28 Jul 2010 10:50:52 -0500 Nicolas Williams
wrote:
> On Wed, Jul 28, 2010 at 11:38:28AM -0400, Perry E. Metzger wrote:
> > On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams
> > wrote:
> > > OCSP Responses are much like a PKI equivalent of Kerberos
> > > tickets. All you need to do to re
On Thu, Jul 29, 2010 at 03:51:33AM +1200, Peter Gutmann wrote:
> Nicolas Williams writes:
>
> >Exactly. OCSP can work in that manner. CRLs cannot.
>
> OCSP only appears to work in that manner. Since OCSP was designed to be 100%
> bug-compatible with CRLs, it's really an OCQP (online CRL quer
On Wed, Jul 28, 2010 at 11:38:28AM -0400, Perry E. Metzger wrote:
> On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams
> wrote:
> > OCSP Responses are much like a PKI equivalent of Kerberos tickets.
> > All you need to do to revoke a principal with OCSP is to remove it
> > from the Responder's da
Nicolas Williams writes:
>Exactly. OCSP can work in that manner. CRLs cannot.
OCSP only appears to work in that manner. Since OCSP was designed to be 100%
bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and
not an OCSP. Specifically, if I submit a freshly-issued,
On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams
wrote:
> OCSP Responses are much like a PKI equivalent of Kerberos tickets.
> All you need to do to revoke a principal with OCSP is to remove it
> from the Responder's database or mark it revoked.
Actually, that's untrue in one very important re
On 07/28/2010 11:05 AM, Nicolas Williams wrote:
Are you arguing for Kerberos for Internet-scale deployment? Or simply
for PKI with rp-only certs and OCSP? Or other "federated"
authentication mechanism? Or all of the above? :)
as i've mentioned ... the relying-party-only certificates are alm
On Wed, Jul 28, 2010 at 11:13:36AM -0400, Perry E. Metzger wrote:
> On Wed, 28 Jul 2010 09:30:22 -0500 Nicolas Williams
> wrote:
>
> I have no objections to "infrastructure" -- bridges, the Internet,
> and electrical transmission lines all seem like good ideas. However,
> lets avoid using the ter
On Wed, 28 Jul 2010 09:30:22 -0500 Nicolas Williams
wrote:
> On Wed, Jul 28, 2010 at 10:05:22AM -0400, Perry E. Metzger wrote:
> > PKI was invented by Loren Kohnfelder for his bachelor's degree
> > thesis at MIT. It was certainly a fine undergraduate paper, but I
> > think we should forget about i
On 28/07/2010 16:01, Perry E. Metzger wrote:
> On Wed, 28 Jul 2010 15:16:32 +0100 Ben Laurie wrote:
>> SSH does appear to have got away without revocation, though the
>> nature of the system is s.t. if I really wanted to revoke I could
>> almost always contact the users and tell them in person.
>
On Wed, Jul 28, 2010 at 10:42:43AM -0400, Anne & Lynn Wheeler wrote:
> On 07/28/2010 10:05 AM, Perry E. Metzger wrote:
> >I will point out that many security systems, like Kerberos, DNSSEC and
> >SSH, appear to get along with no conventional notion of revocation at all.
>
> long ago and far away .
On Wed, 28 Jul 2010 15:16:32 +0100 Ben Laurie wrote:
> On 28 July 2010 15:05, Perry E. Metzger wrote:
> > On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie wrote:
> >>
> >> And still needs revocation.
> >
> > Does it?
> >
> > I will point out that many security systems, like Kerberos,
> > DNSSEC and
On Wed, Jul 28, 2010 at 03:16:32PM +0100, Ben Laurie wrote:
> Maybe it doesn't, but no revocation mechanism at all makes me nervous.
>
> I don't know Kerberos well enough to comment.
>
> DNSSEC doesn't have revocation but replaces it with very short
> signature lifetimes (i.e. you don't revoke, y
On Wed, Jul 28, 2010 at 08:48:14AM -0400, Steven Bellovin wrote:
> There seem to be at least three different questions here: bad code
> (i.e., that Windows doesn't check the revocation status properly),
> the UI issue, and the conceptual question of what should replace the
> current PKI+{CRL,OCSP}
On 28/07/2010 15:18, Peter Gutmann wrote:
> Ben Laurie writes:
>
>> However, using private keys to prove that you are (probably) dealing with
>> the
>> same entity as yesterday seems like a useful thing to do. And still needs
>> revocation.
>
> It depends on what you mean by revocation, tradi
Perry,
I think public key cryptography is a wonderful thing. I'm just not
sure I believe at all in PKI -- that is, persistent certification via
certificates, certificate revocation, etc.
I'm sure you remember Peter Honeyman's "PK-no-I" talk from
the '99 USENIX Security Symposium? :-)
Cheers,
On 07/28/2010 10:05 AM, Perry E. Metzger wrote:
I will point out that many security systems, like Kerberos, DNSSEC and
SSH, appear to get along with no conventional notion of revocation at all.
long ago and far away ... one of the tasks we had was to periodically go by project athena to "audit"
On Wed, Jul 28, 2010 at 10:05:22AM -0400, Perry E. Metzger wrote:
> PKI was invented by Loren Kohnfelder for his bachelor's degree thesis
> at MIT. It was certainly a fine undergraduate paper, but I think we
> should forget about it, the way we forget about most undergraduate
> papers.
PKI alone i
Ben Laurie writes:
>However, using private keys to prove that you are (probably) dealing with the
>same entity as yesterday seems like a useful thing to do. And still needs
>revocation.
It depends on what you mean by revocation, traditional revocation in the PKI
sense isn't needed because (we
On 28 July 2010 15:05, Perry E. Metzger wrote:
> On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie wrote:
>> On 28/07/2010 14:05, Perry E. Metzger wrote:
>> > It is not always the case that a dead technology has failed
>> > because of infeasibility or inapplicability. I'd say that a
>> > number of fi
On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie wrote:
> On 28/07/2010 14:05, Perry E. Metzger wrote:
> > It is not always the case that a dead technology has failed
> > because of infeasibility or inapplicability. I'd say that a
> > number of fine technologies have failed for other reasons.
> > How
On 28/07/2010 14:05, Perry E. Metzger wrote:
> It is not always the case that a dead technology has failed because of
> infeasibility or inapplicability. I'd say that a number of fine
> technologies have failed for other reasons. However, at some point, it
> becomes incumbent upon the proponents of
Steven Bellovin writes:
>For the last issue, I'd note that using pki instead of PKI (i.e., many
>different per-realm roots, authorization certificates rather than identity
>certificates, etc.) doesn't help: Realtek et al. still have no better way or
>better incentive to revoke their own widely
Peter,
In any case though the whole thing is really a moot point given the sucking
void that is revocation-handling, the Realtek certificate was revoked on the
16th but one of my spies has informed me that as of yesterday it was still
regarded as valid by Windows.
I can confirm that, at le
On Wed, 28 Jul 2010 11:38:17 +0100 Ben Laurie wrote:
> On 28/07/2010 09:57, Peter Gutmann wrote:
> > In any case though the whole thing is really a moot point given
> > the sucking void that is revocation-handling, the Realtek
> > certificate was revoked on the 16th but one of my spies has
> > inf
On Jul 28, 2010, at 8:21 33AM, Ben Laurie wrote:
> On 28/07/2010 13:18, Peter Gutmann wrote:
>> Ben Laurie writes:
>>
>>> I find your response strange. You ask how we might fix the problems, then
>>> you
>>> respond that since the world doesn't work that way right now, the fixes
>>> won't
>
On Wed, Jul 28, 2010 at 01:21:33PM +0100, Ben Laurie wrote:
> On 28/07/2010 13:18, Peter Gutmann wrote:
> > Ben Laurie writes:
> >
> >> I find your response strange. You ask how we might fix the problems, then
> >> you
> >> respond that since the world doesn't work that way right now, the fixes
On 28/07/2010 13:18, Peter Gutmann wrote:
> Ben Laurie writes:
>
>> I find your response strange. You ask how we might fix the problems, then
>> you
>> respond that since the world doesn't work that way right now, the fixes
>> won't
>> work. Is this just an exercise in one-upmanship? You know
Ben Laurie writes:
>I find your response strange. You ask how we might fix the problems, then you
>respond that since the world doesn't work that way right now, the fixes won't
>work. Is this just an exercise in one-upmanship? You know more ways the world
>is broken than I do?
It's not just t
On Jul 27, 2010, at 5:34 PM, Ben Laurie wrote:
> On 24/07/2010 18:55, Peter Gutmann wrote:
>> - PKI dogma doesn't even consider availability issues but expects the
>> straightforward execution of the condition "problem -> revoke cert". For a
>> situation like this, particularly if the cert was
On 28/07/2010 09:57, Peter Gutmann wrote:
> Ben Laurie writes:
>> On 24/07/2010 18:55, Peter Gutmann wrote:
>>> - PKI dogma doesn't even consider availability issues but expects the
>>> straightforward execution of the condition "problem -> revoke cert". For
>>> a
>>> situation like this, pa
On 28/07/2010 00:14, Paul Tiemann wrote:
> On Jul 27, 2010, at 3:34 PM, Ben Laurie wrote:
>
>> On 24/07/2010 18:55, Peter Gutmann wrote:
>>> - PKI dogma doesn't even consider availability issues but expects the
>>> straightforward execution of the condition "problem -> revoke cert". For a
>>> s
Ben Laurie writes:
>On 24/07/2010 18:55, Peter Gutmann wrote:
>> - PKI dogma doesn't even consider availability issues but expects the
>> straightforward execution of the condition "problem -> revoke cert". For a
>> situation like this, particularly if the cert was used to sign 64-bit
>> dr
On Jul 27, 2010, at 3:34 PM, Ben Laurie wrote:
> On 24/07/2010 18:55, Peter Gutmann wrote:
>> - PKI dogma doesn't even consider availability issues but expects the
>> straightforward execution of the condition "problem -> revoke cert". For a
>> situation like this, particularly if the cert was
On 24/07/2010 18:55, Peter Gutmann wrote:
> - PKI dogma doesn't even consider availability issues but expects the
> straightforward execution of the condition "problem -> revoke cert". For a
> situation like this, particularly if the cert was used to sign 64-bit
> drivers, I wouldn't have re
77 matches
Mail list logo
