Re: Globalsign accidental intermediate revocation incident

2016-10-16 Thread Peter Gutmann
Nick Lamb  writes:

>Although we'd usually say "contract" means a signed piece of paper the law
>considers that just an artefact, a contract is the "meeting of minds"
>requiring both parties to understand and agree on its terms. That's why
>tricking someone into signing works in the movies but not so much in real
>life. Likewise I think an OCSP "Bad" response, though we'd colloquially call
>it a revocation is only a technical artefact, actual revocation is a decision
>by the Issuer.

Man, that's convoluted logic!  I recently read a paper on the use of language
to make civilians killable ("imminent threat", "signature strikes", and so
on), and even the military lawyers would have to read that paragraph about
three times, possibly accompanied by a few beers, to see how it justified what
was done.

Why not take the easier way out, that since "ISO/IEEE/ETSI/CABF write
guidelines and recommendations, which you're free to follow or not",
Globalsign is free to follow (or not) the BRs, and in this case it can choose
not to (if indeed that's what it's done).

>Does that make sense?

Possibly, but I think my way's easier :-).

Peter.
___
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

2016-10-16 Thread Matt Palmer
On Sun, Oct 16, 2016 at 05:13:54PM +0200, Kurt Roeckx wrote:
> On Sun, Oct 16, 2016 at 07:38:29AM -0700, Nick Lamb wrote:
> > On Sunday, 16 October 2016 08:59:13 UTC+1, Adrian R.  wrote:
> > > They rolled back the revocation, but i thought that the BRs explicitly 
> > > forbid that a suspended/revoked certificate be un-suspended/un-revoked.
> > 
> > I don't know whether the exact text permits this, but it seems from a 
> > common sense point of view that what happened here wasn't a revoked 
> > certificate being unrevoked, but instead a technical fault resulted in the 
> > creation of Bad OCSP responses for a period of time by mistake for 
> > certificates GlobalSign never actually revoked.
> 
> As far as I understood things, it was also in the CRL.

Yes, it was in the CRL for the root that issued the cross-signed cert, which
is entirely proper.  The problem, I surmise, is that the CRLs for multiple
CAs were munged into a single database for the OCSP infrastructure, and it
didn't account for two certs with the same serial (and public key, and subject,
and etc etc) but from different issuers appearing at the same time, and
published erroneous OCSP responses.  I don't feel that fixing the OCSP
responder to publish correct OCSP responses is a BR violation.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: StartCom & Qihoo Incidents

2016-10-16 Thread Ryan Sleevi
On Saturday, October 15, 2016 at 3:18:22 PM UTC-7, Eric Mill wrote:
> On Sat, Oct 15, 2016 at 4:31 AM, Peter Gutmann 
> wrote:
> 
> >  The only one who's openly addressed this
> > seems to be Mozilla.
> >
> 
> It would certainly be nice if Mozilla weren't the only openly operated root
> program. :)
> 
> It seems to put Mozilla in the situation of being the effective first-mover
> whether they want to be or not, since they're the only entity hosting
> public discussions about what to do. It certainly felt that way with
> WorldPay, and Ryan's comments to Kathleen in the other thread about whether
> Mozilla could be more aggressive with WoSign if they knew they were not
> going to be saddled with first/only-mover disadvantage seems to point to
> this dynamic as well.

To be clear: I don't think the fact that this is happening on 
mozilla.dev.security.policy is enough to suggest that there aren't 
open/transparent programs, or that it's limited to Mozilla's response.

Imagine a hypothetical world where there were multiple, independently approved 
root programs - that is, that the software vendor retains final choice in 
deciding to include/not include a given certificate. Let's say that these 
programs also adopted the principles that Mozilla has - of having a community 
driven focus, based on feedback and investigation, and an open period for 
review and discussion.

Would this hypothetical world benefit, or be harmed, if these conversations 
happened on independent lists? My belief is that it would be harmed - that is, 
that having separate root programs operate separate lists would invite all the 
same problems that the Common CA Cert Database (aka Salesforce) is trying to 
solve, by duplicating effort and activity, without providing new or unique 
information.

