Re: Talk at FOSDEM
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
Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla CT Policy
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 only increase) for it's clock? - Maybe you should consider what will happen if/when an important log stops to be available at some point in the future. Will anything break? - And I already mentioned it, but availability of 99% is not as good as it sounds. It means three and a half days down in a year is allowed. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Technically Constrained Sub-CAs and the BRs
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 https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remediation Plan for WoSign and StartCom
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-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remediation Plan for WoSign and StartCom
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
Re: Remediation Plan for WoSign and StartCom
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
Re: Globalsign accidental intermediate revocation incident
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
Globalsign accidental intermediate revocation incident
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remediation Plan for WoSign and StartCom
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-security-policy
Re: Incidents involving the CA WoSign
> >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, information that doesn't exist cannot be propagated at all. So revoking seems te be a start... and a statement. I'd say it does make a sound. ;-) CU Hans ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy