Re: RFC 5280 interpretation of trust anchor certificates

Hi Niklas -

On 10/9/2022 1:52 PM, Niklas Matthies wrote:
> 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?

In the above, it's basically because it didn't really need to be 
repeated to be understood to refer to the same certificate which was 
referenced in the first paragraph.

>
> 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.

Look at the Certificate Path Validation algorithm described in RFC5280.  
A self-signed certificate provides the information needed to initialize 
that algorithm, as does an intermediate CA. There's also RFC5914 which 
describes a non-self-signed ASN1 structure which provides basically the 
same level of information. It's pretty trivial to transform a 
self-signed certificate or other CA certificate into an RFC5914 format 
TrustAnchorInfo object.

A trust anchor is at the END (beginning?)  of the certificate path and 
its presence there is usually by configuration (e.g. inclusion in the 
source code of a browser), rather than by provision and authentication 
by another party - e.g. neither the IssuerName nor the certificate 
signature has any value for the purpose of a given cert path 
validation.  That's mostly why it's not included in the path. That said, 
it's perfectly acceptable to tag any CA certificate as a trust anchor - 
even if it's subordinate to another CA or trust anchor.    See RFC5914 - 
section 3.


>
> 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?

See RFC5914, section 3 - TrustAnchorList/TrustAnchorChoice - a 
Certificate (of any form, including X.509) is one form of a 
TrustAnchor.  I think we're good.

Mike


>
> Kind regards,
> Niklas
>
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix


_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix