[pkix] RFC 5280 interpretation of trust anchor certificates

[Niklas Matthies <[e-mail]>]

Dear all,

On the ESI (ETSI) mailing list, the question came up whether RFC 5280 
says anything about trust anchors provided in the form of certificates 
that are _not_ self-signed.

In section 6.1.1, there is the following wording on page 76:

       The trust anchor information may be provided to the path
       processing procedure in the form of a self-signed certificate.
       When the trust anchor information is provided in the form of a
       certificate, the name in the subject field is used as the trusted
       issuer name and the contents of the subjectPublicKeyInfo field is
       used as the source of the trusted public key algorithm and the
       trusted public key.

The first sentence seems to indicate that the case of providing a 
trust anchor in the form of a non-self-signed certicate is not 
considered here. But the second sentence doesn't repeat the 
"self-signed" bit, which can be interpreted as that sentence also 
applying to non-self-signed certificates. However, if that is the 
case, why does the first sentence restrict itself to specifically 
self-signed certificates?

On page 74 there is also the following wording: 

       When the trust anchor is provided in the form of a self-signed
       certificate, this self-signed certificate is not included as 
       part of the prospective certification path.

If RFC 5280 also allows the possibility of trust anchors being 
provided in the form of non-self-signed certificates, then it would
seem that the above restriction would not apply to those, i.e., that 
they may be included as part of the prospective certifcation path. 
However, I don't see how that would make any sense.

All the wording taken together, my conclusion up to now was that RFC 
5280 simply does not consider the possibility that the trust anchor 
could be provided in the form of a non-self-signed certificate, and 
that therefore, specifications which *do* allow for that possibility 
(such as in the context of ETSI trusted lists) have to clarify how 
that case maps onto what RFC 5280 expects.

If that interpretation is incorrect, that is, if RFC 5280 doesn't 
actually care about whether a trust-anchor-representing certificate 
provided as input to the path validation algorithm is self-signed or 
not, then maybe an erratum is in order?

Kind regards,
Niklas