Re: PKIX Roadmap

[Sean Turner <turners@xxxxxxxx>]

Al and Stefan,

I must admit that I've be derelict in my duties and have not modified the
sections yet to address this comment.  I will make a note of the concern and
make sure it gets into the -02 version.

Cheers,

spt

Stefan Santesson wrote:
> 
> Al,
> 
> I totally agree with everything you say in this last mail.
> 
> /Stefan
> 
> At 08:15 AM 9/22/98 -0400, Al Arsenault wrote:
> >At 06:25 AM 9/22/98 +0200, Stefan Santesson wrote:
> >>Al,
> >>
> >>Just a short reply to CA disaster (See below).
> >>
> >>Thanks for your reply, I still disagree to the disaster part.
> >>
> >>CA2 does not have to be dismanteled, since CA 2:s key is intact.
> >>What has to be done is that:
> >>- CA1 is rebuilt with new key
> >>- The compromise of CA1 and its new key has to be communicated with
> >>out-of-band means
> >>- CA1 cross certify CA2 (and other CA:s) using the new key
> >>- New cross certificates to CA1 has to be issued and published by other
> CA:s.
> >>
> >>Now all certificates issued by CA2 before the disaster of CA1 can be used
> >>and trusted.
> >>This since the disaster of CA1 didn't destroy CA2, just the link to CA2
> >>from CA1.
> >>
> >>/Stefan
> >
> >Stefan,
> >
> >       The more I think about this, the more I realize we agree.  It's the words
> >that need figuring out. Perhaps the words in the draft roadmap are too
> >strong; we'll have to think about that.
> >
> >       First, let me note that when CA1 and CA2 are cross-certified - that is,
> >have a peer relationship, with neither subordinate to the other - I agree
> >with you about what happens when CA1's key is compromised.
> >
> >       Now, let us assume that there is a hierarchical relationship - CA2 is
> >subordinate to CA1. This means to me that the trust anchor used by end
> >entities below CA2 is  not CA2 - it's CA1.  When CA1's key is discovered to
> >be compromised, what you do is:
> >
> >       1 - communicate out of band the compromise. This means that CA2 and all
> >entities below it are essentially "out of action" temporarily; since CA1 is
> >the trust anchor, there's no way to construct a valid cert path
> >
> >       2 - reconstitute CA1 with a new key;
> >
> >       3 - get CA2's key to CA1 for certification (most likely through
> >out-of-band means). Yes, this can still be the same key; since CA2's key
> >wasn't compromised, it can still be used, and it will make things easier in
> >that you don't have to go re-signing end-entity certs with a new CA2 key.
> >
> >Now, you're back in action.
> >
> >If you agree that this is right, we can figure out words that say that.
> >The point I wanted to convey is that the entire PKI is dead in this case
> >until CA1 is brought up and a new CA2 cert is signed, because you can't
> >construct a valid path back to a valid trust anchor.
> >
> >(Of course, if trust anchor's compromised key happens to be on all
> >end-entity hardware tokens in a form that can't easily be changed, you've
> >still got a problem, but that's beyond the scope of PKIX :-)
> >
> >                               Al Arsenault
> >
> >- the above opinions are my own.  They may or may not reflect the opinions
> >of my employer or of any other organization with which I have a relationship.
> >
> >
> >
> >
> >
> -------------------------------------------------------------------
> Stefan Santesson                <stefan@accurata.se>
> Accurata Systemsäkerhet AB
> Lotsgatan 27 D                  Tel. +46-40 152211
> 216 42  Malmö                   Fax. +46-40 150790
> Sweden                        Mobile +46-70 5247799
> 
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------