Subject: [sidr] draft-huston-rpki-validation-00.txt

From: Randy Bush <[email-masked]>
Date: Thu, 12 Sep 2013 09:09:13 -1000

geoff and george,

i am trying to understand $subject, and need some help.  it seems the
key motivation is that, in a transfer,

   If the original registry's certification actions are simply to issue
   a new certificate for the current holder with a reduced resource set,
   and to revoke the original certificate, then there is a distinct
   possibility of encountering the situation illustrated by the example
   in the previous section.  This is a result of an operational process
   for certificate issuance by the parent CA being de-coupled from the
   certificate operations of child CA.

i.e. the operational problem you fear is that a parent CA shrinking a
child's certificate will not cause the child's CA to shrink subordinate
certificates it has issued, and so on down the tree.

but would this not be a spec violation and hence a bug?  is it worth
whacking validation so heavily to whitewash this corner case when good
code and ops practice should prevent it?  

this would be a *really big* change to validation, so had best be really
worthwhile.  

otoh, at breakfast a few weeks ago, i thought you, gih, said that this
hack might make alternate views, aka LTA, much easier.  if so, i might
be much more tempted.  if i did not mis-hear, could you expand?

thanks.

randy

---

From: "Murphy, Sandra" <[email-masked]>
Date: Thu, 12 Sep 2013 21:40:33 +0000

Speaking as regular ol' member

>i am trying to understand $subject, and need some help.  it seems the

I also don't fully grasp the problem or the solution, and so of course I don't quite grasp how the solution solves the problem.

So I would also like some help in understanding.

>certificates it has issued, and so on down the tree.

I don't quite follow this statement.  I didn't think causality was the problem, but lack of synchronization, lack of concurrence in time.

In the case of transfer, the child CA is an aware and willing participant. Yes?  So child CA could take the action to request the parent split its CA cert into two CA certs and avoid the problem that way.  No?  But like I said, I don't quite grasp the problem.

--Sandy, speaking as regular ol' member
________________________________________

---

From: Geoff Huston <[email-masked]>
Date: Fri, 13 Sep 2013 10:08:15 +1000

> be much more tempted.  if i did not mis-hear, could you expand?

The problem is that when a CA is compelled to remove a resource from
a certificate (be it a court order, pressure from some agency, or fat
fingers, or any other reason), the all the subordinate certificates 
that include the removed resource are henceforth invalid. And thats not
just invalid for the resource that was removed - thats ALL resources
in these subordinate certificate that include the removed resource.

Trying to create workarounds that allow relying parties to patch up
this are messy, and are reliant on these relying parties being aware
of the problem and ready and willing to go to some considerable lengths
to generate local material that would validate these otherwise invalid
certificates.

The alternate approach is to alter the validity consideration as per
the draft. In this case when the CA issues its shrunken resource set
all the subordinate certificates from this CA remain valid in the context
of all resources other than the removed resource. Which means that
subordinate CAs are not compelled to re-issue certificates in order
to protect the validity of their signed products. This is a big win imho.

Secondly, the workaround by relying parties need only be concerned with
the production of local trust material for the resource that has
been removed. Nothing more. This makes the workaround process a lot easier,
as a relying party can generate a local TA that references just the
disputed resource and acts as a TA for the certificate that would otherwise
be considered invalid _for this disputed resource_.

Obviously I could expand more, but I hope that is a decent explanation
of what I was saying at the time

regards,

   Geoff