[lamps] Re: Draft leafy greens feedback

[Carl Wallace <[e-mail]>]

Inline...

<snip>

>>> 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/> <http://foo.example.com/&gt;> exclusion being unobserved” is something you see happening in a verifier (today, it’s simple, “foo.example.com <http://foo.example.com/> <http://foo.example.com/&gt;>” does not match “*.example.com <http://example.com/> <http://example.com/&gt;>”) - 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)

[CW] My point is that you've identified a gap between where name constraints processing ends in RFC5280 and service identity validation begins in RFC9525. I am suggesting that RFC5280 be updated by this draft to output the final state of the name constraints processing variables, i.e., permitted_subtrees and excluded_subtrees, for use in evaluating a SAN and a service identity. RFC9525 would be updated to make sure the service identity is matched by a presented identifier in the SAN (per RFC 9525 §6.3 wildcard semantics), falls within permitted_subtrees, and does not fall within excluded_subtrees. This would avoid requiring CAs to change. It may be sufficient to only output and consider the excluded_subtrees state.

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. 

[CW] My suggestion does update two documents, but both approaches update two running code bases. Your approach changes the CA's code and the path processing code. My suggestion changes the path processing code and the name validation code. I tend to think outputting a variable at the end of path validation is easier than bolting in a new critical extension.

<snip>