Instead, we might conclude that these independently operated programs might 
benefit from having a common, shared community review and discussion, but then 
independently declare their final results - whether to include, remove, or 
otherwise sanction or censure. This would allow involved members of the 
community a central place to discuss, publicly, and share information and 
perspectives, while also avoiding the issues alluded too earlier in the thread 
with respect to the antitrust statements of the CA/B Forum.

Whether such a shared list has a name like mozilla.dev.security.policy or some 
new email list largely seems irrelevant, and that the status quo, by having a 
large and involved membership, might be more preferable than creating yet 
another list.

Just a thought ;)
___
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

2016-10-16 Thread Peter Bowen
On Sun, Oct 16, 2016 at 8:41 AM, Vincent Lynch  wrote:
> Looking at the BRs ( 
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf ). 
> Section 4.10.1 says:
>
> "Revocation entries on a CRL or OCSP Response MUST NOT be removed until after 
> the Expiry Date of the revoked Certificate."
>
> In GlobalSign's Incident Report, within the section "Incident Timeline", they 
> write:
>
> "13-Oct-16 12:20 Removal of cross signing certificate from the OCSP Database"
>
> So it seems that be un-publishing the revocation information for the Cross 
> Certificate would indeed be a BR violation. But this is not an area of 
> compliance I am familiar with.

I don't believe it is a BR violation.  This requirement means that
correct certificate status must be published for the lifetime of the
certificate.  The CA cannot simply cease publishing revocation
information because the customer tells them "I'm no longer using this
certificate."

In the case of OCSP, the database referenced is an implementation
detail outside of the scope of the BRs.  The BRs cover the responder
output (i.e. responses).  As long as the responder is (a) returning a
response and (b) not returning 'good' for unissued certificates, I
think GlobalSign is in compliance.

Thanks,
Peter
___
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

2016-10-16 Thread Vincent Lynch
Here is my understanding, according to the wording in GlobalSign's incident 
report ( 
https://downloads.globalsign.com/acton/attachment/2674/f-06d2/1/-/-/-/-/globalsign-incident-report-13-oct-2016.pdf
 ):

-Revocation of the certificate was intended. GlobalSign writes: "In a 
revocation exercise which should have been 'business as usual.'" The 
certificate they intended to revoke is referred to as a "Cross Certificate."

-They first published the revocation to their CRL. No adverse effects.

