[tor-bugs] #17639 [Core Tor/Tor]: provide an option to display the expiry date of a given ed25519 signing key

Mon Jul 31 18:26:03 UTC 2017

#17639: provide an option to display the expiry date of a given ed25519 signing key
------------------------------------------------+--------------------------
 Reporter:  cypherpunks                         |          Owner:  isis
     Type:  enhancement                         |         Status:
                                                |  needs_review
 Priority:  High                                |      Milestone:  Tor:
                                                |  0.3.2.x-final
Component:  Core Tor/Tor                        |        Version:  Tor:
                                                |  0.2.7.2-alpha
 Severity:  Normal                              |     Resolution:
 Keywords:  tor-ed25519-proto, review-group-21  |  Actual Points:
Parent ID:                                      |         Points:  1
 Reviewer:  nickm                               |        Sponsor:
                                                |  SponsorM-can
------------------------------------------------+--------------------------
Changes (by isis):

 * status:  needs_revision => needs_review
 * sponsor:   => SponsorM-can

Comment:

 Replying to [comment:24 isis]:
 > Replying to [comment:23 nickm]:
 > > This looks comparatively solid to me!  A few things to consider as
 possibilities, though maybe they're not needed:
 > >
 > >  - Maybe this should printf() something to stdout, instead of using
 the log facility, and run at --quiet by default?
 >
 > Yes, this makes sense. TBH, I didn't know if I was allowed/encouraged to
 do printf(), since it seems like there's a lot of ways "interfaces" over
 stdin/stdout can be bad/broken/wrong, particularly when they are relied
 upon by other scripts/programs (cf. gnupg). I think it does make sense
 though to work even with --quiet, and in this case the user is asking a
 question like "hey parse this thing and tell me what it says", not
 intending any operation or for the binary to run as a daemon or anything
 more complicated, so it makes sense here.
 >
 > >  - Maybe the output format should be machine-readable?
 >
 > Yeah! But what should this look like?
 >
 > Literally just spit out the expiry in ISO8601 format? (With or without
 the underscore in between the date and the time?) Or some more easily
 machine parseable (but less human readable) format, like seconds-since-
 epoch?
 >
 > Should it be in the local timezone, or in UTC? (Probably UTC, right? if
 we expect scripts to be able to process it?)

 The above two are done in
 [https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug17639&id=6ba245f916e21ef3104d377cf3292f36e97c5e48
 commit] `6ba245f916e`.

 > >  - Maybe it should dump information about the installed authority auth
 key as well
 > >  - I wonder what it should do about hidden service keys?
 >
 > Yes, I can add these. I thought about the first one before, but I didn't
 know how to make the interface, plus had worries about the patch being
 large/invasive. I think the "proper" way to do it would be to add a
 suboptions parser so that the user could be like "--key-expiration auth"
 or "--key-expiration sign"; this way, it would more easily extendable to
 further changes in supported cert types moving forward.

 This is done in
 [https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug17639&id=7c2329c3eb22249cb68676b07bf2912c1ce58ff7
 commit] `7c2329c3eb`, or the suboptions parsing is, at least. I didn't add
 parsers for auth keys or onion service keys yet, because I don't really
 understand which key is the auth key ("dir-identity-key"?) and the
 following questions about OS keys:

 > I'm not sure what to do about onion service keys/certs at all. I imagine
 there are users with multiple hidden services. Frankly, I didn't even know
 OS keys/certs ''could'' expire. Is that just a v2 thing? Is there some
 canonical way to refer to an onion service such that I could provide some
 option like "--key-expiration specifier-for-my-onion-service"? Should I
 optionally take an onion service's address and learn the keys from the
 configured onion service directory?
 >
 > >  - Technically speaking, keys don't expire: certificates do. The user
 needs to replace both of them, not just one.
 >
 > Right. How should we communicate this to users? I'm not a UX person at
 all, but I can vaguely naïvely foresee confusion of like "but I was asking
 about my keys".  Should I change to the cmdline flag to --cert-expiration?

 For this, I kept the command line flag as "--key-expiration" but all the
 function/object names and documentation in the code uses "key certificate"
 or just "certificate" everywhere.
 ([https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug17639&id=d01793e2ee6c5212d9f4add22087a081893645ba
 Commit] `d01793e2ee`.)

 > >  - The buffer in log_ed_key_expiration() can probably just be stack-
 allocated.
 >
 > Yep, done in `cc2af48569`.
 >
 > >  - Documentation on the new option should go into the manpage
 >
 > Yeah… it would probably be the nice thing to do to tell operators how to
 use it. :) I will add this once we agree on what the commandline flags and
 output should be like.

 Done in
 [https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug17639&id=9e6aee990504a57bc92fd11e9c0fd1fe05db2401
 commit] `9e6aee99`.

 > > Please fix whatever from above you agree with. :)

 I also added tests and fixed some problems the tests caught in
 [https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug17639&id=9b82470a27aceb7a279fd910eed878180d43956e
 commit] `9b82470a27`.

 I made oniongit PR for review, if we want that!
 https://oniongit.eu/network/tor/merge_requests/3

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17639#comment:28>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online