Subject: [Trans] text to address DKG's conspiring CAs attack

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Mar 2016 10:39:44 -0400

Below is the text I plan to insert as a new section in the threat 
analysis doc,
to address the attack DKG articulated. Comments welcome.

Steve
------

3.3 Malicious, Colluding CAs

Section 3.2 examined attacks in which a single CA issued a bogus 
certificate. Daniel Kahn Gilmor posited an attack in which two or more 
CAs might collude to issue a bogus certificate in a fashion designed to 
foil the safeguards envisioned by CT. Specifically, he suggested that 
two trust anchors could create intermediate (subordinate) CAs that have 
the same Subject name, the same public key, and the same Subject Key 
Identifier) in the their certificates.In fact, an attack of the sort 
Gilmor envisioned can be mounted by any two CAs that are not 
name-constrained; the attack need not be initiated by trust anchors per 
se. (Also note that X.509 and RFC 5280 do not preclude creation of 
doppelganger CAs; the requirement for Subject name uniqueness applies 
individually to each CA but not across CA boundaries, and there is no 
requirement for public key uniqueness across CAs.)

The attack requires that both of the doppelganger CAs issue a 
certificate for a targeted Subject (e.g., web site). These two (EE) 
certificates are identical; they contain the same name, public key, 
serial number, etc. Only one of the malicious CAs logs a bogus 
certificate and acquires an SCT for it. Because the bogus certificates 
are identical, the SCT will match both.

The logged bogus certificate can be detected by a Monitor (third party 
or self), that is watching the log(s) to which the certificate was 
posted. Thus the detection aspect of CT still works with regard to this 
certificate. When this certificate is detected, the CA that logged the 
certificate may revoke it, i.e., place it on a CRL or create an OCSP 
response for it. However, a browser checking a CRL or OCSP response will 
not match this revocationstatus data against the other, not-logged bogus 
certificate. (This is because revocation status checking is performed in 
the context of a certificate path and the two bogus certificates have 
different certificate paths.) Revoking a detected, bogus certificatemay 
be the best strategy for the malicious CAs. It makes issuance of the 
bogus certificate appear to be an accident, and thus browser vendors may 
not feel the need to make an entry on their blacklists for the bogus 
certificate or the CA that issued it.

If the CA that issued the (logged) bogus certificate fails to revoke it, 
browser vendors might blacklist the certificate. However, as noted 
above, the other bogus certificate, which was not logged, still will 
match the SCT created for the logged (now revoked) certificate. If 
remediation is effected by blacklisting (instead of revocation by the 
malicious CA) then the ability of CT to deal with this sort of attack 
may be diminished. Some forms of blacklisting will cause the not-logged 
bogus certificate to be detected and rejected, while others will not, 
depending on the details of the blacklisting mechanism. Mechanisms for 
blacklisting by browsers are not specified in any IETF standards. The 
mechanisms are browser-specific, and the choice of how to blacklist 
(e.g., the bogus certificate vs. the CA that issued it) are the purview 
of each browser vendor. Thus, depending on the details of the blacklist 
mechanism and the way that a browser vendor chooses to manage this list, 
a doppelganger CA attack might or might not pose a problem in terms of 
successful remediation of the attack.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 14 Mar 2016 20:18:39 +0000

Looks good.   Clever attack; dkg has a twisted mind ☺

Do we generally credit individuals in docs?

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, March 14, 2016 10:40 AM
To: [email-masked]
Subject: [Trans] text to address DKG's conspiring CAs attack

Below is the text I plan to insert as a new section in the threat analysis doc,
to address the attack DKG articulated. Comments welcome.

Steve
------

Section 3.2 examined attacks in which a single CA issued a bogus certificate. Daniel Kahn Gilmor posited an attack in which two or more CAs might collude to issue a bogus certificate in a fashion designed to foil the safeguards envisioned by CT. Specifically, he suggested that two trust anchors could create intermediate (subordinate) CAs that have the same Subject name, the same public key, and the same Subject Key Identifier) in the their certificates. In fact, an attack of the sort Gilmor envisioned can be mounted by any two CAs that are not name-constrained; the attack need not be initiated by trust anchors per se. (Also note that X.509 and RFC 5280 do not preclude creation of doppelganger CAs; the requirement for Subject name uniqueness applies individually to each CA but not across CA boundaries, and there is no requirement for public key uniqueness across CAs.)

The attack requires that both of the doppelganger CAs issue a certificate for a targeted Subject (e.g., web site). These two (EE) certificates are identical; they contain the same name, public key, serial number, etc. Only one of the malicious CAs logs a bogus certificate and acquires an SCT for it. Because the bogus certificates are identical, the SCT will match both.

The logged bogus certificate can be detected by a Monitor (third party or self), that is watching the log(s) to which the certificate was posted. Thus the detection aspect of CT still works with regard to this certificate. When this certificate is detected, the CA that logged the certificate may revoke it, i.e., place it on a CRL or create an OCSP response for it. However, a browser checking a CRL or OCSP response will not match this revocation  status data against the other, not-logged bogus certificate. (This is because revocation status checking is performed in the context of a certificate path and the two bogus certificates have different certificate paths.) Revoking a detected, bogus certificate  may be the best strategy for the malicious CAs. It makes issuance of the bogus certificate appear to be an accident, and thus browser vendors may not feel the need to make an entry on their blacklists for the bogus certificate or the CA that issued it.

If the CA that issued the (logged) bogus certificate fails to revoke it, browser vendors might blacklist the certificate. However, as noted above, the other bogus certificate, which was not logged, still will match the SCT created for the logged (now revoked) certificate. If remediation is effected by blacklisting (instead of revocation by the malicious CA) then the ability of CT to deal with this sort of attack may be diminished. Some forms of blacklisting will cause the not-logged bogus certificate to be detected and rejected, while others will not, depending on the details of the blacklisting mechanism. Mechanisms for blacklisting by browsers are not specified in any IETF standards. The mechanisms are browser-specific, and the choice of how to blacklist (e.g., the bogus certificate vs. the CA that issued it) are the purview of each browser vendor. Thus, depending on the details of the blacklist mechanism and the way that a browser vendor chooses to manage this list, a doppelganger CA attack might or might not pose a problem in terms of successful remediation of the attack.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 14 Mar 2016 12:25:15 -0800

On 3/14/16 12:18 PM, Salz, Rich wrote:
> Looks good.   Clever attack; dkg has a twisted mind J
>

Yes, there should be an acknowledgments section when
appropriate.

Melinda

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 14 Mar 2016 20:25:53 +0000

> Yes, there should be an acknowledgments section when appropriate.

Right, of course, and credit him there for this.  But in the prose?  When say there's no literature to point to?  Shrug.  Not a big deal.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 14 Mar 2016 21:39:05 +0000

On 14 March 2016 at 14:39, Stephen Kent <[email-masked]> wrote:
> The logged bogus certificate can be detected by a Monitor (third party or
> self), that is watching the log(s) to which the certificate was posted. Thus
> the detection aspect of CT still works with regard to this certificate. When
> this certificate is detected, the CA that logged the certificate may revoke
> it, i.e., place it on a CRL or create an OCSP response for it. However, a
> browser checking a CRL or OCSP response will not match this revocation
> status data against the other, not-logged bogus certificate. (This is
> because revocation status checking is performed in the context of a
> certificate path and the two bogus certificates have different certificate
> paths.) Revoking a detected, bogus certificate  may be the best strategy for
> the malicious CAs. It makes issuance of the bogus certificate appear to be
> an accident, and thus browser vendors may not feel the need to make an entry
> on their blacklists for the bogus certificate or the CA that issued it.

I do not believe this is correct. And if it is, it is a serious bug in
revocation that has nothing to do with certificate transparency.

Also, I don't get the logic of the "not-logged bogus certificate",
which is identical to the logged certificate - and is therefore
logged. And not bogus.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 14 Mar 2016 22:15:08 +0000

> which is identical to the logged certificate - and is therefore

+1

The "two" bogus certificates are one and the same.  They will contain 
the same CRL and/or OCSP URLs.  The outcome of a CRL/OCSP check will be 
exactly the same for both certs.

AIUI, for DKG's attack to work, it is necessary for:
   - the "two" bogus certificates to _not_ be revoked.
   - one of the doppelganger intermediates to be logged and revoked.
   - the other one (or more) of the doppelganger intermediates to be 
neither logged nor revoked.

I think that there are two possible ways to thwart this attack:

   1. Redefine SCTs so that they become SCCTs (Signed Certificate Chain 
Timestamps) - i.e. the signature is calculated over the entire chain 
submitted.  I think this is unworkable, because there are too many cases 
where different chains are legitimate and even expected.

   2. Declare that this is not a problem with CT.  It's a problem with 
using CRL and/or OCSP to revoke intermediates.  So we (where "we" may or 
may not be TRANS) need to fix revocation!
Revoking an intermediate _certificate_ just isn't sufficient.
To be effective, the intermediate _public key_ needs to be revoked somehow.

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Mar 2016 08:10:02 -0400

Rich,

> Do we generally credit individuals in docs?
Normally I would not credit an individual in an RFC. However, in this 
case DKG
articulated an attack that had not been described (AFAIK) in this 
context, and
which does have implications for the CT. I'm not hard over on this 
point, but
it seemed reasonable in this case.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 15 Mar 2016 13:50:44 +0000

On 14 March 2016 at 22:15, Rob Stradling <[email-masked]> wrote:
> The "two" bogus certificates are one and the same.  They will contain the
> same CRL and/or OCSP URLs.  The outcome of a CRL/OCSP check will be exactly
> the same for both certs.
>
>   - the other one (or more) of the doppelganger intermediates to be neither
> logged nor revoked.
>
>   2. Declare that this is not a problem with CT.  It's a problem with using
> CRL and/or OCSP to revoke intermediates.  So we (where "we" may or may not
> be TRANS) need to fix revocation!

3. Always revoke bad certs that appear in logs!

---

From: Ben Laurie <[email-masked]>
Date: Tue, 15 Mar 2016 13:51:23 +0000

Oh, also:

4. Require SCTs for all certs in the chain, which prevents hiding the
alternate intermediate.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 15 Mar 2016 14:03:29 +0000

On 15/03/16 13:50, Ben Laurie wrote:
<snip>
> 3. Always revoke bad certs that appear in logs!

If the intermediate is being blacklisted, would you really trust the CA 
to revoke all of the logged end-entity certs?

We need revocation mechanisms that are effective without having to trust 
the CA.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 15 Mar 2016 14:03:43 +0000

> 4. Require SCTs for all certs in the chain, which prevents hiding the

In my experience CA certificates rarely need to be issued in a hurry, so 
maybe requiring Inclusion Proofs for all CA certificates in the chain 
could work.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 15 Mar 2016 14:48:50 +0000

On 15 March 2016 at 14:03, Rob Stradling <[email-masked]> wrote:
> If the intermediate is being blacklisted, would you really trust the CA to
> revoke all of the logged end-entity certs?
>
> We need revocation mechanisms that are effective without having to trust the
> CA.

I will not argue with that.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 15 Mar 2016 14:49:25 +0000

On 15 March 2016 at 14:03, Rob Stradling <[email-masked]> wrote:
> maybe requiring Inclusion Proofs for all CA certificates in the chain could
> work.

That would also work.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 15 Mar 2016 10:57:44 -0400

As others have pointed out, the
description below is fundamentally flawed, and as a result the
conclusion is flawed as well. See comments in-line below.

On 03/14/2016 10:39 AM, Stephen Kent wrote:

Steve

------

3.3
Malicious, Colluding CAs

Section

3.2 examined attacks in which a single CA issued a bogus
certificate. Daniel Kahn Gilmor posited an attack in which two
or more CAs might collude to issue a bogus certificate in a
fashion designed to foil the safeguards envisioned by CT.
Specifically, he suggested that two trust anchors could create
intermediate (subordinate) CAs that have the same Subject
name, the same public key, and the same Subject Key
Identifier) in the their certificates.

What's effectively happening here is not that
the two trust anchors are creating two intermediate (subordinate)
CAs. They are creating a single intermediate (subordinate) CA, and
each of them is issuing a cross-certificate to it.

+----------------+
+----------------+

| trust anchor 1 |    | trust anchor 2 |

+----------------+    +----------------+

\              /

\            /

+----------------+

| subordinate CA |

+----------------+

In
fact, an attack of the sort Gilmor envisioned can be mounted
by any two CAs that are not name-constrained; the attack need
not be initiated by trust anchors per se. (Also note that
X.509 and RFC 5280 do not preclude creation of doppelganger
CAs; the requirement for Subject name uniqueness applies
individually to each CA but not across CA boundaries, and
there is no requirement for public key uniqueness across CAs.)

This is incorrect! X.509 requires name
uniqueness, including across CA boundaries. [Since this issue
isn't relevant to the "conspiring CAs attack," information about
this inaccuracy is at the end of the email.

The
attack requires that both of the doppelganger CAs issue a
certificate for a targeted Subject (e.g., web site). These two
(EE) certificates are identical; they contain the same name,
public key, serial number, etc. Only one of the malicious CAs
logs a bogus certificate and acquires an SCT for it. Because
the bogus certificates are identical, the SCT will match both.

As noted by others, if the two (EE)
certificates are identical, then there is only one EE certificate.
So, in the scenario described above, there aren't two intermediate
CAs and two (identical) EE certificates. There are two trust
anchors, each issuing a certificate to a single subordinate CA,
which in turn has issued a single EE certificate identifying the
target Subject:

+----------------+    +----------------+

| trust anchor 1 |    | trust anchor 2 |

+----------------+    +----------------+

\              /

\            /

+----------------+

| subordinate CA |

+----------------+

|

|  EE certificate

|

+------------------+

| targeted Subject |

+------------------+

The
logged bogus certificate can be detected by a Monitor (third
party or self), that is watching the log(s) to which the
certificate was posted. Thus the detection aspect of CT still
works with regard to this certificate. When this certificate
is detected, the CA that logged the certificate may revoke it,
i.e., place it on a CRL or create an OCSP response for it.
However, a browser checking a CRL or OCSP response will not
match this revocation  status
data against the other, not-logged bogus certificate. (This is
because revocation status checking is performed in the context
of a certificate path and the two bogus certificates have
different certificate paths.)

Again, as others have noted, and as can be
seen clearly in the figure above, from the relying party's point
of view, there is only one intermediate CA. So, a browser checking
a CRL or OCSP response will get the same result whether it is
attempting to validate this EE certificate using trust anchor 1 or
trust anchor 2 as the starting point for the certification path.
There is nothing in a CRL or OCSP response that would make a CRL
or OCSP response valid for a path that starts at trust anchor 1
but invalid for a path that starts at trust anchor 2.

The only way I can see to (possibly) get the results described
above would be if the "two" EE certificates had different values
in the cRLDistributionPoints extension and/or the
authorityInfoAccess extension so that the relying party would go
to different sources for revocation information for the two EE
certificates. But then, that would mean the two EE certificate
weren't identical.

Revoking
a detected, bogus certificate
may be the best strategy for the malicious CAs. It
makes issuance of the bogus certificate appear to be an
accident, and thus browser vendors may not feel the need to
make an entry on their blacklists for the bogus certificate or
the CA that issued it.

If
the CA that issued the (logged) bogus certificate fails to
revoke it, browser vendors might blacklist the certificate.
However, as noted above, the other bogus certificate, which
was not logged, still will match the SCT created for the
logged (now revoked) certificate. If remediation is effected
by blacklisting (instead of revocation by the malicious CA)
then the ability of CT to deal with this sort of attack may be
diminished. Some forms of blacklisting will cause the
not-logged bogus certificate to be detected and rejected,
while others will not, depending on the details of the
blacklisting mechanism. Mechanisms for blacklisting by
browsers are not specified in any IETF standards. The
mechanisms are browser-specific, and the choice of how to
blacklist (e.g., the bogus certificate vs. the CA that issued
it) are the purview of each browser vendor. Thus, depending on
the details of the blacklist mechanism and the way that a
browser vendor chooses to manage this list, a doppelganger CA
attack might or might not pose a problem in terms of
successful remediation of the attack.

If there is an attack here, it seems that it
would be as follows. Upon detection of the bogus certificate
browsers determine that the subordinate CA is malicious and
blacklist the cross-certificate from trust anchor 1 to subordinate
CA, but don't blacklist any of the EE certificates issued by the
subordinate CA (and the subordinate CA doesn't revoke them
either). The browsers don't notice that there is a second
cross-certificate for subordinate CA, from trust anchor 2, and so
there continues to be a valid certification path for certificates
issued by subordinate CA.

------------------------------------------------------------------

Unfortunately, there is some misinformation
that X.509's name uniqueness requirement only applies to each CA.
X.509 is very clear that this is not the case. Among other things,
it says that "For every name form used in the GeneralName
type, there shall be a name registration system that ensures that
any name used unambiguously identifies one entity to both
certificate issuer and certificate users."

In addition, there is text in the Security Considerations section
of RFC 6818 (RFC 5280 Clarifications) warning that there is a risk
that two different CAs could issue certificates with the same
subject name:

Among many other possible attacks, the attacker may
issue bogus

certificates that have the same subject names as
legitimate

certificates in order impersonate legitimate
certificate subjects.

This could include
bogus CA certificates in which the subject names

in the
bogus certificates match the names under which legitimate CAs

issue
certificates and CRLs.  This would allow the attacker
to issue

bogus certificates and CRLs that have the same
issuer names, and

possibly the same serial numbers, as certificates
and CRLs issued by

legitimate CAs.

You can also look at CMS (RFC 5652) to see that this is incorrect.
It issues issuer name and serial number to identify a certificate:

The IssuerAndSerialNumber type identifies a certificate,
and thereby

an entity and a public key, by the distinguished name
of the

certificate issuer and an issuer-specific certificate
serial number.

This only works because the requirement for name uniqueness
applies across all issuers, not individually to each CA.

The indirect CRL mechanism in X.509 also requires on names being
unique across CAs. So does the PKIX profile for attribute
certificates (RFC 5755):

If an attribute
certificate is tied to the holder's PKC using the

baseCertificateID component of the Holder field and
the PKI in use

includes a rogue CA with the same issuer name
specified in the

baseCertificateID component, this rogue CA could issue
a PKC to a

malicious party, using the same issuer name and serial
number as the

proper holder's PKC.  Then the malicious party could
use this PKC in

conjunction with the AC.  This scenario SHOULD be
avoided by properly

managing and configuring the PKI so that there cannot
be two CAs with

the same name.
Another alternative is to tie ACs to PKCs using the

publicKeyCert type in the ObjectDigestInfo field.
Failing this, AC

verifiers have to establish (using other means) that
the potential

collisions cannot actually occur, for example, the
Certificate

Practice Statements (CPSs) of the CAs involved may
make it clear that

no such name collisions can occur.

Again, it notes that CA names have to be unique across the entire
PKI, not just among those that have been issued certificates from
a single CA.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 15 Mar 2016 15:04:03 +0000

On 15/03/16 14:57, David A. Cooper wrote:
<snip>
> If there is an attack here, it seems that it would be as follows. Upon
> detection of the bogus certificate browsers determine that the
> subordinate CA is malicious and blacklist the cross-certificate from
> trust anchor 1 to subordinate CA, but don't blacklist any of the EE
> certificates issued by the subordinate CA (and the subordinate CA
> doesn't revoke them either). The browsers don't notice that there is a
> second cross-certificate for subordinate CA, from trust anchor 2, and so
> there continues to be a valid certification path for certificates issued
> by subordinate CA.

Yes, that is DKG's attack.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 15 Mar 2016 11:18:32 -0400

Okay, thanks. I hadn't read DKG's
attack before, only Steve Kent's text purportedly describing DKG's
attack. It seems that DKG correctly described a possible attack,
and then Steve got it totally wrong when he tried to describe it.
My comments were on Steve Kent's text, not on DKG's description of
the attack.

On 03/15/2016 11:04 AM, Rob Stradling wrote:

On
15/03/16 14:57, David A. Cooper wrote:

<snip>

If there is an attack here, it seems that
it would be as follows. Upon

subordinate CA is malicious and blacklist the cross-certificate
from

trust anchor 1 to subordinate CA, but don't blacklist any of the
EE

certificates issued by the subordinate CA (and the subordinate
CA

doesn't revoke them either). The browsers don't notice that
there is a

second cross-certificate for subordinate CA, from trust anchor
2, and so

there continues to be a valid certification path for
certificates issued

by subordinate CA.

---------------------------------------------------------------------------------------------------------

-------- Forwarded Message --------

Subject:

[Trans] can CT defend against dual
CA compromise?

Date:

Sat, 20 Feb 2016 22:05:27 -0500

From:

Daniel Kahn Gillmor
<[email-masked]>

To:

[email-masked]

CT currently focuses on logging end-entity (leaf) certs; as a result, i
think that an attacker who can compromise two CAs can keep one of those
compromises secret from the CT ecosystem.

Consider an attacker who has compromised two widely-accepted root CAs, A
and B, and wants to mint usable credentials for host Z.

The root CAs each control multiple intermediate authorities: A controls A_1,
A_2, etc; B controls B_1, B_2, etc.

The attacker creates a new secret key X and using A and B creates two
new intermediate authorities A_X and B_X, which both have the same
Subject, the same public key, and the same Subject Key Identifier
extension. The intermediate authority certs themselves differ, however,
because of their issuers.

The attacker generates a new end entity secret key Y and produces a cert
C (Subject = Z, Public Key = Y), issued by X.

Now we have two possible chains:

A -> A_X -> C

B -> B_X -> C

The attacker logs one of those chains and gets an SCT for cert C. For
this example, let's say the A chain gets logged.

If C is discovered and exposed as a forgery, then root CA A takes the
heat. Either they disavow/revoke their sub-CA A_X or they are rejected
>From TLS client root stores.

However, the attacker can still use C in the wild, by supplying the B
chain.

Note that in this scenario, it's unlikely that space-constrained
blacklist-style client updates (e.g. CRLset) will include every leaf
certificate that chains to A after A is known-compromised. So TLS
clients won't necessarily be warned off of C directly.

The B chain (and B_X in particular) won't ever surface in the logs'
audit trails, though, because C has already been logged; this looks to
me like CT will fail at its goal of detecting misissuance by B.

Consider this scenario over time, as well. Once A is publicly-known to
be compromised, the attacker can impersonate new targets with the same
approach: mint a new leaf cert using X (perhaps fiddling with the
validity dates), submit to the logs (and get the SCT) with the A chain,
and then deploy with the B chain.

How to fix this? A few ideas come to mind, but i'm not convinced of
either of them yet:

* recommend that clients who care about transparency should expect that
all intermediate certs themselves are logged -- 6962bis already
permits this, though it seems to be mainly in contemplation of
name-constrained intermediate authorities. This expands the number
of SCTs or inclusion proofs that need to accompany a chain, and makes
verification logic slightly more complicated.

* logs could refuse to log any certs that chain back to a known-failed
CA (or through a known-bad intermediate CA). This would constrain a
dual-compromise attacker from minting new certs after the first CA is
known to be compromised. This seems like a useful mitigation, but
it's also complictated and delicate. What does "known-failed" mean?
What if there is a dispute over the validity of a cert, with one
party claiming that it was misissued, and the CA claiming its
legitimacy? What if some browser vendors have dropped the CA, and
others have not? This puts the logs in a position of being some kind
of arbiter of the root store, with very subtle knock-on effects to
security of the whole ecosystem if they decide to not drop a CA.

Even more subtly, if the public narrative of the compromise ends up
being "A_X is bad" (include the intermediate cert in client
blacklists and refuse to log things that chain through it) instead of
"A is bad" (include the root cert in client blacklists and refuse to
log things that chain to it), then the attacker can simply mint
multiple intermediate keys (X_0, X_1, etc) and corresponding
intermediate certificates at the time of the compromise, and
burn/expose them one spoofing attack at a time.

Any other ideas? Any holes in the reasoning here? I'd love for this
analysis to be mistaken.

--dkg

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Mar 2016 13:13:48 -0400

Good point. I'll move DKGs acknowledgement the Acknowledgments section.

Steve

On 3/14/16 4:25 PM, Salz, Rich wrote:
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Mar 2016 13:44:17 -0400

zBen,

> On 14 March 2016 at 14:39, Stephen Kent<[email-masked]>  wrote:
What do you believe is incorrect about my description of revocation 
status checking?
A relying party validates a cert by walking down a cert pat from a trust 
anchor to
a target cert. In DKG's example, the two CAs with the same name have 
different
trust anchor parents, thus there are two distinct paths. A CRL (or OCSP 
response)
issued by a CA on one path is totally independent from A CRL (or OSCSP 
response)
issued by a CA on a distinct path.
> which is identical to the logged certificate - and is therefore
A cert is bogus when it is issued to an entity that is not authorized
to represent the Subject of the cert. This is true whether the cert is
logged or not.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Mar 2016 13:45:39 -0400

Rob,

> the same CRL and/or OCSP URLs.  The outcome of a CRL/OCSP check will 
> be exactly the same for both certs.
There is no requirement for a cert to contain a back pointer to the CRL on
which it would be listed or to provide OCSP info. The extension (AIA) that
enables these capabilities is not required by 5280 and because it is not 
marked
critical, there is no requirement for all relyng parties to be able to 
process it.

    4.2.2.1.  Authority Information Access

    The authority information access extension indicates how to access
    information and services for the issuer of the certificate in which
    the extension appears.  Information and services may include on-line
    validation services and CA policy data.  (The location of CRLs is not
    specified in this extension; that information is provided by the
    cRLDistributionPoints extension.)  This extension may be included in
    end entity or CA certificates.  Conforming CAs MUST mark this
    extension as non-critical.
>   - the "two" bogus certificates to _not_ be revoked.
disagree, see above.
>   - one of the doppelganger intermediates to be logged and revoked.
logged, yes. blacklisted, maybe.
> neither logged nor revoked.
agreed.
> submitted.  I think this is unworkable, because there are too many 
> cases where different chains are legitimate and even expected.
>
> using CRL and/or OCSP to revoke intermediates. 
my example does not assume that an intermediate CA cert was revoked. It 
suggests
that a clever, malicious CA might revoke the bogus EE cert to deflect 
suspicion from
itself and to avoid having browser vendors blacklist the CA or the bogus 
cert.
> So we (where "we" may or may not be TRANS) need to fix revocation!
One does not revoke keys in a PKI. One revokes certs.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Mar 2016 13:46:05 -0400

Ben,

> 4. Require SCTs for all certs in the chain, which prevents hiding the
If one were to do this, then it would seem to be a significant
change to the CT design, affecting TLS clients, CAs, and Subjects (who
acquire SCTs for themselves). Do you really want to mandate this?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Mar 2016 13:47:07 -0400

David,

> As others have pointed out, the description below is fundamentally 
> flawed, and as a result the conclusion is flawed as well. See comments 
> in-line below.
Others are wrong :-).
> ...
>>
>> In fact, an attack of the sort Gilmor envisioned can be mounted by 
>> any two CAs that are not name-constrained; the attack need not be 
>> initiated by trust anchors per se. (Also note that X.509 and RFC 5280 
>> do not preclude creation of doppelganger CAs; the requirement for 
>> Subject name uniqueness applies individually to each CA but not 
>> across CA boundaries, and there is no requirement for public key 
>> uniqueness across CAs.)
>>
>
> This is incorrect! X.509 requires name uniqueness, including across CA 
> boundaries. [Since this issue isn't relevant to the "conspiring CAs 
> attack," information about this inaccuracy is at the end of the email.

David still believes that the X.500 directory tree is the basis for all 
names in certs.
of course this is not even remotely true, and 5280 is quite clear about 
this. But I am happy
to avoid this argument by omitting the reference to X.509, since we're 
discussing Internet
standards and thus RFC 5280 is relevant reference.
>> certificate and acquires an SCT for it. Because the bogus 
>> certificates are identical, the SCT will match both.
>>
>
> As noted by others, if the two (EE) certificates are identical, then 
> there is only one EE certificate. So, in the scenario described above, 
> there aren't two intermediate CAs and two (identical) EE certificates. 
> There are two trust anchors, each issuing a certificate to a single 
> subordinate CA, which in turn has issued a single EE certificate 
> identifying the target Subject:
wrong, again. In the scenaior there are two distinct, intermediate CAs, 
with distinct parents.
The CA certs for the malicious CAs are different, e.g., at a minimum 
they have different Issuer names.
The question of whether there are one or two bogus certs strikes me as 
an existential distinction.

I'm not going spend my time rebuting the rest of your analysis, as it is 
based on a faulty interpretation
of what I wrote, and is illustrated with diagrams that don't match the 
scenario that DKG and
I are describe.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 16 Mar 2016 14:12:15 -0400

I have never believed that "the X.500
directory tree is the basis for all names in certs.," and you know
that! Nor does that have anything to do with what I said in my
previous email.

There's no reason for you to rebut my analysis. What is needed is
for someone to write a description of the attack scenario that
accurately describes the attack scenario DKG presented, and the
text you proposed doesn't do that.

If my description of the scenario is so wrong, then please explain
(in detail) how a relying party would be able to determine that
there are two distinct intermediate CAs in this scenario and not a
single CA that has been issued cross-certificates by two different
roots (as depicted in my diagrams) and how that fits in with your
response to Ben Laurie that:

A relying party
validates a cert by walking down a cert pat from a trust
anchor to

a target cert. In DKG's example, the two CAs with the same
name have different

trust anchor parents, thus there are two distinct paths. A
CRL (or OCSP response)

issued by a CA on one path is totally independent from A CRL
(or OSCSP response)

What information (specifically) would appear in a CRL or OCSP
response issued by a CA on one path that would make it
distinguishable to a relying party from a CRL or OCSP response
issued by a CA on the other path in the scenario DKG described?

On 03/16/2016 01:47 PM, Stephen Kent wrote:

David,

Others are wrong :-).

...

In

fact, an attack of the sort Gilmor envisioned can be
mounted by any two CAs that are not name-constrained; the
attack need not be initiated by trust anchors per se.
(Also note that X.509 and RFC 5280 do not preclude
creation of doppelganger CAs; the requirement for Subject
name uniqueness applies individually to each CA but not
across CA boundaries, and there is no requirement for
public key uniqueness across CAs.)

This is incorrect! X.509 requires name
uniqueness, including across CA boundaries. [Since this issue
isn't relevant to the "conspiring CAs attack," information
about this inaccuracy is at the end of the email.

David still believes that the X.500
directory tree is the basis for all names in certs.

of course this is not even remotely true, and 5280 is quite
clear about this. But I am happy

to avoid this argument by omitting the reference to X.509, since
we're discussing Internet

The

attack requires that both of the doppelganger CAs issue a
certificate for a targeted Subject (e.g., web site). These
two (EE) certificates are identical; they contain the same
name, public key, serial number, etc. Only one of the
malicious CAs logs a bogus certificate and acquires an SCT
for it. Because the bogus certificates are identical, the
SCT will match both.

As noted by others, if the two (EE)
certificates are identical, then there is only one EE
certificate. So, in the scenario described above, there aren't
two intermediate CAs and two (identical) EE certificates.
There are two trust anchors, each issuing a certificate to a
single subordinate CA, which in turn has issued a single EE
certificate identifying the target Subject:

wrong, again. In the scenaior there are two
distinct, intermediate CAs, with distinct parents.

The CA certs for the malicious CAs are different, e.g., at a
minimum they have different Issuer names.

The question of whether there are one or two bogus certs strikes
me as an existential distinction.

I'm not going spend my time rebuting the rest of your analysis,
as it is based on a faulty interpretation

of what I wrote, and is illustrated with diagrams that don't
match the scenario that DKG and

I are describe.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Wed, 16 Mar 2016 18:48:32 +0000

On 16 March 2016 at 17:44, Stephen Kent <[email-masked]> wrote:
> What do you believe is incorrect about my description of revocation status
> checking?

OK. If you are right, then its pretty clear that any implementation
that relies on CRLs/OCSP specified further up the path than the EE
cert has a serious problem that has nothing to do with CT.

The CT related problem is that people could perhaps be fooled into
thinking it was not necessary to revoke some logged bogus certificates
because they appear to come from a chain that was not trusted anyway.

Don't forget that the purpose of CT is to reveal problems with
certificates, not to solve them.

> to represent the Subject of the cert. This is true whether the cert is

Ah, I see. In that case, is the cert in question not a "logged bogus cert"?

---

From: Tom Ritter <[email-masked]>
Date: Wed, 16 Mar 2016 16:50:49 -0500

My notes on several comments in thread:

==================================

I want to add to this part:

On 15 March 2016 at 09:57, David A. Cooper <[email-masked]> wrote:
> detection of the bogus certificate browsers determine that the subordinate
> CA is malicious and blacklist the cross-certificate from trust anchor 1 to
> subordinate CA, but don't blacklist any of the EE certificates issued by the
> subordinate CA (and the subordinate CA doesn't revoke them either). The
> browsers don't notice that there is a second cross-certificate for
> subordinate CA, from trust anchor 2, and so there continues to be a valid
> certification path for certificates issued by subordinate CA.

This is correct, but there is another attack, one I consider more
damning, new fradulent intermediates that the community 'doesn't care
about' because the issuer has been removed from trust stores. This
isn't mentioned in the text present.

Attacker issues intermediates A_X and B_X from CAs A and B that are identical.
They issue an end entity cert EE1, signed by *_X (doesn't matter who
signs it, the signature is identical.)
They Log A -> A_X -> EE1, and get SCTs for EE1.
EE, A_X, and A are revoked and blacklisted.

Attacker issues a new intermediate A_Y and B_Y from CAs A and B that
are identical.
They issue another end entity cert EE2, signed by *_Y (again, doesn't
matter who signs it)
They log A -> A_Y -> EE2, and get SCTs for EE2.
A_Y is *not* blacklisted, because the path we see in the logs is not
trusted. People decide they don't care.

The attacker can use B -> B_Y -> EE2 with the SCTs for EE2 to perform attacks.

==================================

> To be effective, the intermediate _public key_ needs to be revoked somehow.

I agree with this, except not just intermediates.
Revocation should be done by either the public key or the certificate
everywhere (intermediates and end-entity.)
But practically, because of CA operations, I think it makes sense to
revoke by public key for intermediates and by certificates for
end-entity.

That said, it's a bit beyond our mandate to redo revocation for the
whole internet....

==================================

> 3. Always revoke bad certs that appear in logs!

That revocation would need to be via crl-sets or OneCRL.  So while
this... could work: If I'm the smart attacker I'm going to spam the
everloving shit out of the log with bad certs. And when you have to
revoke 1 million certificates via crl-sets you will be sad. =)

So....

==================================

> 4. Require SCTs for all certs in the chain, which prevents hiding the

I think this is the answer.  I think we need SCTs for all the certs in
the chain.  And yea, I think we need to mandate this.

But how? It's a huge change right, it's going to be some time before
Intermediates are issued as PreCerts. So there'll probably need to be
a bandaid for the time being. The only thing I can think of is using
Mozilla's Intermediate database and hardcoding a few kilobytes of SCTs
into browsers.  Ugly but... could get most of the way there?

==================================

I'll also note that right now we (Gossip authors) don't want to make
defending against this attack one of Gossip's responsabilities.  But
we can defend against this attack in a certain configuration.  We have
some in-progress text I wrote this morning about it, but it is
in-progress. https://github.com/ln5/draft-ietf-trans-gossip/pull/16/files

-tom

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Mar 2016 11:00:24 -0400

Ben,

> cert has a serious problem that has nothing to do with CT.
Yes, I am right. But, again, I am puzzled by your comment. In PKIs in 
general, the revocation
status of an EE cert is specified by the CA that issued the cert. (There 
are provisions
for indirect CRLs, but that's not a commonly used mechanism). RFC 5280 
recognizes that there
can be vulnerabilities associated with acquiring CRLs or OCSP data in 
some contexts, and
that's why AIA allows a CA to tell RPs where to acquire such data. 
However, for backward
compatibility purposes, and because this is not a problem in all 
contexts, 5280 does not
mandate use  of this extension. Thus one ought not assume that it is 
always present,
and it is appropriate to acknowledge this residual vulnerability where 
applicable.
Note, that the RPKI does mandate use of AIA to point to CRLs, and 
relying parties
in that context are required to verify that the extension is present,. 
If it's missing
the cert (EE or CA) is rejected.
> because they appear to come from a chain that was not trusted anyway.
True. Also, a browser vendor might decide that it didn't need to 
blacklist the
EE cert because it had already been revoked by the CA.
> certificates, not to solve them.
My characterization of CT (draft-kent-trans-architecture-02.txt) is:

    Certificate transparency (CT) is a set of mechanisms designed to
    deter, detect, and facilitate remediation of certificate mis-issuance
    (as defined below).

I wrote this (month ago) because I thought it was useful to provide a 
concise
characterization of CT goals. Do you disagree with the text above?
> Ah, I see. In that case, is the cert in question not a "logged bogus cert"?

yes, it is.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Mar 2016 11:13:23 -0400

David,

> I have never believed that "the X.500 directory tree is the basis for 
> all names in certs.," and you know that!
your assertion that X.509 requires all name uniqueness across CA 
boundaries makes sense
only in the context of an X.500 DIT world. We had this debate already in 
the RPKI context
a few years ago. That WG disagreed with your assertion, and nothign has 
changed to suggest
a different resolution this time. But, I.ve removed the mention of X.509 
from my proposed
text, so this is moot.
> Nor does that have anything to do with what I said in my previous email.
it was an attempt to explain your statement about global name uniqueness.
> There's no reason for you to rebut my analysis. What is needed is for 
> someone to write a description of the attack scenario that accurately 
> describes the attack scenario DKG presented, and the text you proposed 
> doesn't do that.
DKG's description was a bit narrow compared to the full range of 
possible attacks enabled
by colluding CAs. I changed the description to try to capture the 
broader attack space. That's
why it differs from DKG's original wording.
> If my description of the scenario is so wrong, then please explain (in 
> detail) how a relying party would be able to determine that there are 
> two distinct intermediate CAs in this scenario and not a single CA 
> that has been issued cross-certificates by two different roots (as 
> depicted in my diagrams) and how that fits in with your response to 
> Ben Laurie that:
the two colluding CAs appear in different cert paths, and thus an RP 
following one cert
path may see revocation status info for only the CA that issued and 
logged the bogus cert.
Remember that the two malicious CAs have the same Subject name but 
different Issuer names
in their certs, so they are distinct in terms of cert paths. A malocious 
web site can send
a full cert path to the browser and thus direct the browser to validate 
the EE cert relative
to the CA that did not log the cert and did not revoke it.

The fact that Ben (and Rob) questioned why the revocation status info 
from one CA would
not match the other CA is an issue I addressed in my replies to them.
> What information (specifically) would appear in a CRL or OCSP response 
> issued by a CA on one path that would make it distinguishable to a 
> relying party from a CRL or OCSP response issued by a CA on the other 
> path in the scenario DKG described?
I'm afraid this question is not relevant to the attack I described.

A web server also can supply OCSP data to a browser as part of the TLS 
handshake (RFC 6066),
thus it may influence the revocation status info that the browser sees. 
(RFC 6066 allows a
client to send a list of OCSP servers that it trusts, but it also allows 
a null list to
indicate that the client assumes that the server knows what this list 
is, implicitly.
The client should verify that the returned OCSP response matches what it 
asked for, but
given the history of buggy browser PKI software, I would not be too 
confident in how
rigorously this is implemented in all browsers.) In this fashion a bogus 
web server, aided
by a malicious CA, may be able to supply revocation status data that 
reflects the not-logged and
not-revoked instance of the bogus cert.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 17 Mar 2016 12:26:14 -0400

On 03/17/2016 11:13 AM, Stephen Kent
wrote:

David,

I have never believed that "the
X.500 directory tree is the basis for all names in certs.,"
and you know that!

only in the context of an X.500 DIT world. We had this debate
already in the RPKI context

a few years ago. That WG disagreed with your assertion, and
nothign has changed to suggest

a different resolution this time. But, I.ve removed the mention of
X.509 from my proposed

text, so this is moot.

The issue is not moot, since the revised text continues to say
that "Requirements for Subject name uniqueness apply individually
to each CA but not across CA boundaries."

You've made it very clear that you don't like that X.509 requires
name uniqueness across CA boundaries, but just because you don't
like the requirement (and believe it couldn't be enforced) doesn't
mean the requirement doesn't exist. The biggest problem for you is
that without the name uniqueness requirement, X.509 (and RFC 5280)
no longer works. I provided several examples of that in my
previous email, and your flawed description of DKG's attack
scenario is also largely based on that.

The RPKI is a specific, highly-constrained hierarchical PKI, and
in that environment, if all of the RPKI-specific constraints are
followed and relying party software is careful to check those
RPKI-specific constraints when validating certificates, then it is
likely that name collisions across CA boundaries would not break
that PKI. However, your assertion that the RPKI WG "disagreed with
[my] assertion" is totally wrong. That is why RFC 6487 (A Profile
for X.509 PKIX Resource Certificates) includes (over your
objections) a warning about name collisions in its Security
Considerations section.

Nor does that have anything to do
with what I said in my previous email.

it was an attempt to explain your statement about global name
uniqueness.

There's no reason for you to rebut
my analysis. What is needed is for someone to write a
description of the attack scenario that accurately describes
the attack scenario DKG presented, and the text you proposed
doesn't do that.

In your description the attacker revokes the
EE certificate. In DKG's description one of the CA certificates is
revoked:

>From TLS client root stores.

Revoking the EE certificate is very different from revoking the CA
certificate. If the CA certificate is revoked, but the EE
certificate is not, then the certification path using the other CA
certificate remains valid.

If my description of the scenario
is so wrong, then please explain (in detail) how a relying
party would be able to determine that there are two distinct
intermediate CAs in this scenario and not a single CA that has
been issued cross-certificates by two different roots (as
depicted in my diagrams) and how that fits in with your
response to Ben Laurie that:

the two colluding CAs appear in different cert paths, and thus an
RP following one cert

path may see revocation status info for only the CA that issued
and logged the bogus cert.

in their certs, so they are distinct in terms of cert paths. A
malocious web site can send

a full cert path to the browser and thus direct the browser to
validate the EE cert relative

The fact that Ben (and Rob) questioned why the revocation status
info from one CA would

not match the other CA is an issue I addressed in my replies to
them.

Actually, there was nothing in your response that addressed the
issue, and your statement in the proposed text about how status
checking is performed in the context of a certification path is
nonsensical. There is nothing in a CRL or OCSP response that limits
it for use with a specific certification path.

What information (specifically)
would appear in a CRL or OCSP response issued by a CA on one
path that would make it distinguishable to a relying party
from a CRL or OCSP response issued by a CA on the other path
in the scenario DKG described?

I'm afraid this question is not relevant to the attack I
described.

A web server also can supply OCSP data to a browser as part of the
TLS handshake (RFC 6066),

thus it may influence the revocation status info that the browser
sees. (RFC 6066 allows a

client to send a list of OCSP servers that it trusts, but it also
allows a null list to

indicate that the client assumes that the server knows what this
list is, implicitly.

The client should verify that the returned OCSP response matches
what it asked for, but

given the history of buggy browser PKI software, I would not be
too confident in how

rigorously this is implemented in all browsers.) In this fashion a
bogus web server, aided

by a malicious CA, may be able to supply revocation status data
that reflects the not-logged and

Here you note a possible way in which the
attack you described could be carried out, but this is not at all
what you describe in your proposed text. If the attacker controls
the web server, and it pushes the entire certification path along
with the certificate status information (CRL or OCSP) for the
certificates to the browser, then it can send different
information to the browser about the EE certificate depending on
which path it sends. It could send an OCSP response to indicates
the certificate is revoked when sending the certification path
that begins with trust anchor A and could send an OCSP response
that indicates the certificate is not revoked when sending the
certification path that begins with trust anchor B.

I don't understand the part about "buggy browser PKI software." In
most cases, the CA that issued the certificate whose status is
being checked (e.g., the EE certificate) would designate the
appropriate OCSP response to sign the OCSP response by issuing the
responder a certificate with an extended key usage of
id-kp-OCSPSigning. Since the attacker controls the CA, the
attacker would be able to create an OCSP response signed by a
responder under its control and containing a certificate for the
responder that it signed. There would be nothing buggy about PKI
software accepting such a response. The problem is if you trust a
CA that is malicious, then that CA can not only feed you bogus
certificates (limited by whatever constraints are imposed by CAs
earlier in the path or by the relying party) and it can feed you
incorrect information about the status of the certificates it has
issued.

Note that a description like this wouldn't require any fuzzy
wording about two different CAs that just happen to be controlled
by the same entity (the attacker) and have the same name and
public key along with two EE certificates (that just happen to be
bit-for-bit identical), or about how CRLs or OCSP responses issued
for use with one certification path "may not match" when a
different certification path is used to validate the same
certificate.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 18 Mar 2016 13:06:35 +0000

> My notes on several comments in thread:

Since CT does not claim to log all possible chains, this is an
erroneous decision.

> The attacker can use B -> B_Y -> EE2 with the SCTs for EE2 to perform attacks.

I agree, revocation is not within CT's remit :-)

Obviously its important, though!

The smart attacker will cause his roots/intermediates to be dropped
from the logs if he does that.

> So....

Yeah, that sounds plausible. FWIW, we're currently pushing an update
to our log pre-loader that should cause all intermediates we see to be
logged, so that would provide another way to construct such a list.

Interesting.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 18 Mar 2016 13:15:41 +0000

On 17 March 2016 at 15:00, Stephen Kent <[email-masked]> wrote:
> Ben,
>
>
> OK. If you are right, then its pretty clear that any implementation that
> relies on CRLs/OCSP specified further up the path than the EE cert has a
> serious problem that has nothing to do with CT.
>
> status of an EE cert is specified by the CA that issued the cert. (There are
> provisions
> can be vulnerabilities associated with acquiring CRLs or OCSP data in some
> contexts, and
> that's why AIA allows a CA to tell RPs where to acquire such data. However,
> for backward
> compatibility purposes, and because this is not a problem in all contexts,
> 5280 does not
> mandate use  of this extension. Thus one ought not assume that it is always
> present,

I am struggling to imagine a context in which this is not a problem.
But maybe there is one.

> Note, that the RPKI does mandate use of AIA to point to CRLs, and relying
> parties
> in that context are required to verify that the extension is present,. If
> it's missing
> True. Also, a browser vendor might decide that it didn't need to blacklist
> the

I think that would depend on the EE cert (i.e. does it include the
AIAs needed?).

> characterization of CT goals. Do you disagree with the text above?

No.

---

From: Rob Stradling <[email-masked]>
Date: Fri, 18 Mar 2016 13:55:08 +0000

<snip>
> One does not revoke keys in a PKI. One revokes certs.

Steve, I know very well how the existing IETF mechanisms for revocation 
(i.e. CRL and OCSP) work.  But I don't see why that should mean that new 
revocation mechanisms can't be invented, especially if those new 
mechanisms can thwart attacks that CRL and OCSP can't.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 18 Mar 2016 14:09:15 +0000

> Steve, I know very well how the existing IETF mechanisms for revocation (i.e.
> CRL and OCSP) work.  But I don't see why that should mean that new

And it would also require changes to CT, no?

I think raw key stuff is out of scope for now.

---

From: Rob Stradling <[email-masked]>
Date: Fri, 18 Mar 2016 14:19:28 +0000

> And it would also require changes to CT, no?

No.  Revoking intermediate keys is one way to defeat DKG's attack.  If 
we decide that this is _the_ way that we plan to defeat DKG's attack, 
then we (for some value of "we") will need to define such a mechanism, 
but CT won't need to be changed.

> I think raw key stuff is out of scope for now.

Indeed.  Revocation is out of scope for CT anyway.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Mar 2016 14:36:59 -0400

Ben,

> I am struggling to imagine a context in which this is not a problem.
In any environment where all relying parties make use of just one
source of revocation  status info AIA is not required. Also, if the
RPs deal with just one CA, or in a very tightly managed PKI, or ...
Remember, 5280 is the IETF PKI spec for _all_ apps and _all_ contexts,
so it needs to avoid being too proscriptive. For a given app or context one
can profile 52580, as we did for the RPKI, as I noted.

> I think that would depend on the EE cert (i.e. does it include the
I agree that if the EE cert contained the AIA extension (there can be only
one per cert) and the extension specified the CRL or OSCP source, then
a browser vendor might decide it isn't necessary to blacklist. But, since
this decision is up to each vendor and there are no IETF guidelines for
how to make such a decision, we really can't assume how this is managed
for browsers in general. Also, if one wants to assert that the CT specs
apply to all TLS client/server contexts (as opposed to the HTTPS context
specified in the charter), then the problem is even less bounded.
> characterization of CT goals. Do you disagree with the text above?
thanks.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Mar 2016 14:39:04 -0400

Rob,

> Steve, I know very well how the existing IETF mechanisms for 
> revocation (i.e. CRL and OCSP) work.  But I don't see why that should 
> mean that new revocation mechanisms can't be invented, especially if 
> those new mechanisms can thwart attacks that CRL and OCSP can't.
I don't dispute the potential for developing new revocation mechanisms. 
But, in writing the threat
analysis I am dealing with what is specified in current IETF standards. 
If your comment was meant
to suggest a mechanism for use in browsers, not PKIs in general, then I 
apologize. Also, it would
be good if there were an RFC defining browser cert blacklisting 
mechanisms, so that we might know
what capabilities we can rely on, in general.

Note that, in PKI in general, revoking a key, vs. a cert, may be 
inappropriate. For example, in the
RPKI context we focus on address and ASN extensions as capabilities, for 
authorization. We might
want to revoke a cert, but not the key in the cert, because a new cert 
will be issued with different extensions. We may not want to create 
operational problems by requiring the new cert to have a new key.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Mar 2016 11:09:35 -0400

David,

No text in 5280 requires name uniqueness across all CAs. It does require 
uniqueness
on a per-CA basis (Section 4.1.2.6 of 5280). So, when two CAs with 
different parents
are created with the same name, that is not a violation of 5280. The 
creation of
the doppelganger EE certs may violate 5280. The relevant text says:

    The DN MUST be unique for each subject entity certified by _the one 
CA_ as defined
    by the issuer field.

The two CAs in my scenario have different parents, but the same name and 
same public key. So
whether they are "the one CA" named in the issuer field is open to 
debate. I have modified
my text to avoid this issue.

As I explained, my description of an colluding CA attack differs from 
DKGs in that it
is more general and thus. I think, more useful for discussion in the 
threat analysis.

Yes, it is true that CRLs and OCSP responses would not generally be tied 
to the
two CA instances on different cert paths. But, that's not the point. It 
would be dangerous
to assume that an RP can be confident that the revocation status data it 
acquires comes
from a specific instance of a CA, when there are two CAs with the same 
names and
same public keys. RFC 5280 does not provide implementation guidance that 
calls for
pooling of revocation status info based on CA name. An RP may maintain a 
cache organized
by cert path, associating revocation status info with each CA in each 
cert path. Such
an implementation strategy is attractive because it can allow an RP to 
avoid redundant
cert path validation processing when a target cert shares a portion of a 
cert path with
other certs that have been validated. In such an implementation an RP 
would not be aware that
there are two CAs with the same name on different cert paths, and 
revocation status data
associated with each of these CAs would be acquired and maintained 
separately. In such
circumstances an attack of the sort I described is feasible.

Thus I stand by my analysis of the vulnerability, in the more general case.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 25 Mar 2016 13:42:17 -0400

On 03/24/2016 11:09 AM, Stephen Kent
wrote:

David,

No text in 5280 requires name uniqueness across all CAs.

Untrue, as I'll demonstrate below.

It does
require uniqueness

are created with the same name, that is not a violation of 5280.
The creation of

the doppelganger EE certs may violate 5280. The relevant text
says:

The DN MUST be unique for each subject entity certified by the

one CA as defined

by the issuer field.

That is only one relevant statement in RFC 5280. There are many
others, and there are also relevant statements in other PKIX
documents. There is also plenty of text in X.509 indicating that
names need to be unambiguous across CAs, and the PKIX charter called
for maintaining compatibility with X.509:

PKIX will continue to track the
evolution of ITU-T X.509 documents, and will maintain
compatibility between these documents and IETF PKI standards,
since the profiling of X.509 standards for use in the Internet
remains an important topic for the working group.

Within the RFC 5280 Security Considerations section (as updated by
RFC 6818), there are at least two paragraphs that address this:

While X.509 mandates that names be
unambiguous, there is a risk that two unrelated authorities will
issue certificates and/or CRLs under the same issuer name.  As a
means of reducing problems and security issues related to issuer
name collisions, CA and CRL issuer names SHOULD be formed in a
way that reduces the likelihood of name collisions.
Implementers should take into account the possible existence of
multiple unrelated CAs and CRL issuers with the same name.  At a
minimum, implementations validating CRLs MUST ensure that the
certification path of a certificate and the CRL issuer
certification path used to validate the certificate terminate at
the same trust anchor.

Why would RFC 5280 describe risks related to two unrelated
authorities issuing certificates under the same name if it is
permitted for two unrelated authorities to issue certificates under
the same name? Are you really suggesting that the document
simultaneously indicates that it is acceptable for two unrelated
authorities issuing certificates under the same name (your claim),
while also stating that CAs SHOULD NOT do this and warning that
there are risks if they do?

If an attacker obtains the private
key of a CA unnoticed, the attacker may issue bogus certificates
and CRLs.  Even if an attacker is unable to obtain a copy of a
CA's private key, the attacker may be able to issue bogus
certificates and CRLs by making unauthorized use of the CA's
workstation or of an RA's workstation.  Such an attack may be
the result of an attacker obtaining unauthorized access to the
workstation, either locally or remotely, or may be the result of
inappropriate activity by an insider.  Existence of bogus
certificates and CRLs will undermine confidence in the system.  Among many other possible
attacks, the attacker may issue bogus certificates that have
the same subject names as legitimate certificates in order
impersonate legitimate certificate subjects. This could
include bogus CA certificates in which the subject names in
the bogus certificates match the names under which legitimate
CAs issue certificates and CRLs. This would allow the attacker
to issue bogus certificates and CRLs that have the same issuer
names, and possibly the same serial numbers, as certificates
and CRLs issued by legitimate CAs.

Again, why would the RFC permit something so risky? Why would a
document with such a security flaw be allowed to progress to RFC
status? Perhaps the answer is that (as I've repeatedly pointed) out,
neither RFC 5280 nor the X.509 standard that it profiles permits two
different CAs to issue certificates with the same subject names to
two different entities, and the Security Considerations section of
RFC 5280 is pointing out that there is a risk that this could happen
even though the standard doesn't permit it, and pointing out some of
the problems that could occur if it did.

Looking at the Section 6.3 of RFC 5280 (CRL Validation) also makes
the requirement clear. When deciding whether a CRL (that could have
been obtained from anywhere) may be used to determine the status of
a certificate, RFC 5280 says:

(f)  Obtain and validate the
certification path for the issuer of

the complete CRL.  The trust anchor for the certification

path MUST be the same as the trust anchor used to
validate

the target certificate.  If a key usage extension is
present

in the CRL issuer's certificate, verify that the cRLSign
bit

is set.

RFC 5280 explicitly allows the certification path for the CRL to be
different from the certification path for the certificate whose
status is being checked, as long as both certification paths start
with the same trust anchor (a requirement imposed by RFC 5280, but
not X.509). So, using the figure below as an example, RFC 5280
states that the CRL shown on the left could be used to determine the
status of the EE certificate on the right (assuming the CRL does not
include an optional issuingDistributionPoint extension). [Feel free
to read all of RFC 5280 Section 6.3 to verify this.]

According to you, however, RFC 5280 permits the subject of the
certificate from subordinate CA 1 and the subject of the certificate
from subordinate CA 2 to be unrelated entities. If that were true,
why would it allow a CRL issued by one entity to be used to
determine the status of a certificate issued by an unrelated entity?
It doesn't, because RFC 5280 doesn't permit unrelated CAs to issue
certificates and/or CRLs under the same name. If it did, then it
would need to impose a much stricter requirement for validating CRLs
than that the certification path MUST have the same trust anchor. It
would need to require something closer to MUST be the same
certification path.

Along the lines of the text in the Security Considerations section,
the text in Section 6.3 requires that the paths start with the same
trust anchor in order to protect against the risk that two
unrelated CAs issue certificates and CRLs under the same name, but
it assumes that there will not be two unrelated CAs issuing under
the same name that are part of the same PKI (i.e., are under the
same trust anchor). Are you really suggesting that RFC 5280 permits
something, but then assumes it won't happen, and then warns that
there are risks if it does happen?

+--------------+

| trust anchor |

+--------------+

/           \

/             \

+------------------+ +------------------+

| subordinate CA 1 | | subordinate CA 2 |

+------------------+ +------------------+

|                   |

|                   |

+-------------------------------------+

|+--------------+     +--------------+|

|| issuing CA A |     | issuing CA A ||

|+--------------+     +--------------+|

+-------------------------------------+

|                  |

|                  | EE certificate

|                  |

+-----+         +------------+

| CRL |         | end entity |

+-----+         +------------+

As I noted before, RFC 5280 isn't the only document that includes
text related to this requirement. RFC 5755 (Attribute Certificate
Profile) is another example. RFC 5755 indicates that there are three
ways to specify the Holder of an attribute certificate (the Holder
of an attribute certificate is the equivalent of the Subject of a
public-key certificate), and then it says:

For any environment where the AC
is passed in an authenticated message or session and where the
authentication is based on the use of an X.509 PKC, the Holder
field SHOULD use the baseCertificateID.

where baseCertificateID is defined as
IssuerSerial, and IssuerSerial is defined as:

IssuerSerial  ::=  SEQUENCE {

issuer         GeneralNames,

serial         CertificateSerialNumber,

issuerUID      UniqueIdentifier OPTIONAL

}

[The issuerUID field would almost always be absent, since public-key
certificates almost never include this field.]

So, RFC 5755 encourages identifying the Holder of an AC by the
issuer name and serial number of the Holder's public-key
certificate, and yet it says the following the Security
Considerations section:

If an attribute certificate is
tied to the holder's PKC using the baseCertificateID component
of the Holder field and the PKI in use includes a rogue CA with
the same issuer name specified in the baseCertificateID
component, this rogue CA
could issue a PKC to a malicious party, using the same issuer
name and serial number as the proper holder's PKC.  Then the malicious party could
use this PKC in conjunction with the AC. This scenario SHOULD be avoided
by properly managing and configuring the PKI so that there
cannot be two CAs with the same name.  Another
alternative is to tie ACs to PKCs using the publicKeyCert type
in the ObjectDigestInfo field.  Failing this, AC verifiers have
to establish (using other means) that the potential collisions
cannot actually occur, for example, the Certificate Practice
Statements (CPSs) of the CAs involved may make it clear that no
such name collisions can occur.

If the PKIX profile for public-key certificates (RFC 5280) really
allowed unrelated CAs to issue certificates under the same name, why
would the PKIX AC profile say that issuers of ACs SHOULD use the
baseCertificateID choice to identity a Holder in some cases and then
warn that using that choice could allow one entity to use (claim
"ownership") of another entity's AC if two unrelated CAs issue
certificates under the same name and happen to issue certificates
with the same serial number (a likely possibility since some CAs
issue certificates with sequential serial numbers)? That would seem
like a fatal flaw in th profile.

If the PKIX profile for public-key certificates (RFC 5280) really
allowed unrelated CAs to issue certificates under the same name, why
would the text above refer to one of the CAs issuing under this name
as a "rogue CA"? Why limit this text to a "rogue CA" if the same
circumstance could occur by accident with two legitimate CAs that
just happen to issue certificates under the same name?

If the PKIX profile for public-key certificates (RFC 5280) really
allowed unrelated CAs to issue certificates under the same name, why
would the text above suggest "properly managing and configuring the
PKI so that there cannot be two CAs with the same name." Doesn't
that imply that a PKI with two CAs issuing under the same name isn't
"properly managed"? Why would it suggest that if, as you claim,
there is nothing improper about two unrelated CAs issuing
certificates under the same name, as long the two unrelated CAs are
not both issued cross-certificates by the same CA?

The answer to all of the above is quite clear. PKIX does not permit
two unrelated CAs to issue certificates under the same name. That
is, it does require names to be unambiguous across CAs.

The two
CAs in my scenario have different parents, but the same name and
same public key. So

Aside from the gratuitous parenthetical in your text falsely stating
that RFC 5280 "doe not preclude the creation of two CAs with the
same name, so long as the parent CAs are distinct," you still write
about two CAs issuing two EE certificates that are identical. If it
walks like a duck and it quacks like a duck, then chances are its a
duck. In the scenario you are trying to describe, there is one CA
that issues one EE certificate. If you stopped trying to pretend
otherwise, that would be a great starting point in improving the
rest of the text, since so much of the rest of the description is
based on trying to treat a single EE certificate issued by a CA as
if it were two different, but identical, certificates issued by two
different, but colluding, CAs that happen to issue under the same
name and using the same key.

Why not just acknowledge that this attack scenario involves one CA
issuing one EE certificate, where the one CA has been issued
cross-certificates by two different "parent" CAs and then write the
remainder of the text based on that. That would eliminate any
justification for including a parenthetical falsely claiming that
RFC 5280 does not preclude the creation of two CAs with the same
name, but it would make the description of the attack so much
better. Right now, the proposed text isn't "more general," it is
just convoluted.

As I explained, my description of an
colluding CA attack differs from DKGs in that it

is more general and thus. I think, more useful for discussion in
the threat analysis.

Yes, it is true that CRLs and OCSP responses would not generally
be tied to the

two CA instances on different cert paths. But, that's not the
point. It would be dangerous

to assume that an RP can be confident that the revocation status
data it acquires comes

from a specific instance of a CA, when there are two CAs with
the same names and

same public keys. RFC 5280 does not provide implementation
guidance that calls for

pooling of revocation status info based on CA name. An RP may
maintain a cache organized

by cert path, associating revocation status info with each CA in
each cert path.

Can you name even one RP that maintains a cache of revocation status
info organized by cert path? If not, then why all the text about
revocation status checking being performed in the context of a
certification path and how "a browser checking a CRL or OCSP
response may not match this revocation status data against the
doppelganger certificate," followed by a suggestion that the
attacker might take advantage of this by revoking one of the two
identical EE certificates while not revoking the other. Why would it
be the "best strategy" for the attacker to rely on browsers behaving
in a way that no browsers actually behave? As I said before, there
are ways the attacker might be able to perform the type of attack
where some RPs see the EE certificate as having been revoked and
others do not, but that it not what you described.

Why not just go back to what DKG described, where the attacker
revokes the CA certificate along the path submitted to the log and
leaves the other CA certificate unrevoked so that there is still a
valid certification path to the one EE certificate?

Such

an implementation strategy is attractive because it can allow an
RP to avoid redundant

cert path validation processing when a target cert shares a
portion of a cert path with

other certs that have been validated. In such an implementation
an RP would not be aware that

there are two CAs with the same name on different cert paths,
and revocation status data

associated with each of these CAs would be acquired and
maintained separately. In such

Thus I stand by my analysis of the vulnerability, in the more
general case.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Mar 2016 10:25:13 -0400

David,

I appreciate your persistence, but we will just have to agree to 
disagree on the
topic of whether 5280 requires global name uniqueness.

First, I cited text from Secyion 4.1.2.6, which is the one place in 5280 
where global
name uniqueness should be mandated if it were a requirement. That 
section establishes a
requirement for local (per-CA) name uniqueness, not for global name 
uniqueness. IMHO
that is the definitive statement on this topic.

RFC 5280, like its predecessors, has deviated from X.509 where we felt 
necessary. Your
argument that PKIX docs will maintain compatibility with X.509 is just 
an indication
of overall intent, not a promise to never deviate. You acknowledge this 
later when you
discuss CRL issuer paths and say ".. a requirement imposed by RFC 5280, 
but not X.509."

Yes, the Security Considerations section of 5280 notes that problems 
that can arise if
names are not globally unique. However, that is not the same as saying 
that 5280 requires
them to be so. Rather it is a warning of the bad things that may happen 
if name collisions
occur. A warning in the Security Considerations section the way we 
usually note a residual
vulnerability in a standard. It is NOT a backdoor way to add a 
requirement to a standard.

Your other comments cite text that, in your opinion, suggests the need 
for global name
uniqueness, rather than citing text that establishes this requirement. 
Hence I'm not going
to spend time addressing those comments.

> that RFC 5280 "doe not preclude the creation of two CAs with the same 
> name, so long as the parent CAs are distinct," you still write about 
> two CAs issuing two EE certificates that are identical. If it walks 
> like a duck and it quacks like a duck, then chances are its a duck. In 
> the scenario you are trying to describe, there is one CA that issues 
> one EE certificate. 
One might argue that two entities acting as CAs that have the same name 
and same public
key are the same CA. But if the entities happen to be different 
organizations, perhaps
in different geopolitical regions, others might argue that they are 
different CAs.
> info organized by cert path? 
BBN has implemented RP code for at least 4 products over the past 20 
years. Some were part
of PKI systems developed for clients in the financial services area. The 
most recent is
the RPSTIR code for the RPKI. All of them operate as I described.

I'll discuss whether my attack scenarios are accurate and match the 
spirit of DKGs original
message with him, not you.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 30 Mar 2016 11:33:37 -0400

On 03/30/2016 10:25 AM, Stephen Kent
wrote:

I'll discuss whether my attack scenarios are accurate and match
the spirit of DKGs original

Is it appropriate for a document editor to declare that he will
ignore input from members of the working group?

---

From: Melinda Shore <[email-masked]>
Date: Wed, 30 Mar 2016 07:37:28 -0800

> message with him, not you.

Just a friendly reminder that the draft is a working group
document, not an individual contribution.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Wed, 30 Mar 2016 07:38:42 -0800

On 3/30/16 7:33 AM, David A. Cooper wrote:
> Is it appropriate for a document editor to declare that he will ignore
> input from members of the working group?

Of course not.

Melinda

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 30 Mar 2016 12:02:23 -0400

So, your contention is that PKIX
diverged from X.509 by removing the requirement for names to be
unambiguous, and did nothing to address the vulnerability created
by this divergence other than noting the vulnerability in the
Security Considerations sections of its documents? The working
group then went on to develop protocols and profiles that relied
on names being unambiguous, and then just noted in the Security
Considerations that an unnecessary vulnerability had been created?
I have even looked for evidence that the PKIX WG discussed the
idea of deviating from X.509 and allowing names to be ambiguous
(i.e., unrelated entities operating under the same name) and have
been unable to find any evidence of that on the mail list. I have,
however, heard an explanation for why the text in Section 4.1.2.6
says what it does, and it was not about a deliberate decision to
deviate from X.509.

The proposed text for Section 3.3 seems to be written with the
goal of advancing your personal belief about what RFC 5280 does or
does not require rather than trying to explain a potential attack
in the clearest way possible. Removing the parenthetical about RFC
5280 and simply referring to the intermediate CA and EE as the
single entities that they are would go a long way towards
improving the text.

On 03/30/2016 10:25 AM, Stephen Kent wrote:

David,

I appreciate your persistence, but we
will just have to agree to disagree on the

First, I cited text from Secyion 4.1.2.6, which is the one place
in 5280 where global

name uniqueness should be mandated if it were a requirement.
That section establishes a

requirement for local (per-CA) name uniqueness, not for global
name uniqueness. IMHO

RFC 5280, like its predecessors, has deviated from X.509 where
we felt necessary. Your

argument that PKIX docs will maintain compatibility with X.509
is just an indication

of overall intent, not a promise to never deviate. You
acknowledge this later when you

discuss CRL issuer paths and say ".. a requirement imposed by
RFC 5280, but not X.509."

Yes, the Security Considerations section of 5280 notes that
problems that can arise if

names are not globally unique. However, that is not the same as
saying that 5280 requires

them to be so. Rather it is a warning of the bad things that may
happen if name collisions

occur. A warning in the Security Considerations section the way
we usually note a residual

Your other comments cite text that, in your opinion, suggests
the need for global name

uniqueness, rather than citing text that establishes this
requirement. Hence I'm not going

Aside from the gratuitous parenthetical in your text falsely
stating that RFC 5280 "doe not preclude the creation of two CAs
with the same name, so long as the parent CAs are distinct," you
still write about two CAs issuing two EE certificates that are
identical. If it walks like a duck and it quacks like a duck,
then chances are its a duck. In the scenario you are trying to
describe, there is one CA that issues one EE certificate.

One might argue that two entities acting as CAs that have the same
name and same public

in different geopolitical regions, others might argue that they
are different CAs.

Can
you name even one RP that maintains a cache of revocation status
info organized by cert path?

BBN has implemented RP code for at least 4 products over the past
20 years. Some were part

of PKI systems developed for clients in the financial services
area. The most recent is

Steve

---

From: Watson Ladd <[email-masked]>
Date: Wed, 30 Mar 2016 09:09:43 -0700

On Wed, Mar 30, 2016 at 9:02 AM, David A. Cooper <[email-masked]> wrote:
> So, your contention is that PKIX diverged from X.509 by removing the
> requirement for names to be unambiguous, and did nothing to address the
> vulnerability created by this divergence other than noting the vulnerability
> in the Security Considerations sections of its documents? The working group
> then went on to develop protocols and profiles that relied on names being
> unambiguous, and then just noted in the Security Considerations that an
> unnecessary vulnerability had been created? I have even looked for evidence
> that the PKIX WG discussed the idea of deviating from X.509 and allowing
> names to be ambiguous (i.e., unrelated entities operating under the same
> name) and have been unable to find any evidence of that on the mail list. I
> have, however, heard an explanation for why the text in Section 4.1.2.6 says
> what it does, and it was not about a deliberate decision to deviate from
> X.509.

What "vulnerability" is created? The reason DKG's attack functions is
CT records the end entity certificate,

In the attack model the conspiring CAs can just ignore the requirement
on name validity. I don't see why X509 protects against this more.

>
> The proposed text for Section 3.3 seems to be written with the goal of
> advancing your personal belief about what RFC 5280 does or does not require
> rather than trying to explain a potential attack in the clearest way
> possible. Removing the parenthetical about RFC 5280 and simply referring to
> the intermediate CA and EE as the single entities that they are would go a
> long way towards improving the text.

Define "entity". End of the day there are only bits: the question is
how implementations will behave when given two bitstrings concocted in
the way described by DKG. Disputes over the metaphysics are really
in(trans)substantial.

> I appreciate your persistence, but we will just have to agree to disagree on
> the
> name uniqueness should be mandated if it were a requirement. That section
> establishes a
> argument that PKIX docs will maintain compatibility with X.509 is just an
> indication
> discuss CRL issuer paths and say ".. a requirement imposed by RFC 5280, but
> not X.509."
>
> Yes, the Security Considerations section of 5280 notes that problems that
> can arise if
> names are not globally unique. However, that is not the same as saying that
> 5280 requires
> them to be so. Rather it is a warning of the bad things that may happen if
> name collisions
> occur. A warning in the Security Considerations section the way we usually
> note a residual
> vulnerability in a standard. It is NOT a backdoor way to add a requirement
> to a standard.
>
> Your other comments cite text that, in your opinion, suggests the need for
> global name
> uniqueness, rather than citing text that establishes this requirement. Hence
> I'm not going
> Aside from the gratuitous parenthetical in your text falsely stating that
> RFC 5280 "doe not preclude the creation of two CAs with the same name, so
> long as the parent CAs are distinct," you still write about two CAs issuing
> two EE certificates that are identical. If it walks like a duck and it
> quacks like a duck, then chances are its a duck. In the scenario you are
> trying to describe, there is one CA that issues one EE certificate.
>
> One might argue that two entities acting as CAs that have the same name and
> same public
> Can you name even one RP that maintains a cache of revocation status info
> organized by cert path?
>
> BBN has implemented RP code for at least 4 products over the past 20 years.
> Some were part
> I'll discuss whether my attack scenarios are accurate and match the spirit
> of DKGs original

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 30 Mar 2016 13:04:32 -0400

I described some of the vulnerabilities that I was referring to in a 
message on March 25, and they had nothing to do with CT or DKG's attack.

The problem is that Steve's proposed text for Section 3.3 includes a 
false statement about RFC 5280. The rest of the text then seems to have 
been written in a way to try to justify the inclusion of this false 
statement, with the result that it is very confusing, and it is leading 
some people on this list to believe that X.509 must be broken.

My point was that both X.509 and PKIX (RFC 5280 is just a profile of 
X.509) work well as long as there are not two different trusted entities 
(e.g., CAs, CRL issuers, OCSP responders) that operate under the same 
entity, but that if Steve's claim about RFC 5280 was true, there would 
be vulnerabilities in PKIX profiles/protocols even if all of the CAs in 
the PKI were honest and followed the requirements in RFC 5280. An 
example of a vulnerability (see the March 25 email) would be that a 
relying party might use a CRL issued by one CA to determine the status 
of a certificate issued by another CA, even though the CAs are unrelated 
and the CRL doesn't actually provide any status information about 
certificates issued by the other CA. This would happen even though 
neither CA was trying to "attack" the other, and they were just each 
operating in a way that Steve claims that RFC 5280 allows.

I agree with you about "metaphysics." When I read Steve's text, I 
couldn't understand what it was trying to say, even though I was the 
primary author of RFC 5280 and have been working in PKI for almost 20 
years. When I then read DKG's email, it was very easy for me to 
understand the attack he was trying to describe, and it was clear that 
it was not the same as what Steve was describing in his text.

If Steve would just describe DKG's attack instead of trying to use this 
as a forum for advancing his personal beliefs about X.509, then we 
wouldn't have to deal with these metaphysical arguments.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 30 Mar 2016 18:15:05 +0100

On 30 March 2016 at 17:02, David A. Cooper <[email-masked]> wrote:

> vulnerability created by this divergence other than noting the
> vulnerability in the Security Considerations sections of its documents? The
> working group then went on to develop protocols and profiles that relied on
> names being unambiguous, and then just noted in the Security Considerations
> that an unnecessary vulnerability had been created? I have even looked for
> evidence that the PKIX WG discussed the idea of deviating from X.509 and
> allowing names to be ambiguous (i.e., unrelated entities operating under
> the same name) and have been unable to find any evidence of that on the
> mail list. I have, however, heard an explanation for why the text in
> Section 4.1.2.6 says what it does, and it was not about a deliberate
> decision to deviate from X.509.
>

In practice, how would you ensure names were unambiguous? (actually, a
CT-like mechanism could be used, but CT does rather post-date 5280)

The vulnerability is also mitigated by requiring AIA in the EE certificate,
which the BRs do. Arguably, 5280 should also.

BTW, in case it is not clear, I do agree with Steve that 5280 does not
require global uniqueness.

> I appreciate your persistence, but we will just have to agree to disagree
> on the

---

From: Melinda Shore <[email-masked]>
Date: Wed, 30 Mar 2016 09:18:29 -0800

> wouldn't have to deal with these metaphysical arguments.

I understand that you and some other participants are
frustrated at the moment but it would be helpful if the
discussion could remain technical in nature.

We have working group agreement that the attack described
by DKG needs to be documented and included in the threat
draft.  The draft is not going to back into working group
last call without it, period.

There may be other missing attacks as well and I think
that given where we are today it might be productive for
those to be discussed in a  different thread, to avoid
confusion about what's actually under discussion.

In the meantime, if we can't get some text about the
dual CA attack in the next few weeks we may reach out to
other participants to draft something up for inclusion.

Melinda

---

From: Carl Wallace <[email-masked]>
Date: Wed, 30 Mar 2016 13:31:19 -0400

From:  Trans <[email-masked]> on behalf of Ben Laurie
<[email-masked]>
Subject:  Re: [Trans] text to address DKG's conspiring CAs attack

> In practice, how would you ensure names were unambiguous? (actually, a CT-like
> mechanism could be used, but CT does rather post-date 5280)

You could express name constraints on a trust anchor to prevent re-use of
the same CA subject name. Of course, there are very few implementations of
this and none (that I know of) in the web PKI and the expression could get
long for overpopulated TA stores. Details are in 5914 and 5937, as noted in
6818. Using this you would just need to make sure there are no overlaps in
your TA store. 

> which the BRs do. Arguably, 5280 should also.

How does an AIA help? AIAs could be suppressed or mis-populated and path
building may use artifacts previously download from a different AIA.

> 
> BTW, in case it is not clear, I do agree with Steve that 5280 does not require
> global uniqueness.
>

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 30 Mar 2016 14:36:14 -0400

I provided rather detailed evidence
that RFC 5280 does require global name uniqueness. Can you explain
why my evidence is wrong? How does the text in Section 6.3 of RFC
5280 ensure that a CRL issued by one CA isn't used to determine
the status of certificates issued by an unrelated CA issuing
certificates under the same name if both can be validated from the
same trust anchor?

I have been explaining what RFC 5280 says (and what X.509 says). I
have not been trying to justify that it was a correct design
decision, so there's no need for me to answer the question about
how one would ensure names are unambiguous.

You are free to agree with Steve that RFC 5280 shouldn't
have required names to be globally unambiguous, but that doesn't
change the fact that (as I have shown) RFC 5280 and other PKIX
documents were written in a way that things don't work unless
names are globally unambiguous.

If RFC 5280 didn't require names to be unambiguous, why didn't the
text in Section 6.3.3 address the problem I mentioned above by
requiring that the certification path for a CRL be the same as for
the certificate whose status is being checked (or at least require
that the list of CA names in the paths be the same)? Again, you
can agree with Steve that something like that should have
been done, but where's the evidence that it was done?

Dave

P.S. It would really be helpful if this discussion thread could
end. It's not relevant to TRANS, and there would be no reason to
discuss it at all in this group if there wasn't an attempt to
include text about it in one of the TRANS documents.

On 03/30/2016 01:15 PM, Ben Laurie wrote:

On 30 March 2016 at 17:02, David A. Cooper <[email-masked]>
wrote:

So, your contention is that PKIX diverged from
X.509 by removing the requirement for names to be
unambiguous, and did nothing to address the
vulnerability created by this divergence other than
noting the vulnerability in the Security
Considerations sections of its documents? The working
group then went on to develop protocols and profiles
that relied on names being unambiguous, and then just
noted in the Security Considerations that an
unnecessary vulnerability had been created? I have
even looked for evidence that the PKIX WG discussed
the idea of deviating from X.509 and allowing names to
be ambiguous (i.e., unrelated entities operating under
the same name) and have been unable to find any
evidence of that on the mail list. I have, however,
heard an explanation for why the text in Section
4.1.2.6 says what it does, and it was not about a
deliberate decision to deviate from X.509.

In practice, how would you ensure names were
unambiguous? (actually, a CT-like mechanism could be used,
but CT does rather post-date 5280)

The vulnerability is also mitigated by requiring AIA in
the EE certificate, which the BRs do. Arguably, 5280
should also.

BTW, in case it is not clear, I do agree with Steve
that 5280 does not require global uniqueness.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Mar 2016 12:38:11 +0100

> last call without it, period.

I should reiterate that this is _not_ an attack on CT, but on RFC 5280. Is
our document the right place for it?

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Mar 2016 12:41:49 +0100

On 30 March 2016 at 18:31, Carl Wallace <[email-masked]> wrote:

>
> From: Trans <[email-masked]> on behalf of Ben Laurie <
> [email-masked]>
> the same CA subject name.
>

How would that work? Name constraints only constrain subordinate certs...

> Of course, there are very few implementations of this and none (that I
> know of) in the web PKI and the expression could get long for overpopulated
> TA stores. Details are in 5914 and 5937, as noted in 6818. Using this you
> would just need to make sure there are no overlaps in your TA store.
>

AFAIK, all modern browsers support name constraints. But perhaps that's not
what you meant?

>
>
> The vulnerability is also mitigated by requiring AIA in the EE
> certificate, which the BRs do. Arguably, 5280 should also.
>
>

If the AIA is in the end cert, then it is unambiguous how that cert is
revoked.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Mar 2016 12:51:59 +0100

On 30 March 2016 at 19:36, David A. Cooper <[email-masked]> wrote:

> I provided rather detailed evidence that RFC 5280 does require global name
> uniqueness. Can you explain why my evidence is wrong?
>

As far as I can work out, your evidence is that RFC 5280 _ought_ to have
required global name uniqueness, not that it _does_. I haven't seen you
quote anything from RFC 5280 that requires it.

> How does the text in Section 6.3 of RFC 5280 ensure that a CRL issued by
> one CA isn't used to determine the status of certificates issued by an
> unrelated CA issuing certificates under the same name if both can be
> validated from the same trust anchor?
>

It doesn't.

>
> I have been explaining what RFC 5280 says (and what X.509 says). I have
> not been trying to justify that it was a correct design decision, so
> there's no need for me to answer the question about how one would ensure
> names are unambiguous.
>
> You are free to agree with Steve that RFC 5280 *shouldn't* have required
> names to be globally unambiguous, but that doesn't change the fact that (as
> I have shown) RFC 5280 and other PKIX documents were written in a way that
> things don't work unless names are globally unambiguous.
>

I don't agree with Steve that RFC 5280 *shouldn't* have required names to
be globally unambiguous, because AFAICS it doesn't.

I also don't agree that RFC 5280 was written s.t. it doesn't work unless
names are globally unambiguous - there is at least one other solution to
the problem, as I've pointed out.

> If RFC 5280 didn't require names to be unambiguous, why didn't the text in
> Section 6.3.3 address the problem I mentioned above by requiring that the
> certification path for a CRL be the same as for the certificate whose
> status is being checked (or at least require that the list of CA names in
> the paths be the same)? Again, you can agree with Steve that something like
> that *should* have been done, but where's the evidence that it was done?
>

I am not saying there is any evidence it was done.

>
> Dave
>
> P.S. It would really be helpful if this discussion thread could end. It's
> not relevant to TRANS, and there would be no reason to discuss it at all in
> this group if there wasn't an attempt to include text about it in one of
> the TRANS documents.
>

Agreed.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 31 Mar 2016 08:14:04 -0400

From:  Ben Laurie <[email-masked]>
Date:  Thursday, March 31, 2016 at 7:41 AM
To:  Carl Wallace <[email-masked]>
Cc:  "David A. Cooper" <[email-masked]>, "[email-masked]"
<[email-masked]>, Stephen Kent <[email-masked]>
Subject:  Re: [Trans] text to address DKG's conspiring CAs attack

>> You could express name constraints on a trust anchor to prevent re-use of the
>> same CA subject name.
> 

All CA certs are subordinate to trust anchors. RFC5914 defines how to
associate name constraints with a TA. RFC5937 defines how to use those
constraints to provide inputs to a 5280 compliant validation engine so they
apply across a certification path. The attack (as I followed it early on in
this thread) required two CAs to have the same subject name in an
arrangement like this:

  A -> A_X -> C

  B -> B_X -> C

If B was defined with an excluded name constraint asserting subject name
from A_X, then the B_X certificate with that name could not be validated.
This mechanism is used when validating client certificates presented during
mutually authenticated TLS within the US Federal PKI, where the names are
sufficiently hierarchical that the name constraints expression is not
terribly verbose. In the implementation I am familiar with, the
TrustAnchorInfo option from 5914 is used exclusively, with self-signed root
certs wrapped by a structure that asserts the name constraints (or policy
constraints). B could also be defined with permitted name constraints that
align with CAs it legitimately issues.

The validation rules are straightforward. Once you build a path, you use the
constraints from the trust anchor to set the inputs to the 5280 validation
algorithm. So the name constraints from the TA would be used to populate the
permitted_subtrees or excluded_subtrees input variables defined in 5280. As
long as you can store/use the alternative TA structure, any 5280 compliant
validation engine can be used for processing (since the mechanism only
manipulates inputs to the validation algorithm, not internal details).

> 
>  
>>  Of course, there are very few implementations of this and none (that I know
>> of) in the web PKI and the expression could get long for overpopulated TA
>> stores. Details are in 5914 and 5937, as noted in 6818. Using this you would
>> just need to make sure there are no overlaps in your TA store.
> 

I meant use of name constraints associated with a TA.

> If the AIA is in the end cert, then it is unambiguous how that cert is

OK, I was focused on the caIssuers AIA. How does that help, though? The X
key could either sign OCSP responses itself or sign an OCSP responder cert
that could be used to provide the desired revocation results.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Mar 2016 14:58:30 +0100

On 31 March 2016 at 13:14, Carl Wallace <[email-masked]> wrote:

> Cc: "David A. Cooper" <[email-masked]>, "[email-masked]" <
> [email-masked]>, Stephen Kent <[email-masked]>
> All CA certs are subordinate to trust anchors.
>

Surely not? Surely many of them are trust anchors?

> RFC5914 defines how to associate name constraints with a TA. RFC5937
> defines how to use those constraints to provide inputs to a 5280 compliant
> validation engine so they apply across a certification path. The attack (as
> I followed it early on in this thread) required two CAs to have the same
> subject name in an arrangement like this:
>
>   A -> A_X -> C
>
>   B -> B_X -> C
>
>
> If B was defined with an excluded name constraint asserting subject name from A_X, then the B_X certificate with that name could not be validated. This mechanism is used when validating client certificates presented during mutually authenticated TLS within the US Federal PKI, where the names are sufficiently hierarchical that the name constraints expression is not terribly verbose. In the implementation I am familiar with, the TrustAnchorInfo option from 5914 is used exclusively, with self-signed root certs wrapped by a structure that asserts the name constraints (or policy constraints). B could also be defined with permitted name constraints that align with CAs it legitimately issues.
>
>
> The validation rules are straightforward. Once you build a path, you use the constraints from the trust anchor to set the inputs to the 5280 validation algorithm. So the name constraints from the TA would be used to populate the permitted_subtrees or excluded_subtrees input variables defined in 5280. As long as you can store/use the alternative TA structure, any 5280 compliant validation engine can be used for processing (since the mechanism only manipulates inputs to the validation algorithm, not internal details).
>
>
>
>
>
> AFAIK, all modern browsers support name constraints. But perhaps that's
> not what you meant?
>
>
That is a different attack. And is why you also need Revocation
Transparency. :-)

---

From: Carl Wallace <[email-masked]>
Date: Thu, 31 Mar 2016 10:21:27 -0400

> Surely not? Surely many of them are trust anchors?

OK, but the name constraints asserted in a TA as passed in validation would
still be enforced.

<snip>

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 31 Mar 2016 11:15:39 -0400

You seem to contradict yourself. You
say you disagree with my assertion that RFC 5280 as written
doesn't work unless names are globally unambiguous, and then you
try to support your disagreement by saying that "there is at least
one other solution to the problem." So, you acknowledge
that if RFC 5280 didn't require names to be globally unambiguous,
then there would be a problem, and then suggest how RFC 5280 could
be changed to address that problem.

Even Steve Kent acknowledges this:

Yes, the Security Considerations section
of 5280 notes that problems that can arise if names are not
globally unique. However, that is not the same as saying that
5280 requires them to be so. Rather it is a warning of the bad
things that may happen if name collisions occur. A warning in
the Security Considerations section the way we usually note a
residual vulnerability in a standard. It is NOT a backdoor way
to add a requirement to a standard.

If you and Steve were correct that RFC 5280 didn't require names
to be globally unambiguous, then (as I've shown) relying parties
could obtain incorrect results even if all of the CAs, OCSP
responders, etc., in the PKI were behaving honestly in accordance
with the standard. That isn't residual security risk to documented
in the Security Considerations section. That is a design flaw in
the protocol that should have prevented the document from becoming
an RFC. Are you and Steve really saying that the PKIX WG
deliberating chose to introduce a design flaw into RFC 5280 (and
RFC 5755 and other PKIX documents) by deviating from X.509? Why
would the PKIX WG co-chairs allow this?

I also disagree that you've pointed out "at least one other
solution to the problem." The only things I've seen you suggest is
that "the vulnerability is also mitigated by requiring AIA in the
EE certificate." I can only guess what that means. Do you mean
require an AIA extension with the id-ad-ocsp access method in the
EE certificate? Would you simultaneously be forbidding the use of
CRLs? What about CA certificates? How would the AIA extension fix
the problem with attribute certificates (RFC 5755) that I
highlighted?

Need further evidence of the RFC 5280 requirement? RFC 5280 says:

Section 4.1.2.4: The issuer
field identifies the entity that has signed and issued the
certificate.  The issuer field MUST contain a non-empty
distinguished name (DN).  The issuer field is defined as the
X.501 type Name [X.501].

Section 4.1.2.6: The subject field is defined as the X.501
type Name.  Implementation requirements for this field are
those defined for the issuer field (Section 4.1.2.4).

How does X.509 define the Name type:

A (directory) name is a construct that
identifies a particular object from among the set of all
objects. A name shall be
unambiguous, that is, denotes just one object. However,
a name need not be unique, that is, be the only name that
unambiguously denotes the object.

So, RFC 5280 says that the issuer and subject fields in
certificates as defined as the X.501 type Name, and point to X.501
for the definition of Name, which defines Name to be something
that is unambiguous.

I'm sure some will argue that RFC 5280 only intended to adopt some
aspects of the definition of Name from X.501, and not this part of
the definition. However, there is nothing in RFC 5280 to support
that. And, you still can't get around the problem that if RFC 5280
didn't require names to be unambiguous, then as it is currently
written, it and other PKIX documents would be flawed by design.

On 03/31/2016 07:51 AM, Ben Laurie wrote:

On 30 March 2016 at 19:36, David A. Cooper <[email-masked]>
wrote:

I provided rather detailed evidence that RFC 5280
does require global name uniqueness. Can you explain
why my evidence is wrong?

As far as I can work out, your evidence is that RFC
5280 _ought_ to have required global name uniqueness, not
that it _does_. I haven't seen you quote anything from RFC
5280 that requires it.

How does the text in Section 6.3 of RFC 5280
ensure that a CRL issued by one CA isn't used to
determine the status of certificates issued by an
unrelated CA issuing certificates under the same name
if both can be validated from the same trust anchor?

It doesn't.

I have been explaining what RFC 5280 says (and what
X.509 says). I have not been trying to justify that it
was a correct design decision, so there's no need for
me to answer the question about how one would ensure
names are unambiguous.

You are free to agree with Steve that RFC 5280 shouldn't
have required names to be globally unambiguous, but
that doesn't change the fact that (as I have shown)
RFC 5280 and other PKIX documents were written in a
way that things don't work unless names are globally
unambiguous.

I don't agree with Steve that RFC 5280 shouldn't have
required names to be globally unambiguous, because AFAICS
it doesn't.

I also don't agree that RFC 5280 was written s.t. it
doesn't work unless names are globally unambiguous - there
is at least one other solution to the problem, as I've
pointed out.

If RFC 5280 didn't require names to be unambiguous,
why didn't the text in Section 6.3.3 address the
problem I mentioned above by requiring that the
certification path for a CRL be the same as for the
certificate whose status is being checked (or at least
require that the list of CA names in the paths be the
same)? Again, you can agree with Steve that something
like that should have been done, but where's
the evidence that it was done?

Dave

P.S. It would really be helpful if this discussion
thread could end. It's not relevant to TRANS, and
there would be no reason to discuss it at all in this
group if there wasn't an attempt to include text about
it in one of the TRANS documents.

Agreed.

On 30 March 2016 at 17:02, David A.
Cooper <[email-masked]>
wrote:

So, your contention is that PKIX
diverged from X.509 by removing the
requirement for names to be unambiguous,
and did nothing to address the
vulnerability created by this divergence
other than noting the vulnerability in
the Security Considerations sections of
its documents? The working group then
went on to develop protocols and
profiles that relied on names being
unambiguous, and then just noted in the
Security Considerations that an
unnecessary vulnerability had been
created? I have even looked for evidence
that the PKIX WG discussed the idea of
deviating from X.509 and allowing names
to be ambiguous (i.e., unrelated
entities operating under the same name)
and have been unable to find any
evidence of that on the mail list. I
have, however, heard an explanation for
why the text in Section 4.1.2.6 says
what it does, and it was not about a
deliberate decision to deviate from
X.509.

In practice, how would you ensure names
were unambiguous? (actually, a CT-like
mechanism could be used, but CT does rather
post-date 5280)

The vulnerability is also mitigated by
requiring AIA in the EE certificate, which
the BRs do. Arguably, 5280 should also.

BTW, in case it is not clear, I do agree
with Steve that 5280 does not require global
uniqueness.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Mar 2016 16:30:55 +0100

On 31 March 2016 at 16:15, David A. Cooper <[email-masked]> wrote:

> You seem to contradict yourself. You say you disagree with my assertion
> that RFC 5280 as written doesn't work unless names are globally
> unambiguous, and then you try to support your disagreement by saying that
> "there is at least one other solution to the *problem*." So, you
> acknowledge that if RFC 5280 didn't require names to be globally
> unambiguous, then there would be a problem,
>

I do, but I also assert that it does not require names to be unambiguous.

> and then suggest how RFC 5280 *could be changed* to address that problem.
>
> can arise if names are not globally unique. However, that is not the same
> as saying that 5280 requires them to be so. Rather it is a warning of the
> bad things that may happen if name collisions occur. A warning in the
> Security Considerations section the way we usually note a residual
> If you and Steve were correct that RFC 5280 didn't require names to be
> globally unambiguous, then (as I've shown) relying parties could obtain
> incorrect results even if all of the CAs, OCSP responders, etc., in the PKI
> were behaving honestly in accordance with the standard.
>

I agree!

> That isn't residual security risk to documented in the Security
> Considerations section. That is a design flaw in the protocol that should
> have prevented the document from becoming an RFC. Are you and Steve really
> saying that the PKIX WG deliberating chose to introduce a design flaw into
> RFC 5280 (and RFC 5755 and other PKIX documents) by deviating from X.509?
> Why would the PKIX WG co-chairs allow this?
>

I am not saying anything of the sort. I am just observing that the flaw
exists.

> I also disagree that you've pointed out "at least one other solution to
> the problem." The only things I've seen you suggest is that "the
> vulnerability is also mitigated by requiring AIA in the EE certificate." I
> can only guess what that means. Do you mean require an AIA extension with
> the id-ad-ocsp access method in the EE certificate?
>

Yes.

> Would you simultaneously be forbidding the use of CRLs?
>

Specifying the CRL endpoint would also fix the problem.

> What about CA certificates?
>

What about them?

> How would the AIA extension fix the problem with attribute certificates
> (RFC 5755) that I highlighted?
>

I don't know. Are you saying it wouldn't? I don't really know anything
about 5755.

> Section 4.1.2.4: The issuer field identifies the entity that has signed
> and issued the certificate.  The issuer field MUST contain a non-empty
> distinguished name (DN).  The issuer field is defined as the X.501 type
> Name [X.501].
>
> Section 4.1.2.6: The subject field is defined as the X.501 type Name.
> Implementation requirements for this field are those defined for the issuer
> field (Section 4.1.2.4).
>
> A *(directory) name* is a construct that identifies a particular object
> from among the set of all objects. A name shall be unambiguous, that is,
> denotes just one object. However, a name need not be unique, that is, be
> the only name that unambiguously denotes the object.
>
>
> So, RFC 5280 says that the issuer and subject fields in certificates as
> defined as the X.501 type Name, and point to X.501 for the definition of
> Name, which defines Name to be something that is unambiguous.
>
> I'm sure some will argue that RFC 5280 only intended to adopt some aspects
> of the definition of Name from X.501, and not this part of the definition.
> However, there is nothing in RFC 5280 to support that. And, you still can't
> get around the problem that if RFC 5280 didn't require names to be
> unambiguous, then as it is currently written, it and other PKIX documents
> would be flawed by design.
>

Interesting.

OK, for the sake of argument, let's assume that RFC 5280 does require names
to be unambiguous. Now what? There is no mechanism in place to prevent (or
even detect) ambiguity - that seems like a problem. Furthermore, what
happens when it turns out a name is ambiguous? Presumably that makes all
certs containing that name not 5280 compliant?

>> I provided rather detailed evidence that RFC 5280 does require global
>> name uniqueness. Can you explain why my evidence is wrong?
>>
>
>> If RFC 5280 didn't require names to be unambiguous, why didn't the text
>> in Section 6.3.3 address the problem I mentioned above by requiring that
>> the certification path for a CRL be the same as for the certificate whose
>> On 30 March 2016 at 17:02, David A. Cooper < <[email-masked]>
>> [email-masked]> wrote:
>>

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 31 Mar 2016 14:38:19 -0400

On 03/31/2016 11:30 AM, Ben Laurie
wrote:

On 31 March 2016 at 16:15, David A.
Cooper <[email-masked]>
wrote:

I also disagree that you've pointed out "at least
one other solution to the problem." The only things
I've seen you suggest is that "the vulnerability is
also mitigated by requiring AIA in the EE
certificate." I can only guess what that means. Do you
mean require an AIA extension with the id-ad-ocsp
access method in the EE certificate?

Yes.

The id-ad-ocsp access method in AIA just contains an HTTP URI that
provides information about where an OCSP responder can be found. It
does nothing to help ensure that the response it authoritative for
the certificate. That is addressed by other means. Perhaps if PKIX
were changed to only allow the use of OCSP to distribute status
information and it imposed (as SHALLs) certain restrictions on the
validation of OCSP responses, this would avoid the problems that
name collisions might cause with respect to determining the
revocation status of a certificate. But, there's a lot more to a PKI
than just determining whether certificates are revoked.

Would you simultaneously be forbidding the use of
CRLs?

I can again only guess what you mean. As with OCSP, including a URL
in the cRLDistributionPoints extension just provides an (insecure)
pointer to where a CRL can be found. It doesn't provide any
security. In order for the URL to provide any additional assurance,
that same URL would need to appear in a critical
issuingDistributionPoint extension in the CRL. If it appeared in the
CRL's IDP extension, then the CRL could only be used if the same
name (e.g., HTTP URI) appeared in both the CRL's IDP and the
certificate's CRLDP. But this again relies on names being
unambiguous, because it wouldn't solve the problem if unrelated
issuers could use the same names for distribution points.

What about them?

There needs to be a reliable revocation mechanism for all
certificates, not just EE certificates, and the mechanisms that PKIX
describes (CRLs and OCSP) are the same for both. So, if something
needs to be done in EE certificates to make revocation reliable,
then something needs to be done in CA certificates as well.

How would the AIA extension fix the problem with
attribute certificates (RFC 5755) that I highlighted?

I don't know. Are you saying it wouldn't? I don't
really know anything about 5755.

Yes. The problem with attribute certificates has nothing to do with
revocation. RFC 5755 allows attribute certificates to be issued to
entities (humans, devices, etc.). How does a relying party know to
whom (or what) the attribute certificate was issued? The entity to
which the attribute certificate was issued is identified by
providing the issuer name and serial number of the entity's public
key certificate. So, if issuer names are ambiguous, then relying
parties cannot reliably determine to whom (or to what) an attribute
certificate has been issued.

Need further evidence of the RFC 5280 requirement?
RFC 5280 says:

Section 4.1.2.4: The issuer field
identifies the entity that has signed and issued
the certificate.  The issuer field MUST contain a
non-empty distinguished name (DN).  The issuer
field is defined as the X.501 type Name [X.501].

Section 4.1.2.6:
The subject field is defined as the X.501 type
Name.  Implementation requirements for this field
are those defined for the issuer field (Section
4.1.2.4).

A (directory) name is a construct
that identifies a particular object from among the
set of all objects. A name shall be
unambiguous, that is, denotes just one object.
However, a name need not be unique, that is, be the
only name that unambiguously denotes the object.

So, RFC 5280 says that the issuer and subject fields
in certificates as defined as the X.501 type Name, and
point to X.501 for the definition of Name, which
defines Name to be something that is unambiguous.

I'm sure some will argue that RFC 5280 only intended
to adopt some aspects of the definition of Name from
X.501, and not this part of the definition. However,
there is nothing in RFC 5280 to support that. And, you
still can't get around the problem that if RFC 5280
didn't require names to be unambiguous, then as it is
currently written, it and other PKIX documents would
be flawed by design.

Interesting.

OK, for the sake of argument, let's assume that RFC
5280 does require names to be unambiguous. Now what? There
is no mechanism in place to prevent (or even detect)
ambiguity - that seems like a problem. Furthermore, what
happens when it turns out a name is ambiguous? Presumably
that makes all certs containing that name not 5280
compliant?

In practice, this just isn't a problem. CAs aren't just arbitrary
system components. They are trusted entities that operate under
well-defined policies and practices, and they don't just assign
simple names for their CAs like "cn=Joe's CA". Just look, for
example, at the name of the CA that issued the certificate for the
IETF web site:

CN = Starfield Secure Certificate
Authority - G2, OU = http://certs.starfieldtech.com/repository/,
O = "Starfield Technologies, Inc.", L = Scottsdale, ST =
Arizona, C = US

Is some unrelated entity going to issue certificates under that same
name by accident?

Given the way names are formed, if two entities were found to be
using the same name, it is far more likely that is was a
result of one of these entities deliberately trying to impersonate
the other. That's not a case of names being ambiguous, that's an
attack. The solution to that (if name constraints don't prevent the
impersonator's certificate from being validated) is revocation. PKIX
doesn't deal with the issue of how to detect that there is a
certificate that should be revoked. But this has nothing to do with
names. If you have an undetected attacker in your PKI that is
trusted as a CA, then you have problems regardless of whether the
PKI standard was developed to mitigate problems associated with
ambiguous CA names.