Clarify the One-SPIFFE-ID-Per-SVID rule (spiffe#72)

* Clarify the One-SPIFFE-ID-Per-SVID rule
From the very first version of the X.509-SVID specification, a requirement has been set that an SVID may contain one and only one SPIFFE ID. Users requiring more than one identity must use multiple SVIDs, as opposed to a single SVID representing multiple identities.

SIG-Spec has re-visited this restriction. After a lengthy discussion, consensus was reached that the rule should stand. There were two primary concerns in relaxing this restriction: 1) Audit logging would become more difficult, as an authenticator would have to understand which identity is the one that was in fact authorized, and 2) authorization would become more difficult, and SPIFFE is not in a position to provide authorization instructions with regards to how policies governing multiple SPIFFE IDs should be combined.

It was acknowledged that it would be useful to include multiple SPIFFE IDs in the context of a server certificate, however workloads may choose to use the same SVID as both server and client certificates, and the complexity introduced in allowing such a concession was decidedly more dangerous than simply keeping the restriction in place.

This commit:
1. Updates the text to give a short explanation on the existence of the restriction
1. Updates the text to specify what a validator should do when encountering multiple SPIFFE IDs in an SVID
1. Clarifies SVID validation of signing certificates
1. Fixes spiffe#32

Signed-off-by: Evan Gilman <egilman@vmware.com>

standards/X509-SVID.md

@@ -36,7 +36,9 @@ Perhaps the most important function of SPIFFE is to secure process to process co
 This specification addresses the encoding of SVID information into an X.509 certificate, the constraints which must be set, as well as how to validate X.509 SVIDs.
 
 ## 2. SPIFFE ID
-In an X.509 SVID, the corresponding SPIFFE ID is set as a URI type in the Subject Alternative Name extension (SAN extension, see [RFC 5280 section 4.2.16][2]). An X.509 SVID MUST contain exactly one URI SAN. It MAY contain any number of other SAN fields, including DNS SANs.
+In an X.509 SVID, the corresponding SPIFFE ID is set as a URI type in the Subject Alternative Name extension (SAN extension, see [RFC 5280 section 4.2.16][2]). An X.509 SVID MUST contain exactly one URI SAN, and by extension, exactly one SPIFFE ID. SVIDs containing more than one SPIFFE ID introduce challenges related to auditing and authorization logic, and SVIDs containing more than one URI SAN introduce challenges related to SPIFFE ID validation. Validators encountering an SVID containing more than one URI SAN MUST reject the SVID. Please see the [Validation](#5-validation) section for more information.
+
+An X.509 SVID MAY contain any number of other SAN field types, including DNS SANs.
 
 ## 3. Hierarchy
 This section discusses the relationship between leaf, root, and intermediate certificates, as well as the requirements placed upon each.
@@ -95,7 +97,7 @@ Certificate path validation requires the leaf SVID certificate and one or more S
 ### 5.2. Leaf Validation
 When authenticating a resource or caller, it is necessary to perform validation beyond what is covered by the X.509 standard. Namely, we must ensure that 1) the certificate is a leaf certificate, and 2) that the signing authority was authorized to issue it.
 
-When validating an X.509 SVID for authentication purposes, the validator MUST ensure that the `CA` field in the basic constraints extension is set to `false`, and that `keyCertSign` and `cRLSign` are not set in the key usage extension. The validator must also ensure that the scheme of the SPIFFE ID is set to `spiffe://`.
+When validating an X.509 SVID for authentication purposes, the validator MUST ensure that the `CA` field in the basic constraints extension is set to `false`, and that `keyCertSign` and `cRLSign` are not set in the key usage extension. The validator must also ensure that the scheme of the SPIFFE ID is set to `spiffe://`. SVIDs containing more than one URI SAN MUST be rejected.
 
 As support for URI name constraints becomes more widespread, future versions of this document may update the requirements set forth in this section in order to better leverage name constraint validation.