> On 2 Nov 2015, at 6:32 PM, Yaron Sheffer <yaronf.i...@gmail.com> wrote: > >>>>> If not here, where does this advice go? >>>> >>>> I see your point. But for instance for X509 certificates, I really would >>>> like to not make any statement and point to whatever equivalent of PKIX >>>> documents there are on that. Does the TLS WG have any documents on >>>> crypto agility for PKIX? >>> >>> The TLS list currently has a thread about whether TLS 1.3 should prohibit >>> SHA-1 only in signatures or also in the certificate chain. >> >> https://mailarchive.ietf.org/arch/msg/tls/-1LxtUHZTQXvvMVsLR4jzp79q9E >>> >>> It’s not decided yet, but they *are* prohibiting SHA-1 in the protocol >>> (CertificateVerify message), and current spec prohibits server certificate >>> signed with SHA-1 (only EE certificate) when another certificate exists. >>> > > For TLS, the industry is moving faster than the WG on this. Chrome warnings > are causing people to migrate to all-SHA256 certificate chains soon. IKE > often works with custom certs and private CAs, so the IPsec community needs > to set its own standards.
Chrome is both a TLS implementation and a PKIX relying party. The question there is not whether signing intermediate certificates with SHA-1 is good or bad. It’s definitely bad. These chains ought to be rejected. The only question is whether such advice belongs in the TLS spec or some PKIX document (tentatively named “SHA-1 die, die, die”) As for IKE, yes we often work with private CAs, but if those CAs sign certificates with SHA-1, it would make it as easy to forge as if they were public CAs. Issuance usually involves generating a certificate request and running an enrollment protocol, no matter how many layers of pretty purple GUI my employer hides this under. So if your private CA signs with SHA-1, it should be modified to sign with something better, just as it should have been modified to issue certificates with 2048-bit RSA rather than 1024-bit. Just like TLS, we can specify requirements on the certificates in an IPsecME spec, or we can rely on PKIX best practices. But what algorithm is used in the AUTH payload? That’s entirely up to us. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