-They then published the revocation to their OCSP database. This is where the 
issue occurred. It seems that, due to the subject information of the revoked 
certificate, it was inferred that a separate intermediate certificate, which 
had NOT been revoked (at least, in GlobalSign's opinion) HAD been revoked.

It appears that this error is a bug in the third-party OCSP software that 
GlobalSign uses. They wrote: "the logic within the responder code base
determined that the revocation of the Cross Certificate, identified by its 
Public Key and Subject Name in a lookup table, was
effectively an instruction to also identify all other subordinate certificate 
authorities including DomainSSL and AlphaSSL as ‘bad’."

-This incident caused the widespread revocation errors that The Register 
reported on.

-GlobalSign remediated the issue in multiple ways: They "unrevoked" the Cross 
Certificate, so that the CDNs they were using for OCSP availability would 
"refresh" and stop reporting the revocation. They also issued a new set of 
intermediate certificates that server admins could configure their server to 
use. 

Either option would hopefully allow affected sites to solve the problem.

Some users were never affected because the CDNs that provided the OCSP 
information did not cache  at those CDNs. Some sites were never affected 
because GlobalSign has separate roots for some certs (EV, etc).



-

So, on to the question of if this is a violation of the Baseline Requirements. 
It seems like it may indeed be a violation.

Looking at the BRs ( 
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf ). 
Section 4.10.1 says:

"Revocation entries on a CRL or OCSP Response MUST NOT be removed until after 
the Expiry Date of the revoked Certificate."

In GlobalSign's Incident Report, within the section "Incident Timeline", they 
write:

"13-Oct-16 12:20 Removal of cross signing certificate from the OCSP Database"

So it seems that be un-publishing the revocation information for the Cross 
Certificate would indeed be a BR violation. But this is not an area of 
compliance I am familiar with. 

Hopefully someone else can chime in and say for sure if this is a violation.

___
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

2016-10-16 Thread okaphone . elektronika
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


Re: Globalsign accidental intermediate revocation incident

2016-10-16 Thread Kurt Roeckx
On Sun, Oct 16, 2016 at 07:38:29AM -0700, Nick Lamb wrote:
> On Sunday, 16 October 2016 08:59:13 UTC+1, Adrian R.  wrote:
> > They rolled back the revocation, but i thought that the BRs explicitly 
> > forbid that a suspended/revoked certificate be un-suspended/un-revoked.
> 
> I don't know whether the exact text permits this, but it seems from a common 
> sense point of view that what happened here wasn't a revoked certificate 
> being unrevoked, but instead a technical fault resulted in the creation of 
> Bad OCSP responses for a period of time by mistake for certificates 
> GlobalSign never actually revoked.

As far as I understood things, it was also in the CRL.


Kurt

___
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

2016-10-16 Thread Nick Lamb
On Sunday, 16 October 2016 08:59:13 UTC+1, Adrian R.  wrote:
> They rolled back the revocation, but i thought that the BRs explicitly forbid 
> that a suspended/revoked certificate be un-suspended/un-revoked.

I don't know whether the exact text permits this, but it seems from a common 
sense point of view that what happened here wasn't a revoked certificate being 
unrevoked, but instead a technical fault resulted in the creation of Bad OCSP 
responses for a period of time by mistake for certificates GlobalSign never 
actually revoked. Mere _machines_ believed these certificates had been revoked, 
but they were not.

Although we'd usually say "contract" means a signed piece of paper the law 
considers that just an artefact, a contract is the "meeting of minds" requiring 
both parties to understand and agree on its terms. That's why tricking someone 
into signing works in the movies but not so much in real life. Likewise I think 
an OCSP "Bad" response, though we'd colloquially call it a revocation is only a 
technical artefact, actual revocation is a decision by the Issuer.

Does that make sense?
___
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

2016-10-16 Thread Han Yuwei
在 2016年10月16日星期日 UTC+8下午3:59:13,Adrian R.写道:
> Hello
> 
> i read in the news (but not here on m.d.s.p) that a few days ago Globalsign 
> revoked one of their intermediary roots and then un-revoked it (well, the 
> revocation is accidental, but it was still a properly announced revocation, 
> via signed CRL and OCSP).
> 
> http://www.theregister.co.uk/2016/10/15/globalsign_incident_report/
> 
> They rolled back the revocation, but i thought that the BRs explicitly forbid 
> that a suspended/revoked certificate be un-suspended/un-revoked.
> 
> https://www.globalsign.com/en/customer-revocation-error/
> 
> is this revival/un-revocation of an intermediary CA allowed by the BRs?
> 
> 
> Adrian R.
> 
> (p.s. can we call this revived certificate a zombie? :) )
> 
> 
> 
> 
> 
> (off-topic note: sigh, was intending not to post here again because news 
> relay servers that strip DKIM signatures will generate a lot of DMARC failure 
> reports for rejected messages. oh well.)

It's said that OCSP servers are responsible for this. Not a intented revocation.

Don't sure, but I would see someone can explain this.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Globalsign accidental intermediate revocation incident

2016-10-16 Thread okaphone . elektronika
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Globalsign accidental intermediate revocation incident

2016-10-16 Thread okaphone . elektronika
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


Globalsign accidental intermediate revocation incident

2016-10-16 Thread Adrian R.
Hello

i read in the news (but not here on m.d.s.p) that a few days ago Globalsign 
revoked one of their intermediary roots and then un-revoked it (well, the 
revocation is accidental, but it was still a properly announced revocation, via 
signed CRL and OCSP).

http://www.theregister.co.uk/2016/10/15/globalsign_incident_report/

They rolled back the revocation, but i thought that the BRs explicitly forbid 
that a suspended/revoked certificate be un-suspended/un-revoked.

https://www.globalsign.com/en/customer-revocation-error/

is this revival/un-revocation of an intermediary CA allowed by the BRs?


Adrian R.

(p.s. can we call this revived certificate a zombie? :) )





(off-topic note: sigh, was intending not to post here again because news relay 
servers that strip DKIM signatures will generate a lot of DMARC failure reports 
for rejected messages. oh well.)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy