On 7/7/22 3:40 AM, tom petch wrote:
On 06/07/2022 15:14, Valery Smyslov wrote:
Hi Peter,
On 7/6/22 12:41 AM, Valery Smyslov wrote:
Hi Martin,
The chairs think that the rough consensus is to limit the scope of
the
draft to domain names
(with the pointer to the HTTP RFC as advise for
On 06/07/2022 15:14, Valery Smyslov wrote:
Hi Peter,
On 7/6/22 12:41 AM, Valery Smyslov wrote:
Hi Martin,
The chairs think that the rough consensus is to limit the scope of the
draft to domain names
(with the pointer to the HTTP RFC as advise for protocols that support
IP addresses).
Is
>whether the scope of rfc6125bis draft should be broaden
to include non-domain names, like IP addresses
(at the cost of delaying its publication) or this issue
should be addressed in a separate document.
I am slightly opposed. My concern is not the delay in publication, but in
Hi Peter,
> On 7/6/22 12:41 AM, Valery Smyslov wrote:
> > Hi Martin,
> >
> >>> The chairs think that the rough consensus is to limit the scope of the
> >>> draft to domain names
> >>> (with the pointer to the HTTP RFC as advise for protocols that support
> >>> IP addresses).
> >>
> >> Is this the
On 7/6/22 12:41 AM, Valery Smyslov wrote:
Hi Martin,
The chairs think that the rough consensus is to limit the scope of the
draft to domain names
(with the pointer to the HTTP RFC as advise for protocols that support
IP addresses).
Is this the consensus of the chairs, or was there some
Hi Martin,
> > The chairs think that the rough consensus is to limit the scope of the
> > draft to domain names
> > (with the pointer to the HTTP RFC as advise for protocols that support
> > IP addresses).
>
> Is this the consensus of the chairs, or was there some discussion that I
> missed?
On Sat, Jul 2, 2022, at 00:11, Valery Smyslov wrote:
> The chairs think that the rough consensus is to limit the scope of the
> draft to domain names
> (with the pointer to the HTTP RFC as advise for protocols that support
> IP addresses).
Is this the consensus of the chairs, or was there some
On 7/5/22 8:44 AM, Salz, Rich wrote:
I found the part "and a DNS domain name of apps.example.net." to be
confusing, as I initially read it as "the combination of an application
service type ... and a DNS domain name of apps.example.net.", which is
not the case according to
>I found the part "and a DNS domain name of apps.example.net." to be
confusing, as I initially read it as "the combination of an application
service type ... and a DNS domain name of apps.example.net.", which is
not the case according to the following sentence.
So I suggest
Hi,
My apologies for late response. I read the document and I generally
found it in a good state and thus support its publication. I have one
minor comment:
2nd paragraph of 6.4 reads:
These identifiers provide an application service type portion to be
checked, but that portion is
Hi,
the WGLC period is over, thanks to everybody who sent comments.
Regards,
Leif & Valery.
> Hi,
>
> this message starts a Working Group Last Call for
> draft-ietf-uta-rfc6125bis-06:
> https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/
>
> The WGLC will last for two weeks and will
Hi,
> We have not yet seen that there is WG consensus to accommodate Martin's
> point. Can the chairs handle
> that? If there is consensus, then the wording needs to be discussed and the
> WGLC should be re-started.
The chairs think that the rough consensus is to limit the scope of the draft
On Fri, Jul 1, 2022, at 03:17, Peter Saint-Andre wrote:
>> I believe this document could just point to the HTTP RFC as advise for
>> protocols that support IP addresses, as I have also said.
>
> That might work.
I could live with that if there is pushback on a more complete change.
That said, I
On 6/30/22 8:18 AM, Salz, Rich wrote:
A reference identity of type IP-ID matches if the address is
identical to an iPAddress value of the subjectAltName extension of
the certificate.
My concern about this is what I stated before. This document, and its
predecessor,
> A reference identity of type IP-ID matches if the address is
identical to an iPAddress value of the subjectAltName extension of
the certificate.
My concern about this is what I stated before. This document, and its
predecessor, clearly state that they are about domain
On Thu, Jun 30, 2022, at 07:03, Peter Saint-Andre wrote:
> I think Martin is suggesting that we add the matching rule to 6125bis:
>
>A reference identity of type IP-ID matches if the address is
>identical to an iPAddress value of the subjectAltName extension of
>the certificate.
On 6/29/22 7:16 AM, Salz, Rich wrote:
Re: https://httpwg.org/specs/rfc9110.html#https.ip-id
6125-bis has always been solely about names, specifically fully-qualified
domain names. It has not been explicitly discussed, but I think the WG
understanding is as I just described it.
Looking at the
Re: https://httpwg.org/specs/rfc9110.html#https.ip-id
6125-bis has always been solely about names, specifically fully-qualified
domain names. It has not been explicitly discussed, but I think the WG
understanding is as I just described it.
Looking at the section above, I don't see what 6125bis
>I think this is better: "The rules specified here apply whenever service
identities are included in X.509 certificates, either directly or
indirectly through credentials derived from such a certificate."
Work for me!
___
Uta mailing list
I realize that this WGLC deadline passed, but maybe I can exploit the fact that
discussion is continuing to ask for one last change (apologies for not writing
this up sooner, I haven't been following closely).
RFC 9110 Section 4.3.5 (https://httpwg.org/specs/rfc9110.html#https.ip-id)
contains
On 6/28/22 11:12 AM, Salz, Rich wrote:
With regard to PKIX certificates, the primary usage is in the
context of the public key infrastructure described in {{5280}}.
In addition, technologies such as DNS-Based Authentication
of Named Entities (DANE) {{RFC6698}} sometimes use
The new text is kind-of normative, but IMO it's a significant improvement over
the old text. Thanks!
On 6/27/22, 22:16, "Peter Saint-Andre" wrote:
On 6/24/22 5:07 PM, Peter Saint-Andre wrote:
>> * Which identifier types a client includes in its list of reference
>> identifiers,
>With regard to PKIX certificates, the primary usage is in the
context of the public key infrastructure described in {{5280}}.
In addition, technologies such as DNS-Based Authentication
of Named Entities (DANE) {{RFC6698}} sometimes use certificates based
on PKIX (more
On 6/27/22 4:33 PM, Peter Saint-Andre wrote:
On 6/27/22 4:27 PM, Viktor Dukhovni wrote:
On Mon, Jun 27, 2022 at 02:37:22PM -0600, Peter Saint-Andre wrote:
It does for the majority of the certificate usages, but in practice
today DANE is primarily used with SMTP, and predominantly with
On 6/28/22 8:14 AM, Viktor Dukhovni wrote:
On Mon, Jun 27, 2022 at 04:31:25PM -0600, Peter Saint-Andre wrote:
I'm not necessarily saying that - I'm saying only that Jeff and I tried
to find a canonical definition of "fully-qualified domain name" and the
best we could do was RFC 1034.
On Mon, Jun 27, 2022 at 04:31:25PM -0600, Peter Saint-Andre wrote:
> >> I'm not necessarily saying that - I'm saying only that Jeff and I tried
> >> to find a canonical definition of "fully-qualified domain name" and the
> >> best we could do was RFC 1034. Alternative proposals are welcome.
> >
>RFC 6125 (and now 6125bis) are not documents about the definition or
enforcement of DNS naming rules, only about client-side matching of
service identifiers presented in X.509 certificates against the client's
conception of what the service ought to be (i.e., against a
On 6/27/22 4:27 PM, Viktor Dukhovni wrote:
On Mon, Jun 27, 2022 at 02:37:22PM -0600, Peter Saint-Andre wrote:
It does for the majority of the certificate usages, but in practice
today DANE is primarily used with SMTP, and predominantly with
DANE-EE(3) TLSA records, in which case identity
On 6/27/22 4:13 PM, Viktor Dukhovni wrote:
On Mon, Jun 27, 2022 at 02:43:43PM -0600, Peter Saint-Andre wrote:
On 6/27/22 1:08 PM, Viktor Dukhovni wrote:
On Mon, Jun 27, 2022 at 12:52:00PM -0600, Peter Saint-Andre wrote:
Yep, we can punt the definition but then we need to address all the
On Mon, Jun 27, 2022 at 02:37:22PM -0600, Peter Saint-Andre wrote:
> > It does for the majority of the certificate usages, but in practice
> > today DANE is primarily used with SMTP, and predominantly with
> > DANE-EE(3) TLSA records, in which case identity questions are settleda
> > at the DNS
On Mon, Jun 27, 2022 at 02:43:43PM -0600, Peter Saint-Andre wrote:
> On 6/27/22 1:08 PM, Viktor Dukhovni wrote:
> > On Mon, Jun 27, 2022 at 12:52:00PM -0600, Peter Saint-Andre wrote:
> >
> >>> Yep, we can punt the definition but then we need to address all the
> >>> special cases.
> >>
> >> I
On 6/27/22 1:08 PM, Viktor Dukhovni wrote:
On Mon, Jun 27, 2022 at 12:52:00PM -0600, Peter Saint-Andre wrote:
Yep, we can punt the definition but then we need to address all the special
cases.
I would prefer to bring back the reference to RFC 1034.
A DNS FQDN is sequence of dot-separated
On 6/25/22 2:43 PM, Viktor Dukhovni wrote:
On Sat, Jun 25, 2022 at 10:13:28PM +0300, Yaron Sheffer wrote:
My question was about identity validation, which is what 6125bis is
about. So it's a subset of your second option, "validation of
certificates". And yes, this boils to, are DANE-based EE
On 6/24/22 5:07 PM, Peter Saint-Andre wrote:
* Which identifier types a client includes in its list of reference
identifiers, and their priority, is a matter of local policy - given
the situation today, can we have a normative recommendation for
clients to be strict in constructing their
On Mon, Jun 27, 2022 at 12:52:00PM -0600, Peter Saint-Andre wrote:
> > Yep, we can punt the definition but then we need to address all the special
> > cases.
>
> I would prefer to bring back the reference to RFC 1034.
A DNS FQDN is sequence of dot-separated labels each of whose wire forms
is
Most items Yaron raised (thanks for the review!) are addressed in
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/50/files
>> * The DTLS reference should change to DTLS 1.3.
>> * See Appendix A of [VERIFY]
>> * The rules are brief - it's not clear from the
On 6/25/22 8:30 AM, Yaron Sheffer wrote:
Thank you Rich and Peter, some follow-ups below.
Yaron
On 6/25/22, 02:07, "Peter Saint-Andre" wrote:
> In the archive [1], Yaron's message continued as follows...
>
> ###
>
> * No definition is given for "FQDN"
On Mon, Jun 27, 2022 at 05:15:09PM +, Salz, Rich wrote:
> Does a DANE certificate have the same "name" as a non-DANE
> certificate?
Yes, the name is a DNS name, and for DANE certificate usages PKIX-TA(0),
PKIX-EE(1) and DANE-TA(2) the same logic applies to the EE certificate
as in PKIX with
Does a DANE certificate have the same "name" as a non-DANE certificate? If the
subjectAltNAME for a DANE-based certificate is the same as for non-DANE, then
yes the rules should apply. If not, no.
I cannot answer that question, and look to you experts to advise us.
Note that "validating the
On Sat, Jun 25, 2022 at 10:13:28PM +0300, Yaron Sheffer wrote:
> My question was about identity validation, which is what 6125bis is
> about. So it's a subset of your second option, "validation of
> certificates". And yes, this boils to, are DANE-based EE certificates
> expected to adhere to the
Hi Viktor,
My question was about identity validation, which is what 6125bis is about. So
it's a subset of your second option, "validation of certificates". And yes,
this boils to, are DANE-based EE certificates expected to adhere to the draft's
requirements.
And the reason I raised this
On Fri, Jun 24, 2022 at 07:04:28PM +0300, Yaron Sheffer wrote:
> * Similarly, it is not clear to me whether certs obtained through DANE
> are in or out of scope.
I may be able to help, but I am struggling to understand the question in
sufficient detail. Can you be more specific about:
-
Thank you Rich and Peter, some follow-ups below.
Yaron
On 6/25/22, 02:07, "Peter Saint-Andre" wrote:
On 6/24/22 4:40 PM, Peter Saint-Andre wrote:
> The list admins might want to be aware that this message was truncated
> as follows (at least for me and Rich)...
>
On 6/24/22 4:40 PM, Peter Saint-Andre wrote:
The list admins might want to be aware that this message was truncated
as follows (at least for me and Rich)...
On 6/24/22 10:04 AM, Yaron Sheffer wrote:
So here's a few comments. Thanks Valery for the reminder!
* The DTLS reference should change
The list admins might want to be aware that this message was truncated
as follows (at least for me and Rich)...
On 6/24/22 10:04 AM, Yaron Sheffer wrote:
So here's a few comments. Thanks Valery for the reminder!
* The DTLS reference should change to DTLS 1.3.
* See Appendix A of [VERIFY]
*
Thanks for the feedback Yaron!
* The DTLS reference should change to DTLS 1.3.
Updated. Fun factoid, RFC6347 (dtls 1.2) is not RFC9147, 1800 apart. (
* See Appendix A of [VERIFY]
Fixed.
* The rules are brief - it's not clear from the text if this is a summary
of the totality of
uot; wrote:
Hi,
this is a reminder, that WGLC for draft-ietf-uta-rfc6125bis-06
is still in progress and we received no single message
in response to the call. Please, consider reviewing the draft
(possibly once again) and sending your opinion about its shape.
We hope people do care.
Hi,
this is a reminder, that WGLC for draft-ietf-uta-rfc6125bis-06
is still in progress and we received no single message
in response to the call. Please, consider reviewing the draft
(possibly once again) and sending your opinion about its shape.
We hope people do care.
Regards,
Leif & Va
Hi,
this message starts a Working Group Last Call for
draft-ietf-uta-rfc6125bis-06:
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/
The WGLC will last for two weeks and will end June the 27th.
Please send your comments to the list before this date.
Regards,
Leif & Valery.
49 matches
Mail list logo
