Re: RFC 5280 interpretation of trust anchor certificates

Inline...

On 10/9/22, 11:21 PM, "pkix on behalf of Niklas Matthies" <[email protected] on behalf of [email protected]> wrote:

<snip>

    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.

[CW] The first sentence of the paragraph you are referencing, i.e., in bullet (d) in section 6.1.1, states: " The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate." The "may" in this sentence leaves open the possibility to use other formats, so it's not clear why you are reading this as *the* only admissible way or have doubts that use of formats other than self-signed certificates is permitted. As noted in this thread, RFC 5914 defines an alternative format and includes similar language re: how to extract the necessary information to input to the path validation algorithm, so you are correct that where alternative formats are used some mapping from that format to the inputs to the path validation algorithm need to be defined. This issue has come up before and was addressed in RFC 6818 by updating Section 6.2 in RFC 5280 to clarify that other specs may describe how to use alternative formats or additional information:

  Section 6.1 does not assume that trust anchor information is provided
| in self-signed certificates and does not specify processing rules for
| additional information included in such certificates.
| However, [RFC5914] defines several formats for representing trust
| anchor information, including self-signed certificates, and [RFC5937]
| provides an example of how such information may be used to initialize
| the path validation inputs.  Implementations are free to make use of
| any additional information that is included in a trust anchor
| representation, or to ignore such information.

<snip>


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