Oh okay. We just need to remove the final "at" in the last sentence (this
is what makes it seem like there is a link to follow).

No link is necessary, because the link is already there at [original proof
of concept]


On Fri, May 9, 2014 at 12:55 AM, Terence Lee <notifications@github.com>wrote:

> In en/news/_posts/2014-05-09-disputed-vulnerability-cve-2014-2734.md:
>
> > +
> > +There are two cases to consider:
> > +
> > +### Resigning a root certificate
> > +
> > +As trust anchors, we trust root certificates unconditionally. Even if they did contain invalid information, the status of being a publicly acknowledged root certificate alone is what keeps them pristine. They are preconfigured values in the trust stores of our browsers or operating systems, simply possessing them establishes their status as valid trust anchors. For example, OpenSSL itself does not check the signature of self-signed root certificates by default for the same reasons. [cf. X509_V_FLAG_CHECK_SS_SIGNATURE documentation](https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_flags.html)
> > +
> > +A resigned root certificate becomes a de facto “self-signed” certificate (albeit with incorrect Subject Public Key Info). This is not any more powerful or dangerous than a normal self-signed root certificate. In fact , anyone is able to produce self-signed root certificates whose certificate information may completely match that of a valid root certificate - except for the signature. Since we trust root certificates merely by possession, such an imposter certificate is meaningless without any client’s active consent to trust it.
> > +
> > +### Resigning an intermediate or leaf certificate
> > +
> > +Resigning a non-root certificate does not violate the security of the X.509 trust model either. While we usually do not possess these kinds of certificates in advance, their forgery would be detected during the [path validation  procedure](http://tools.ietf.org/html/rfc5280#section-6). Here, any non-root certificate’s signature is verified using the public key of the issuing certificate. At some point in the certificate chain, the forgery would be ultimately detected in the form of an invalid certificate signature value.
> > +
> > +## Conclusion
> > +
> > +In conclusion, we believe that `X509Certificate#verify` operates as expected. Others have independently arrived at the [same conclusion](https://github.com/adrienthebo/cve-2014-2734/) and we have therefore disputed CVE-2014-2734, asking for its revocation. You may find our complete analysis of the [original proof of concept](https://gist.github.com/emboss/91696b56cd227c8a0c13) including comments at.
>
> what link?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/ruby/www.ruby-lang.org/pull/744/files#r12466804>
> .
>



-- 
Hajime Kenneth Murakami
(650) 793-3820