add clarification about the current CSR signing rules

keps/sig-auth/20190607-certificates-api.md

@@ -162,9 +162,9 @@ Kubernetes provides the following well-known signers.  Today, failures for all o
     1. Trust distribution: signed certificates must be honored as client-certificates by the kube-apiserver.  The CA bundle
        is not distributed by any other means.
     2. Permitted subjects - no subject restrictions.
-    3. Permitted x509 extensions - none
-    4. Permitted key usages - must include `[]string{"client auth"}`
-    5. Expiration/cert lifetime - max of CSR signer or request.
+    3. Permitted x509 extensions - Non-critical extensions should be dropped.
+    4. Permitted key usages - must include `[]string{"client auth"}`.  Must not include key usages beyond `[]string{"digital signature", "key encipherment", "client auth"}`
+    5. Expiration/cert lifetime - minimum of CSR signer or request.  Sanity of the time is the concern of the signer.
     6. CA bit allowed/disallowed - not allowed.
  2. kubernetes.io/kubelet-client - signs client certificates that will be honored as client-certs by the kube-apiserver.
     May be auto-approved by kube-controller-manager.
@@ -173,7 +173,7 @@ Kubernetes provides the following well-known signers.  Today, failures for all o
     2. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"`
     3. Permitted x509 extensions - none
     4. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "client auth"}`
-    5. Expiration/cert lifetime - max of CSR signer or request.
+    5. Expiration/cert lifetime - minimum of CSR signer or request.  Sanity of the time is the concern of the signer.
     6. CA bit allowed/disallowed - not allowed.
  3. kubernetes.io/kubelet-serving - signs serving certificates that are honored as a valid kubelet serving certificate 
     by the kube-apiserver, but has no other guarantees.  Never auto-approved by kube-controller-manager.
@@ -182,15 +182,15 @@ Kubernetes provides the following well-known signers.  Today, failures for all o
     2. Permitted subjects - organizations are exactly `[]string{"system:nodes"}`, common name starts with `"system:node:"`
     3. Permitted x509 extensions - SAN DNS has value
     4. Permitted key usages - exactly `[]string{"key encipherment", "digital signature", "server auth"}`
-    5. Expiration/cert lifetime - max of CSR signer or request.
+    5. Expiration/cert lifetime - minimum of CSR signer or request.
     6. CA bit allowed/disallowed - not allowed.
  4. kubernetes.io/legacy-unknown - has no guarantees for trust at all.  Some distributions may honor these as client
     certs, but that behavior is not standard kubernetes behavior.  Never auto-approved by kube-controller-manager.
     1. Trust distribution: None.  There is no standard trust or distribution for this signer in a kubernetes cluster.
     2. Permitted subjects - any
-    3. Permitted x509 extensions - any
+    3. Permitted x509 extensions - honors SAN extensions and discards other extensions.
     4. Permitted key usages - may include `[]string{"key encipherment", "digital signature", "client auth", "server auth"}`
-    5. Expiration/cert lifetime - max of CSR signer or request.
+    5. Expiration/cert lifetime - minimum of CSR signer or request.  Sanity of the time is the concern of the signer.
     6. CA bit allowed/disallowed - not allowed.
 
 Distribution of trust happens out of band for these signers.  Any trust outside of those described above are strictly