Talk:Simple Certificate Enrollment Protocol

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Notability[edit]

Removing the notability warning badge. This article seems fine to me, at a start. SCEP is supported by every iPhone, so fairly broadly applicable to the modern world. DouglasHeld (talk) 18:27, 8 April 2011 (UTC)[reply]

I agree that it's notable. However, @Anton.bersh put another warning on the page. These people who are doing this need to start giving some sort of justification on why they think it isn't notable. I am going to remove the notice.—Kjsehyrt (talk) 22:38, 13 January 2022 (UTC)[reply]

Security[edit]

According to http://www.kb.cert.org/vuls/id/971035 even the SCEP RFC encourages the use of CMP/CMS/CMC over SCEP. Also there are many warnings about using SCEP with MDM systems on the internet. I don't think the security issues are clearly stated here.

Some more resources:

--Dveeden (talk) 09:16, 2 July 2014 (UTC)[reply]

It was actually Cisco pushing for the new shiny, the world didn't follow suit. Cisco put a lot of lies out about SCEP (SCEP not supporting ECC keys etc) when it's actually their implementation limitation -- JidGom (talk) 07:57, 15 September 2020 (UTC)[reply]

Vulnerability[edit]

The SCEP "vulnerability" mentioned in this article is bollocks, it was created by CSS to sell their expensive patent-pending "SCEP Validation Service". What their advisory in effect says is that if a CA blindly signs whatever comes in in a SCEP request then there's a privesc vulnerability. That's a bit like saying that if the State Department blindly issues passports without checking that the paperwork is valid, there's a bit of a security problem. Oh, and we have an expensive enterprise-grade service we'll sell you to fix this. Should this piece of marketing PR be part of a Wikipedia article?

806f0F (talk) 06:26, 28 March 2015 (UTC)[reply]

I removed it at last, the final RFC is now clear on secure usage, it was always more about misuse than protocol vulnerability. -- JidGom (talk) 08:07, 15 September 2020 (UTC)[reply]

Known implementations[edit]

The "implementations" section was removed a while back on the basis of it being spam (since, I guess, some of the implementations are commercial?). I think it was useful information to include in this article, and did not appear to be being used for advertising. — Preceding unsigned comment added by 198.151.161.131 (talk) 21:07, 15 April 2019 (UTC)[reply]

Criticism[edit]

Currently in the article : "Due to the use of the self-signed PKCS#10 format for Certificate Signing Requests (CSR), certificates can be enrolled only for keys that support signing."

What would be the possible use case for a non signing public key in a certificate, is there even such a thing? No such criticism was talked about during the very lengthy standardization process. JidGom (talk) 10:32, 31 May 2021 (UTC)[reply]

Courtesy ping for @DvO: who added this statement in the first place.
@JidGom: I agree that this statement does not make any sense. I'll remove it, since it is not supported by any source and I don't see any way to find out what DvO meant by it.
Anton.bersh (talk) 16:12, 31 May 2021 (UTC)[reply]
@Anton.bersh: and @JidGom: you seem to have insufficient knowledge of cryptography and PKI.
There are certs for public keys not capable of signing, e.g., Diffie-Hellman key agreement keys.
You should have a look at, e.g., the CMP spec: RFC 4210 which does allow for such keys.
Moreover, with post-quantum cryptography we will very likely see this much more often.
So I re-added the wrongly removed item.
DvO (talk) 10:39, 10 June 2021 (UTC)[reply]
@DvO: Thanks for stopping by. Yes, there are public key schemes not capable of signing (like Diffie–Hellman key exchange mentioned by you), but these are typically not used in the wild by themselves, and instead, they can be used together with a signature scheme to authenticate at least one party who actually presents the certificate. Also, most Post-quantum cryptography algorithms used in the wild do support signing (for example, ECDSA and EdDSA), so I don't understand what you mean. Also, Wikipedia articles should contain information backed by reliable soureces and does not care about truth known only by one person on the internet. Anton.bersh (talk) 12:17, 10 June 2021 (UTC)[reply]
@DvO: Has there been a single deployed in the wild usage of DH certificate? CMP did specify all sort of design by committee stuff, but thankfully it didn't make it to the real world. https://crypto.stackexchange.com/a/19468 did quite a bit of research and come to the conclusion "Apparently for the last 15 years there has been essentially no demand; this suggests that the peer systems you can communicate with using static-DH is probably the empty set." Even e.g. DSA keys nowadays have anecdotal usage in the real world, since the biggest certificates user, the web, through the CABforum baselines, mandates RSA or ECDSA. JidGom (talk) 14:40, 10 June 2021 (UTC)[reply]
Correct that DH certs are very rare.
So can we agree that this criticism is bunk, as the limitation is shared by competing protocols, and that being able to enroll with DH certs would serve no practical purpose whatsoever (standardizing DH certs was a mistake, since it has been made abundantly clear since that encryption without authentication worthless, and that's the thing DH certs would enable in that theoritical protocol) JidGom (talk) 12:49, 15 June 2021 (UTC)[reply]
@Anton.bersh: ECDSA and EdDSA are NOT post-quantum algs. Would be really great if they were quantum computer resistant, but they are not. DvO (talk) 18:57, 11 June 2021 (UTC)[reply]

Timeline[edit]

Of note: Xiaoyi Liu of Cisco was a listed author of both the CMC and SCEP first drafts. It seems that the lack of adoption of CMC led major actors (most notably Cisco and Microsoft at the time) to favor the simpler SCEP and try to formaly standardize it instead of keeping it de facto standard, before Cisco jumped ship to push for EST in the late 2000s. JidGom (talk) 13:43, 1 June 2021 (UTC)[reply]

Summary needed[edit]

The opening part of this article could do with a compact summary of how SCEP works. Something like this: SCEP is an authenticated, HTTP-based protocol for downloading a client certificate from a CA. — Preceding unsigned comment added by 60.241.24.90 (talk) 03:49, 3 November 2022 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Simple_Certificate_Enrollment_Protocol&oldid=1205304068"