Re: [Rescert] Notes from RPKI security review

[Rob Austein <sra@hactrn.net>]

At Tue, 19 Jun 2007 14:14:17 -1000, Randy Bush wrote:
> 
> >> The CMS certs are the "Business" certs that are exchanged as part of the
> >> establishement of a business relationship between the parent and child.
> >>
> >> Can you elaborate on the TLS certs here?
> > 
> > They might come from the same business PKI that generated the CMS, or
> > might not.  There's been a bit of follow-up discussion between me,
> > Randy, and the security guys since NANOG on a few issues around TLS
> > certs, this is one of them.
> 
> the cms certs are between the two *IRs which have an allocation business
> relationship.  the tls certs are between two rpki service hosting
> providers, who contracted to provide rpki services to the two *IRs.

Hmm.  Not where I thought the conversation two weeks ago was going,
but perfectly reasonable.  Ok, take two.

Your analysis of the trust relationships above sounds right.

I now plead ignorance on how we're managing the TLS certs, but no
doubt we'll think of something.

> > Note that the security guys told us to use TLS client certificates
> > too, which is one of the reasons why I think we really might want the
> > TLS certificates to tie into the same business PKI as the CMS
> > certificates.
> 
> may not be able to.  see above and add restriction of one cert per
> server (alt names are wobbly in my experience).

I've been using subjectAltName heavily for several years now and have
seen no problems.  Doesn't make you wrong, but OpenSSL and Apache
clearly can deal with it and I was assuming we'd support it in our
client and server code.

> > Also note that we don't currently say anything about CRLs in the
> > business PKI universe.
> 
> not our business.  can't have parent reaching through child's irbe to
> biz key back end to check a crl.  irbes should check crls for the biz
> certs in their back ends, innuendo intended.

Mumble.  Agree about not reaching through somebody else's IRBE.  Had
been thinking of publishing CRLs via HTTP in some boring fashion, but
that has potential network partition issues.  I suspect you're right
but it seems a bit lame somehow.