Changes between Version 1 and Version 2 of Credentials

Author:

gary (IP: 155.98.60.98)

Timestamp:

06/09/10 12:31:07 (3 months ago)

Comment:

Add a section with detailed credential validation requirements.

Credentials

@@ -36 +36 @@
-The wildcard privilege "*" may be used in place of any other
-privilege string.
-
-A simple credential (one with no ancestors) must be signed by the
-ProtoGENI authority whose certificate subject exactly matches the authority
-in the `target` URN.  (This certificate will be included in a signature
-element, according to standard XML Signature processing.  Other
-certificates might also be enclosed, since it is necessary to
-verify CA certificates up to one of the ultimately trusted roots.)
-
-For the detailed specification, please consult the
-outermost child credential.
-
-No privilege may be included in a child credential unless either
-a privilege with identical name or the privilege named "*" is present
-in the parent.  In addition, the parent privilege must include
-the element {{{<can_delegate>1</can_delegate>}}}.
-
-The expiry time on a child credential may be no later than the
-expiry time of the parent.
-
-[wiki:DelegationExample A concrete example] of a delegated
-credential is available, along with instructions on how to use
-the ProtoGENI tools to create one.
+
+== Validating credentials ==
+
+The following procedure should be followed before accepting any credential
+as proof of corresponding privileges.  Naturally, all credentials must
+be ''syntactically'' correct (and validate against the
+[attachment:wiki:Authentication:credential.rnc credential schema]);
+the following requirements describe restrictions which are necessary
+for ''semantic'' correctness as well.
+
+For any credential to be honoured, the current time must be no later
+than that specified in the `expires` element of the credential.  When
+issuing subsequent credentials under the authority conferred by an
+existing credential (e.g. when a slice credential has been presented to
+authenticate the issuing of a corresponding sliver credential), the
+`expires` element time of the consequent credential must be no later
+than the `expires` element time of the existing credential.
+
+=== Validating the root ===
+
+Any simple credential (one with no ancestors), including the ultimate
+root credential which is contained in delegated credentials, must be
+signed by a ProtoGENI authority whose certificate `subject` matches the
+authority in the `target` URN.  (This certificate will be included in
+a signature element, according to standard XML Signature processing.
+Other certificates might also be enclosed, since it is necessary to
+verify CA certificates up to one of the ultimately trusted roots.)
+
+The certificate subject is considered to match the credential target
+if and only if:
+
+ 1. The subject [wiki:URNs URN] in the authority's certificate has
+    `resource-type` "authority".
+ 1. The `toplevelauthority` field in the authority's certificate
+    subject [wiki:URNs URN] is identical to the `toplevelauthority`
+    in the credential target URN.
+    [http://tools.ietf.org/html/rfc3151 RFC 3151]
+    defines transcription and equivalence of public identifier URNs.
+
+=== Validating any delegation ===
+
+If the credential has been delegated, then each delegation must
+satisfy the following:
+
+ 1. The `type` field of the child must be identical to the `type`
+    field of the parent.
+ 1. The expiry time on a child credential must be no later than the
+    expiry time of the parent.
+ 1. The expiry time of the child must be no later than the current
+    time.
+ 1. A valid signature over the child credential, signed by the principal
+    identified in the `owner` element of the parent credential,
+    must be present in the `signatures` element of the outermost
+    credential.
+ 1. For credentials of `type` `privilege`:
+    a. No privilege may be included in a child credential unless either
+       a privilege with identical name or the privilege named "*" is present
+       in the parent.  In addition, the parent privilege must include
+       the element {{{<can_delegate>1</can_delegate>}}}.
+
+=== Validating subauthorities ===
+
+Please note that Utah's ProtoGENI software does not yet support
+subauthorities.  If a validator does not support subauthorities, it
+should reject any credential if either the authority certificate
+subject URN or the credential target URN contain one or more
+subauthority fields.
+
+If the validator does process subauthorities, the following
+restrictions will apply:
+
+ 1. The number of subauthorities specified in the authority subject
+    and the credential target must agree, and each `subauthority`
+    field must match (just as the `toplevelauthority` must).
+ 1. Any authority certificate where the subject URN contains one or
+    more subauthorities must have been signed by a CA such that the
+    certificate issuer URN contains exactly the same `toplevelauthority`
+    and `subauthority` fields as the certificate subject URN in
+    exactly the same order, except that the very last `subauthority`
+    in the certificate subject must not be present in the certificate
+    issuer.