I think if we can make the SSL deployment automatically, then Ryan's dream is not a problem. One year even one month is ok. Currently, subscriber like 39 months since less work for the deployment.
Regards, Richard > On Mar 30, 2016, at 17:55, Ryan Sleevi <[email protected]> wrote: > > Doug, > > Forgive my ignorance, but could you perhaps expand on this, and explain a bit > more about the challenges your organization would face? > > From the browser perspective, reducing validity times and revalidation times > is a big win for security and the ability to change. The ability to make > changes one year sooner is a HUGE win. I can understand and appreciate that > you may value that increased security differently, but where I would like to > understand better is what impact this would have from the CAs side, and why > this would be undesirable. > > To that end, would you be willing to explain in more detail what would have > to happen on the CA's side to bring this in? Can you "sell me" on the > difficulty, by perhaps providing more concrete explanations of the changes > necessary, and not just the abstract categories? My ideal response to such an > email from you would ideally be "Wow, that's so much, I didn't realize" - so > can you fill in that blank and help me have that reaction? > > Ultimately, the goal is to better understand the concrete concerns and > objections, as well as have a better understanding of the overall challenges, > so that if and when we revisit this topic, we can make sure to fully consider > the impact and perhaps explore solutions. > > The challenge that I have with your current response is that it doesn't share > enough detail to really see if there is any room for changes or compromise, > nor does it really help form a picture other than "This is hard because I say > it's hard," and I suspect there's much more subtlety and nuance than the > broad stroke I just painted it as. > >> On Mar 30, 2016 9:41 AM, "Doug Beattie" <[email protected]> wrote: >> Jeremy, >> >> >> >> I’m also against making any changes. I don’t see the value of this change >> exceeding all the work on communications, system updates and operational >> procedure changes needed to make this happen. >> >> >> >> Doug >> >> >> >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Rich Smith >> Sent: Wednesday, March 30, 2016 12:32 PM >> To: [email protected] >> Subject: Re: [cabfpub] Certificate validity periods >> >> >> >> Jeremy, >> I'm not sure Comodo would support any change at this point, but if we were >> to change I'd like to propose, let's call it 1c; >> Set all max validity to 27 months; Require re-validation for all at 27 >> months. >> >> I'm against your proposal of 1a for the same reasons I don't like 27/13 for >> EV It puts us in position of having to redo validation of a replacement >> request by the customer. In this case, the customer would get the DV or OV >> for 27 months, be able to replace at will, renew the cert for an additional >> 27 months, but be subject to revalidatiion half way through the 2nd when >> trying to get a replacement/re-issuance. This is bad enough with EV >> already, and I'm very much against extending it to OV/DV. If we can't find >> a reasonable path to match up the re-validation requirement with max >> validity then I'm against making any changes. >> >> >From the customer perspective, they expect to have to jump through hoops at >> >the point of placing a new order. We don't generally get push back on >> >that. What they don't expect, and what it is very difficult to make them >> >understand is having to jump through the hoops again during the validity >> >period of the same order. The customer doesn't understand these >> >requirements and it causes a bad customer experience, for which they blame >> >the CA. >> >> -Rich >> >> On 3/30/2016 11:04 AM, Jeremy Rowley wrote: >> >> Hi everyone, >> >> >> >> I’d like to resurface the certificate validity period discussion and see if >> there is a way to move this forward. I’m still keen on seeing a >> standardized maximum validity period for all certificate types, regardless >> of whether the certificate is DV, OV, or EV. I believe the last time this >> was discussed, we reached an impasse where the browsers favored a shorter >> validity period for OV/DV and the CAs were generally supportive of a >> longer-lived EV certificate (39 months). The argument for a shorter validity >> period were 1) encourages key replacement, 2) ensures validation occurs more >> frequently, 3) deters damage caused by key loss or a change in domain >> control, and 4) permits more rapid changes in industry standards and >> accelerates the phase-out of insecure practices. The argument for longer >> validity periods: 1) customers prefer longer certificate validity periods, >> and 2) the difficulty in frequent re-validation of information. >> >> >> >> So far, there seems to be two change proposals with a couple of variations: >> >> >> >> 1) Set all certificate validity periods to no more than 27 months >> >> a. Require re-validation of information for OV/DV certificates at 39 >> months OR >> >> b. Require re-validation of information for all certs at 13 months >> >> 2) Set all certificate validity periods to 39 months >> >> a. Require re-validation every 13 months >> >> b. Require re-validation of information for OV/DV certificates at 39 >> months >> >> >> >> What are the objections to 1a? With all the automated installers abounding, >> 1a seems to capture the simplicity and customer convenience of 39 months >> with the advantages of shorter-lived certs. Who would oppose/endorse a >> ballot that does one of these? >> >> >> >> Jeremy >> >> >> >> >> >> _______________________________________________ >> Public mailing list >> [email protected] >> https://cabforum.org/mailman/listinfo/public >> >> >> >> _______________________________________________ >> Public mailing list >> [email protected] >> https://cabforum.org/mailman/listinfo/public > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
