Hi Toerless, I agree with your analysis here. RFC 2818 does allow to omit the hostname check if the client has additional information about the expected identity of the server. (Which is in the PRM case, the CA trust anchors of the manufacturer of the device - or a set of trusted manufacturers that the commissioning tool tusts.)
Also notice that although EST (RFC 7030) mentions RFC 2818, the BRSKI-PRM device to be onboarded does not implement EST server so any RFC 7030 requirements on the server are not really applicable for that BRSKI-PRM device. We define a new type of server here (the "Pledge-PRM" TLS server?) with own rules. I don't see why it should follow EST server rules here, it's not an EST server. That said, RFC 9110 makes things more restrictive it seems. But it also says in 4.3 "However, authoritative access is not limited to the identified mechanism." which means that other means of authoritative access to a resource/HTTPS server , i.e. other than the method defined in section 4.3 , are also foreseen. So it should be okay to use HTTPS for the BRSKI-PRM use case. Regards Esko -----Original Message----- From: Anima <[email protected]> On Behalf Of Toerless Eckert Sent: Wednesday, April 26, 2023 19:11 To: [email protected]; [email protected] Cc: [email protected] Subject: [Anima] ANIMA: Certificate authentication, BRSKI PRM and RFC8995 In the process of discussing shepherd review feedback for BRSKI-PRM draft, the authors brought up arguments relating to their interpretation of requirements against required TLS server certificate validation by the client. Let me try to hopefully correctly restate and provide my thoughts, if i am misrepresenting, please correct me! Pre: A pledge has an IDevID and some dynamically assigned IP(v6) address, and no domain name. Claim of the authors Another device can not build a HTTP over TLS connection to the pledge and authenticate the pledge, because of the absence of domain name and IP-address based SubjectAltNames in the certificate - according to RFC2818. RFC2818 is required to be met because BRSKI relies on RFC7030 and RFC7030 requires RFC2818. My assessment: I think this is an incorrect reading: I think that any time that a TLS server would identify itself with an IDevID, paragraph 2 of section 3.1 of RFC2818 would be applicable: The "narrow the scope of acceptable certificates" are those certificates that can be validted against the trust anchors that the client trusts. E.g.: The trust anchors from the vendor(s) from which the client expects the IDevID to be signed. Furthermore: I think the very same is also true for BRSKI itself, e.g.: the only authentication that pledges are doing against a registrar is authenticating the certificate against the trust anchor provided in the voucher. There is no additional authentication against any type of additional Subject Name or SubjectAltName that the certificate of a registrar my carry (dns name or ip address). draft-t2trg-idevid-considerations I did not have time to read through this draft, but would that potentially be a good place to reconfirm that one can build a TLS connection to a device that will use it's IDevID to authenticate itself, and a secure authentication of that device as a TLS server effectively only requires validation of the certificate chain against the trust anchor of the menufacturer for the device - no additional verification of other addresses. RFC2818 -> RFC9110: I find these whole HTTP drafts quite confusing: - RFC2818 was never standards track, but only informational but still uses RFC2119 terminology (MUST / SHOULD / ...). - RFC2818 was obsoleted by RFC9110. And RFC9110 is now standards track. - RFC9110 states in section B.1 that it does not changes anything from RFC2818. But then you look at RFC9110 section 4.3.4 and the text is quite different from RFC2818 section 3.1. In fact, i would claim that RFC9110 is even more WebPKI centric written than RFC2818 ("In general, a client MUST verify the service identity using the verification process defined in Section 6 of [RFC6125].") Aka: "In General all certificate validation is WebPKI validation".... With our non-webPKI uses cases i feel somewhat neglected ;-) Does this help ? Cheers Toerless _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
