search

dragonresearch / rpki.net

Dragon Research Labs rpki.net RPKI toolkit
53 stars 30 forks source link

Adding router certificates to rpkid et al #683

Closed sraustein closed 8 years ago

sraustein commented 10 years ago

Sketch for what will be involved in adding router certificates to rpkid et al.

IRDB:: New "ee-cert-request" object (may as well cover detached RSA EE certs we've talked about for years for things like S/MIME as long as we're at this). Exactly which attributes (other than SQL boilerplate) this needs still a bit hand-wavy, something like:

Trac ticket #671 component rpkid priority major, owner , created by sra on 2014-01-23T03:11:52Z, last modified 2016-08-05T15:45:14Z

sraustein commented 10 years ago

Left-right protocol::

New PDUs to allow rpkid to query IRDB for EE-cert-requests. Details to be determined once IRDB nailed down, but algorithm stuff is probably something like: {{{ element blah { .... ((attribute algorithm { "RSA" } attribute key_length { "2048" }) | (attribute algorithm { "EC" } attribute curve { "P255" })) .... } }}}

Maybe it is implied (or obvious), but will there be some field that associates the router cert with a particular ResourceHolderCA?

pubd:: Add support for publishing EE certs. May not really require anything, as these will be X.509v3 objects with .cer extensions, but by same token may need to be a little more careful in rpkid to make sure we're not assuming that all .cer objects are child certificates (which I think they are, at the moment).

The code that imports the rcynic XML also likely makes that assumption.

rtr-origin:: The name of this program is now wrong.

Might need to have some kind of command line option to control whether we offer router certs or not; I forget whether we bumped the version number when adding the new PDU, if we did then that's the same command line control. Not a big deal, just pick something.

rcynic-cron:: If we do add a new control option to rtr-origin for router-cert yes/no, rcynic-cron may have to know about it, and we may need some way to configure rcynic-cron on how to set it. So far we've avoided configuration files for rcynic-cron, but the subject has come up before, this may be what pushes us over the edge. If we do go for a config file, it'd probably just be an [rcynic-cron] section of rcynic.conf, no need for a new file.

Another option would be to make rtr-origin consult rcynic.conf, and rcynic-cron could check whether or not rtr-origin wants router certs. Single option that controls both?

Trac comment by melkins on 2014-01-23T20:00:47Z

sraustein commented 10 years ago

Left-right protocol::

Maybe it is implied (or obvious), but will there be some field that associates the router cert with a particular ResourceHolderCA?

I would have figured that out eventually, but, doh, thanks, good catch.

may need to be a little more careful in rpkid to make sure we're not assuming that all .cer objects are child certificates (which I think they are, at the moment).

The code that imports the rcynic XML also likely makes that assumption.

Hmm. You going to need some kind of marker in the XML to tell these cases apart? It's easy enough to tell if one has the objects themselves (you look at the basicConstraints extension) but there's nothing currently in the XML itself that would tell you.

rtr-origin:: Might need to have some kind of command line option to control whether we offer router certs or not

rcynic-cron:: If we do add a new control option to rtr-origin for router-cert yes/no, rcynic-cron may have to know about it, and we may need some way to configure rcynic-cron on how to set it.

Another option would be to make rtr-origin consult rcynic.conf, and rcynic-cron could check whether or not rtr-origin wants router certs.

Yeah, that's plausible. For various reasons, rtr-origin probably needs major refactoring at this point, roll that in as part of it.

Single option that controls both?

If it works out that way, sure.

Trac comment by sra on 2014-01-23T22:05:07Z

sraustein commented 10 years ago

IRDB and Left-Right also need to encode RFC 3779 resources that EE certificate needs; this will be in the PKCS !#10 in any case, could be broken out as well.

The IRDB requirements border on what the (G)UI will need from the user, although some bits may be filled in or generated by the (G)UI. Probably best to think of router certificates as a special case of the more general EE certificate request mechanism: in the general case, user uploads a PKCS !#10, while in the router certificate case, the user supplies the parameters the (G)UI needs to generate the PKCS !#10, but otherwise the code path is pretty much the same.

Trac comment by sra on 2014-01-23T22:22:41Z

sraustein commented 10 years ago

UI/ops question, primarily for Randy: Does (G)UI need to give operator explicit control of expiration dates of router certificates?

For child certificates, validity is (conceptually) determined by contractual relationship parent and child, we make validity interval explicit so that it can reflect contract renewal if necessary.

Router certificates are intra-organization, but installing on routers may require human intervention (or at least human oversight), so we can't just automatically update every N days and assume that all will be well. This suggests to me that validity interval should be explicit, although we probably want it to default to something we consider sane.

Fun question whether incrementally adding one more router certificate when one already has some should default to fixed validity interval from date of issue or should attempt to batch so that all router certificates owned by a single resource holder expire at the same time. If we assume a human-driven installation model, the latter might be preferable. Just talking about default here, so this is more about convenience than it is about correctness.

Don't think we need to worry about expiration date of parent certificates, either they'll reissue or they won't, trying to adjust expiration date of router EE certificate to track expiration date of issuing CA certificate seems unlikely to simplify anything and will just lead to insanity. Optimize for steady state operation, where bills get paid on time, CA certificates get renewed, and the human-visible thing we're trying to make easy is router certificate installation.

Sanity check?

Trac comment by sra on 2014-01-23T22:41:11Z

sraustein commented 10 years ago

In [changeset:"5644"]: {{{

!CommitTicketReference repository="" revision="5644"

Adding router certificate support looks complicated enough to require a branch. See #671. }}}

Trac comment by sra on 2014-01-24T20:52:44Z

sraustein commented 10 years ago

IRDB model is dependent on what we can stick in the PKCS !#10. Current router certificate profile is:

https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/

which tells us that the RFC 3779 resources do //not// go in the PKCS !#10 any more than they do for the up-down protocol, thus desired resources have to be carried outside the PKCS !#10 (somehow). I'm not sure this is the right choice, but it's what the doc says, so go with it for now.

Trac comment by sra on 2014-01-24T22:55:53Z

sraustein commented 10 years ago

IRDB model is dependent on what we can stick in the PKCS !#10. Current router certificate profile is:

https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-pki-profiles/

which tells us that the RFC 3779 resources do //not// go in the PKCS !#10 any more than they do for the up-down protocol, thus desired resources have to be carried outside the PKCS !#10 (somehow). I'm not sure this is the right choice, but it's what the doc says, so go with it for now.

Another question that comes to mind is that in the situation where a resource holder has multiple ASNs. At what point does the ASN get selected? If it is not in the PKCS !#10 request, is it something that is entered via the (G)UI at the time the PKCS !#10 request is imported into the IRDB? (This also means that the association between router cert and ResourceHolderCA needs an associated AS value in the IRDB).

Trac comment by melkins on 2014-01-25T00:52:19Z

sraustein commented 10 years ago

may need to be a little more careful in rpkid to make sure we're not assuming that all .cer objects are child certificates (which I think they are, at the moment).

The code that imports the rcynic XML also likely makes that assumption.

Hmm. You going to need some kind of marker in the XML to tell these cases apart? It's easy enough to tell if one has the objects themselves (you look at the basicConstraints extension) but there's nothing currently in the XML itself that would tell you.

I don't think we will need any marker in the XML itself. We will just need to modify rpki.rcynic.xml_output_iterator() so that it returns the proper rcynic_cert or rcynic_router_cert object. The GUI already needs to inspect the contents of the objects anyway, so peeking at the basicConstraints is fine.

Trac comment by melkins on 2014-01-25T00:55:53Z

sraustein commented 10 years ago

Another question that comes to mind is that in the situation where a resource holder has multiple ASNs. At what point does the ASN get selected? If it is not in the PKCS !#10 request, is it something that is entered via the (G)UI at the time the PKCS !#10 request is imported into the IRDB? (This also means that the association between router cert and ResourceHolderCA needs an associated AS value in the IRDB).

Yes, the ASN (or, more generally, the resources that the user would like to have certified) need to be specified in the (G)UI.

See [5645] for gory details of what I've done to the IRDB so far. This approach treats router certificates as a special case of a more general mechanism (discussed years ago but never implemented) for issuing freestanding (not bundled in CMS) RPKI EE certificates.

A simpler alternative approach would be to restrict all of this to router certificates, in which case we could probably get away with an IRDB RouterCertificateRequest class that just holds a single ASN. My suspicion is that most of the code on the rpkid side will be the same regardless of whether we're handling the general case or not.

Grotty details will likely end up hidden in Zookeeper methods.

Trac comment by sra on 2014-01-25T01:43:07Z

sraustein commented 10 years ago

[ finally catching up ]

UI/ops question, primarily for Randy: Does (G)UI need to give operator explicit control of expiration dates of router certificates?

can we finesse and not do this, at least for the moment?

note that we told folk that they could use exipry to deal with replay. but you can always revoke, i guess.

Router certificates are intra-organization, but installing on routers may require human intervention (or at least human oversight), so we can't just automatically update every N days and assume that all will be well.

bingo

the sad truth today is that bgp auth keys between two providers are almost never changed

This suggests to me that validity interval should be explicit, although we probably want it to default to something we consider sane.

if sane == very very long

Fun question whether incrementally adding one more router certificate when one already has some should default to fixed validity interval from date of issue or should attempt to batch so that all router certificates owned by a single resource holder expire at the same time.

wow! when the expiry day comes, can we take a picture? from far away. wearing very dark glasses.

If we assume a human-driven installation model, the latter might be preferable.

i would like to descend from a very long running asn cert. but the rirs control those.

trying to adjust expiration date of router EE certificate to track expiration date of issuing CA certificate seems unlikely to simplify anything and will just lead to insanity.

agree

the human-visible thing we're trying to make easy is router certificate installation.

this deserves discussion in a wider audience.

Trac comment by randy on 2014-01-26T14:27:39Z

sraustein commented 10 years ago

Another question that comes to mind is that in the situation where a resource holder has multiple ASNs.

with as aliasing, one router, with i presume one key, can have multiple asns. see draft-ga-idr-as-migration-03.txt. so i am not sure that the router cert is bound as tightly to one asn as we might think. though we very well might choose one seemingly arbitrarily.

At what point does the ASN get selected? If it is not in the PKCS !#10 request, is it something that is entered via the (G)UI at the time the PKCS !#10 request is imported into the IRDB? (This also means that the association between router cert and ResourceHolderCA needs an associated AS value in the IRDB).

i am trying to think about this from the gooey abuser's point of view.

in Operator-Generated Keys mode of draft-ymbk-bgpsec-rtr-keying, i choose one of my asns and tell the gooey that i need 42 router certs please. i hold a cup under the slot and 42 private keys drop out and i go shove them up routers.

in Router-Generated Keys mode of draft-ymbk-bgpsec-rtr-keying, i hand you 42 requests with public keys and tell you which asn 'signs' them. and i somehow find the router for each PKCS#7 to upload it.

i am trying to remember why the routerid (four byte number unique only within an operator's mess) is not in the router cert. i may be starting to regret this. so, these are 42 'unlabeled' certs, i.e. they have no real world association with any particular router.

and you tell me one is expiring and i have no frelling idea which of my O(10^3) routers has it.

hmmm. another item for discussion.

Trac comment by randy on 2014-01-26T15:04:13Z

sraustein commented 10 years ago

i am trying to remember why the routerid (four byte number unique only within an operator's mess) is not in the router cert. i may be starting to regret this. so, these are 42 'unlabeled' certs, i.e. they have no real world association with any particular router.

Section 3.1.1.1 of draft-ietf-sidr-bgpsec-pki-profiles says that certificate subject name should be in a stylized form that includes both the router-id and the (singular) AS number.

I don't know why we're using a subject name hack instead of adding an X.509v3 extension.

Trac comment by sra on 2014-01-26T16:50:49Z

sraustein commented 10 years ago

with as aliasing, one router, with i presume one key, can have multiple asns. see draft-ga-idr-as-migration-03.txt. so i am not sure that the router cert is bound as tightly to one asn as we might think. though we very well might choose one seemingly arbitrarily.

In such cases is there one ASN which would be the obvious "the ASN" when building a certificate subject name that includes exactly one ASN? Or are they all pretty much the same?

If the latter, we may need to take this back to the WG and change the text suggesting that router certificate names be of the form:

{{{

!python

"/commonName=ROUTER-%08x/serialNumber=%08x" % (asn, router_id) }}}

Trac comment by sra on 2014-01-27T17:09:27Z

sraustein commented 10 years ago

{{{

!python

"/commonName=ROUTER-%08x/serialNumber=%08x" % (asn, router_id) }}}

routers do not have serial numbers per se. cards change, chassis change. they do have RouterID, a unique within the provider four octet number.

Trac comment by randy on 2014-01-28T00:45:39Z

sraustein commented 10 years ago

routers do not have serial numbers per se. cards change, chassis change. they do have RouterID, a unique within the provider four octet number.

You're getting distracted by somebody else's terminology. serialNumber is an X.509 name attribute. The current specification for router certificates says to encode the router-id using that attribute; the fact that the name of the field is "serialNumber" has nothing to do with hypothetical serial numbers of routers.

But you didn't answer the question. Do you need me to repeat it?

Trac comment by sra on 2014-01-28T00:55:21Z

sraustein commented 10 years ago

when migrating from asn A to asn B, i am not sure there is an "obvious" one. when hiding asn B behind asn A, i guess A is the "obvious" one. but the question arises obvious to whom?

Trac comment by randy on 2014-01-28T02:24:58Z

sraustein commented 10 years ago

when migrating from asn A to asn B, i am not sure there is an "obvious" one. when hiding asn B behind asn A, i guess A is the "obvious" one. but the question arises obvious to whom?

So should we tell the WG that it would it be better to leave the ASN(s) out of the EE certificate subject name? The ASN(s) is(are) already present in the RFC 3779 extension, of course.

If we kept the rest of the current proposal, that would mean that router certificate subject names were of the form:

{{{

!python

"/commonName=ROUTER/serialNumber=%08x" % router_id }}}

so you would have straightforward (if rather silly) way of matching certificates up with routers by router-id.

Trac comment by sra on 2014-01-28T02:31:25Z

sraustein commented 10 years ago

matching by RouterID is not "silly." it's the only real handle you have [0]. you probably want one of the ASes too, in case i manage multiple universes where RouterID could be non-unique.

which AS you choose is not really that important. as you see below, the user will choose or specify one anyway.

in the case of operator generated keys, i suppose the user will hand the gui (or batch) a list of {AS,RouterID} and get back the private keys clearly labeled in some way that she can shove them up the appropriate routers.

in the case of router generated keys, the rpki would get (through the gooey or in batch) {AS,RouterID,PKCS#10} and hand back clearly labeled PKCS#7s.

the reason i say gooey or batch is that a small user may have just one router and just want to use a gui, and a large user may want to whack a thousand routers.

some day, the router and the rpki might deal directly!

[0] - btw, it is traditionally the ipv4 address of the primary loopback interface. but we think of it as an arbitraty four octet id because the router might have no ipv4 addresses, ipv6 only.

Trac comment by randy on 2014-01-28T02:53:07Z

sraustein commented 10 years ago

matching by RouterID is not "silly."

Was referring to hack of encoding router ID in the X.509 subject name.

you probably want one of the ASes too, in case i manage multiple universes where RouterID could be non-unique.

OK, that answers the question: text in current specification is OK.

Thanks!

Trac comment by sra on 2014-01-28T03:50:33Z

sraustein commented 10 years ago

matching by RouterID is not "silly." Was referring to hack of encoding router ID in the X.509 subject name.

not mine. i had AS and RouterID as plain data. some cert nut did the x.509 hackery.

randy

Trac comment by randy on 2014-01-28T04:12:52Z

sraustein commented 10 years ago

matching by RouterID is not "silly." Was referring to hack of encoding router ID in the X.509 subject name.

not mine. i had AS and RouterID as plain data. some cert nut did the x.509 hackery.

Still not communicating.

If we're going to be stuffing structured data into the subject name, the current encoding is as good as we're likely to get without more work than it's worth.

The thing I don't understand is why we're stuffing structured data into the subject name rather than defining an X.509v3 extension to carry the router ID. Encoding structured data in the subject name is kind of like embedding preprocessor directives in comments, a trick we've all seen before (and we know how it ends, when more than one clever person is playing the same game with the same comments and different preprocessors...).

But I don't care all that much. I did need to know whether the current specification is actually wrong as far as your expected usage goes, but you already answered that.

Trac comment by sra on 2014-01-28T04:46:28Z

sraustein commented 10 years ago

matching by RouterID is not "silly." Was referring to hack of encoding router ID in the X.509 subject name. not mine. i had AS and RouterID as plain data. some cert nut did the x.509 hackery. Still not communicating.

i understand you. i suspect you may not be understanding me,

The thing I don't understand is why we're stuffing structured data into the subject name rather than defining an X.509v3 extension to carry the router ID.

because that is what sean chose. so fix it.

Trac comment by randy on 2014-01-28T08:51:50Z

sraustein commented 10 years ago

i understand you. i suspect you may not be understanding me,

You mean the part where I said "But I don't care that much" and the rathole thread that spun off the side of me asking you about something else still staggered on through the night in ghostly torment?

You're right, I don't understand that part. :)

Trac comment by sra on 2014-01-28T15:39:18Z

sraustein commented 10 years ago

So, at least as currently specified, neither the ASN(s) nor the router-id are included in the PKCS !#10 request, so we need to ship them around separately. That's OK, but has implications for user interface.

For the moment, I'm going to assume that we're using some kind of XML wrapper containing things like router-id and ASN(s) as XML attributes and the PKCS !#10 as Base64-encoded DER in an XML element.

This is a bit clunky, but at least has the advantage of consistency with the way we handle other multi-part things like OOB setup protocol objects.

This in turn has implications for what the command line interface for router certificates is likely to be: you have to whack them individually, no CSV file listing the complete intended state. No obvious way to avoid this that doesn't have worse side effects (eg: rolling the clock all the way back to before we had the OOB setup protocol and you had to coordinate entries in a CSV file with .pem files in a directory ... no thanks).

Holler if any objections or if you think you see a better way.

Trac comment by sra on 2014-01-29T23:38:46Z

sraustein commented 10 years ago

if we can't squeeze the PKCS#10 into a csv field, i see no magic.

Trac comment by randy on 2014-01-29T23:48:54Z

sraustein commented 10 years ago

if we can't squeeze the PKCS#10 into a csv field, i see no magic.

"Squeeze" may indeed be the appropriate word here.

Typical Base64-DER PKCS !#10 is one or two kbytes. Quick test with gzip, bzip2, and xz suggests that compression doesn't buy enough to be worth the trouble.

So one //could// put the PKCS !#10 into a CSV, but it would be significantly less human readable than the other ones we use.

This is not necessarily a problem, unless we think that human beings are going to be assembling these by hand. If we assume that a program will be doing it, sure, why not?

So, serious question, do we need these to be something a human can work with or is this just an interchange format? If the latter, CSV might be a better answer than XML, since it would let us put the whole set in a single file, deal with it as an atomic SQL transaction, etc.

Trac comment by sra on 2014-01-30T00:34:34Z

sraustein commented 10 years ago

Of course, if we just want some way to do the whole batch as a single file, we can do that in XML as easily as in CSV, we just allow multiple elements.

Six of one, half a dozen of the other, mostly, but XML has things like namespaces and element names that make it a bit easier to figure out when one has fed a file to the wrong command, so on the whole XML is probably safer for the user.

Trac comment by sra on 2014-01-30T00:41:38Z

sraustein commented 10 years ago

i am trying to see the operational chain from asking a thousand routers to generate keys and hand over their xml-wrapped pkcs#10 requests to telling rpki about this.

what i am seeing is some tool collecting the pkcs#10 requests in a directory, somehow each one being tagged with asn/routerid, and then handing it to rpki processing.

Trac comment by randy on 2014-01-30T00:43:53Z

sraustein commented 10 years ago

what i am seeing is some tool collecting the pkcs#10 requests in a directory, somehow each one being tagged with asn/routerid, and then handing it to rpki processing.

Yep. If I recall correctly, when we discussed this in Reston, our theory was that the router frobbing would likely be handled by some tool that did expect-over-ssh on the router CLI (or NETCONF, if anybody actually uses that). So Base64-encoded PKCS #8 and PKCS #10 flying about on that end, and a tool driving it, with the ability for a human to do it via cut-and-paste if absolutely necessary.

Said tool would also be responsible for pushing private keys (more Base64-encoded PKCS #8) into routers in cases where the router is not generating the keys itself.

This model probably fits better with a directory of .xml files than it does with a single monolithic file (XML or CSV, doesn't matter).

Unclear yet whether there might end up being some purpose in standardizing the XML format. Seems likely but too early to tell.

Trac comment by sra on 2014-01-30T01:04:22Z

sraustein commented 10 years ago

Preliminary router certificate support seems to be working. Not all tools support it yet, still some rough edges, not heavily tested, YMMV, ....

One current bit of confusion has to do with subject names. Current EE certificate code gets them from PKCS !#10, which is wrong. Need to whack left-right <list_ee_certificate_request/> to have attributes for requested CN, requested SN, and requested EKU (last would be comma-separated numeric OIDs, in an attempt to keep this simple). This would give the generality we want without making things any worse than they are now, I think, and we could remove the router_id field from left-right and IRDB without losing anything we care about. I think.

We may end up with some of the checks on what is and is not legal form depending on the EKU (router cert EKU means router cert rules, etc), but that seems fair, that's kind of what EKU is about.

Big task still to do: upgrade script. Lots of SQL changes, this is not going to be a drop-in replacement without a conversion script to make things right. Pity we're not using Django ORM and South for everything; I'm almost tempted to force that conversion to avoid ever having to look at an upgrade mess like this again, but not sure it's worth it.

Trac comment by sra on 2014-02-21T02:36:47Z

sraustein commented 10 years ago

One current bit of confusion has to do with subject names. Current EE certificate code gets them from PKCS !#10, which is wrong.

[[https://mailarchive.ietf.org/arch/msg/sidr/u-RKTcP9hACwhuAlBCiDEHxah7w|As noted just now on the SIDR list]], it's more complicated than this: the current specs conflict on whether the router-id goes in the PKCS !#10 or not. This may have to wait for WG discussion.

Trac comment by sra on 2014-02-21T23:48:23Z

sraustein commented 10 years ago

Only reply from WG so far is from Steve Kent, who says having name in PKCS !#10 is probably a mistake. In the interest of moving forward, will go ahead with change described above and see where that takes us.

Trac comment by sra on 2014-02-25T17:47:40Z

sraustein commented 10 years ago

gambatte

Trac comment by randy on 2014-02-25T20:21:04Z

sraustein commented 10 years ago

[5683] added what look like valid router certificates to me; as of [5685] they are using the proper EKU OID.

[5687] adds RP support for router certificates and tightens up checking: we now require the right OID in the EKU before accepting an RPKI EE certificate with an ECDSA key, and we don't whine about the missing SIA extension when we know it's a router certificate. There are probably other checks we should be performing in the router certificate case (eg, no RFC 3779 IP addresses, just ASNs), but, still, progress.

Trac comment by sra on 2014-02-26T23:34:53Z

sraustein commented 10 years ago

In [changeset:"5708"]: {{{

!CommitTicketReference repository="" revision="5708"

First cut at rpki-sql-upgrade script. See #671. }}}

Trac comment by sra on 2014-03-28T15:42:30Z

sraustein commented 10 years ago

Hmm, might want to merge rpki-sql-update into rpki-sql-setup so that the merged program can set up the upgrade_version table correctly when creating the database from scratch.

Trac comment by sra on 2014-03-29T04:40:40Z

sraustein commented 10 years ago

In [changeset:"5716"]: {{{

!CommitTicketReference repository="" revision="5716"

Merge rpki-sql-upgrade into rpki-sql-setup. See #671. }}}

Trac comment by sra on 2014-03-29T22:05:44Z

sraustein commented 10 years ago

(In #479) Change [5678] made #671 dependent on #479. Current branch for #671 includes basic SQL upgrade facility, but has not done anything about code which must be executed while daemons are running.

Not (yet) sure what to do about that one; complicated by different platform expectations as to whether installing package will start daemons (Debian/Ubuntu package: yes; FreeBSD port or source build: no).

This may turn out to be complicated enough that it's not worth trying to automate, just tell existing users to run magic script after upgrade. Don't much like that answer. Would be easier if there were some SQL change we could make that would quietly tell daemons to do whatever is necessary. Hmm. Bit of a kludge, but put a table in irdbd which is only used by stupid external daemons-must-be-running upgrade scripts like this, and maybe hook into rpki-start-servers to run upgrade actions once after starting daemons? Icky, but might work. Needs thought. Better than putting one-shot upgrade code into daemons themselves....

Trac comment by sra on 2014-03-30T04:33:55Z

sraustein commented 10 years ago

In [changeset:"5718"]: {{{

!CommitTicketReference repository="" revision="5718"

Add rpki-sql-setup --apply-deferred-updates to support migrations which can't be executed until the daemons are up. See #671. }}}

Trac comment by sra on 2014-03-30T21:29:14Z

sraustein commented 10 years ago

Taking a step back, current status of router certs (original subject of this ticket and branch):

CA engine:: Not "done", exactly, but probably done enough to merge to trunk.

CA GUI:: Not touched. Up to Michael whether needs to done before merge to trunk or can be separate.

RP rcynic:: Done enough to merge to trunk.

RP rpki-rtr:: Not touched. Unclear whether needs to be done before merge to trunk.

So rpki-rtr (the increasingly-inaccurately-named rtr-origin program) is my next sub-project. Not obvious to me that this needs to be done before merging current work to trunk, as I'm pretty sure current rpki-rtr code will just ignore router certificates.

Trac comment by sra on 2014-04-04T02:19:00Z

sraustein commented 10 years ago

On Fri, Apr 04, 2014 at 02:19:00AM -0000, Trac Ticket System wrote:

CA GUI:: Not touched. Up to Michael whether needs to done before merge to trunk or can be separate.

This work can be done in a separate branch after the merge. None of the changes should break any of the GUI.

Trac comment by melkins on 2014-04-04T16:36:27Z

sraustein commented 10 years ago

On Fri, Apr 04, 2014 at 04:36:27PM -0000, Trac Ticket System wrote:

This work can be done in a separate branch after the merge. None of the changes should break any of the GUI.

Thinking about this some more, it appears that router certs will (initially) be indistinguisable from resource certs in the rcynic XML output? So the GUI will register those router certs as resource certs in its internal db. Still, this shouldn't present a problem, because other than the RPKI cache browser, the resource cert entries are not consulted during normal GUI operation. Likely, we'd want to augment rpki.rcynic.rcynic_cert to add some data to the to note router certs vs resource certs.

Trac comment by melkins on 2014-04-04T17:42:58Z

sraustein commented 10 years ago

Thinking about this some more, it appears that router certs will (initially) be indistinguisable from resource certs in the rcynic XML output?

In the current XML, yes. You'd need to look at the DER object to tell the difference. Not hard to tell when looking at the parsed ASN.1: among other things, router certs have an X.509v3 Extended Key Usage extension containing a particular OID marking them as router certs. But that doesn't show up in the XML.

So the GUI will register those router certs as resource certs in its internal db. Still, this shouldn't present a problem, because other than the RPKI cache browser, the resource cert entries are not consulted during normal GUI operation. Likely, we'd want to augment rpki.rcynic.rcynic_cert to add some data to the to note router certs vs resource certs.

Add this to rpki.rcynic.rcynic_certificate.__init__():

{{{ self.eku = self.obj.get_EKU() }}}

then add this method to the class:

{{{ @property def is_router_cert(self): return rpki.oids.id_kp_bgpsec_router in (self.eku or ()) }}}

Or something like that.

Trac comment by sra on 2014-04-04T23:59:31Z

sraustein commented 10 years ago

OK, this ticket and branch may be approaching completion.

[5750] added preliminary rpki-rtr support. It won't work without the CA tools installed, because I was trying to sail between two very hairy yaks. This problem will go away when we address the package restructuring issue that lurks beneath the surface of #633..

[5751] completes the basic set of rpkic commands needed to manage router certificate requests, at least in their present form (but keep an eye on the SIDR WG...). At the moment the only things that knows how to generate these requests are test programs (smoketest and yamltest); current theory says that eventually there will be a small separate tool (or tools) for generating these based on conversations with routers about keys and PKCS !#10 requests.

Anyway, I think we're approaching the point of trying to merge this into trunk/. Do we have any workshops coming up that we'd break if this goes pear shaped?

Trac comment by sra on 2014-04-05T04:11:29Z

sraustein commented 10 years ago

Anyway, I think we're approaching the point of trying to merge this into trunk/. Do we have any workshops coming up that we'd break if this goes pear shaped?

next i have is late may, afnog

Trac comment by randy on 2014-04-05T07:30:28Z

sraustein commented 10 years ago

In [changeset:"5753"]: {{{

!CommitTicketReference repository="" revision="5753"

Merge tk671 (router certificate support) back to trunk. See #671. }}}

Trac comment by sra on 2014-04-05T19:24:27Z

sraustein commented 8 years ago

Long since done

Trac comment by sra on 2016-08-05T15:45:14Z

sraustein commented 8 years ago

Closed with resolution fixed