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

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 10 Feb 2005 18:42:48 -0000

Denis,

Sorry for being unclear, and maybe for not seeing what you try to say.

What I meant was that the problem should not exist at all for
non-indirect CRLs. Here I totally agree that the CRL and the CA can't
have unrelated chaining. I'm not sure what the standard says about this
but if this is unclear, then it should be made clear.

What I further mean is that the existence of diversified cert and CRL
paths is therefore only an issue for indirect CRLs, AND for indirect
CRLs CDP and IDP matching IS a requirement.

The conclusion I make is: The current text in the crl-aia draft is
correct since diversified CRL and cert paths may exist where the CRL
issuer cert is issued by someone else that the CA that issued the
validated cert.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 10 februari 2005 17:44
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> 
> Stefan,
> 
> > Denis it looks like there are some misconceptions here:
> 
> > 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
> > 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: Fri, 11 Feb 2005 11:33:16 +0100

Stefan,

> issuer cert is issued by someone else that the CA that issued the

The problem is that neither the abstract nor the introduction of this draft 
is limiting the scope to indirect CRLs only.

The point is that a relying party cannot know in advance whether indirect 
CRLs or "direct CRLs" are being used. So the story starts when the relying 
party gets a "candidate CRL" from the CRL DP and then it can see whether it 
contains or not an IDP.

The draft should thus address the two scenarios (i.e. an IDP is or is not 
present) and for direct CRLs there is no "superiority" of the new extension.

Would you prepare a revison of the draft along these lines ?

If you agree, I woud propose that we discuss off-line with your co-editor 
the details of the new draft and come back to the list when a new draft is 
ready.

Denis