> On Mar 11, 2020, at 4:11 PM, Kathleen Wilson via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On 3/11/20 3:51 PM, Paul Walsh wrote: >> Can you provide some insight to why you think a shorter frequency in domain >> validation would be beneficial? > > To start with, it is common for a domain name to be purchased for one year. A > certificate owner that was able to prove ownership/control of the domain name > last year might not have renewed the domain name. So why should they be able > to get a renewal cert without having that re-checked?
[PW] I look at it differently. If the owner’s identity has already been validated and that information is still valid, why ask them to validate again? I would like to see the time, effort and cost to website owners reduced where possible - without increasing risk from a security perspective. That’s my response to your specific question, but what about domains that are purchased for longer durations? Given that you raised this topic, I believe the onus should be on you to demonstrate why it’s a good idea, not for me or others to demonstrate why it’s not a good idea :) I’m simply asking questions to learn more about your perspective. I’m on the fence until I hear of good reasons to change something that might not be broken. > > >> At the very least it deserves a new thread as the potential impact could be >> significant. > > What exactly do you think is the significant impact in regards to > re-verifying that the certificate requestor still has control of the domain > name to be included in the new certificate? [PW] I believe it’s a good idea to ensure they’re still in control of the domain. My comment is in relation to the cost of validating their identity. Any change that you propose and which is accepted, will have an impact on website owners - however small we might think, it might not be small to them. I specifically use the term “website owners” to humanize the conversation. It’s not about “domains”, it’s about people who have to pay for extra things that we as stakeholders and guests of the web, ask of them. Or in this case, tell them. I’d love to hear what CAs think as they’re the ones who know what website owners want more than any other stakeholder. > > >> And out of curiosity, why not raise your question inside the CA/Browser >> forum if you believe the original change being discussed should have been >> brought up there? I believe the potential outcome would have a separate >> impact on CAs and website owners. In particular, it would cost website >> owners in more time, resource and money. For this reason, I’m assuming >> you’re not asking the question to simply line up with another change. > > It was part of the CAB Forum Ballot SC22 that was proposed last year by > Google. That ballot was to change both the cert validity period and the > validation information to 398 days. > "| 2020-03-01 | 4.2.1 and 6.3.2 | Certificates issued SHOULD NOT have a > Validity Period greater than 397 days and MUST NOT have a Validity Period > greater than 398 days. Re-use of validation information limited to 398 days. > |" > > > Reference: > https://cabforum.org/pipermail/servercert-wg/2019-August/000894.html > https://github.com/cabforum/documents/compare/master...sleevi:0a72b35f7c877e6aa1e7559f712ad9eb84b2da12?diff=split#diff-7f6d14a20e7f3beb696b45e1bf8196f2 [PW] Thanks for this info. If this is already part of the CA/B Forum, is it your intention to potentially do something different/specific for Firefox, irrespective of what happens in that forum? I’m trying to learn more about your intent and the benefits as you perceive them, it’s not to debate, as I don’t have an opinion on whether it’s a good or bad thing. Thanks, Paul > > > Thanks, > Kathleen > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
