On 02/04/2009 08:27 PM, Frank Hecker:
2. I understand that what happened in the case of StartCom was not
exactly the same as what happened in the case of Comodo/CertStar.
However it's part of web security basics to assume that whatever a
client sends to a server is untrusted and must be (re)verified on the
server side to forestall potential attacks (e.g., SQL injection, etc.)
Correct. Since there wasn't much interest in this issue I haven't kept
updating on this. It appears - and according to our records, that the
time-window for this error was of limited nature too and some changes in
the code (incidentally made for EV certs) allowed for this type of
attack. As you correctly state, lots of potential attacks are taken into
consideration, validated and monitored. We improved also the procedures
for such changes.
So IMO you get points for prompt disclosure and fixes, but in the end
you messed up just like Comodo and CertStar did.
Nonono :-)
I see the main differences as followed and I believe the main
differences are policy wise (and allow me to comment on this since you
made the comparison).
StartCom requires domain control validation performed in a very specific
way. This is a matter of choice and policy. StartCom doesn't out-source
the validation nor uses RAs, hence doesn't have to implement controls
for RAs and third parties validations.
Now, due to the validations StartCom DOES perform and due to the careful
recording of all data, StartCom had the ability to KNOW exactly which
email address was used to validate a domain. Due to other protection
layers including staff awareness, this incidents potential damage was
kept to a minimum.
Unfortunately at Certstart there was no domain validation at all. Any
such steps didn't exist. And Comodo has apparently failed to verify how
Certstar does that.
Does Comodo know how the domain name was validated? Do they have any
records about which email addresses or any other evidences about how the
supposed validation was done? Which protective layers prevented the
issuance of a high-profile domain? Or anything?
From where I stand and from my point of view, I see clear differences
in both cases - policy and implementation wise. The differences can have
consequences, because a fix in a program is one thing, a fix in a policy
quite another.
(As such, both events didn't came close to a situation which isn't
correctable)
3. To paraphrase what Nelson (?) wrote, "bugs happen". I don't think the
PKI/CA system is so fragile that it necessarily comes tumbling down
whenever a CA or RA makes a mistake. (If it really is that fragile then
we have bigger problems than those we're discussing here.) From a policy
point of view I think our interest is having CAs acknowledge problems
and fix them in a timely manner, both in terms of revoking certs when
needed and also in terms of addressing any underlying root causes.
Frank, of course every effort has to be made to prevent any failures,
but it's a reality that vulnerabilities and bugs can happen. The MD5
collision and the Debian weak keys are also just another example. It
really matters how prepared a CA is to act under such circumstances. It
matters which additional protection layers exist and which conflicts of
interests would prevent a CA from acting upon a known failure or
vulnerability. In this respect I hope that StartCom served as an example
to follow, even under the circumstances of a negative event. Or perhaps
because of it, since the real test happens under such circumstances and
not when everything is rosy ;-)
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog: https://blog.startcom.org
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
