Re: [pkix] RFC 5280 interpretation of trust anchor certificates

[Niklas Matthies <[e-mail]>]

On Sun 2022-10-09 at 21:17h, Michael StJohns wrote on pkix:
>On 10/9/2022 4:03 PM, Niklas Matthies wrote:
:
>>So, if I understand correctly, the intent is that the second 
>>sentence also only applies to self-signed certificates. Hence, the 
>>specification given by the second sentence of how to reduce a 
>>certificate to a "plain" trust anchor is, strictly speaking, only 
>>applicable to self-signed certificates, as far as RFC 5280 is 
>>concerned.
>>
>>
>That's not quite what I said or meant.  What I meant was there was no 
>reason to include "self-signed" in the second sentence because it was 
>implied that we were talking about the same certificate.

Some readers take the second sentence to be intended to apply to any 
certificate, not just self-signed ones. That's what made me start this 
thread, because there were different readings. So "no reason" is 
relative, because clearly people interpret the wording in different 
ways due to the omission of "self-signed" in the second sentence.

>In any event, you're going to be happiest if you stop reading 
>"self-signed certificate" and read "trust anchor information in 
>whatever form provided".  "... trust anchor information may be 
>provided ... in the form of a self-signed certificate..." does not 
>prevent the provision of the trust anchor information (d)1,2,3,4 in 
>another format.

Well. RFC 5280 specifically describes how one should go about to 
determine the trust anchor information from a self-signed certificate, 
presumably because it might not be obvious how to do so. The way it is 
written also suggests that it is the only allowable way to interpret a 
self-signed certificate as trust anchor information, e.g. one does not
(say) take a DN from the subjectAltName as the trusted issuer name. 
The RFC doesn't say "one way to use a self-signed certificate as a 
trust anchor is to do x", instead it says (paraphrased) "it is done 
this way" (though without SHALL).

So, given that the way to interpret a self-signed certificate as trust 
anchor requires explanation, and that a specific way is presented as 
*the* apparantly only admissible way, it is only natural to have 
doubts regarding non-self-signed certificates, because why would the 
description not include them if the same procedure was admissible for 
those? Maybe the procedure is different for non-self-signed 
certificates, or not applicable at all for some reason? It is not 
obvious, prima facie.

:
>>Yes, that's clear to me. My point is, if another specification 
(ETSI 
>>specifications, in this case) refers to RFC 5280 for path validation
>>using trust anchors in the form of non-self-signed certificates, 
>>then that specification would have to specify how to map 
>>non-self-signed certificates to trust anchors as understood by RFC 
>>5280, because RFC 5280 only addresses self-signed certificates.
>
>It does not.  That self same section you quote just suggests 
>self-signed certificates as one form of trust anchor info and actually 
>lists what the trust anchor info needs to consist of.

My point is that if you have a certificate that you want to use as a 
trust anchor, you need to apply a mapping from the certificate to the 
trust anchor information. That mapping is reasonably straightforward 
in principle, but conceivably there might be important considerations 
depending on the type and content of the certificate. The fact that 
RFC 5280 restricts its description of such a mapping to self-signed 
certificates could be taken as an indication that such considerations 
exist.

Therefore, in the context of a technical specification that 
specifically refers to RFC 5280 for the use of trust anchors provided 
in the form of a certificate (which is the case with ETSI), and that 
wants you to apply RFC 5280 with potential trust anchor certificates 
that may or may not be self-signed, at least some note would be in 
order to clarify that the restriction of RFC 5280's description to 
self-signed certificates is to be taken as immaterial, and that this 
mapping is the one to apply to the certificates in question, whether 
self-signed or not.

In programming terms, it's like if RFC 5280 defines a validation 
function taking either a SelfSignedCertficate or a PlainTrustAnchor, 
but the other specification says "call the RFC 5280 validation 
function with the Certificate value you have", and the result is a 
type mismatch. (This is what I mean by the "disconnect".) You need 
*something* that specifies that you are expected to first convert your 
Certificate to a PlainTrustAnchor, presumably as described in RFC 5280 
for self-signed certificates, and that there are no further strings 
attached to that conversion (which otherwise might conceivably be the 
case).

>>Specifying that mapping is trivial, of course (it's the same as for 
>>self-signed certificates), but without specifying it there is a 
>>formal disconnect between the two specifications.
>>
>I'm actually surprised that RFC5914 isn't tagged as updating 5280.

I think RFC 5914 is just intended as a data format specification, and 
is not intended to change anything about RFC 5280. At least that's how 
I've always interpreted it.

>I wouldn't actually say "disconnect" as Section 6.1.1 bullet (d) just 
>says "trust anchor information" and then notes that a self-signed 
>certificate is one form.

The question that immediately comes up when reading that part is "why 
self-signed certificates specifically?". If there is a need for RFC 
5280 to tell you that self-signed certificates are a valid form of 
specifying trust anchors, one would assume that it would also want to 
tell you that non-self-signed certifcates are a valid form as well, 
assuming that indeed that's the case. The fact that it does not do 
that suggests to the reader that maybe they are not a valid form for 
some reason.

:
>>Just to clarify: There is no particular reason why RFC 5280 should 
>>restrict certificate-represented trust anchors to self-signed 
>>certificates, but it just happens to do so for historical reasons?
>
>It goes back before that I think to X.509 v1.  A self-signed 
>certificate was a well defined ASN1 object that could be used to carry 
>trust information.  It could also be used to carry the information 
>needed to enroll a public key in a certificate.

That might explain how the current wording came about.

>In any event, I believe you're mis-reading 5280 as restricting trust 
>anchor information to X509 self-signed certificates.  It does not.

I'm not reading RFC 5280 as disallowing non-self-signed certificates, 
but as being silent on how, if at all, they are used to represent 
trust anchor information. Therefore any specification that wants to 
use them to provide trust anchor information needs to clarify how, in 
my view, because RFC 5280 doesn't.

Niklas