Subject: Re: [pkix] An alternative proposal Was: Fwd: New Version

From: "Kyle Hamilton" <[email-masked]>
Date: Thu, 3 Nov 2011 02:22:30 -0700 (Pacific Daylight Time)

On Wed, Nov 2, 2011 at 7:24 PM, Martin Rex <[email-masked]> wrote:
> Rob Stradling wrote:
>>
>> On Monday 31 Oct 2011 17:35:48 Martin Rex wrote:
>> >
>> > ...and the client can indicate whether it still has cached OCSP-responses
>> > available and for which server certificate chain, which would obviate the
>> > sending of the stapled OCSP responses with each and every handshake (such as
>> > abbreviated TLS handshakes, aka session resumes) and still work
>> > successfully/transparently for credentials updates on the server.
>>
>> Do you think the best way to accomplish this would be to extend draft-ietf-
>> tls-cached-info ?
>
> If anything, I would be interested in a *SIMPLE* TLS extension
> which results in _one_ single set of OCSP responses per server
> certificate that the server can cache for several hours and
> refresh truely asynchronous.  And that is something where
> monitoring the OCSP retrieval on the server side would
> make sense without having to define filters on which kind
> of client-specified OCSP requests ought to be ignored for sanity.

I think that this is inappropriate as a TLS extension.

Instead, the problem can be completely solved in PKIX.

Have a self-signed certificate which contains everything -- not just one certificate chain, but several certificate chains.  Not just one OCSP response, but several OCSP responses.  Not just one timestamp, but several timestamps.  Have provable signature chains, all of which end up signing the self-certified key inside a certificate extension, which self-certified key is used to authenticate TLS.  If any one of those identity chains is trusted, then the ownership of the key can in fact be determined and the connection meets browser https standards.

(This has the added benefit that the truly important key, the potentially EV-certified key, can be kept off of the webserver and perhaps thus be less prone to theft.)

I've got an ASN.1 module worked up for this, but I haven't fleshed out the description enough for a draft.  https://kyanha.net/wordpress/?page_id=34

-Kyle H

---

From: Rob Stradling <[email-masked]>
Date: Thu, 3 Nov 2011 11:15:59 +0000

On Thursday 03 Nov 2011 09:22:30 Kyle Hamilton wrote:
<snip>
> I think that this is inappropriate as a TLS extension.

Why do you think this?

> Instead, the problem can be completely solved in PKIX.

Maybe it could, but IMHO that's not an argument for why it might be 
"inappropriate as a TLS extension".

<snip>

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 3 Nov 2011 12:35:14 +0000

On 11/3/11 4:22 AM, "Kyle Hamilton" <[email-masked]> wrote:

>Have a self-signed certificate which contains everything -- not just one
>certificate chain, but several certificate chains.  Not just one OCSP
>response, but several OCSP responses.  Not just one timestamp, but
>several timestamps.  Have provable signature chains, all of which end up
>signing the self-certified key inside a certificate extension, which
>self-certified key is used to authenticate TLS.  If any one of those
>identity chains is trusted, then the ownership of the key can in fact be
>determined and the connection meets browser https standards.

Color me confused, but how is this different from SPKI delegation?
Wouldn't that be simpler?

-- T

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Nov 2011 11:12:24 -0400

At 2:22 AM -0700 11/3/11, Kyle Hamilton wrote:
>C
>>...
>Have a self-signed certificate which contains everything -- not just 
>one certificate chain, but several certificate chains.  Not just one 
>OCSP response, but several OCSP responses.  Not just one timestamp, 
>but several timestamps.  Have provable signature chains, all of 
>which end up signing the self-certified key inside a certificate 
>extension, which self-certified key is used to authenticate TLS.  If 
>any one of those identity chains is trusted, then the ownership of 
>the key can in fact be determined and the connection meets browser 
>https standards.

One ought mot confuse the ability to encode data as a cert extension with the
desirability of doing so :-).

I do not envision this sort of stuffing everything into a cert to be 
adopted by PKIX.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Nov 2011 14:07:56 -0400

On Thu, Nov 3, 2011 at 11:12 AM, Stephen Kent <[email-masked]> wrote:

