Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 10 Feb 2005 15:17:37 -0000

I think this question is the key issue:

<Snip>
> Can there be another rule which guarantes that there is no ambiguity
about
> the right CRL issuer bearing the name contained in cRLIssuer ? The
answer
> is
> no, ... unless you demonstrate the contrary.
> 
> Note: remember that the CA cannot know in advanced which trust
anchor(s)
> will be placed in the validation policies used by relying parties.
> 
> Denis
>

If a relying party trust a rouge CA, then all bets are off. This is part
of the PKI fundamentals we have to accept. So the issue is to prevent
matching of unrelated certs and CRLs from trusted issuers.  

This is only a theoretically realistic threat if the CDP in the cert
doesn't include any pointer/address to the CRL storage location (which
should be considered really BAD practice). Storage location addresses
(which have to match between CDP and IDP if present) do have sufficient
uniqueness characteristics to effectively mitigate accidental CA name
collisions. In fact, there are ways to form CDP and IDP to completely
eliminate this threat without imposing your requirement.

Yes - an extra level of security would be guaranteed if the rule you
suggest would be imposed, but I think it is too late and too
restrictive. The threat is not material and realistic enough to justify
a restriction that would declare perfectly secure current
implementations non-conformant.

You are free to seek support for your position, but until you have
obtained rough consensus on your suggested limitation, the crl-aia
drafting process must assume that the limitation you suggest does NOT
exist.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 10 februari 2005 14:31
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> Stefan,
> 
> There is a major security issue here.
> 
> > Denis,
> >
> > It is obvious that you base your objections on the assumption that a
CRL
> > issuer cert MUST be issued by the CA issuing the validated subject
cert.
> >
> > But you also admit that this is what you think the stand should say
but
> > do not say (at least not explicitly).
> >
> > Quote from your text: "This is not explicitly stated in RFC 3280 for
CRL
> > issuers, but it is for OCSP responders"
> >
> > I guess it will be useless to get into details before we have sorted
out
> > this major cause of disagreement. But since even you admit that
there is
> > no such requirement in RFC 3280 (nor X.509), I'm not sure what there
is
> > to discuss.
> 
> The security considerations section needs to be discussed.
> 
> The current text is:
> 
>       Implementers should take into account the possible existence of
>       multiple unrelated CAs and CRL issuers with the same name.  As
>       means of reducing problems and security issues related to issuer
>       name collisions, CA names SHOULD be formed in a way that reduce
the
>       likelihood of name collisions.
> 
> The SHOULD in the previous sentence does not solve the problem, since
this
> cannot be prevented. The text should explain how to have a secure
system
> even in the case of a name collision, i.e. two CAs pick the same name
to
> designate a CRL issuer but that name now relates to two different
> entities.
> 
>       Implementations validating CRLs
>       MUST ensure that the certification path of the target
certificate
>       and the CRL issuer certification path used to validate the
target
>       certificate, terminate at the same trust anchor.
> 
> This sentence does not solve the problem. The only way to solve the
> problem
> is, for relying parties, to be able to know unambiguously which CA is
> allowed to certify the CRL issuer name. It cannot be "any CA" in a
> certification tree.
> 
> Since the syntax of the cRLIssuer contained in DistributionPoint does
not
> permit to place any other information than a name, it cannot designate
the
> CA allowed to certify the CRL issuer name, hence there needs to be a
fixed
> rule to be known by all relying parties.
> 
> The fixed rule I proposed mimics the conditions of the OCSP responder,
> i.e.
> 
>   "The CRL Issuer must have a specially marked certificate issued
>    directly by the CA, indicating that the CRL issuer may issue CRLs".
> 
> Can there be another rule which guarantes that there is no ambiguity
about
> the right CRL issuer bearing the name contained in cRLIssuer ? The
answer
> is
> no, ... unless you demonstrate the contrary.
> 
> Note: remember that the CA cannot know in advanced which trust
anchor(s)
> will be placed in the validation policies used by relying parties.
> 
> Denis
> 
> 
>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 10 Feb 2005 17:20:44 +0100

Stefan,

 >> about he right CRL issuer bearing the name contained in cRLIssuer ?
 >> The answer is no, ... unless you demonstrate the contrary.

 >> anchor(s) will be placed in the validation policies used by relying
 >> parties.

 > should be considered really BAD practice).

At this stage of explanations, the CRL pointer whether present or absent 
does not help. We  all know that it is possible to replace a CRL by another 
one since it is never required to secure the protocol to query CRLs. So an 
attacker having noticed that two CRL issuer names are the same, might 
perform an active attack and exchange CRLs at will.

  > Storage location addresses

Interresting. Your proposal would lead to the following:

    1) both the CDP and the IDP MUST must be present,
    2) then they must match.

  ... but the proposal would mandate the presence of the IDP.

This leads to the following conclusion:

   a) if the IDP is not present, then my scenario applies.
   b) if the IDP is present, then your scenario applies.

Both scenarios would then co-exist.

If you can revise the main body of the draft along these lines, then we may 
be close to an agreement.

Then the second implication is : if the CRL issuer is under the same
trust anchor, it will be trusted, otherwise it might not unless the other
trust anchor is also present in the validation policy. So the recommandation
to use the same trust anchor would be better explained this way in the 
security considerations section.

Denis

---

From: "Julien Stern" <[email-masked]>
Date: Thu, 10 Feb 2005 18:06:27 +0100

> matching of unrelated certs and CRLs from trusted issuers.  

I do not want to (re)start some heated discussions about this topic,
but I'm still curious about the above assumption. Is there a consensus
on it from all the list members ?

Usually, when a security assumption is broken, there are consequences,
but the often used "all bets are off" sentence is a fairly vague
consequence. So what does this "all bets are off" mean ?

- That the rogue CA can do anything it wants under its hierarchy ?
- That the rogue CA can do anything it wants above its hierarchy ?
- That the rogue CA can do anything it wants in any other hierarchy ?
- That the earth will suddently spin the other way round ? :)
- Something else ?

(Quite arguably, my consequences still remain quite vague,
but hopefully clarify my point).

I mean, let's take Microsoft certificate store. And let's assume
that some low-level CA far down in the hierarchy of some trust anchor
gets corrupted. Do we really want it to be able to impact the security
of the system as a whole, and in particular of all the other trust
anchor hierarchies ?

If this is the case, no system will be usable with two trust anchors
with different security clearances.

An other way to state the problem would be: is there a solution that
would allow to limit the scope of a CA compromise to something much
lower than "all bets are off" and if so, how practical would it be,
and do we want to implement it somehow ?

My (humble) position on the general topic would be directly inferred 
by an answer on the previous assumption.

Regards,

--
Julien Stern
R&D director
Cryptolog International SAS
16-18, rue Vulpian
75013 Paris
Tel +33 1 44 08 73 04