Fair enough. So, JC's text without the optionality: *"Required Website Content*: Either a Random Value or a Request Token, together with information that uniquely identifies the Subscriber, as specified by the CA"
On Wed, May 4, 2016 at 10:27 AM, Tim Hollebeek <[email protected]> wrote: > Well, the point is that in addition to removing the optionality, the added > information must bind the RWC to the request. I actually like JC’s change > as a good step in the right direction. > > > > Writing generic descriptions of validation methods tends to allow more bad > things than it helps. I’d rather see a description of enough of the ACME > protocol to capture it’s necessary security features. If people want to > add similar validation schemes in the future, they should be added as new > methods after being adequately reviewed, instead of trying to anticipate > all possible similar future methods in advance. > > > > -Tim > > > > *From:* Richard Barnes [mailto:[email protected]] > *Sent:* Wednesday, May 04, 2016 10:18 AM > *To:* J.C. Jones > *Cc:* Tim Hollebeek; Ryan Sleevi; CABFPub > > *Subject:* Re: [cabfpub] Pre-Ballot 169: Revised Validation Requirements > > > > > > > > On Tue, May 3, 2016 at 8:06 PM, J.C. Jones <[email protected]> wrote: > > Tim, Ryan: > > Your points are well-made. As it sounds like we'd prefer to err being more > ACME-specific, I propose changing the definition of Required Website > Content (RWC) to: > > *Required Website Content*: Either a Random Value or a Request Token, > optionally concatenated with additional information +{*to uniquely > identify the Subscriber*}+ as specified by the CA. > > > > I would think the change needed would be in the other direction -- rather > than adding description, remove the optionality: > > *"Required Website Content*: A byte string specified by the CA containing > either a Random Value or a Request Token, as well as some additional > information" > > > > > > This should preclude concatenating a fixed prefix, or other such simple > validation schemes. > > I've also made a one-word clarification to my change from yesterday, > clarifying that the RWC can't be contained in its entirety anywhere in the > whole request, not only the path. > > Both of these changes are reflected in the diff at GitHub [1]. > > 1) > https://github.com/cabforum/documents/compare/Ballot-169...jcjones:Ballot-169?expand=1 > > Cheers, > J.C. > > > > On Tue, May 3, 2016 at 4:21 PM, Tim Hollebeek <[email protected]> > wrote: > > Given the goal of this ballot is to remove "any other method", and we > explicitly agreed at the start of this process to simply enumerate existing > practice (unless egregiously wrong), I'm not going to hold things up over > my concerns. I'd like to see any other method go away ASAP. > > > > That said, this language allows "Tim's Zero Fuss Certificate Authority", > which uses Random Value + "ZFCA" as the challenge, and "Tim's Zero Fuss Web > Server" which simply parrots back Request + "ZFCA" for all requests for any > file under .well_known/pki-validation. > > > > I predict my product will be extremely popular, as issuance will always > succeed without any configuration or manual steps. Once my web server > achieves ubiquity, it will succeed even if you accidentally use the wrong > domain name in your CSR! > > > > Basically, I don't see anywhere in the proposed text where there is a > requirement that the validation method must include the essential security > that account_key_thumbprint might provide. > > > > -Tim > > > ------------------------------ > > *From:* [email protected] <[email protected]> on > behalf of Ryan Sleevi <[email protected]> > *Sent:* Tuesday, May 3, 2016 6:07:23 PM > *To:* Richard Barnes > *Cc:* CABFPub > *Subject:* Re: [cabfpub] Pre-Ballot 169: Revised Validation Requirements > > > > > > > > On Tue, May 3, 2016 at 3:02 PM, Richard Barnes <[email protected]> > wrote: > > Hey Ryan, > > I'm confused about where you're going here. > > It seems like the property that we need to remedy the flaw that Peter > exposed is that the server's response cannot be generated based on the > request from the CA. It seems to me that the right response is just to > make that requirement explicitly. As I think JC's text does, though > perhaps it could be made clearer. > > Do you agree with that approach, and we're just arguing about wording? Or > do you think the HTTP validation method needs to be even more prescriptive? > > > > Well, the wording is to make the HTTP validation method more prescriptive > ;) > > > > To be clear: We're discussing wording. Tim proposed some more restrictive > changes, and J.C. raised the concern that ACME relies on the lax language. > The question is fundamentally trying to find out what options we have to > tweak wording or implementation - to try to close the gap so that everyone > is happy. > > > ------------------------------ > > > This transmission may contain information that is privileged, > confidential, and/or exempt from disclosure under applicable law. If you > are not the intended recipient, you are hereby notified that any > disclosure, copying, distribution, or use of the information contained > herein (including any reliance thereon) is strictly prohibited. If you > received this transmission in error, please immediately contact the sender > and destroy the material in its entirety, whether in electronic or hard > copy format. > > > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public > > > > > > ------------------------------ > > This transmission may contain information that is privileged, > confidential, and/or exempt from disclosure under applicable law. If you > are not the intended recipient, you are hereby notified that any > disclosure, copying, distribution, or use of the information contained > herein (including any reliance thereon) is strictly prohibited. If you > received this transmission in error, please immediately contact the sender > and destroy the material in its entirety, whether in electronic or hard > copy format. >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
