Re: RFC 5280 interpretation of trust anchor certificates

On 10/9/2022 4:03 PM, Niklas Matthies wrote:
> Hi Michael,
>
> On Sun 2022-10-09 at 14:21h, Michael StJohns wrote on pkix:
>> On 10/9/2022 1:52 PM, Niklas Matthies wrote:
> :
>>> 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.
>
> 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.

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.

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


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


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

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

Later, Mike


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