The capability URL stuff introduces a level of complexity that I'd rather not try to analyze at this point. I'm afraid people will rush to implement it and get it wrong in hard to anticipate ways, or that there are consequences we haven't foreseen at this late hour.
POSTs seem to be the right long term solution. Why is it necessary that the server MUST allow GETs, and cannot consider them to be a legacy feature that should eventually be deprecated? -Tim > -----Original Message----- > From: Acme <[email protected]> On Behalf Of Nico Williams > Sent: Friday, August 31, 2018 5:16 PM > To: Felipe Gasper <[email protected]> > Cc: ACME WG <[email protected]> > Subject: Re: [Acme] ACME breaking change: Most GETs become POSTs > > On Thu, Aug 30, 2018 at 08:45:50PM -0400, Felipe Gasper wrote: > > I suppose if I have: > > > > GET /order/123/certificate => cert for yin.com > > > > GET /order/124/certificate => cert for yang.com > > > > … then one could surmise (however justifiably) that these two may be > related, so I see the point. > > If these numbers are certificate serial numbers, then by all means they must > be > randomized. Even if not, predictable, serial account-number- like numbers > should not be part of a URL without some other component to make URL > generation unpredictable. > > > > You could make the certificate URLs unpredictable, but then you've > > > introduced a notion of capability URLs[1], which breaks the notion > > > of having a single authentication system for ACME. > > > > I can see that. > > Eh? Just because they are randomized / unpredictable does not mean that > they are capability URLs or confidentiality-sensitive, nor that they must be > one- > time-use only. > > Nico > -- > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
