On 1/19/12 10:32 AM, Alexey Melnikov wrote: > Hi Brian, > > On 19/01/2012 09:48, Brian Trammell wrote: >> On Jan 18, 2012, at 7:01 PM, Alexey Melnikov wrote: >>> On 18/01/2012 17:43, Alexey Melnikov wrote: >>>> Hi Brian, >>>> >>>> On 18/01/2012 16:16, Brian Trammell wrote: >>>>> On Jan 18, 2012, at 3:38 PM, Alexey Melnikov wrote: >>>>> >>>>> Actually, since the binding between RID and a PKI is better defined >>>>> in rfc6045-bis, 6046-bis now refers to it, as follows: >>>>> >>>>> Each RID system SHOULD authenticate its peers via a PKI as >>>>> detailed >>>>> in Section 9.3 of [I-D.ietf-mile-rfc6045-bis]. >>>>> >>>>> Would this address the concern? >>>> Let me check. >>> So the text in rfc6045bis seems to suggest that all server >>> certificates will be verified based on some prior arrangement. Is my >>> understanding correct? >> Yes; in essence, a RID consortium is "closed". > I think that this approach is unwise, because this wouldn't scale. But > if nobody else see a problem with this, I will let it go.
I have a problem with it. Version -05 said: Each RID consortium SHOULD use a trusted public key infrastructure (PKI) to manage identities for RID systems participating in TLS connections. At minimum, each RID system MUST trust a set of X.509 Issuer identities ("Certificate Authorities") [RFC5280] to directly authenticate RID system peers with which it is willing to exchange information, and/or a specific white list of X.509 Subject identities of RID system peers. RID systems MUST provide for the verification of the identity of a RID system peer presenting a valid and trusted certificate, by verifying the fully-qualified domain name and service name from the DNS SRV record, if available, against that stored in the certificate, as in Section 6 of [RFC6125]. In version -06, that was replaced with: Each RID system SHOULD authenticate its peers via a PKI as detailed in Section 9.3 of [I-D.ietf-mile-rfc6045-bis]. As far as I can see, a RID system is not the same as a RID consortium. Even if every RID system is a member of such a consortium, it seems like a bad idea to leave the authentication rules up to the consortium, without providing any sort of guidance. Version -05 at least pointed to RFC 6125. Since 6046bis is the HTTPS/TLS binding only, it might be more appropriate to point to RFC 2818 here instead of RFC 6125, but I think we need to say *something* about how authentication works (matching of endpoint identities and such) instead of hoping that consortia get the security right. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art