Changes between Version 10 and Version 11 of GID

Author:

ricci (IP: 166.70.37.238)

Timestamp:

04/23/08 18:32:51 (2 years ago)

Comment:

--

GID

@@ -21 +21 @@
-   * Can there be more than one certificate bound to a particular GID (possibly serially, not in parallel)?
-
+
+=== GID a Certificate ===
+
+The idea: An entity's GID is a certificate binding a UUID to a public key
+
+Pros:
+   * It's what is currently in the GENI docs, so is most likely to be inter-operable with other implementations
+   * Self-certifying
+
+Cons:
+   * The certificate includes an expiration date, and if we were to renew a certificate by creating
+     one with a later expiration date, this would constitute the creation of a new identity, unrelated 
+     at an architectural level to the previous one. 
+   * It also ties identity strongly to the authority that has signed the certificate - ie. if my 
+     institution signed my GID, and I change institutions, I have to get a new identity (or my old institution must
+     continue vouching for my identity.)
+   * If an entity needs to change its public key for any reason - ie. a real or suspected  
+     compromise of its private key, this also requires a new identity.
+
+     Rob says:
+          There are plenty of best-practices reason I might want to change keys.
+          Obviously if my private key is compromised or lost, I need to change
+          it, but there are many reasons short of these I might want to change
+          my keypair. We change passwords routinely in case they've been
+          compromised and we don't know it. If someone breaks into my machine,
+          no matter what the vector, I change my passwords and ssh keys just in
+          case. By tying identity and authentication, we (strongly) discourage
+          GENI users from using these best practices, which doesn't seem like a
+          good idea.
+
+          This feels to me kinda like making my UID = my password hash: it just
+          doesn't seem like a good idea.
+
-=== GID as Hash of Public Key ===
-
-
-Pros:
-It's what is currently in the GENI docs, so is most likely to be inter-operable with other implementations
+~~It's what is currently in the GENI docs, so is most likely to be inter-operable with other implementations~~
-   * Self-certifying: because the GID is generated from the public key, anybody can generate a certificate for a given GID, but only someone who hold the matching private key can actually use it. This keeps it safe from misbehaving/compromised authorities
-   * Transferrable: If someone moves to a different authority (say, a different institution), they can get a certificate for the same GID from their new authority