notaryproject/specifications

The term "root certificate" is not rigorously defined

Opened this issue · 1 comments

The Notary Project specifications use the term "root certificate" many times within the context of X.509 PKI, but I could not find any language within the specs which defines what a root certificate is. Neither X.509 nor RFC 5280 define the term, either. A rigorous definition is needed to ensure that all implementations of the Trust Store and Trust Policy specification agree on whether a signature is authentic, given that a "complete chain" is defined as a chain of certificates which begins with a leaf certificate and terminates with a root certificate.

The notation reference implementation operates on the definition that a root certificate as a self-issued, self-signed certificate. But other implementations could interpret "root certificate" tautologically as the last certificate in the signature envelope's list. Under this interpretation, signature envelopes containing a chain of certificates terminating in a cross-certificate (a CA certificate where the issuer and the subject are different CAs, in X.509 terminology) would not necessarily be invalid.

An implementer may be drawn to the tautological definition of root certificate, despite it not entirely agreeing with the colloquial common definition of "a self-signed certificate with CA=true" as the tautological definition resolves an ambiguity in the specification for validating signature authenticity using the trustStore.

1. For the `trustStore` configured in applicable trust-policy perform the following steps.
1. Validate that certificate and certificate-chain lead to a trusted certificate present in the named store.

If "certificate-chain" is taken to mean the complete certificate chain as listed in the signature envelope, it would follow that an image is authentic iff appending a trust anchor from the trust store to the certificate chain in the envelope results in a valid certification path with no certificates left over. This is more in line with how RFC 5280 PKI is used in practice: the TLS handshake, for instance, does not transmit the trust anchor certificate as part of the chain as the remote peer must already have a copy in its trust store for authentication to succeed. By this interpretation, a signature envelope containing a self-signed certificate could never be valid as the chain would terminate at the self-signed certificate in the envelope, leaving the appended trust anchor disconnected from the chain. A signature considered valid by notation would never pass validation by an implementation following this interpretation, and vice versa.

Thank @corhere for pointing out the ambiguity of improperly defined terms.

@yizha1 @gokarnm @priteshbandi @toddysm We should refine and define terms rigorously to avoid ambiguity.