On Fri, May 18, 2018 at 11:56 AM, Eliot Lear <l...@cisco.com> wrote: > Hi EKR, > > > On 18.05.18 19:57, Eric Rescorla wrote: > > Eliot, > > The certificate part seems basically right (I think you > should require specific KeyUsage bits). > It's in there: > > It is expected that the Key Usage extension would contain "Digital > Signature" and that the extended key usage would include either "code > signing" or "email protection". > > > This leaves a little a little flexibility. I think this is sufficient, > and compatible with existing CAs. >
I disagree. This is going to lead to a lot of interop problems. You need to actually specify the bits > > Maybe I missed it, but I didn't see anything about the level of trust you should have in cases where you can't reliably tie the endpoint's transmissions to its certificate. It's there but could be clearer: OLD: A MUD manager MUST cease processing of that file it cannot validate the chain of trust to a known trust anchor until an administrator has given approval. NEW: A MUD manager MUST cease processing of that file it cannot validate the chain of trust to a known trust anchor or the MUDsigner until an administrator has given approval. That is- throw an exception and let the admin sort it out. This is about the file. I'm talking about IP/MAC forgery. -Ekr > Eliot >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
