Reflow proposals 233, 234.
[torspec.git] / proposals / 220-ecc-id-keys.txt
1 Filename: 220-ecc-id-keys.txt
2 Title: Migrate server identity keys to Ed25519
3 Authors: Nick Mathewson
4 Created: 12 August 2013
5 Target: 0.2.x.x
6 Status: Draft
7
8    [Note: This is a draft proposal; I've probably made some important
9    mistakes, and there are parts that need more thinking.  I'm
10    publishing it now so that we can do the thinking together.]
11
12 0. Introduction
13
14    In current Tor designs, router identity keys are limited to
15    1024-bit RSA keys.
16
17    Clearly, that should change, because RSA doesn't represent a good
18    performance-security tradeoff nowadays, and because 1024-bit RSA is
19    just plain too short.
20
21    We've already got an improved circuit extension handshake protocol
22    that uses curve25519 in place of RSA1024, and we're using (where
23    supported) P256 ECDHE in our TLS handshakes, but there are more uses
24    of RSA1024 to replace, including:
25
26       * Router identity keys
27       * TLS link keys
28       * Hidden service keys
29
30    This proposal describes how we'll migrate away from using 1024-bit
31    RSA in the first two, since they're tightly coupled.  Hidden service
32    crypto changes will be complex, and will merit their own proposal.
33
34    In this proposal, we'll also (incidentally) be extirpating a number
35    of SHA1 usages.
36
37 1. Overview
38
39    When this proposal is implemented, every router will have an Ed25519
40    identity key in addition to its current RSA1024 public key.
41
42    Ed25519 (specifically, Ed25519-SHA-512 as described and specified at
43    http://ed25519.cr.yp.to/) is a desirable choice here: it's secure,
44    fast, has small keys and small signatures, is bulletproof in several
45    important ways, and supports fast batch verification. (It isn't quite
46    as fast as RSA1024 when it comes to public key operations, since RSA
47    gets to take advantage of small exponents when generating public
48    keys.)
49
50    (For reference: In Ed25519 public keys are 32 bytes long, private keys
51    are 64 bytes long, and signatures are 64 bytes long.)
52
53    To mirror the way that authority identity keys work, we'll fully
54    support keeping Ed25519 identity keys offline; they'll be used to
55    sign long-ish term signing keys, which in turn will do all of the
56    heavy lifting.  A signing key will get used to sign the things that
57    RSA1024 identity keys currently sign.
58
59 1.1. 'Personalized' signatures
60
61    Each of the keys introduced here is used to sign more than one kind
62    of document. While these documents should be unambiguous, I'm going
63    to forward-proof the signatures by specifying each signature to be
64    generated, not on the document itself, but on the document prefixed
65    with some distinguishing string.
66
67 2. Certificates and Router descriptors.
68
69 2.1. Certificates
70
71    When generating a signing key, we also generate a certificate for it.
72    Unlike the certificates for authorities' signing keys, these
73    certificates need to be sent around frequently, in significant
74    numbers.  So we'll choose a compact representation.
75
76          VERSION         [1 Byte]
77          CERT_TYPE       [1 Byte]
78          EXPIRATION_DATE [3 Bytes]
79          CERT_KEY_TYPE   [1 byte]
80          CERTIFIED_KEY   [32 Bytes]
81          EXTENSIONS      [variable length, up to length of certificate
82                           minus 64 bytes.]
83          SIGNATURE       [64 Bytes]
84
85    The "VERSION" field holds the value [01].  The "CERT_TYPE" field
86    holds a value depending on the type of certificate. (See appendix
87    A.1.) The CERTIFIED_KEY field is an Ed25519 public key if
88    CERT_KEY_TYPE is [01], or a SHA256 hash of some other key type
89    depending on the value of CERT_KEY_TYPE. The EXPIRATION_DATE is a
90    date, given in HOURS since the epoch, after which this
91    certificate isn't valid. (A three-byte field here will work fine
92    until 5797 A.D.)
93
94    The EXTENSIONS field contains zero or more extensions, each of
95    the format:
96
97          ExtLength [1 or 2 bytes]
98          ExtType   [1 or 2 bytes]
99          ExtData   [Length bytes]
100
101    The ExtLength and ExtType fields can represent values between 0
102    and 2^15-1, representing values under 128 as "0xxxxxxx" and
103    values over 128 as "1xxxxxxx yyyyyyyy".  The meaning of the
104    ExtData field in an extension is type-dependent.
105
106    It is an error for an extension to be truncated; such a
107    certificate is invalid.
108
109    Before processing any certificate, parties MUST know which
110    identity key it is supposed to be signed by, and then check the
111    signature.  The signature is formed by signing the first N-64
112    bytes of the certificate prefixed with the string "Tor node
113    signing key certificate v1".
114
115 2.2. Basic extensions
116
117 2.2.1. Signed-with-ed25519-key extension [type 04]
118
119    In several places, it's desirable to bundle the key signing a
120    certificate along with the certificate.  We do so with this
121    extension.
122
123         ExtLength = 32
124         ExtData =
125            An ed25519 key    [32 bytes]
126
127    When this extension is present, it MUST match the key used to
128    sign the certificate.
129
130 2.3. Revoking keys.
131
132    We also specify a revocation document for revoking a signing key or an
133    identity key.  Its format is:
134          FIXED_PREFIX    [8 Bytes]
135          VERSION         [1 Byte]
136          KEYTYPE         [1 Byte]
137          IDENTITY_KEY    [32 Bytes]
138          REVOKED_KEY     [32 Bytes]
139          PUBLISHED       [8 Bytes]
140          REV_EXTENSIONS  [variable length, up to length of revocation
141                           document minus 64 bytes]
142          SIGNATURE       [64 Bytes]
143
144    FIXED_PREFIX is "REVOKEID" or "REVOKESK". VERSION is [01]. KEYTYPE is
145    [01] for revoking a signing key or [02] for revoking an identity key.
146    REVOKED_KEY is the key being revoked; IDENTITY_KEY is the node's
147    Ed25519 identity key. PUBLISHED is the time that the document was
148    generated, in seconds since the epoch. REV_EXTENSIONS is left for a
149    future version of this document.  The SIGNATURE is generated with
150    the same key as in IDENTITY_KEY, and covers the entire revocation,
151    prefixed with "Tor key revocation v1".
152
153    Using these revocation documents is left for a later specification.
154
155 2.4. Managing keys
156
157    By default, we can keep the easy-to-setup key management properties
158    that Tor has now, so that node operators aren't required to have
159    offline public keys:
160
161         * When a Tor node starts up with no Ed25519 identity keys, it
162           generates a new identity keypair.
163         * When a Tor node has an Ed25519 identity keypair, and it has
164           no signing key, or its signing key is going to expire within
165           the next 48 hours, it generates a new signing key to last
166           30 days.
167
168    But we also support offline identity keys:
169
170         * When a Tor node starts with an Ed25519 public identity key
171           but no private identity key, it checks whether it has
172           a currently valid certified signing keypair.  If it does,
173           it starts.  Otherwise, it refuses to start.
174         * If a Tor node's signing key is going to expire soon, it starts
175           warning the user.  If it is expired, then the node shuts down.
176
177 2.5. Router descriptors
178
179    We specify the following element that may appear at most once in
180    each router descriptor:
181       "identity-ed25519" SP certificate NL
182
183    The identity-key and certificate are base64-encoded with
184    terminating =s removed.  When this element is present, it MUST appear
185    as the first or second element in the router descriptor.
186    [XXX The rationale here is to allow extracting the identity key and
187    signing key and checking the signature before fully parsing the rest
188    of the document. -NM]
189
190    The certificate has CERT_TYPE of [04].  It must include a
191    signed-with-ed25519-key extension (see section 2.2.1), so that we
192    can extract the identity key.
193
194    When an identity-ed25519 element is present, there must also be a
195    "router-signature-ed25519" element.  It MUST be the next-to-last
196    element in the descriptor, appearing immediately before the RSA
197    signature.  It MUST contain an ed25519 signature of the entire
198    document, from the first character up to but not including the
199    "router-signature-ed25519" element, prefixed with the string "Tor
200    router descriptor signature v1".  Its format is:
201
202       "router-signature-ed25519" SP signature NL
203
204    Where 'signature' is encoded in base64 with terminating =s removed.
205
206    The signing key in the certificate MUST
207    be the one used to sign the document.
208
209    Note that these keys cross-certify as follows: the ed25519 identity
210    key signs the ed25519 signing key in the certificate.  The ed25519
211    signing key signs itself and the ed25519 identity key and the RSA
212    identity key as part of signing the descriptor.  And the RSA identity
213    key also signs all three keys as part of signing the descriptor.
214
215
216 2.5.1. Checking descriptor signatures.
217
218    Current versions of Tor will handle these new formats by ignoring the
219    new fields, and not checking any ed25519 information.
220
221    New versions of Tor will have a flag that tells them whether to check
222    ed25519 information.  When it is set, they must check:
223
224       * All RSA information and signatures that Tor implementations
225         currently check.
226       * If the identity-ed25519 line is present, it must be well-formed,
227         and the certificate must be well-formed and correctly signed,
228         and there must be a valid router-signature-ed25519 signature.
229       * If we require an ed25519 key for this node (see 3.1 below), the
230         ed25519 key must be present.
231
232    Authorities and directory caches will have this flag always-on.  For
233    clients, it will be controlled by a torrc option and consensus
234    option, to be set to "always-on" in the future once enough clients
235    support it.
236
237 2.5.2. Extra-info documents
238
239    Extra-info documents now include "identity-ed25519" and
240    "router-signature-ed25519" fields in the same positions in which they
241    appear in router descriptors.
242
243    Additionally, we add the base64-encoded, =-stripped SHA256 digest of
244    a node's extra-info document field to the extra-info-digest line in
245    the router descriptor. (All versions of Tor that recognize this line
246    allow an extra field there.)
247
248 2.5.3. A note on signature verification
249
250    Here and elsewhere, we're receiving a certificate and a document
251    signed with the key certified by that certificate in the same step.
252    This is a fine time to use the batch signature checking capability of
253    Ed25519, so that we can check both signatures at once without (much)
254    additional overhead over checking a single signature.
255
256 3. Consensus documents and authority operation
257
258 3.1. Handling router identity at the authority
259
260    When receiving router descriptors, authorities must track mappings
261    between RSA and Ed25519 keys.
262
263    Rule 1: Once an authority has seen an Ed25519 identity key and an RSA
264    identity key together on the same (valid) descriptor, it should no
265    longer accept any descriptor signed by that RSA key with a different
266    Ed25519 key, or that Ed25519 key with a different RSA key.
267
268    Rule 2: Once an authority has seen an Ed25519 identity key and an RSA
269    identity key on the same descriptor, it should no longer accept any
270    descriptor signed by that RSA key unless it also has that Ed25519
271    key.
272
273
274    These rules together should enforce the property that, even if an
275    attacker manages to steal or factor a node's RSA identity key, the
276    attacker can't impersonate that node to the authorities, even when
277    that node is identified by its RSA key.
278
279
280    Enforcement of Rule 1 should be advisory-only for a little while (a
281    release or two) while node operators get experience having Ed25519
282    keys, in case there are any bugs that cause or force identity key
283    replacement.  Enforcement of Rule 2 should be advisory-only for
284    little while, so that node operators can try 0.2.5 but downgrade to
285    0.2.4 without being de-listed from the consensus.
286
287
288    [XXX I could specify a way to do a signed "I'm downgrading for a
289    while!" statement, and kludge some code back into 0.2.4.x to better
290    support that?]
291
292 3.2. Formats
293
294    Vote and microdescriptor documents now contain an optional "id"
295    field for each routerstatus section.  Its format is:
296
297        "id" SP "ed25519" SP ed25519-identity NL
298
299    where ed25519-identity is base64-encoded, with trailing = characters
300    omitted.  In vote documents, it may be replaced by the format:
301
302        "id" SP "ed25519" SP "none" NL
303
304    which indicates that the node does not have an ed25519 identity.  (In
305    a microdescriptor, a lack of "id" line means that the node has no ed25519
306    identity.)
307
308    [XXXX Should the id entries in consensuses go into microdescriptors
309      instead? I think perhaps so. -NM]
310
311    A vote or consensus document is ill-formed if it includes the same
312    ed25519 identity key twice.
313
314 3.3. Generating votes
315
316    An authority should pick which descriptor to choose for a node as
317    before, and include the ed25519 identity key for the descriptor if
318    it's present.
319
320    As a transition, before Rule 1 and Rule 2 in 3.1 are fully enforced,
321    authorities need a way to deal with the possibility that there might
322    be two nodes with the same ed25519 key but different RSA keys.  In
323    that case, it votes for the one with the most recent publication
324    date.
325
326    (The existing rules already prevent an authority from voting for two
327    servers with the same RSA identity key.)
328
329 3.4. Generating a consensus from votes
330
331    This proposal requires a new consensus vote method.  When we deploy
332    it, we'll pick the next available vote method in sequence to use for
333    this.
334
335    When the new consensus method is in use, we must choose nodes first
336    by ECC key, then by RSA key.
337
338    First, for every {ECC identity key, RSA identity key} pair listed by
339    over half of the voting authorities, list it, unless some other RSA
340    identity key digest is listed more popularly for the ECC key.  Break
341    ties in favor of low RSA digests. Treat all routerstatus entries that
342    mention this <ECC,RSA> pair as being for the same router, and all
343    routerstatus entries that mention the same RSA key with an
344    unspecified ECC key as being for the same router.
345
346    Then, for every node that has previously not been listed, perform the
347    current routerstatus algorithm: listing a node if it has been listed
348    by at least N/2 voting authorities, and treating all routerstatuses
349    containing the same identity as the same router.
350
351    In other words:
352
353      Let Entries = []
354
355      for each ECC ID listed by any voter:
356         Find the RSA key associated with that ECC ID by the most voters,
357         breaking ties in favor of low RSA keys.
358
359         If that ECC ID and RSA key ID are listed by > N/2 voting authorities:
360             Add the consensus of the routerstatus entries for those
361             voters, along with the routerstatus entry for every voter
362             that included that RSA key with no ECC key, to Entries.
363             Include the ECC ID in the consensus.
364
365       For each RSA key listed by any voter:
366         If that RSA key is already in Entries, skip it.
367
368         If the RSA key is listed by > N/2 voting authorities:
369             Add the consensus of the routerstatus entries for those
370             voters to Entries.  Do not include an ECC key in the
371             consensus.
372
373    [XXX Think about this even more.]
374
375 4. The link protocol
376
377 4.1. Overview of the status quo
378
379    This section won't make much sense unless you grok the v3
380    link protocol as described in tor-spec.txt, first proposed in
381    proposal 195. So let's review.
382
383    In the v3 link protocol, the client completes a TLS handshake
384    with the server, in which the server uses an arbitrary
385    certificate signed with an RSA key.  The client then sends a
386    VERSIONS cell.  The server replies with a VERSIONS cell to
387    negotiate version 3 or higher.  The server also sends a CERTS
388    cell and an AUTH_CHALLENGE cell and a NETINFO cell.
389
390    The CERTS cell from the server contains a set of one or more
391    certificates that authenticate the RSA key used in the TLS
392    handshake.  (Right now there's one self-signed RSA identity key
393    certificate, and one certificate signing the RSA link key with
394    the identity key.  These certificates are X509.)
395
396    Having received a CERTS cell, the client has enough information
397    to authenticate the server.  At this point, the client may send a
398    NETINFO cell to finish the handshake.  But if the client wants to
399    authenticate as well, it can send a CERTS cell and an AUTENTICATE
400    cell.
401
402    The client's CERTS cell also contains certs of the same general
403    kinds as the server's key file: a self-signed identity
404    certificate, and an authentication certificate signed with the
405    identity key.  The AUTHENTICATE cell contains a signature of
406    various fields, including the contents of the AUTH_CHALLENGE
407    which the server sent cell, using the client's authentication
408    key.  These cells allow the client to authenticate to the server.
409
410
411 4.2. Link protocol changes for ECC ID keys
412
413    We add four new CertType values for use in CERTS cells:
414         4: Ed25519 signing key
415         5: Link key certificate certified by Ed25519 signing key
416         6: Ed25519 TLS authentication key certified by Ed25519 signing key
417         7: RSA cross-certificate for Ed25519 identity key
418    These correspond to types used in the CERT_TYPE field of
419    the certificates.
420
421    The content of certificate type [04] (Ed25519 signing key)
422    is as in section 2.5 above, containing an identity key and the
423    signing key, both signed by the identity key.
424
425    Certificate type [05] (Link certificate signed with Ed25519
426    signing key) contains a SHA256 digest of the X.509 link
427    certificate used on the TLS connection in its key field; it is
428    signed with the signing key.
429
430    Certificate type [06] (Ed25519 TLS authentication signed with
431    Ed25519 signing key) has the signing key used to sign the
432    AUTHENTICATE cell described later in this section.
433
434    Certificate type [07] (Cross-certification of Ed25519 identity
435    with RSA key) contains the following data:
436        ED25519_KEY                       [32 bytes]
437        EXPIRATION_DATE                   [4 bytes]
438        SIGNATURE                         [128 bytes]
439    Here, the Ed25519 identity key is signed with router's RSA
440    identity key, to indicate that authenticating with a key
441    certified by the Ed25519 key counts as certifying with RSA
442    identity key.  (The signature is computed on the SHA256 hash of
443    the non-signature parts of the certificate, prefixed with the
444    string "Tor TLS RSA/Ed25519 cross-certificate".)
445
446    (There's no reason to have a corresponding Ed25519-signed-RSA-key
447    certificate here, since we do not treat authenticating with an RSA
448    key as proving ownership of the Ed25519 identity.)
449
450    Relays with Ed25519 keys should always send these certificate types
451    in addition to their other certificate types.
452
453    Non-bridge relays with Ed25519 keys should generate TLS link keys of
454    appropriate strength, so that the certificate chain from the Ed25519
455    key to the link key is strong enough.
456
457
458    We add a new authentication type for AUTHENTICATE cells:
459    "Ed25519-TLSSecret", with AuthType value 2. Its format is the same as
460    "RSA-SHA256-TLSSecret", except that the CID and SID fields support
461    more key types; some strings are different, and the signature is
462    performed with Ed25519 using the authentication key from a type-6
463    cert.  Clients can send this AUTHENTICATE type if the server
464    lists it in its AUTH_CHALLENGE cell.
465
466    Modified values and new fields below are marked with asterisks.
467
468        TYPE: The characters "AUTH0002"* [8 octets]
469        CID: A SHA256 hash of the initiator's RSA1024 identity key [32 octets]
470        SID: A SHA256 hash of the responder's RSA1024 identity key [32 octets]
471        *CID_ED: The initiator's Ed25519 identity key [32 octets]
472        *SID_ED: The responder's Ed25519 identity key, or all-zero. [32 octets]
473        SLOG: A SHA256 hash of all bytes sent from the responder to the
474          initiator as part of the negotiation up to and including the
475          AUTH_CHALLENGE cell; that is, the VERSIONS cell, the CERTS cell,
476          the AUTH_CHALLENGE cell, and any padding cells.  [32 octets]
477        CLOG: A SHA256 hash of all bytes sent from the initiator to the
478          responder as part of the negotiation so far; that is, the
479          VERSIONS cell and the CERTS cell and any padding cells. [32
480          octets]
481        SCERT: A SHA256 hash of the responder's TLS link certificate. [32
482          octets]
483        TLSSECRETS: A SHA256 HMAC, using the TLS master secret as the
484          secret key, of the following:
485            - client_random, as sent in the TLS Client Hello
486            - server_random, as sent in the TLS Server Hello
487            - the NUL terminated ASCII string:
488              "Tor V3 handshake TLS cross-certification with Ed25519"*
489           [32 octets]
490        RAND: A 24 byte value, randomly chosen by the initiator. [24 octets]
491        *SIG: A signature of all previous fields using the initiator's
492           Ed25519 authentication flags.
493           [variable length]
494
495    If you've got a consensus that lists an ECC key for a node, but the
496    node doesn't give you an ECC key, then refuse this connection.
497
498 5. The extend protocol
499
500    We add a new NSPEC node specifier for use in EXTEND2 cells, with
501    LSTYPE value [03].  Its length must be 32 bytes; its content is the
502    Ed25519 identity key of the target node.
503
504    Clients should use this type only when:
505      * They know an Ed25519 identity key for the destination node.
506      * The source node supports EXTEND2 cells
507      * A torrc option is set, _or_ a consensus value is set.
508
509    We'll leave the consensus value off for a while until more clients
510    support this, and then turn it on.
511
512    When picking a channel for a circuit, if this NSPEC value is
513    provided, then the RSA identity *and* the Ed25519 identity must
514    match.
515
516    If we have a channel with a given Ed25519 ID and RSA identity, and we
517    have a request for that Ed25519 ID and a different RSA identity, we
518    do not attempt to make another connection: we just fail and DESTROY
519    the circuit.
520
521    If we receive an EXTEND or EXTEND2 request for a node listed in the
522    consensus, but that EXTEND/EXTEND2 request does not include an
523    Ed25519 identity key, the node SHOULD treat the connection as failed
524    if the Ed25519 identity key it receives does not match the one in the
525    consensus.
526
527 6. Naming nodes in the interface
528
529    Anywhere in the interface that takes an $identity should be able to
530    take an ECC identity too.  ECC identities are case-sensitive base64
531    encodings of Ed25519 identity keys. You can use $ to indicate them as
532    well; we distinguish RSA identity digests by length.
533
534    When we need to indicate an Ed25519 identity key in a hostname
535    format (as in a .exit address), we use the lowercased version of the
536    name, and perform a case-insensitive match.  (This loses us a little
537    less than one bit per byte of name, leaving plenty of bits to make
538    sure we choose the right node.)
539
540    Nodes must not list Ed25519 identities in their family lines; clients and
541    authorities must not honor them there.  (Doing so would make different
542    clients change paths differently in a possibly manipulatable way.)
543
544    Clients shouldn't accept .exit addresses with Ed25519 names on SOCKS
545    or DNS ports by default, even when AllowDotExit is set.  We can add
546    another option for them later if there's a good reason to have this.
547
548    We need an identity-to-node map for ECC identity and for RSA
549    identity.
550
551    The controller interface will need to accept and report Ed25519
552    identity keys as well as (or instead of) RSA identity keys.  That's a
553    separate proposal, though.
554
555 7. Hidden service changes out of scope
556
557    Hidden services need to be able to identify nodes by ECC keys, just as
558    they will need to include ntor keys as well as TAP keys.  Not just
559    yet though.  This needs to be part of a bigger hidden service
560    revamping strategy.
561
562 8. Proposed migration steps
563
564    Once a few versions have shipped with Ed25519 key support, turn on
565    "Rule 1" on the authorities.  (Don't allow an Ed25519<->RSA pairing
566    to change.)
567
568    Once the release with these changes is in beta or rc, turn on the
569    consensus option for everyone who receives descriptors with
570    Ed25519 identity keys to check them.
571
572    Once the release with these changes is in beta or rc, turn on the
573    consensus option for clients to generate EXTEND2 requests with
574    Ed25519 identity keys.
575
576    Once the release with these changes has been stable for a month
577    or two, turn on "Rule 2" on authorities.  (Don't allow nodes that
578    have advertised an Ed25519 key to stop.)
579
580 9. Future proposals
581
582    * Ed25519 identity support on the controller interface
583    * Supporting nodes without RSA keys
584    * Remove support for nodes without Ed25519 keys
585    * Ed25519 support for hidden services
586    * Bridge identity support.
587    * Ed25519-aware family support
588
589 A.1. List of certificate types
590
591    The values marked with asterisks are not types corresponding to
592    the certificate format of section 2.1.  Instead, they are
593    reserved for RSA-signed certificates to avoid conflicts between
594    the certificate type enumeration of the CERTS cell and the
595    certificate type enumeration of in our Ed25519 certificates.
596
597
598    **[00],[01],[02],[03] - Reserved to avoid conflict with types used
599           in CERTS cells.
600
601    [04] - signing a signing key with an identity key (Section 2.5)
602
603    [05] - TLS link certificate signed with ed25519 signing key
604          (Section 4.2)
605
606    [06] - Ed25519 authentication key signed with ed25519 signing key
607           (Section 4.2)
608
609    **[07] - reserved for RSA identity cross-certification (Section 4.2)
610
611
612 A.2. List of extension types
613
614
615    [01] - signed-with-ed25519-key (section 2.2.1)
616
617 A.3. List of signature prefixes
618
619    We describe various documents as being signed with a prefix. Here
620    are those prefixes:
621
622       "Tor router descriptor signature v1" (section 2.5)
623       "Tor node signing key certificate v1" (section 2.1)
624
625 A.4. List of certified key types
626
627    [01] ed25519 key
628    [02] SHA256 hash of an RSA key
629    [03] SHA256 hash of an X.509 certificate
630
631 A.5. Reserved numbers
632
633    We need a new consensus algorithm number to encompass checking
634    ed25519 keys and putting them in microdescriptors.
635
636
637    We need new CertType values for use in CERTS cells.  We reserved
638    in section 4.2.
639
640         4: Ed25519 signing key
641         5: Link key certificate certified by Ed25519 signing key
642         6: TLS authentication key certified by Ed25519 signing key
643         7: RSA cross-certificate for Ed25519 identity key
644