Hi SM,
apologies for latency in replying..
>>You mean removing the parenthetical "(following the definition of
>>"label" from [DNS])", yes?
>>
>>In reviewing RFC 1035 I see your concern, tho we'd like to reference
>>a description of "label". I note that RFC 1034 [S3.1] seems to
>>appropriately supply this, so I propose we keep the parenthetical
>>but alter it to be..
>>
>> (following the description of labels and domain names in [DNS-CONCEPTS])
>
> That's fine to me.
k
>
>>Yes, but that definition (and term) appears to be specific to
>>underlying DNS internals, not to (pseudo) domain names as wielded
>>(or "presented" (eg in certs)) in other protocols.
>
> This brings us to the question of the DNS specific usage of "domain
> names" and when the term is used in an application context.
>
> For example, is the left-most part in "foo*.example.com" (
> draft-saintandre-tls-server-id-check-12, Section 5.2) acceptable as a label?
No, "foo*" isn't a legit dns label per se. However, it's only used in
"presented" domain names in various contexts -- certs being one -- and intended
for matching within applications, not for actual dereferencing via the DNS.
> I'll react to some comments from Cullen Jennings.
>
> At 23:17 15-12-10, Cullen Jennings wrote:
>>So let me start with I think there is great information in here and
>>I think it should be published as a standards track RFC however I do
>>think there are some issues with the relation with this draft and
>>the realities of what would help improve security in deployment of
>>SIP, HTTP, IMAP, XMPP etc.
>
> The information in draft-saintandre-tls-server-id-check is
> helpful. It's been a mouthful to comment on the draft as it requires
> the reading of several referenced documents first. This in itself
> gives us an idea of the breath this draft tries to cover.
>
>>process review. Next this draft contradicts the procedures in
>>existing protocols and says that it does not apply to the existing
>>protocols but that it would take precedence over any future updates
>>of existing protocols that use TLS within the scope specified here. I
>
> That begs the question about whether this draft should be a BCP. I
> would feel more comfortable if such a document is carefully reviewed
> by people from the different application groups it touches on as it
> attempts to shape the future. This is not to say that there hasn't
> been enough discussion about the draft or that it did not get
> adequate socialization. If the authors are of the opinion that there
> has been that breath of review, I am fine with that.
above is no longer an issue as the draft is now approved as a proposed std. thx
for the input on the issue in any case.
>
>>In section 3.2, in the imap example, you are saying that if I
>>configure my imap server to mail.example.com and it presents a
>>certificate with a DNS-ID of example.com that this is OK. That does
>>not sound OK to me but I don't know how IMAP works. In the SIP example, the
>
> Consider an email address of "[email protected]". The IMAP service is
> discovered by the MUA by doing a DNS SRV lookup on _imaps.example.com
> ( draft-daboo-srv-email ) and the target is mail.example.net, i.e
> that's where the IMAP server is running. The certificate provides a
> SRV-ID of "_imaps.example.com" and a DNS-ID of "example.com".
we've incorp'd such an example in the draft, thx.
>
> BTW, the reference to draft-ietf-tls-rfc4366-bis could be normative
> for the reader to understand SNI and not rely on the workaround for
> multiple identifiers.
we don't feel its approp at this time to make that a normative reference, for
at least the reasons given in the draft in S7.4.
thanks again for your review,
=JeffH
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