>> response, but several OCSP responses.  Not just one timestamp, but several
>> timestamps.  Have provable signature chains, all of which end up signing
>> the self-certified key inside a certificate extension, which self-certified
>> key is used to authenticate TLS.  If any one of those identity chains is
>> trusted, then the ownership of the key can in fact be determined and the
>> connection meets browser https standards.
>>
>

Well I could see it happening if there was no other way to do it :)

But we have a slot in the protocol that is made for this exact purpose so
there would have to be a good reason not to use TLS extensions for an
extension to TLS IMO

-- 
Website: http://hallambaker.com/

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 04 Nov 2011 10:36:00 +1300

Stephen Kent <[email-masked]> writes:

>I do not envision this sort of stuffing everything into a cert to be adopted
>by PKIX.

Exactly.  Defining a mechanism for putting theme music into a certificate (RFC
3709, PKIX Standards Track) is perfectly appropriate for PKIX, but this...
this is just going too far.

Peter (sorry, couldn't resist :-).

---

From: "Kyle Hamilton" <[email-masked]>
Date: Sun, 6 Nov 2011 09:03:46 -0800 (Pacific Standard Time)

(long)

>> I think that this is inappropriate as a TLS extension.

Several reasons.

1) It perpetuates the "single point of failure" model.  Exactly one certificate chain (and heaven help you and your business if it's from DigiNotar or any other CA which loses trust, or a private-label/unknown CA on a site which doesn't deal with credit cards or personal information at all).  Precisely one set of OCSP responses.  We have seen what this does (from both "too big to fail" and "sleepwalking CA" standpoints), and it is not something that should be perpetuated.

2) It is inflexible, requiring additional standards-body wrangling to make a different patch for additional problems which will undoubtedly be found, but which (for political reasons) can't be directly addressed in the structure from the WG which created it.

3) It is a patch for a problem related to the provision of multiple PKIX-standard.data formats.  It does nothing to address the core issues with PKIX which make consuming it so hit-or-miss and so brittle when implemented.

4) It relates to only one specific class of communication which occurs on the Internet (reliable non-multicast).  It does nothing to address or resolve the same issues which also exist in the email, code signing, and other consumptions of PKIX data structures and information within them.  Notably, this kind of extensible structure would also be useful for email, where you might wish to include the OCSP responses, the various hashes of the message, and the timestamps to prove that it was all generated within the validity period of the certificate chain (which is something S/MIME's implementations apparently currently lack).  It makes no sense to try to address this kind of extensibility issue in each individual protocol.

5) It doesn't provide any means for additional extensibility, such as would be required by risk managers to implement redundancy in their CA services.  e.g., TLS lets each peer assert one certificate chain.  Instead of forcing TLS to try to create a means to atomically assert multiple certified end-entity public keys (for risk-management's sake, to give businesses a fighting chance to sleep well at night) or forcing the host to have the same key certified by multiple CAs (not necessarily the easiest thing to do, depending on the vendors involved), PKIX should adopt a means to let the same structures be used to transport a greater amount of trustworthy information than it originally thought would be sufficient.

6) It relies upon active non-hostile participation in the protocol, and is something that would be better served by simply having the server periodically (cron, anyone?) obtain its chain's OCSP responses and provide them.

> "inappropriate as a TLS extension".

Different protocols have different needs from the authentication package.  Shifting the data format to something flexible would permit these protocols and implementations to deal with their own vulnerabilities from within the security layer, in a place where only trustworthy information can exist (barring signature algorithm breakage).  PKIX-WG would retain control of the format, so it would still be able to specify defenses for model-wide attacks (like sleepwalking CAs).  Different protocols also suffer different potential vulnerabilities.  For instance, code signing requires a timestamp to prove that the binary existed prior to the expiration of the certificate, which has led to the provision of signatures and timestamps in various executable and archive formats.

On the other hand, TLS relates to reliable communications near-realtime, so it doesn't need to timestamp.  But, it doesn't provide any means for the client to convey its acceptable list of CAs to the server, and so (for risk-management) needs to be able to provide multiple certificate chains and possibly their collective OCSP responses.  Those certificate chains from the multiple CAs might certify the same key, but they might also certify different keys.  To address this, the eventual format should provide for both/all of them to be able to certify a third/extra key, which would self-certify an extension containing the signature chains which signed it, and prove possession during the handshake.

