Good reference. That shows modifying initialization steps and using new variables. RFC5937 has an example of a new input flag. Between those two the basic skeleton is there. The effort just needs to make sure status quo is captured.
> On Jan 31, 2023, at 9:34 AM, Corey Bonnell <[email protected]> wrote: > > > Hello, > Unfortunately, I don’t think that the CABF BRs or other CABF documents will > provide much insight here; they mainly just say that CAs MUST include EKUs in > CA certificates. Instead, I’d recommend starting with reading this discussion > on m.d.s.p., which prompted the “EKU chaining” rules that we know today: > https://groups.google.com/g/mozilla.dev.security.policy/c/0jnELviAxxo/m/VF1564nFcgwJ. > > As for some inspiration on how to write the path validation procedure, I > recommend taking a look at Russ Housley’s (expired) I-D on the EKU > Constraints extension: > https://datatracker.ietf.org/doc/html/draft-housley-spasm-eku-constraints-01. > This extension was not standardized, but the way that Russ presents the > algorithm could likely be reused for this draft. > > Thanks, > Corey > > From: TLS <[email protected]> On Behalf Of Salz, Rich > Sent: Saturday, January 28, 2023 10:57 AM > To: Oleg Pekar <[email protected]>; Carl Wallace > <[email protected]> > Cc: [email protected] > Subject: Re: [TLS] Regulations for EKU validation for CA certificates in the > certificate chain > > Great, I will prepare the initial draft then. Are there any informal > documents where WebPKI rules are captured? > > I would start by looking at the CA/Browser forum documents.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
