私がVoceraの証明書に関するセキュリティ迂回問題を報告すると、SecurityFocusはこれを取り上げてBugtraq ID 27935を割り当て、顧客にこの脆弱性について警告した。私はSecuniaにもこのセキュリティホールについて知らせたが、セキュリティホールは想定外のもので、無責任な設計上の選択の結果でなければセキュリティホールではないと考えているようだった。Secuniaの私への返答は次のようなものだった。

　VoceraのPEAPの実装に関する調査結果について注意喚起を頂き感謝します。

　しかしながら、Secuniaは本件について勧告を出すことはしないことに決定しました。これは、（あなた自身が自らの記事で指摘しているとおり）Voceraの文書に、証明書の検証を行わないのは設計上の判断であることが明記されているためです。それに加え、Voceraは電話機では他のプロトコルをサポートしていることも記しており、これにはあなたがユーザーに推奨しているWPA-PSKも含まれています（http://www.vocera.com/downloads/InfrastructureGuide.pdf 55ページ）。従って、この問題は本来電話機のものでも、ユーザーが選択するプロトコルのものでもありません。

　また、ユーザーが自らのセキュリティの必要性に応じたプロトコルを選択する責任を負っていることから、ユーザーへの影響は最小限のものです。

　この問題に注意喚起を行うため、個人的にわれわれに連絡して頂いたことに感謝します。今後も、あなたが重要だと考える問題については、同様にしてください。

　私はSecuniaの返答は奇妙なものだと思う。PEAPは正しく実装された場合、非常に安全な認証プロトコルだとされているからだ。また、SecuniaはCiscoのACS RADIUSサーバが電子証明書の暗号処理上の検証を行っていないという非常に似た問題は取り上げていることから、一貫性にも欠けている。また、SecuniaはVoceraの脆弱性が明らかになった2日後に確認された、Cisco 7921のまったく同じ脆弱性についてはどう扱うつもりなのだろうか。Ciscoはこれが設計上の選択であるとは述べておらず、事前にウェブサイトでこの事実を開示することもしていなかったのだ。

　もしベンダーが簡単にセキュリティホールは設計上の選択であり、ユーザーはそれを回避すればいいだけだと主張したらどうなるかを考えてみるべきだろう。私はまた、Secuniaが彼らが設計上の「特性」であり「セキュリティホール」ではないと見なして省いているセキュリティホールは他にどんなものがあるのかと考え、Secuniaのセキュリティ情報に依存することに対する確信が薄れた。ひょっとすると、かわりにSecurityFocusを使い始めた方が賢明かも知れない。