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

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 10 Feb 2005 16:33:08 -0000

Denis it looks like there are some misconceptions here:

Your scenario only applies to indirect CRLs. For indirect CRLs both CDP
AND IDP MUST be present and at least 1 DP location/URL in CDP MUST match
at least one DP location/URL in IDP.

This is already a requirement of both RFC 3280 and X.509.

<snip>
> 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.

Conclusion: a) never apply to this problem space.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 10 februari 2005 17:21
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> Stefan,
> 
>  > I think this question is the key issue:
> 
>  > <Snip>
> 
>  >> Can there be another rule which guarantes that there is no
ambiguity
>  >> about he 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).
> 
> 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
>  > (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.
> 
> 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
> 
>  > 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:43:32 +0100

Stefan,

> Your scenario only applies to indirect CRLs. 

In X.509/ 3.3.32 indirect CRL (iCRL): A revocation list that at least 
contains revocation information about certificates issued by authorities 
other than that which issued this CRL.

I already mentioned that this sentence is not crystal clear while RFC 3280 
states:

    Whenever the CRL issuer is not the CA that issued the certificates,
    the CRL is referred to as an indirect CRL.

  ... which is worse and would need to be corrected. However, this is not 
the main issue for this thread.

Don't you mean the reverse ? i.e. you scenario applies to indirect CRLs 
while mine does not apply to indirect CRL, but only when the CRL only 
contains revocation information for certificates coming from one single CA ?

Denis

> For indirect CRLs both CDP