[{"author": "Sean Turner", "text": "<p>morning!</p>", "time": "2025-07-22T07:31:59Z"}, {"author": "Thom Wiggers", "text": "<p>morning</p>", "time": "2025-07-22T07:34:06Z"}, {"author": "Sophie Schmieg", "text": "<p>For certain values of fun</p>", "time": "2025-07-22T07:37:07Z"}, {"author": "Yoav Nir", "text": "<p>Author HA</p>", "time": "2025-07-22T07:37:17Z"}, {"author": "Tim Hollebeek", "text": "<p>Just take the limit as fun goes to infinity.</p>", "time": "2025-07-22T07:39:54Z"}, {"author": "Corey Bonnell", "text": "<p>If hint is a FQDN, then probably PrintableString would be better than IA5String</p>", "time": "2025-07-22T07:49:49Z"}, {"author": "Russ Housley", "text": "<p>the underscore character (\"_\") is not part of the PrintableString character set as defined in ASN.1. PrintableString</p>", "time": "2025-07-22T07:52:29Z"}, {"author": "Thom Wiggers", "text": "<p>are underscores allowed in FQDN?</p>", "time": "2025-07-22T07:52:50Z"}, {"author": "Tim Hollebeek", "text": "<p>way too many electrons have died on that hill</p>", "time": "2025-07-22T07:53:16Z"}, {"author": "Emil Lundberg", "text": "<p>I think the difference here is between<br>\n{stmt: serialize(foo), hint: \"bar\" }<br>\nand<br>\n{ stmt: serialize({ value: foo, hint: \"bar\" }) }</p>", "time": "2025-07-22T07:53:17Z"}, {"author": "Tim Hollebeek", "text": "<p>yep, essentially</p>", "time": "2025-07-22T07:54:22Z"}, {"author": "Thom Wiggers", "text": "<p>I don't know anything about this problem space but if \"passports\" need an url and other statements need another type of string then there is something to be said for another layer that could be more selectable based on the type field (with a view to future expansion)</p>", "time": "2025-07-22T07:57:00Z"}, {"author": "Michael Richardson", "text": "<p>I wonder if there are others who want to argue/explain/interpret MSJ's comments?</p>", "time": "2025-07-22T07:57:11Z"}, {"author": "Mike Ounsworth", "text": "<p><span class=\"user-mention silent\" data-user-id=\"6280\">Emil Lundberg</span> <a href=\"#narrow/channel/68-lamps/topic/ietf-123/near/169441\">said</a>:</p>\n<blockquote>\n<p>I think the difference here is between<br>\n{stmt: serialize(foo), hint: \"bar\" }<br>\nand<br>\n{ stmt: serialize({ value: foo, hint: \"bar\" }) }</p>\n</blockquote>\n<p>I belive MSJ is now asking us to go find all the defined container formats and define specific <code>serialize({value: foo, hint: \"bar\"})</code> for each container type in the world.</p>", "time": "2025-07-22T07:57:38Z"}, {"author": "Dennis Jackson", "text": "<p>Chairs: Can you help the conversation move forwards?</p>", "time": "2025-07-22T07:57:54Z"}, {"author": "Michael Richardson", "text": "<p><span class=\"user-mention silent\" data-user-id=\"86\">Thom Wiggers</span> <a href=\"#narrow/channel/68-lamps/topic/ietf-123/near/169449\">said</a>:</p>\n<blockquote>\n<p>I don't know anything about this problem space but if \"passports\" need an url and other statements need another type of string then there is something to be said for another layer that could be more selectable based on the type field (with a view to future expansion)</p>\n</blockquote>\n<ol>\n<li>They aren't literal passports. It's a model. Please see RFC9334.   2. if you add a layer, then you wind up forcing every single vendor to register with IANA for an identical thing.</li>\n</ol>", "time": "2025-07-22T07:58:23Z"}, {"author": "Thom Wiggers", "text": "<p>1) yeah that's why I put it in quotes</p>", "time": "2025-07-22T07:58:42Z"}, {"author": "Michael Richardson", "text": "<p><span class=\"user-mention silent\" data-user-id=\"86\">Thom Wiggers</span> <a href=\"#narrow/channel/68-lamps/topic/ietf-123/near/169459\">said</a>:</p>\n<blockquote>\n<p>1) yeah that's why I put it in quotes</p>\n</blockquote>\n<p>So, <em>this</em> is the selectable layer.</p>", "time": "2025-07-22T07:59:22Z"}, {"author": "Thom Wiggers", "text": "<p>would it be possible to define a generic container format \"FORMAT-WITH-HINT\" in the outer type and then the inner value of statement is (oid, stmt, hint)</p>", "time": "2025-07-22T08:03:47Z"}, {"author": "Thom Wiggers", "text": "<p>and then FORMAT-WITH-AUX would be the same structure but MSJs version</p>", "time": "2025-07-22T08:04:42Z"}, {"author": "Michael Richardson", "text": "<p><span class=\"user-mention silent\" data-user-id=\"86\">Thom Wiggers</span> <a href=\"#narrow/channel/68-lamps/topic/ietf-123/near/169492\">said</a>:</p>\n<blockquote>\n<p>would it be possible to define a generic container format \"FORMAT-WITH-HINT\" in the outer type and then the inner value of statement is (oid, stmt, hint)</p>\n</blockquote>\n<p>The point of the authors is that we've defined EXACTLY that.</p>", "time": "2025-07-22T08:04:44Z"}, {"author": "Thom Wiggers", "text": "<p>I guess you're just unpacking hint into the outer layer and with OPTIONAL it's usually just not there if you want to do something else</p>", "time": "2025-07-22T08:05:31Z"}, {"author": "Michael Richardson", "text": "<p><span class=\"user-mention silent\" data-user-id=\"86\">Thom Wiggers</span> <a href=\"#narrow/channel/68-lamps/topic/ietf-123/near/169505\">said</a>:</p>\n<blockquote>\n<p>I guess you're just unpacking hint into the outer layer and with OPTIONAL it's usually just not there if you want to do something else</p>\n</blockquote>\n<p>The next layer is format-specific. (CWM, WebAuthN, etc..).  We'd have to add yet-another-layer of OID+type.</p>", "time": "2025-07-22T08:06:33Z"}, {"author": "Emil Lundberg", "text": "<p>I'm not very familiar with LAMPS but very familiar with WebAuthn: if you're talking about WebAuthn attestation objects, why not use the \"fmt\" attribute embedded in the attestation object?<br>\nAlso YubiKeys emit the \"packed\" attestation statement format which is the FIDO2 standard and not proprietary</p>", "time": "2025-07-22T08:12:36Z"}, {"author": "Deirdre Connolly", "text": "<p><span aria-label=\"donkey\" class=\"emoji emoji-1facf\" role=\"img\" title=\"donkey\">:donkey:</span></p>", "time": "2025-07-22T08:15:08Z"}, {"author": "Jean-Pierre Fiset", "text": "<p>The hint has the advantage to allow an implementer to move forward without having to request an OID.</p>", "time": "2025-07-22T08:16:31Z"}, {"author": "Michael StJohns", "text": "<p>@jean.   That\u2019s not actuallly a thing.  Most companies have an enterprise number under 1.3.6.1.4.1 and can allocate oids without any delay.  Enterprise numbers are free and easy to get quickly- about a day</p>", "time": "2025-07-22T08:19:05Z"}, {"author": "Michael StJohns", "text": "<p>@corey - yes, printablestring (from \u201c\u201d) is actually where we should go with that def</p>", "time": "2025-07-22T08:20:19Z"}, {"author": "Tim Hollebeek", "text": "<p>Well, to be fair, it depends. In some organizations, if you know or are the right person, you can get an OID in 5 minutes. In other organizations, it might be an epic struggle. It's usually more of the former than that latter, but the amount of mileage, paperwork, and effort may vary significantly.</p>", "time": "2025-07-22T08:20:59Z"}, {"author": "Michael StJohns", "text": "<p>Not an IETF problem I would suggest</p>", "time": "2025-07-22T08:22:02Z"}, {"author": "Tim Hollebeek", "text": "<p>Yep, and if your organization can't do it, another probably can. I personally think the OID solution is potentially viable, but haven't thought it through as much as I'd like.</p>", "time": "2025-07-22T08:23:47Z"}, {"author": "Alicja Kario", "text": "<p>sha-1? really?</p>", "time": "2025-07-22T08:27:45Z"}, {"author": "Dmitry Belyavskiy", "text": "<p>I think it's a quoting of the rfc</p>", "time": "2025-07-22T08:28:19Z"}, {"author": "Alicja Kario", "text": "<p>ah, right... well, then we should update it...</p>", "time": "2025-07-22T08:28:32Z"}, {"author": "Rich Salz", "text": "<p>You can get an OID from IETF \"enterprise MIB\" arc trivially <a href=\"https://www.iana.org/assignments/enterprise-numbers/assignment/apply/\">https://www.iana.org/assignments/enterprise-numbers/assignment/apply/</a></p>", "time": "2025-07-22T08:29:14Z"}, {"author": "Alicja Kario", "text": "<p>yes, I've done that myself for a company of like 20 people, if your Corp is too obstinate, you can just ask for an OID for the department or something like that</p>", "time": "2025-07-22T08:30:18Z"}, {"author": "Mike Ounsworth", "text": "<p><span class=\"user-mention silent\" data-user-id=\"6280\">Emil Lundberg</span> <a href=\"#narrow/channel/68-lamps/topic/ietf-123/near/169544\">said</a>:</p>\n<blockquote>\n<p>I'm not very familiar with LAMPS but very familiar with WebAuthn: if you're talking about WebAuthn attestation objects, why not use the \"fmt\" attribute embedded in the attestation object?<br>\nAlso YubiKeys emit the \"packed\" attestation statement format which is the FIDO2 standard and not proprietary</p>\n</blockquote>\n<p>Yeah, this is the right question.<br>\nThe answer is because the layer that is unpacking the CSR (the CA or RA) does not otherwise have any reason to have a WebAuthn parser lying around. If the CA / RA has to parse the WebAuthn blob enough to find the \"fmt\" value, then it needs a WebAuthn parser. Ideally, the CSR contains enough OID + Hint data that it can select the right verifier and forward the opaque blob over to it for parsing.</p>", "time": "2025-07-22T08:34:00Z"}, {"author": "Michael StJohns", "text": "<p>Re printablestring - Russ is correct abou _.</p>", "time": "2025-07-22T08:35:14Z"}, {"author": "Rich Salz", "text": "<p>Was anyone really questioning whether Russ was correct on an ASN1 issue?</p>", "time": "2025-07-22T08:35:49Z"}, {"author": "Mike Ounsworth", "text": "<p><span class=\"user-mention silent\" data-user-id=\"435\">Michael StJohns</span> <a href=\"#narrow/channel/68-lamps/topic/ietf-123/near/169592\">said</a>:</p>\n<blockquote>\n<p>@jean.   That\u2019s not actuallly a thing.  Most companies have an enterprise number under 1.3.6.1.4.1 and can allocate oids without any delay.  Enterprise numbers are free and easy to get quickly- about a day</p>\n</blockquote>\n<p>Part of the problem has to do with Attester vs Presenter.<br>\nFor example, a Yubikey is not going to produce a CSR; something like Openssl will take a WebAuthn blob  from a Yubikey and pack it into a CSR.<br>\nIn your model of unique OIDs, then OpenSSL would be physically unable to construct this CSR if Yubico hasn't registered an OID for putting its WebAuthn into a CSR. Or if OpenSSL uses the wrong OID, then the thing is fundamentally unparsable.</p>\n<p>Our current model of \"generic WebAuthn OID + vendor Hint\" still works, even if Yubico hasn't registered an OID. By the way, it also works if Openssl doesn't know what Hint to use ... that's why Hint is OPTIONAL and why not all WebAuthn blobs will be able to come with a hint. For example, with our model the CA / RA is allowed to ignore the Hint, for example if it wants to just go down its list of Verifiers until one works, or if it knows how to parse WebAuthn and extract the <code>fmt</code>. Our proposal is more flexible and has more redundancy.</p>", "time": "2025-07-22T08:38:07Z"}, {"author": "Michael StJohns", "text": "<p>I sent something about printable\u2026 but missed his note</p>", "time": "2025-07-22T08:38:18Z"}, {"author": "Michael StJohns", "text": "<p>@mo - the client has to wrap an attestation according to the source of the attestation .  If the client doesn\u2019t know it\u2019s yubico, then how can it pick a hint?  If it does know yubico, why can\u2019t it pick an OID?</p>", "time": "2025-07-22T08:40:59Z"}, {"author": "Mike Ounsworth", "text": "<p><span class=\"user-mention silent\" data-user-id=\"435\">Michael StJohns</span> <a href=\"#narrow/channel/68-lamps/topic/ietf-123/near/169734\">said</a>:</p>\n<blockquote>\n<p>@mo - the client has to wrap an attestation according to the source of the attestation .  If the client doesn\u2019t know it\u2019s yubico, then how can it pick a hint?  If it does know yubico, why can\u2019t it pick an OID?</p>\n</blockquote>\n<p>In my example:<br>\n1) hint is OPTIONAL, it is not required to pick a hint, it is allowed to leave it empty.<br>\n2) in my constructed example, let's say that Yubico has not registered an OID, ... let's say such an OID does not exist, so what is OpenSSL supposed to do?</p>", "time": "2025-07-22T08:43:08Z"}, {"author": "Tim Hollebeek", "text": "<p>It's probably better to take the discussion of previous presentations to the list</p>", "time": "2025-07-22T08:46:02Z"}, {"author": "Dmitry Belyavskiy", "text": "<p>Why do we need to limit the moment of renewing the certificate? It can be revoked at any moment because of compromise, and I don't think we can limit it. The rest looks like a business logic to me...</p>", "time": "2025-07-22T08:48:21Z"}, {"author": "Thom Wiggers", "text": "<p><span class=\"user-mention\" data-user-id=\"123\">@Meetecho Robot</span> the online participants screen in room Patio-3 is dead</p>", "time": "2025-07-22T08:51:43Z"}, {"author": "Tadahiko Ito", "text": "<p>If that PKI is very large scale, and revoked all together, subscribers would request too much requests to proceed for CA. It might be part of business logic, but I believe we do not have altanative mechanism.</p>", "time": "2025-07-22T08:52:29Z"}, {"author": "Lorenzo Miniero", "text": "<p>Checking</p>", "time": "2025-07-22T08:52:31Z"}, {"author": "Dmitry Belyavskiy", "text": "<p>For a too-big-to-fail PKI it's a problem anyway</p>", "time": "2025-07-22T08:53:22Z"}, {"author": "Mike Ounsworth", "text": "<p>For the minutes: the authors of EST Renewal Info should go look at rfc8295</p>", "time": "2025-07-22T08:53:50Z"}, {"author": "Rich Salz", "text": "<p>This sounds like turning ARI upside-down.  ACME ARI says \"when to come back to me\" but this says \"now or later, and when is later\"</p>", "time": "2025-07-22T08:54:14Z"}, {"author": "Deb Cooley", "text": "<p>@rich, exactly</p>", "time": "2025-07-22T08:54:36Z"}, {"author": "Rich Salz", "text": "<p>well, with that endorsement I put myself in the mic line</p>", "time": "2025-07-22T08:55:14Z"}, {"author": "Rich Salz", "text": "<p>maybe the way to fix is to have the ari-like reply contain multiple answers.</p>", "time": "2025-07-22T09:00:50Z"}, {"author": "Mike Ounsworth", "text": "<p>I think Rich's point is that nobody is going to start scheduling truck visit to oil rigs based on the ARI window of certs on devices on the oil rig ... so if the truck is there anyway, might as well try to renew everything, so why is this adding any value.<br>\nIs that about right Rich?</p>", "time": "2025-07-22T09:01:26Z"}, {"author": "Flo D", "text": "<p>Could people please check the notes, particularly from the CSR attestation discussion.</p>", "time": "2025-07-22T09:02:42Z"}]