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
