Re: Forcing RPKI revoke/rekey in left-right protocol

[Rob Austein <sra@hactrn.net>]

At Tue, 17 Apr 2007 21:22:22 -0400, Tim Christensen wrote:
> 
> Why is there a <parent> 1:n <ca> relationship?  Because this instance
> of the RE holds 1-to-N <ca>s for a <self>'s <parent>?  Seems
> to me the PARENT holds the <ca> in their RE, and what <self>
> has from the <parent>(s) is/are <cert>(s), tied to the keypairs
> that <self> holds for itself. (and in the special case of an RIR,
> the <self> holds these, only difference being that the cert is
> anchored by a TA that is a URL+public key.)

For everybody but the top level, each <self> has one or more
<parent>s.  Each <parent> may issue zero or more classes (nee genres)
to this <self>.  So relationships are <self> 1:n <parent> 1:n <ca>.

> What makes more sense to me is that the 1:N line from <parent>
> to <ca> evaporates, but <parent> now needs a home to place
> 1 to N 3779 certs/keypairs.

<ca-keypair>s hang off of <ca>s because one can replace the
<ca-keypair> without changing the conceptual relationship between the
<ca> and the objects it has signed.

> If the intention was to overload the <ca> object with a non-ca
> for the case of the parent (so as to have an object hierarchy
> that you can store the cert(s) from the parent, the associated
> pub/priv keypairs) then it can work, but the model is confusing
> to me.
> 
> A separate object to represent the parent-issued 3779 cert and
> its attendant hangers-on seems to be in order?

A <ca> in this model always represents the data associated with a CA
the certificate for which was issued by some <parent> of this <self>.
The <ca-keypair> is separate from the <ca> for reasons stated above.

In other words, I think the combination of the <ca> object and the
<ca-keypair> object already are the parent-issued thing you think we
need.  Perhaps I'm missing something?