> > Unless you're willing to say that whatever is doing the authz/policy is > *offline* -- ie, can't look that policy up in real time -- this can all be > done using normal online mechanisms. That is, "server, can is this identity > allowed to do this or that?" in your example. > > I'm not arguing that it doesn't work as stated. I'm arguing that they > bring a tremendous amount of cert baggage -- business models, enrollment, > revocation, etc, etc -- that is really hard to justify under any normal > circumstance. Asymmetric keying unfortunately involves way too many people > thinking that once they are involved, certs are necessary. It need not be, > and in fact the vast majority of cases would greatly simplified to just get > rid of certs entirely, even the basic name/identity binding they provide. >
I don't entirely disagree with that perspective. Lots of merit to it. I think most of my responses have been directed towards those who seem to be *disagreeing* with the 'this is how it works" bits. On Tue, May 20, 2025 at 2:23 PM Michael Thomas <m...@mtcc.com> wrote: > > On 5/20/25 11:12 AM, Tom Beecher wrote: > > Same difference: burying policy into an authentication token. What is the >> point? A backend presented with an authenticated identity can do the same >> thing far easier and far more scalable without any of the downsides like >> mentioned. A backend server doesn't even need a name/key binding borne by >> the client at all, let alone bearing policy info as well. > > > Say I run a storage unit business. When you rent a unit, I give you a > code. I have decided (by my policy) that any user with a valid code can > access their unit 24/7/365. > > You come to rent a unit from me. You ask that your code only works on > Sundays, because that is the only day you will ever come. You have decided > (by your policy) you want something more restrictive than mine. I agree. > > Someone shows up on Wednesday and tries to use your code. You told me that > would never be you, so I deny the entry, because *YOU* told me not to allow > it. Semantically, you could say it's 'you did not authorize' , but really > it's "I did not not authenticate the identity of this user, based on > verified instructions that person provided me". > > > This is really al EKU is. I'm not arguing it's perfect. But that's what it > is. > > Unless you're willing to say that whatever is doing the authz/policy is > *offline* -- ie, can't look that policy up in real time -- this can all be > done using normal online mechanisms. That is, "server, can is this identity > allowed to do this or that?" in your example. > > I'm not arguing that it doesn't work as stated. I'm arguing that they > bring a tremendous amount of cert baggage -- business models, enrollment, > revocation, etc, etc -- that is really hard to justify under any normal > circumstance. Asymmetric keying unfortunately involves way too many people > thinking that once they are involved, certs are necessary. It need not be, > and in fact the vast majority of cases would greatly simplified to just get > rid of certs entirely, even the basic name/identity binding they provide. > > Mike > > _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/S55YQHNSX3Q2UMIWAJTQYUEJ4ULOAF6A/
