[OLD] Trust Anchors

This is outdated and content has been moved to https://github.com/notaryproject/notaryproject/pull/132

Update trust policy to support verification of OCI artifact signed using publicly trusted codesigning certificates. The certificates issued by CAs that are publicly trusted(abides by CAB forum guidelines and trusted by many operating systems) are referred to as publicly trusted certificates.

Why do we need this change

The user MUST be able to use a codesigning certificate issued from publicly trusted CAs e.g. Digicert, Entrust, Verisign, etc to sign and verify OCI artifacts.

Publicly trusted CAs issue codesigning certificates to various entities from the same CA, the only way for a consumer to verify that the artifact came from a specific publisher is to pin(in trust-policy) on the publisher's signing certificate. Signing certificates have limited validity and it's recommended to rotate keys periodically. If consumer pins on the publisher's signing certificate, the rotation of the publisher's singing certificate will require all consumers to update the trust policy to pin on the new certificate.

Since there can be thousands of consumers for an artifact, asking each and every consumer to update their trust store is not scalable. Thus we need a scalable mechanism where a consumer can reliably trust an artifact signed using a publicly trusted certificate.

PR BEGINS

Trust Policy

{
    "version": "1.0",
    "trustPolicies": [
        {
            "name": "aws-tp",
            "trustStores": [ "PUBLIC_TRUST_TS" ],
            "trustAnchors": [
                    "subject: C=US, ST=WA, L=Seattle, O=acme-rockets.io",
                    "Subject: C=US, ST=WA, L=Seattle, O=wabbit-networks Name, OU=java-client"
            ],
            "expiryValidations": {...},
            "revocationValidations": {...}
        }
    ]
}

• version(string): …
• trustPolicies(string-object map): …
  • …
  • trustAnchors(array of strings): This OPTIONAL property specifies a list of elements/attributes of the signing certificate's subject. If present, the collection MUST contain at least one value.
  • …

Certificate Anchors Constraints

• A distinguished name(usually just shortened to "DN") uniquely identifies an entry and in the case of certificate subject DN uniquely identifies the requestor/holder of the certificate. DNs are comprised of zero or more comma-separated components called relative distinguished names, or RDNs. For example, the DN C=US, ST=WA, O=wabbit-network.io, OU=org1"` has four RDNs. RDN consists of an attribute type name followed by an equal sign and the string representation of the corresponding attribute value. However, there are special cases in which it is necessary to escape one or more characters in an RDN. Those cases are:
  • If a value starts or ends with a space, then that space character MUST be escaped as \ .
  • All occurrences of the comma character (,) MUST be escaped as \,.
  • All occurrences of the semicolon character (;) MUST be escaped as \;. This is required for backward compatibility, in case Notary v2 allows anchoring on multiple attributes, ; MUST be used as delimiter.
  • All occurrences of the backslash character (\) MUST be escaped as \\.
• Signing certificate anchors MUST Support a full and partial list of all the attribute types present in x509 certificate's subject DN.
• The values of trustAnchors MUST begin with subject: followed by comma-separated one or more RDNs. For example, subject: C=${country}, ST=${state}, L=${locallity}, O={organization}, OU=${organization-unit}, CN=${common-name}.
• The anchor MUST contain country(CN), state Or province (ST), and organization(O) RDNs. All other RDNs are optional. The minimal anchor is subject: C=${country}, ST=${state}, O={organization},
• Signing certificate anchors MUST support overlapping values. Signing certificate anchors are considered overlapping if there exists a certificate for which multiple trust anchors evaluate true. For example, the following two certificate anchors are overlapping:
  • subject: C=US, ST=WA, O=wabbit-network.io, OU=org1
  • subject: C=US, ST=WA, O=wabbit-network.io

---

Signature Evaluation

…

1. Validate that the signature envelope format is supported. …
2. Validate the signature envelope integrity. …
3. Validate the signature against trust policy and trust store.
   1. Using the scopes configured in trust policies, get the applicable trust policy. (Implementations might have this value precomputed, added it for completeness)
   2. For the applicable trust policy, validate trust store: …
   3. For the applicable trust policy, validate trust anchor (if present):
      1. If trust anchors are present, validate that the signing certificate complies with trustAnchors i.e. the value of subject attributes configured in trustAnchors matches with the value of corresponding attributes in the signing certificate’s subject. If trust anchors are not present continue to step 4.
      2. If the above verification succeeds then continue to the next step else iterate over the next set of trust stores. If all of the trust stores have been evaluated then fail the signature validation and exit.
   4. Validate trust policy: …

PR ENDS

---

FAQ

Q. Why trust anchor is not scoped to a trusted certificate. A. If a user added certificates in the trusted roots, it means they trust those CAs to do the right thing(validations) when issuing certificates thus we don't need to tie trust anchor to trust root.

Q. Why notary v2 supports only certificate subject in trust anchor? A. The Signing certificate's subject can uniquely identify an organization and none of the other mandatory attributes have this capability. Also, the specification is extensible to support other attributes.

References

• [rfc5280] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
• [Oracle] Distinguished Names and Relative Distinguished Names
• https://www.cryptosys.net/pki/manpki/pki_distnames.html
• https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ldap/distinguished-names
• https://frasertweedale.github.io/blog-redhat/posts/2018-03-15-x509-dn-attribute-encoding.html
• https://ldap.com/ldap-dns-and-rdns/

tags: notary