On 19/01/2012 22:05, Brian Trammell wrote:
Hi, Peter, Alexey, all,
Hi Brian,
On Jan 19, 2012, at 8:34 PM, Peter Saint-Andre wrote:
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.
Okay; how about the following (including Alexey's comments from the previous
review, and pointing more specifically to 6125)
<t>RID systems MUST verify the identity of their peers against that stored
in the certificate presented, as in section 6 of<xref target="rfc6125"/>.
As RID systems are identified not by URI and RID does not use DNS SRV
records, they are identified solely by their DNS Domain Names; see Section
6.4 of<xref target="rfc6125"/>.
(I think you are saying that [using RFC 6125 terminology] DNS-IDs are
supported, but SRV-IDs or URI-IDs aren't.)
This is better, but I think you need to say a bit more. Are CN-IDs
allowed? Are wildcards allowed?
Another example of the document that describes
http://tools.ietf.org/html/draft-melnikov-email-tls-certs-00
General information on the use of PKI
with RID systems is detailed in Section 9.3 of<xref
target="I-D.ietf-mile-rfc6045-bis"/>.</t>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
