On 28/03/2017 15:20, Ryan Sleevi wrote:
On Tue, Mar 28, 2017 at 8:52 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


While this has apparently already passed, the earlier date for
requiring revalidation is going to be a problem for any CA that has
already sold a large number (thousands, millions) of prepaid 3 year
contracts based on the assumption that validation costs would be
incurred by the CA only once during the contract period.


It's unclear to me the point you're trying to make with this comment, so
I'm hoping you can expand. It sounds like you're just making a position
statement, and not asking Mozilla to change or reconsider anything that was
already considered. Is that a correct understanding?

That is, given that Gerv is asking for feedback, it's unclear whether
you're offering the feedback for change, or just making statements. Given
that you're talking about "future consideration", it sounds like that's
best directed to the CA/Browser Forum, and given that the CAs affected
voted in favour of it, it doesn't sound like they agree with your analysis,
but I could be mistaken.



For this part, I am only making a position statement as it seems the
CAB/F has already voted and passed the rules as stated.

Note that it is very common for all the underlying validity information
to be fixed for 2 or more years (for example domain registrations,
company registrations etc.), providing little reason to impose the
inconvenience and cost of short certificate lifespans onto every
ongoing business and every personal website on the planet.


I think including domain registrations in that would be a stretch that
borderlines inaccurate, and thus while it may impose some degree of
inconvenience over the status quo, it will also significantly improve
security.

While a domain may be registered for a number of years, there's no
guarantee as to the frequency of that information being updated, and
there's no guarantee that the domain holder's contact information won't
change during the operation, thus there is a great benefit for ensuring
it's revalidated.

To the general point that different aspects of different information
require different revalidation periods, I'm on record in the CA/Browser
Forum as agreeing with that sentiment, as my goal with 186 is
post-readoption of the 169/182 methods of validation, the lifetime of reuse
will be appropriately scoped to the method used to validate that
information.


In principle any source of information could change just one minute
later.  A domain could be sold, a company could declare bankruptcy, a
personal domain owner could die.

For smaller organizations (i.e. not Google), requesting and deploying
new certificates every few years is a real hassle, and often a
non-trivial expense.  Forcing the paid, carefully validated
certificates to be repurchased and reinstalled a lot more often imposes
a real burden on real websites and real e-mail accounts.

The previous CAB/F rule of 3 years max seemed to be a useful
compromise, only slightly more difficult than the old 5 year offering
from some CAs, and well within reason as to handling the frequency of
ordinary changes in domain and company ownership/status that occur in
the real world.

The somewhat sudden (to outsiders) tendency to force frequent
certificate replacements for those not using "Let's encrypt" seems
arbitrary, harmful and mostly pointless.

It should also be noted, that many countries have services that a CA
could subscribe to in order to be alerted to changes in validated
information, such as whois changes, company closures, changes of
address etc.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to