[lamps] Re: Draft leafy greens feedback

[Bob Beck <[e-mail]>]

> On Jul 14, 2026, at 15:15, Mike Ounsworth <[e-mail]> wrote:
> 
> @Bob -- You promised me that you would give Carl a response about this. Tisk tisk.

I got busy, and airplaned, and ietfed, and forgot to get back to it.. sorry.

> 
> -Mike 
> 
> "Knowing is a barrier which prevents learning" -- Frank Herbert, Dune.
> 
> "An expert is a person who has found out by his own painful experience all the mistakes that one can make in a very narrow field.” -- Niels Bohr
> 
> On Tuesday, July 14th, 2026 at 7:55 AM, Carl Wallace <[e-mail]> wrote:
>> [offlist]
>> Forwarding since I foolishly piggybacked on an agenda email (though this was the first reference to leafy greens I had seen).
>>  
>>> From: Carl Wallace <[e-mail]>
>>> Date: Monday, July 6, 2026 at 12:21 PM
>>> To: Mike Ounsworth <[e-mail]>, Tim Hollebeek <tim.hollebeek=[e-mail]>
>>> Cc: SPASM <[e-mail]>
>>> Subject: Re: [lamps] Re: Draft Agenda for IETF 126
>>>  
>>> Re: leafy-greens, did you consider augmenting 6.1.6 of RFC5280 to return the state of name constraints processing and defining additional checks in RFC9525 to consider them? I didn't see this approach listed in the appendix. The foo.example.com exclusion is sitting there unobserved in the state variable. This would be a lighter approach to get at a similar end as the EENR extension.

I’m not *quite* sure what you mean by this - how the “foo.example.com <http://foo.example.com/> exclusion being unobserved” is something you see happening in a verifier (today, it’s simple,  “foo.example.com <http://foo.example.com/>” does not match  “*.example.com <http://example.com/>”) - if you have some way you are pondering updating both 5280 and 9525 to deal with this, ok, I’d need some more details and then happily add them into the draft as an alternative to consider (PR’s or issues on the draft in github are also welcome)

However, if an approach requires updating *two* drafts and keeping things consistent over time while still providing a reliable signal to a CA (that wishes to include name constraints) about “what will the relying party do with this?” I would hope there’s some benefit to this approach that makes that easier to get into specs, get implementations, and have a mechanism that can be relied upon than other alternatives. 


>>>  
>>> Per some testing, it’s not clear that this is a huge issue. Most of the browsers I tested failed given a chain like the one described in the draft using the excluded name. Things that only validate the cert without considering a name successfully verify the path (which is as expected). 
>>>  
>>> I recognize this alternative would not fail closed for non-adopters, but it’s fewer moving parts. Both approaches require verifiers to change; the alternative leaves CAs untouched (it acts on the nameConstraints they already emit) and applies to already-issued certs, whereas EENR needs CAs to issue a new critical extension before it is effective.
>>>  
>>> From: Mike Ounsworth <[e-mail]>
>>> Date: Friday, July 3, 2026 at 1:22 PM
>>> To: Tim Hollebeek <tim.hollebeek=[e-mail]>
>>> Cc: SPASM <[e-mail]>
>>> Subject: [lamps] Re: Draft Agenda for IETF 126
>>>  
>>> Hi Tim,
>>>  
>>> Request an Under Consideration For Adoption slot for: draft-beck-lamps-leafy-greens-00
>>> Presenter: Bob Beck
>>>  
>>> Context: NameConstraints as defined in 5280 has a bug when applied to TLS wildcard dNSName SANs. This draft proposes one potential fix and discusses alternatives. 
>>>  
>>> On Mon, 29 Jun 2026 at 11:48, Tim Hollebeek <tim.hollebeek=[e-mail]> wrote:
>>> Hello LAMPS,
>>>  
>>> In order to help the meeting run smoothly, I would like to ask the authors who is going to be presenting each draft.
>>>  
>>> Don't worry, if you need to change it later, you can, but this will help the chairs know who to call on, and will help prevent unfortunate circumstances where the authors miscommunicate amongst themselves as to who is presenting (never happens, I know).
>>>  
>>> If you're on this list, please confirm who the presenter is. If the listed presenter is already correct, just say so.
>>>  
>>> 5)  Active Documents
>>>     a)  draft-ietf-lamps-attestation-freshness (Hannes, Hendrik)
>>>     b)  draft-ietf-lamps-certdiscovery (TBD)
>>>     c)  draft-ietf-lamps-one-signature-certs (Stefan)
>>>     d)  draft-ietf-lamps-fn-dsa-certificates (Sean)
>>>     e)  draft-ietf-lamps-cms-fn-dsa (Sean)
>>>     f)  draft-ietf-lamps-est-renewal-info (Rifaat)
>>>     g)  draft-ietf-lamps-rfc8550bis (Sean)
>>>     h)  draft-ietf-lamps-rfc8551bis (Sean)
>>>  
>>> 6)  Under consideration for adoption
>>>     a)  draft-smyslov-lamps-frodokem-certificates (Valery)
>>>     b)  draft-chen-lamps-cms-frodokem
>>>     c)  draft-vangeest-lamps-update-asn1-signed-type (Daniel)
>>>  
>>> -Tim
>>>  
>>>  