One flexible data format would permit consuming protocols to evolve on their own and defend against their own newly-discovered vulnerabilities.  One flexible data format would be enough to support current and future applications.  One flexible data format would permit PKIX-WG to retain control and provide defenses for model-wide vulnerabilities, such as sleepwalking CAs.

There needs to be an overarching schema for extensibly consuming current and future PKIX data formats, modularly, in ways and with defenses appropriate to the context, without forcing the client protocols to have to reinvent the wheel to get authenticated data from point A to point B.

PKIX-WG is all about authenticated information.  Why does it limit itself to one rigid, brittle, and broken paradigm where it only needs to provide one piece of it?  We're not the ITU.  We have much different needs than they ever envisioned.  We have been shackled by that worldview that says, in effect, self-signed certificates have no conceivable use, so they have no possible use.  This is completely untrue, and has absolutely no place enshrined in an Internet standard.

PKIX-WG's steadfast blindness remains that its standards are littered with single points of failure, against the Internet's "function even without particular networks or services available" design criterion.  I believe that its insistence that it would provide only so much and only one of that so much, with no extensibility at all, has led us to a place where we simply cannot progress without flexibility.  (There's still wrangling over CRL sizes, and an absolute non-starter on a certificate whitelist.)

Worse, though, client protocols like TLS have taken their cues from this simplistic and dictatorian arrogance, providing only one place for authentication information, only one encoding, only one credential chain, and only one credential semantic as a completely exclusive and inextensible proposition.  They almost cry out for a single extensible PKIX-specified format to put into them.

PKIX-WG can completely solve this impedence mismatch.  Even better, it can be done simply, easily, and relatively cheaply.

Thanks for your time.

-Kyle H

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 7 Nov 2011 13:55:29 +0000

On 11/6/11 11:03 AM, "Kyle Hamilton" <[email-masked]> wrote:

>PKIX-WG is all about authenticated information.  Why does it limit itself
>to one rigid, brittle, and broken paradigm where it only needs to provide
>one piece of it?  We're not the ITU.  We have much different needs than
>they ever envisioned.  We have been shackled by that worldview that says,
>in effect, self-signed certificates have no conceivable use, so they have
>no possible use.  This is completely untrue, and has absolutely no place
>enshrined in an Internet standard.

Um, what?  No-one is stopping you from using Certificate in any way you
choose.  Self-signed certificates have plenty of uses, and in fact are
used extensively in real systems.  You can use PKIX-defined formats
without using PKIX-defined trust concepts; I use key continuity systems
avery day using CA-signed certificates, and they work.  TCG uses
PKIX-defined formats with a *completely different* delegation trust model,
and the Grid people have also built different trust models atop the same
formats.

PKIX in reality defines very little:  (1) A format for data; (2) a method
of binding a key to that data; and (3) one method of establishing
assurance in that binding.  Everything else is your business.

>PKIX-WG can completely solve this impedence mismatch.  Even better, it
>can be done simply, easily, and relatively cheaply.

You have a complete misapprehension of how this body functions and what it
provides.

-- T

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Nov 2011 15:07:37 -0500

Kyle,

I think your proposal has several problems.

First, many folks have noted why they do not believe that a whitelist 
would really solve the cited problem.

Second, many folks believe that DigiNotor is a bad example, because 
their security practices seem to have been rather lax.

Other methods, consistent with current standards, can accommodate 
failures of the sort noted. For example, it is common practice for 
many CAs to have an offline CA, and subordinate, online (production) 
CAs. If one of the production CAs were compromised ala the DigiNotor 
case, one could revoke the production CA cert, and reissue certs to 
all of the (known, valid) clients under a new, production CA. This 
could be done using the extant public keys for each client, so the 
only requirement is distribution of the new certs to the clients, for 
inclusion in TLS handshakes (I use the TLS example because that is 
the context of the cited failure.)

Steve

---

From: Martin Rex <[email-masked]>
Date: Wed, 9 Nov 2011 23:38:41 +0100 (MET)

> I think your proposal has several problems.

I'm sympathetic with Kyle's motiviation and at least some
of his goal, but I'm not feeling comfortable yet with this specific
proposal.

> their security practices seem to have been rather lax.

I think that DigiNotar is a perfectly valid example and actually
representative for a larger number of real CAs.  Btw. Up to today,
my Windows XP machine "trusted RootCA store" has been populated
by Microsoft with 345 RootCA certs (46 of those expired), so the
risk is ever expanding.  You probably read the news about
the recent revocation of cross-certificates for a Malaysian CA
that probably does not have its own RootCA in the Browsers, e.g.:
http://www.theregister.co.uk/2011/11/03/certificate_authority_banished/

I'm slightly puzzled by the text in this software update:
http://www.securityfocus.com/archive/1/520453/30/0/threaded

  Several weak certificates were issued by Malaysian intermediate CA
  "Digicert Sdn. Bhd." This event, along with other issues, has lead to
  Entrust Inc. and Verizon Cybertrust to revoke the CA's cross-signed
  certificates.

Does this mean that Digicert Malaysia obtained *TWO* independent
cross-certificates, one from Entrust Inc. plus one from Verizon Cybertrust,
both of which have rootCA certs as trust anchors in Browsers?
(and the result that revoking only one of those might not help?)

> the context of the cited failure.)

