[Uta] Requesting adoption of draft-rsalz-use-san

I presented this at SECDISPATCH, which said “get thee to UTA” The draft is short, five pages, and updates RFC 6125 as described below. 6125 was AD sponsored. The draft below addresses some feedback given during the SECDISPATCH session. Name: draft-rsalz-u

Re: [Uta] Adoption of draft-rsalz-use-san

> I think it would be much better to rewrite RFC 6125 with all the patches > applied, and then have that new document obsolete RFC 6125 instead of > updating it. I took another look at 6125 and I am happy to put up a draft if the WG prefers that approach. ___

Re: [Uta] Adoption of draft-rsalz-use-san

>I’m quite certain this is NOT what Rich had in mind when he was writing > the document, and thus my suggestions. There are more things in heaven and earth, Horatio, than are covered by your draft :) Happy to add some wording if anyone has suggestions. _

Re: [Uta] Adoption of draft-rsalz-use-san

Your suggestions seem okay to me, and we can work on it once adopted. Thanks! ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Adoption of draft-rsalz-use-san

BTW, recorded here: https://github.com/richsalz/draft-rsalz-use-san/issues/1 From: Rich Salz Date: Monday, March 15, 2021 at 1:29 PM To: Eliot Lear Cc: "uta@ietf.org" Subject: Re: [Uta] Adoption of draft-rsalz-use-san Your suggestions seem okay to me, and we can work on it once adopted. Thank

Re: [Uta] Adoption of draft-rsalz-use-san

* It actually looks pretty good to me. The only thing I disagree with is "Severs either MUST NOT issue a CN-ID, or MUST use a form for the Common Name RDN that cannot be mistaken for an identifier" and similar language. It would be better to let people put whatever they want in the CN field

Re: [Uta] Adoption of draft-rsalz-use-san

* The draft is adopted. Rich, can you please re-issue the draft with draft-ietf-uta-* name. Posted, waiting confirmation from the chairs. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

[Uta] How should we change draft-ietf-use-san?

I don’t know of a good way to address the concern raised by Eliot [1]. I don't want to make the requirements weaker. I would really like to hear from others. [1] https://mailarchive.ietf.org/arch/msg/uta/ayfVzc_j0kK7wY0_cW8OR9r81LE/ ___ Uta mailing li

Re: [Uta] How should we change draft-ietf-use-san?

* I would very much like to stick to the original idea I proposed back before the initial draft: Let's just rewrite RFC 6125 to remove the concept of CN-ID, and call it a day. Don't put any requirements on producers of certificates. They can put whatever they want into the Common Name field

Re: [Uta] How should we change draft-ietf-use-san?

I am of mixed-mind about Eliot’s suggestions. The phrase that keeps coming back is “we’re not the protocol police.” If an application wants to stay on its own specifications, and not follow the use-san document, it almost seems like it should just do that, and not clutter up use-san with esca

Re: [Uta] Some draft-ietf-uta-use-san nits

Victor suggests replacing section 3.3 as follows: OLD: When constructing a list of reference identifiers, the client MUST NOT include any CN-ID present in the certificate. ... NEW: When constructing a list of presented DNS identifiers, the client MU

Re: [Uta] How should we change draft-ietf-use-san?

I am beginning to think that doing a complete re-issue of 6125 will be better, because trying to fit the “patch” described below seems awkward. On the other hand, if anyone has suggestions on how to do that, please post or email or make a PR at https://github.com/richsalz/draft-rsalz-use-san F

Re: [Uta] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

>In summary, I don't see anything in use-san that will affect BRSKI. That is great to hear, thanks for the careful analysis. >Some nits: All look like good things to do, I'll make a PR soonish. What do you think of just rewriting this to completely replace 6125, rather than trying to b

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

>There are a VAST number of devices that run off of iDevIDs: they never > transition off of them. I’m not a fan, but that’s what they do. Okay, so this draft doesn't apply to them. There doesn't seem to be a problem with, say, not using TLS 1.3 in cases, or not using ECDH in some cases, so

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

>As I wrote, I think we’re past it, because this is about domain/IP address > validation and not client cert validation. Correct? Ah, right. Thanks. Too many balls in the air :) ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/list

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

[Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san For what it's worth, On Fri, May 14, 2021 at 1:52 PM Michael Richardson mailto:mcr%2bi...@sandelman.ca>> wrote: Salz, Rich mailto:rs...@akamai.com>> wrote: > That is great to hear, thanks for the careful anal

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

* I believe the “obsoleting” path is a better choice here. In general, the “Updates” field can be interpreted in different ways, while “Obsoletes” is straightforward. In addition, 6125 does not have other documents updating it, so that information would not be lost by obsoleting it. Just b

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

* there are few errata for RFC 6125 with different status (mostly Reported, but at least one - Held for Document Update) - RFC Errata Report » RFC Editor (rfc-editor.org)

Re: [Uta] High level comments on draft-ietf-uta-use-san

* Some sections mention "server" while other sections does not state anything, therefor applying to both client and server. I think the draft needs to be very clear on this point. * I saw that there was a discussion on client certs and that some client certs are built with CN and can

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

* IMO it's fine to contact the authors of an original RFC and point out that an update is needed. But it's really presumptuous and rude to appoint oneself a co-author of a bis document and suggest that the original authors should become co-authors. IMO that should be a last resort option

Re: [Uta] [Iotops] BRSKI and IDevID (non-!)issues with draft-ietf-uta-use-san

After Valery’s suggestion I wrote to Jeff and Peter on May 24. No reply yet, but it’s been a holiday weekend in the US. This particular document was AD-sponsored, so perhaps Keith’s thoughts are more applicable. For WG docs, however, another aspect to consider is that the WG owns the doc, the C

Re: [Uta] draft-ietf-uta-rfc6125bis replacement status updated by Valery Smyslov

Following the recommendations of our AD and WG chairs, I uploaded a new version of "use-san" to be a complete replacement of RFC6125. Peter and Jeff have agreed to be co-authors. Carsten graciously used tooling to convert the RFC Published XML to markdown. There is a GitHub repo for the document

Re: [Uta] draft-ietf-uta-rfc6125bis replacement status updated by Valery Smyslov

> Following the recommendations of our AD and WG chairs, I uploaded a new > version of "use-san" to be a complete replacement of RFC6125. Peter and Jeff > have agreed to be co-authors. Carsten graciously used tooling to convert the > RFC Published XML to markdown. There is a GitHub repo for th

Re: [Uta] draft-ietf-uta-rfc6125bis replacement status updated by Valery Smyslov

> Following the recommendations of our AD and WG chairs, I uploaded a new > version of "use-san" to be a complete replacement of RFC6125. Peter and Jeff > have agreed to be co-authors. Carsten graciously used tooling to convert the > RFC Published XML to markdown. There is a GitHub repo for the

[Uta] Wildcards

A discussion started on the GitHub repo https://github.com/richsalz/draft-ietf-uta-rfc6125bis about what is allowed for the wildcard character, such as in DNS entries in subjectAltName. I am about to publish a new draft which takes the old adopted “diff” version and does a full version of 6125

Re: [Uta] Wildcards

In anticipation of consensus around "only * as the left-most label," I created a PR; https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/9 ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Wildcards

I agree with the reasoning, but I think you have to deprecate before removal and therefore not in this draft. We could update the security concerns and say MAY NOT about issuance perhaps. The text already says clients MAY use them. They're still allowed in the WebPKI, and I am unsure of non-web

Re: [Uta] Wildcards

I am adding the following commit to https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/9 which I will merge if/when we have consensus. Let me know if this is not ok. MAC ~/git/draft-ietf-uta-rfc6125bis$ g l1 commit d4dcbd397e1342c634f3ab19eb4bc52b4b7ef5e8 (HEAD -> simpler-wildcard) Autho

Re: [Uta] Wildcards

> +A wildcard in a presented identifier can only match exactly one label > in > +a reference identifier. Note that this is not the same as DNS wildcard > +matching, where the `*` label always matches at least one whole > +label and sometimes more. See {{DNS-CONCEPTS, Section 4.

Re: [Uta] Wildcards

>Support for wildcards in RFC 6125 is application-protocol specific, see Appedix B. Well, I want to make 6125bis be a Standard, not a best practices, so Appendix B is gone from my draft :) But yes, I still want wildcards to be a MAY. Perhaps a SHOULD. ___

Re: [Uta] Wildcards

* that further validation happens outside (before, after, or in parallel to) RFC 6125 processing. It seems like it would be worthwhile for us to mention that in the beginning. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/u

Re: [Uta] Wildcards

I think the 6125 was explicit about what it covered, and I hope the new version will be more explicit: how to validate server “names” when using PKIX certs and TLS. Everything else is out of scope. As Viktor said, it’s often local policy. What RFC describes Chrome’s behavior? And why should t

Re: [Uta] Wildcards

>> I don't think that makes the above text incorrect, since this draft >> says "only the first label" >Sort of. The text I quoted does not. You could say "can only match the > leftmost label in ...". Assuming we have consensus, the PR on this says that the wildcard character can

Re: [Uta] rfc7525bis and CNSA

> We are wondering if the WG thinks it makes sense to adopt some of these recommendations and informatively reference draft-cooley-cnsa-dtls-tls-profile from rfc7525bis. I strongly support this. ___ Uta mailing list Uta@ietf.org https://www.ietf

[Uta] Removing "the directory" text

At the meeting yesterday, I said I think we should remove text about the X.500 directory and some people, quite reasonably, wanted to see the text. A diff is attached. You can also find it at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/10 It removes references to X.500, X.501,

[Uta] Planned 6125bis changes

I am planning on merging two pull requests next week, unless there is strong objection. I mentioned these at the last IETF. There has been no mailing list traffic on them. https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/10 Removes all mention of X.500 (The Directory) except to say “

Re: [Uta] Planned 6125bis changes

I merged the PR’s and draft-02 is now available at https://www.ietf.org/id/draft-ietf-uta-rfc6125bis-02.html, etc. From: Rich Salz Date: Monday, August 30, 2021 at 12:57 PM To: "uta@ietf.org" Subject: Planned 6125bis changes I am planning on merging two pull requests next week, unless there is

[Uta] Pinning

I would like to remove the discussion of pinning from 5126bis for the following reason: * It’s an escape hatch, saying “do all these things but if you don’t get a match, you can pin.” * The current wording allows its use, anyway. * Pinning is bad. A proposed change is in https://g

Re: [Uta] Pinning

>Perhaps the text can be made more concise, but I don't think full removal is warranted. This is *not* the fragile key pinning from HPKP. Right now the text has this. Is more needed? ### Failure: No Match Found If the client does not find a presented identifier matching any of the refe

Re: [Uta] Pinning

This is most of what's needed. Plus something along the lines of: In some cases the user should be able to accept the certificate in question as valid also for subsequent connections. Such ad-hoc "pinning" should typically not restrict future connections to just

Re: [Uta] Pinning

>This is most of what's needed. Plus something along the lines of: I updated https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/19 to have something based on Viktor's suggestion. The main wording changes were about using MUST MAY SHOULD language in that whole section. _

Re: [Uta] High level comments on draft-ietf-uta-use-san

FYI, I created https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/21 for this. From: Brian Smith Date: Tuesday, June 1, 2021 at 6:34 PM To: Rich Salz Cc: "john.matts...@ericsson.com" , "uta@ietf.org" Subject: Re: [Uta] High level comments on draft-ietf-uta

Re: [Uta] High level comments on draft-ietf-uta-use-san

>RFC 6125 was written with TLS in mind (it's even mentioned in the title), and in any given TLS interaction one entity is the client and the other is the server. The use of these terms in RFC 6125 had nothing to do with what are usually called "client certs" (e.g., a certificate

[Uta] 6125bis changes

I merged the pinning PR. After Viktor’s addition it seemed non-controversial. It’s now only discussed in the “failed to find an identifier” section as a fallback. I have another PR, https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/23 that does a lot of editing on the Introduction sec

[Uta] 6125bis changes

I have a PR that does a lot of editing of the “naming” section. It is mostly editorial work, also an update for cross-protocol Attacks. It is at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/24 and is based on the existing PR to edit the “introduction” section. As with that, the

[Uta] 6125bis: client and server

John Mattson had pointed out that the document uses client and server, when in fact if you use mutual auth or machine-to-machine, that’s not really correct. Peter st Andre explained that it’s the terms used in TLS. I just merged a PR that addresses some of this, but not all. John and others int

Re: [Uta] 6125bis changes

I have merged the first two big, boring, editorial PR’s and would like WG feedback on the quoted text below. Thanks. From: "Salz, Rich" Date: Wednesday, September 22, 2021 at 2:58 PM To: "uta@ietf.org" Subject: [Uta] 6125bis changes I have a PR that does a lot of ed

Re: [Uta] 6125bis: client and server

> I just merged a PR that addresses some of this, but not all. John and > others interested in this issue, should look at the new draft when > published next week. I'll try to take a look. Which PR number? Thank you Viktor. This pull request has the changes, https://github.com/

[Uta] Viktor's feedback

Viktor made some comments on https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/23 and here is my proposal to address them. diff --git a/draft-ietf-uta-rfc6125bis.md b/draft-ietf-uta-rfc6125bis.md index 28cc46f..8bb46f4 100644 --- a/draft-ietf-uta-rfc6125bis.md +++ b/draft-ietf-uta-rfc6

[Uta] 6125bis -- security considerations

I am proposing the following for the security section. Any comments? In particular, what about the “multiple identifiers” at the last few lines? Should that go away now? If so, that will have ripple effects. This text is currently at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pul

Re: [Uta] 6125bis -- security considerations

Your suggestions make sense to me. Let’s see if anyone disagrees. Thanks for reading! I agree about the PSL and spreading it around. Maybe just drop the reference? But then, I understood what you wrote about crossing the beams, er administrative domains. _

Re: [Uta] 6125bis -- security considerations

Thanks for your feedback, Ryan and Alexey. I basically did what you suggested. I share your concerns about the public suffix list. Does the WG have any thoughts? FYI, Ryan wrote this: * I'm a little sad any time there is a new dependency on the public suffix list, even informative :) I

Re: [Uta] 6125bis -- security considerations

* What sort of ripple effects are you thinking? Purely editorial within the document which talks about one or more DNS-ID/URI-ID in a couple of places. * I agree that, in practice, the use of multiple names has been normalized beyond the "SNI workaround" (e.g. the discussions on cross-

Re: [Uta] 6125bis -- security considerations

Thanks for the contribution, Ryan. I already merged your two smaller changes around SNI and ALPN. I hope the WG will comment on the larger text you provided, below. Ryan’s mail. I'm specifically proposing splitting up "Multiple Identifiers" into two discussions - "Multiple Presented Identifier

Re: [Uta] 6125bis -- multiple identifiers (was security considerations)

* It started off with this discussion, but clearly, it's a much broader change. It does try and reintroduce the ALPN conversation, although with a looser 2119 fit, and trying to explain the "why" of the SHOULD, in a way directly relevant to this specification, in a way that is hopefully acce

[Uta] Editorial changes to 6125bis

I have a number of editorial changes I want to make to the draft. Most of them are about avoiding redundant terms like “client” instead of “interactive or automated client” and CA, etc., instead of “certification authority”, etc. The diffs are big (83 lines added and 95 lines removed, for a di

Re: [Uta] Editorial changes to 6125bis

arity, but these are not blocking and entirely optional. On Wed, Oct 20, 2021 at 11:21 AM Salz, Rich mailto:40akamai@dmarc.ietf.org>> wrote: I have a number of editorial changes I want to make to the draft. Most of them are about avoiding redundant terms like “client” instead of “interact

Re: [Uta] 7525bis: recommend RSASSA-PSS in TLS 1.2?

>Well, we've been thinking specifically about whether to recommend PSS for TLS 1.2 implementations and deployments. Naturally you get PSS for free if you've upgraded to TLS 1.3, but do we want to say that if you haven't upgraded to TLS 1.3 yet you should update your TLS 1.2

Re: [Uta] 7525bis: recommend RSASSA-PSS in TLS 1.2?

> This has been my impression, too, but we want to check with the list. OpenSSL has a comment "/* Only allow PSS for TLS 1.3 */" and it looks like the code (tls12_check_peer_sigalg() in ssl/t1_lib.c) enforces that. ___ Uta mailing list Uta@ietf.org

Re: [Uta] 7525bis: recommend RSASSA-PSS in TLS 1.2?

>So if OpenSSL client connects to server that supports PSS but not TLS 1.3, the connection will fail because the client vomits at the server response? I *think* it will fail cleanly because it gets an ALERT message, but I am not sure. I am no longer involved with OpenSSL, I just did a

Re: [Uta] [TLS] supported_versions in TLS 1.2

* So, yes, I'd agree there's not much benefit to recommend that a TLS-1.2-only implementation add supported_versions, or that an operator look for such an implementation. Any implementation-gated effort is better spent getting to TLS 1.3. I agree that if you have supported_versions than y

[Uta] 6125bis: proposed new title

In https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/36 I suggest changing the title to: “On TLS Service Names” I also added the following to the acknowledgement section. If I left you out, please let me know. +In addition to discussion on the mailing list, the following people +contri

[Uta] 6125bis: multiple identifiers

Ryan Sleevi has proposed adding the text below to the security considerations section. I’ve posted about this before and had miniscule feedback. Barring strong objections, I intend to merge this near the end of the week and publish a new draft containing this and the name-change. ## Multiple P

Re: [Uta] 6125bis: proposed new title

For those not active in GitHub, Martin suggests -title: On TLS Service Names +title: Service Names in TLS I don’t care, although I have a mild preference for the historic “On …” construct. From: Rich Salz Date: Tuesday, November 16, 2021 at 2:48 PM To: "uta@ietf.org" Subject: 6125bis: proposed

Re: [Uta] 6125bis: proposed new title

> Just to elaborate slightly. I read "On X" as being a dissertation about a > subject, whereas the other form reads as being definitive. I believe we're > aiming for definitive in this work and so would prefer to avoid demurring. Fair comment; changed. __

[Uta] FW: New Version Notification for draft-ietf-uta-rfc6125bis-04.txt

This version includes the various editorial changes etc as discussed on-list and last week. It *does not* include the text on multiple identifiers as that discussion still seems to be going on. On 11/18/21, 12:58 PM, "internet-dra...@ietf.org" wrote: A new version of I-D, draft-ietf-ut

Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-04.txt

I find Viktor's description of the asymmetry between clients and servers to be spot-on. John, could you craft a sample sentence you'd like to see? Something like this as a new sentence at the end of the second paragraph of the "In Scope" section: In cases where both parties are part of

Re: [Uta] Some quick comments on some changes in draft-ietf-uta-rfc6125bis-04

Alexey, Thanks very much for your comments. I was a little over-zealous :). Does this diff address your concerns? It's also at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/37 ; g diff diff --git a/draft-ietf-uta-rfc6125bis.md b/draft-ietf-uta-rfc6125bis.md index bf8eb3d..8f1080e 1

Re: [Uta] Some quick comments on some changes in draft-ietf-uta-rfc6125bis-04

> Thanks very much for your comments. I was a little over-zealous :). Does this diff address your concerns? >Works for me. Merged into the editor's copy. Thanks. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] WGLC for draft-ietf-uta-rfc7525bis-04

I am reading this now. It’s good, I like it. One nit; should Section 4.2 be titled “Cipher Suites for TLS 1.2” ? In section 6.4, the “(e.g., even more than a few hours)” should probably replace it with “(in some cases, even as little as a few hours)” but it would be REALLY helpful for guidance

[Uta] 7525bis and Certificate Transparency

On-list discussion of https://github.com/yaronf/I-D/issues/273 This is about section 6.5, “Certificate Revocation” Starting the bullet list saying “CRLs are the most widely supported mechanism” should really have a qualifier. Something like “While in the general PKI case, CRL’s are …” I mean,

Re: [Uta] OCSP in RFC7525bis

* We would be grateful for feedback based on implementation experience. In particular if you have quantitative data on the use or quality of OCSP that’s more recent than Chung18 [3], that would be very useful. For what it’s worth, *our* customers want OCSP stapling. (It’s enabled by default

Re: [Uta] [TLS] OCSP in RFC7525bis

>I share your skepticism, but i'm still trying to salvage something useful -- for the purpose of defending against CA malfeasance -- from the mechanisms we have available. For that, you mainly want certificate transparency, no? > If certificate validation is the process of confirmin

Re: [Uta] FW: New Version Notification for draft-ietf-uta-rfc7525bis-05.txt

I re-read the document. It's very nice. A few nits, I think all are editorial and can be fixed later. I support moving this doc forward. I note that you say "use encrypted client hello when it's ready" Do you want to make the same recommendation for DTLS 1.3? Do you want to say anything abo

Re: [Uta] FW: New Version Notification for draft-ietf-uta-rfc7525bis-05.txt

Your answers all make sense. I think 6125bis is more appropriate than 6125, but that would probably mainly depend on publication schedule. >You and Peter know best. Do you mind if I show that to my wife? :) ___ Uta mailing list Uta@ietf.org http

Re: [Uta] Second WGLC for draft-ietf-uta-rfc7525bis-05

* I’ve tried to register ALPN for SIP/2.0 for a long time now, but fail to get responses and confusing ones. I don’t recall seeing the request, and I am one of the designated experts for the TLS registries. I wonder where you asked? tls-reg-rev...@iana.org

Re: [Uta] Second WGLC for draft-ietf-uta-rfc7525bis-05

> In fact if you look up the relevant IANA page [1], it refers to Sec. 17 of > RFC 8447, which in turn lists the email address that Rich mentions at > iana.org. You're right. Every TLS registry has that note. Ugh, I missed it. And I swear I looked at a registry before my note. (

Re: [Uta] Second WGLC for draft-ietf-uta-rfc7525bis-05

>we'd like to have more explicit confirmation that people are happy with the way the concerns revealed in the first WGLC were addressed. Hey, the draft is OK. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] review of specs that cite RFC 6125

>* RFC 8314 discusses pinned certificates and points to RFC 6125 for further discussion about pinning; although we're removing this text from 6125bis, the pointer to RFC 6125 will remain valid. It's not completely removed, but it has fallen out of favor :) There's still text, but i

[Uta] Multiple identifiers in 6125bis

The only open item left is around “multiple identifiers” The main (only?) people participating in the discussion have been Martin Thomson and Ryan Sleevi. Ryan contributed some text, it got some feedback from Martin. The email thread started at [1] by Ryan. He proposed some text in an unrelate

[Uta] FW: [Ntp] Wildcards in NTS certificate checking

A new reader in the NTP working group had some feedback on 6125bis. >The part that I was looking for was an explicit statement that the "SHOULD > NOT contain the wildcard" has been dropped. It might help to add something like that to the 3rd bullet in section 1.2 I propose to add

Re: [Uta] secdispatched: draft-ciphersuites-in-sec-syslog-01

>Folks - is there any interest working on this in UTA? I support adoption. I'll read and give feedback. Should be a pretty easy doc to finish off. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta

Re: [Uta] Multiple identifiers in 6125bis

Ya got slightly less than 24 hours to complain :) From: Rich Salz Date: Monday, April 18, 2022 at 10:16 AM To: "uta@ietf.org" Subject: Multiple identifiers in 6125bis The only open item left is around “multiple identifiers” The main (only?) people participating in the discussion have been Mar

Re: [Uta] FW: [Ntp] Wildcards in NTS certificate checking

This is now an open issue https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/44 On 4/19/22, 7:42 PM, "Peter Saint-Andre" wrote: On 4/19/22 12:14 PM, Salz, Rich wrote: > A new reader in the NTP working group had some feedback on 6125bis. > >>

Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-05.txt

This version has a handful of changes since the last draft. There are a handful of editorial improvements (courtesy Martin, Hal, Ryan, Peter, Olle, Viktor, Alexey; apologies if I missed anyone). Also the text on "multiple identifiers" was merged. There are now two open issues: some more exampl

Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-06.txt

Colleagues, With this draft we (the authors) think the document is done. We received a lot of excellent feedback and comments, and incorporated pretty much all of it. We believe this document is ready for WGLC, and ask the chairs to do that. Depending on what happens during the WGLC, we'll want

Re: [Uta] I-D Action: draft-ietf-uta-rfc6125bis-06.txt

Thanks for the review! * - I think QUIC should be mentioned already in section 1.1 and mentioned everytime DTLS is mentioned I made some changes so that things are more “equal” at https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/48 Please take a look. * - The document use

Re: [Uta] Extended Master Secret as a MUST in 7525bis

* We are now addressing AD reviews for rfc7525-bis. Ben Kaduk asked why we only added TLS 1.2 Extended Master Secret support as a SHOULD, and we tend to agree (given widespread support of this feature) that is needs to be a MUST [1]. We would appreciate the group’s input before we make this

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

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 t

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

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 ch

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

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 te

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

>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 reference

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

>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 precisely

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

>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

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

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

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

> 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 names.

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

>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

Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

>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 me

Re: [Uta] [Last-Call] Secdir telechat review of draft-ietf-uta-rfc7525bis-09

* Every TLS implementation maintains divided codebases for 1.2 vs 1.3. No one reads the TLS 1.2 code very closely these days, in my experience Strongly disagree. OpenSSL, and its forks do not have a divided codebase. As for reading the code, I can’t argue with your experience, but in my ex

Re: [Uta] [Last-Call] Secdir telechat review of draft-ietf-uta-rfc7525bis-09

* It is definitely the "BCP" already--there are good reasons not to support TLS 1.2 on a server, and good reasons for clients not to connect to a server that negotiates it. What are they? ___ Uta mailing list Uta@ietf.org https://www.ietf.org/ma

  1   2   3   >