WoSign/StartCom at 26:00... good story! :-)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Hi Gerv,
You start by noticing "The scope of the BRs is a matter of debate..."
And then you use that same "scope of the BRs" in 1) to specify Mozilla's
requirements. Isn't that somewhat strange, if what you are trying to do is
solve some problems that are caused by the former?
CU Hans
On Wednesday, 25 January 2017 08:25:41 UTC+1, Jakob Bohm wrote:
> Tiny nit: What if the original language of the CP/CPS is English. Then
> there can't be a "translation" etc.
Mmmm... indeed.
It actually says "The English version is not required to be authoritative in
cases of dispute...". I do
Well, these are logs. So:
- Is it necessary to require that log items can't be modified after they have
been created? (Or is that implied by the cryptography being used.) How about
deleted?
- Is is perhaps a good idea to require a certain minimum accuracy (or other
characteristics, timestamps
Reading this makes me wonder. Will it still be possible to have such a thing as
a non disclosed sub-CA now that Chrome has announced that they soon will
require CT?
CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
http
Isn't that something you should take up with StartCom? Bottom line you payed
them for your certificate, didn't you. Not Mozilla. Perhaps StartCom should
have been a bit more careful so they could keep serving their customers.
CU Hans
___
dev-security-p
Perhaps "haste" is not what you want here. How about "urgency"?
CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Measure with a micrometer, mark with chalk and cut with an axe... it's the best
you can do.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Sound to me like they probably still want that particular certificate revoked
as soon as the bug has been fixed.
CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
The revocation was not accidental. They intended to do it, it was only the
effects they did not like. (Because of buggy software?)
So, what can you do when that happens. Seems best to pull try and undo the
revocation. Perhaps even when you can't do that according to the rules.
CU Hans
_
So that explains why our URL checking batch job was logging certificate invalid
errors for some 700 links to the Wikipedia we have on our website for two days.
I checked with a browser but couldn't see anything wrong. Make more sense
knowing this... ;-)t
CU Hans
99% uptime sounds good but it allows being down for three and half days in a
year. It's not actually a very high availabillity. ;-)
CU Hans
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev
It seems to me that, considering WoSign and StarCom were when it happened
actually the same entity, the things that went wrong should be weighed equally
against them. So if only what has happened is relevant, it makes no sense to
deal with them separately.
If however what they propose/promise t
> >Easy. It doesn't make a sound. Unrevoked certificates don't make sounds
> >either.
>
> What I was really asking, in a tongue-in-cheek way, was whether there was any
> indication of how successfully the information could be propagated to
> browsers.
Good question. Regardless of the answer, in
14 matches
Mail list logo