I don't think this helps by any measure.  At best it helps customers
to get a new cert without having to pay again, but the administrative
overhead is exactly the same as enrolling with an CA from an entirely
different company, therefore I do not see this as a solution of any kind.

While it is a common US military stereotype in Hollywood movies
that they blindly and quickly nuke the entire area of an outbreak
or contamination, rather than trying to minimize collateral damage
and save lives, I do not think that is a desirable goal for
PKIX to always, quickly and unconditionally nuke CAs, and entire PKIs
along with it, whenever there is the slightest sign of suspicious
activity on any of the CAs equipment.

There was just the other news report about another dutch CA operated
by KPN has suspended certificate issuance for an investigation:
http://www.kpn.com/corporate/overkpn/Newsroom/nieuwsbericht/KPN-stopt-uit-voorzorg-uitgifte-nieuwe-veiligheidscertificaten.htm
They found malware on some of their machines and it seems that
this malware may have sneaked in already 4 years ago.  They haven't
found any evidence yet that any fraudulent certs have been issued.

So whitelist could really help to deal more sensibly and safely
with (much more common) security breaches rather than complete CA
compromises.

Why should the compromise of a CA adversely affect the credentials
of a TLS server AT ALL?  As you suggest yourself "reissue certs
under a new CA using the extant public keys".  Your suggestion
only cuts down on the CA expenses (for RA checking and invoicing)
but hits the certificate holders as badly as possible (the same
re-personalization effort as for getting certs issued from a CA
operated by a different company.

I would really appreciate *NOT* having to re-personalize everything
*PLUS* not having to constantly software-update the blacklists
wihtin every TLS client (in particular the huge numbers of
them without credentials) for every such event.

Your assumption
"reissue certs under a new CA using the extant public keys"
is vitally dependent on the ability to distinguish good from
fraudulent certs.  If the CA is capable of performing this
distinction, and the organization is sufficiently trusted for
continued confirmation of prior known-good RA validations,
then the most reasonable engineering approach would be to
convey exactly this information to the RPs -- which would
obviate the immediate nuking of the CA and its surrounding PKI,
i.e. obviate the repersonalization of all current certificate holders.

And it is up to PKIX to "wiggle out" a solution to limit the
necessity for frequent nuking CAs&PKIs.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 10 Nov 2011 09:30:05 +0200

On 11/10/11 12:38 AM, "Martin Rex" <[email-masked]> wrote:
>You probably read the news about

I was wondering about that. The CA issued 22 certificates with 512-bit
public keys.  How could this possibly happen?

Is it that the EE made a PKCS#10 with a 512-bit public key, and the CA
just signed it?  That wouldn't be too bad.

If the CA generated the public keys, how did it happen that all the other
customers get good public keys, but a particular subset gets weak ones?
Was this caused by a break-in?

This is far weirder than the mis-issued certificates stories.

Yoav

---

From: Rob Stradling <[email-masked]>
Date: Thu, 10 Nov 2011 12:22:48 +0000

> >cross-certificates, one from Entrust Inc. plus one from Verizon

Yes.

http://www.digicert.com.my/repository.htm
http://www.digicert.com.my/download/Digisign%20Server%20ID%20Enrich.cer
http://www.digicert.com.my/download/Digisign%20Server%20ID%20-%20(Enrich).cer

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

I understand that these 2 certs have been revoked by Entrust and Cybertrust.

> >(and the result that revoking only one of those might not help?)

The 2 certs above have different keypairs, so they couldn't have been used 
interchangeably for verifying any given EE cert.

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

Rob Stradling

---

From: Tim Moses <[email-masked]>
Date: Thu, 10 Nov 2011 09:54:53 -0500

Yoav - You've answered your own question.  Why would a CA be generating server SSL keys?

Best regards.  Tim.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Thursday, November 10, 2011 2:30 AM
To: [email-masked]
Subject: [pkix] Malaysian CA (Was: An alternative proposal Was: Fwd: New Version)

Yoav

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Nov 2011 11:03:31 -0500

Martin,

The point I and other have made is that well-run CAs ought not be 
susceptible to the sort of massive failure that DigiNotor exhibited.

We do not favor creating new mechanisms (which impose burdens on CAs, 
RPs, OCSP servers, etc.) designed to address procedural security 
lapses at poorly run CAs.

As folks have noted, many of the failure scenarios cited would NOT be 
ameliorated by a white list, as the white list also could be forged as
a side effect of issuing bogus certs. When it is detected that bogus certs have
been issued, then a competently run CA can revoke them.

Steve

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 10 Nov 2011 16:11:40 +0000

>(and the result that revoking only one of those might not help?)

Yes.  PKIs are not limited in the number of cross-certificates they can
issue or accept.

>with (much more common) security breaches rather than complete CA

I still don't see how.  If a breach at an issuer that is less than
"complete CA compromise" results in a fraudulent certificate, how does the
whitelist inform the relying party about anything more than a simple
revocation?

>of a TLS server AT ALL?

Because in X.509, the key the web server is using isn't the important
part; the *name* the certificate bears is what matters (keys are bound to
names, not the other way around, remember).  A compromised CA can bind a
new key to any existing name or names.

This is exactly what the attacker did in both the Comodo and DigiNotar
incidents.

A response to this kind of compromise does not need to revoke all
certs--provided 
the CA can revoke all the fraudulent certificates.  This requires that the
CA know at least the serial number of those certificates.  If the CA
doesn't know or can't recover all these values, then the only other
recourse is to invalidate the CA because there is no way to assure relying
parties that a given certificate is not fraudulent.

Consider a CA that has issued the set of certs A, where cert x (in A) is
known to be valid, and all others in A are frauds.  In this case, an OCSP
or SCVP service can validate x and invalidate everything else by comparing
all queries to x.  

That¹s great, but unfortunately, it's also insufficient.  The CA must also
issue a CRL, but the set A may be infinite.  Relying parties that need
CRLs can't reach a conclusion, so to support all relying parties the CA
must be invalidated.

If OCSP and CRLs are to be semantically equivalent, whitelist extensions
to OCSP means we need to change CRLs too, or add a third instrument
("Certificates Issued List") that carries the same information.  This
ripples through all implementations.

In my opinion, OCSP and CRL semantics must be consistent, else the
difference can be exploited.  For example, an attacker can block OCSP
services using whitelists but permit CRLs that lack that data, and the
relying party will improperly conclude that a given certificate is not
revoked.

-- T

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 10 Nov 2011 12:04:09 -0500

If a CA has been compromised, but has a record of every certificate that 
was fraudulently issued, it can simply revoke those certificates.  No 
white list needed.  If a CA has been compromised and can't be certain 
about what certificates were fraudulently issued, how can the CA be 
certain that the attacker hasn't generated an OCSP responder certificate?

If I understand the basic idea behind the recent compromises, the 
attacker has obtained fraudulent TLS server certificates.  Presumably 
this means that the attacker was also able to redirect traffic from the 
legitimate sites to servers controlled by the attacker.  Couldn't the 
attacker similarly redirect traffic to an OCSP responder that it 
controls?  If an attacker has so much control over a CA that it can get 
the CA to issue fraudulent certificates and it can remove from the CA's 
logs any record that the certificates were issued (or at least prevent 
the CA's operators from determining the serial numbers of the fraudulent 
certificates), shouldn't it be assumed that the attacker would be able 
to get the CA to issue it a fraudulent OCSP responder certificate (with 
an id-pkix-ocsp-nocheck extension, of course)?  The attacker could then 
have its OCSP responder provide a response of "good" for the fraudulent 
certificates that the attacker obtained from the CA, and it could even 
include the new "white list" extension in the OCSP response so that the 
relying party could have extra confidence that the certificates really 
were legitimate.  The client would accept the OCSP response from the 
attacker based on the fraudulently-issued OCSP responder certificate, 
and the fact that the OCSP responder certificate didn't appear on a 
"white list" wouldn't matter since the certificate has an 
id-pkix-ocsp-nocheck extension.  (I don't think anyone is suggesting 
that a relying party should have to download a CA's entire white list 
before using OCSP to determine the status of a certificate.)

Under what circumstances could a white list protect against such an 
attack without requiring the revocation of the compromised CA's 
certificate?  Under which of those circumstances would the current 
certificate revocation mechanisms be inadequate?

Dave

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Nov 2011 19:52:42 +0100 (MET)

> certain that the attacker hasn't generated an OCSP responder certificate?

If I CA determines a security breach, it will have to investigate.
When it finds no find records of certificate issuance, that does
not proof that none were issued.  Requiring a whitelist means
that in order to make a fraudulently and covertly created cert
MUST be added to the online database of issued certs when there
is a whitelist requirement.  Without such a requirement, not only
covertly created certs will have to be considered valid, but also
all other certs that may have been created without access to
the CA hardware, that includes those created by a hash collision.
Remeber that the fake rapidSSL cert was created *WITHOUT* a
a CA breakin.  If there was a whitelisting requirement,
then a CA breakin and revealing of the fraudulent cert
at least to the issuing CA will be an unavoidable prerequisite.

I also pointed to the X.509/PKIX design flaw in previous messages.
Conveying the OCSP responder through the

  EE cert ("this is where you can query the revocation status of this cert")

instead of through the

  CA cert ("this is where I you can query the revocation status of certs
            that I have issued")

is a design flaw in the OCSP-AIA and CRL-distributionpoint extensions.

One of the complaints about the certs issued by that Malaysian CA
was that the certs were issed with not revocation info in them:

  ... The omissions of Digicert Malaysia appear to be a serious violation
  of CA security standards. Its use of 512-bit keys, for instance,
  stand in stark contrast to the minimum requirement that keys contain
  twice that length. What's more, the lack of revocation information
  makes it harder to recall Digicert Malaysia certificates if they're
  found to be flawed, and the failure to include EKU information
  allows them to be abused in ways that otherwise wouldn't be possible.

Being able to issue yourself CRL signer, OCSP signer certs and
subordinate CA certs *AND* controlling the location where these
fraudulent certs will be checked for revocation looks like a
very bad idea to me.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 11 Nov 2011 13:24:55 +1300

Tim Moses <[email-masked]> writes:

>You've answered your own question.  Why would a CA be generating server SSL
>keys?

The CA generates the client's key for them and sends it out as a PKCS #12
file, it's relatively common.  So no, I don't think he's answered his own
question.

Peter.

---

From: Tom Gindin <[email-masked]>
Date: Thu, 10 Nov 2011 20:21:18 -0500

I don't think that the various whitelist proposals can work unless 
there is a way of issuing a set of whitelist CRL's (a single whitelist CRL 
is unwieldy for any but the smallest CA's), and also a way of detecting 
bogus CRL Distribution Points issued by an attacker in temporary control 
of the CA's key.
        I think that a whitelist CRL for a distribution point consisting 
of a lot of removeFromCRL entries with a few ones with other reason codes 
is workable, and if the distribution point CRL's are partitioned with 1000 
or so certificates assigned to each one they are easily downloaded. 
However, an attacker with reasonable sophistication would surely issue his 
own distribution point CRL or a certificate pointing at a captive OCSP 
server - perhaps both.  For similar reasons to those you give below, I see 
little point to any whitelist procedure unless it makes an RP capable of 
detecting this.
        Any recovery from a CA compromise short of revoking the issuer 
will violate the principle that all security lies in the key.  Once the 
key has ever been compromised, its signature on a long-lived document has 
only provisional value.  Under those conditions, the security of a 
predefined set of servers is actually greater than that of the 
once-compromised key.  So to detect a bogus CRL signed by the temporarily 
successful attacker, we'd need a constraint extension that allowed the 
issuer's certificate to restrict the domains allowed to be used for 
Distribution Points or OCSP servers.  To have that constraint extension 
enforced, the CA's own certificate would not be a self-signed root.  It 
could be (as I suggested in a different context, 
http://www.ietf.org/mail-archive/web/pkix/current/msg29762.html) a 
cross-certificate from the RP maker or distributor.  For such a purpose 
the anchor would need to be the RP's own chosen issuer rather than the 
cross-certificate, along the lines which you earlier suggested.
        We don't have these facilities now, but I don't believe that they 
break X.509's model.  Are they worth it?

Tom Gindin

P.S.    The opinions above are mine, and not necessarily those of my 
employer.

From:   "David A. Cooper" <[email-masked]>
To:     "[email-masked]" <[email-masked]>, 
Date:   11/10/2011 12:06 PM
Subject:        Re: [pkix] An alternative proposal Was: Fwd: New Version
Sent by:        [email-masked]

Dave

---

From: Yoav Nir <[email-masked]>
Date: Sat, 12 Nov 2011 03:20:31 +0200

>file, it's relatively common.  So no, I don't think he's answered his own

True. Most website administrators don't know the secret openssl
incantation to generate a PKCS#10.

If all the CA did was agree to sign requests without checking for weak
keys, that could be considered a bug worth fixing, but it would be
entirely their customers' fault. If that had prompted the blacklisting and
revocation of the CA certificate, I would say the community was
over-reacting this time.

Yoav

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 12 Nov 2011 16:07:12 +1300

Yoav Nir <[email-masked]> writes:
>>file, it's relatively common.  
>
>True. Most website administrators don't know the secret openssl incantation
>to generate a PKCS#10.

I'm not sure it's actually that, for almost all of the ones I know of it's the
CA that insists on generating the private key.  The reasons are usually some
handwaving variant of "it's for security reasons", but the explanations
generally aren't very convincing [0].  I suspect the main motivator is
convenience for the CA, the client enters their email address and credit card
details on a web page and the CA emails them their new key and cert, it's
the lowest-overhead-cost way of doing it.

Peter.

[0] I've been sent PKCS #12 files from commercial CAs that generate insecure
    RSA keys, so they're really not at all convincing.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 12 Nov 2011 08:03:26 +0200

>    RSA keys, so they're really not at all convincing.

Maybe. The MD5 attack on RapidSSL would not succeed if they didn't accept
PKCS#10 requests.

I just checked, and openssl's genrsa subcommand generates 512-bit RSA keys
by default.  Maybe bad defaults killed the Malaysian CA.

---

From: Tim Moses <[email-masked]>
Date: Mon, 14 Nov 2011 09:18:26 -0500

Yoav - I don't believe CA-generated subscriber key-pairs is a common practice in the mainstream SSL PKI.

I agree, if the only mistake this CA made was to certify some weak keys, then it would have been asked to revoke them, adjust some settings and continue with its business.

In general, PKIX CAs are not forgiven for signing any old thing presented to them in a certificate request.  They are required to enforce policy flowed down to them by upstream CAs and (ultimately) the policy management authority.

Best regards.  Tim.

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Friday, November 11, 2011 8:21 PM
To: Peter Gutmann; Tim Moses
Cc: [email-masked]
Subject: Re: [pkix] Malaysian CA (Was: An alternative proposal Was: Fwd: New Version)

Yoav

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 15 Nov 2011 13:49:39 +1300

Tim Moses <[email-masked]> writes:

>I don't believe CA-generated subscriber key-pairs is a common practice in the
>mainstream SSL PKI.

Unfortunately we don't have any real figures for this, but I run into it an
awful lot.  I'd rate it as "disturbingly widespread", possibly not so much for
SSL PKI but for higher-value stuff like signing of messages/transactions.
That's more or less the reverse of what you'd really want to see, SSL's PKI is
effectively anon-DH so it doesn't really matter where you get your keys from,
but when you're signing tax returns or EDI transactions you probably want a
bit of control over where your key's been.

Peter.

---

From: Tim Moses <[email-masked]>
Date: Mon, 14 Nov 2011 21:20:12 -0500

We were discussing the SSL PKI.