Re: [Gen-art] Gen-ART last call review of draft-ietf-mile-rfc6046-bis-05

[Alexey Melnikov <[e-mail]>]

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>