>>> From: Tim Hollebeek <[e-mail]>
>>> Sent: Tuesday, June 23, 2026 1:26 PM
>>> To: SPASM <[e-mail]>
>>> Subject: Draft Agenda for IETF 126 
>>>  
>>>  
>>> LAMPS WG Agenda at IETF 126
>>>  
>>> 0)  Minute Taker, Jabber Scribe, Bluesheets
>>>  
>>> 1)  Agenda Bash
>>>  
>>> 2)  Recently Published RFCs
>>>  
>>>    a)  draft-ietf-lamps-kyber-certificates (RFC 9935)
>>>  
>>>    b)  draft-ietf-lamps-cms-kyber (RFC 9936)
>>>  
>>> 3)  With the RFC Editor
>>>  
>>>    a)  draft-ietf-lamps-rfc5019bis (RFC-to-be 9919)
>>>  
>>>    b)  draft-ietf-lamps-rfc5272bis (RFC-to-be 10002)
>>>  
>>>    c)  draft-ietf-lamps-rfc5273bis (RFC-to-be 10003)
>>>  
>>>    d)  draft-ietf-lamps-rfc5274bis (RFC-to-be 10004)
>>>  
>>>    e)  draft-ietf-lamps-pq-composite-sigs
>>>  
>>>    f)  draft-ietf-lamps-cms-composite-sigs
>>>  
>>>    g)  draft-ietf-lamps-macaddress-on
>>>  
>>>    h)  draft-ietf-lamps-keyusage-crl-validation
>>>  
>>> 4)  With IESG
>>>  
>>>    a)  draft-ietf-lamps-pq-composite-kem
>>>  
>>>    b)  draft-ietf-lamps-cms-composite-kem
>>>  
>>>    c)  draft-ietf-lamps-cms-euf-cma-signeddata
>>>  
>>>    d)  draft-ietf-lamps-csr-attestation
>>>  
>>> 5)  Active Documents
>>>  
>>>    a)  draft-ietf-lamps-attestation-freshness (Hannes, Hendrik)
>>>  
>>>    b)  draft-ietf-lamps-certdiscovery (TBD)
>>>  
>>>    c)  draft-ietf-lamps-one-signature-certs (Stefan)
>>>  
>>>    d)  draft-ietf-lamps-fn-dsa-certificates (Sean)
>>>  
>>>    e)  draft-ietf-lamps-cms-fn-dsa (Sean)
>>>  
>>>    f)  draft-ietf-lamps-est-renewal-info (Rifaat)
>>>  
>>>    g)  draft-ietf-lamps-rfc8550bis (Sean)
>>>  
>>>    h)  draft-ietf-lamps-rfc8551bis (Sean)
>>>  
>>> 6)  Under consideration for adoption
>>>  
>>>    a)  draft-smyslov-lamps-frodokem-certificates
>>>  
>>>    b)  draft-chen-lamps-cms-frodokem
>>>  
>>>    c)  draft-vangeest-lamps-update-asn1-signed-type (Daniel)
>>>  
>>> 7)  Wrap up
>>>  
>>> _______________________________________________
>>> Spasm mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>> _______________________________________________ Spasm mailing list -- [e-mail] To unsubscribe send an email to [e-mail]
>