Re: RFC 5280 interpretation of trust anchor certificates

On Mon 2022-10-10 at 07:22h, Carl Wallace wrote on pkix:
>On 10/9/22, 11:21 PM, "pkix on behalf of Niklas Matthies" 
><[email protected] on behalf of [email protected]> wrote:
:
> [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.

Ah, I think there is a misunderstanding here. I didn' say that the RFC 
is saying that self-signed certificates are the only way. What I meant 
is that it seems to be saying that _if_ a self-signed certificate is 
used to represent a trust anchor, _then_ the trust anchor information 
has to be derived in the following way:

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

This reads as being prescriptive for the case where a self-signed 
certificate is used, i.e., using a different mapping for a self-signed 
certificate (for example, using subjectAltName instead of the subject 
field) would be in conflict with this wording.

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

Thanks for pointing out that reference.

Niklas

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