ตัวแปลงคีย์ JWK ⇄ PEM

JSON Web Keys (JWK) และคีย์ที่เข้ารหัส PEM จะแสดงสลับกันได้ในไลบรารี JWT, เครื่องมือ TLS และการกำหนดค่า OAuth/OIDC แต่การแปลงระหว่างทั้งสองด้วยมือหมายถึงโครงสร้าง DER ที่ถอดรหัส base64 หรือฟอร์แมต JSON ใหม่ ซึ่งง่ายต่อการเข้าใจผิดอย่างละเอียด เครื่องมือนี้ทำการแปลงด้วย Web Crypto API จริงของเบราว์เซอร์แทนการจัดการข้อความ: บล็อก PEM ที่วางจะถูกนำเข้าด้วย crypto.subtle.importKey('spki'|'pkcs8', ...) และส่งออกอีกครั้งเป็น JWK ด้วย ExportKey('jwk', ...); JWK ที่วางจะถูกนำเข้าด้วย importKey('jwk', ...) และส่งออกอีกครั้งเป็น SPKI หรือ PKCS8 DER จากนั้นรวมไว้ในส่วนหัว PEM ที่ถูกต้อง เนื่องจากเบราว์เซอร์จะตรวจสอบและถอดรหัสวัสดุคีย์เอง คีย์ที่มีรูปแบบไม่ถูกต้องหรือการเลือกอัลกอริธึมที่ไม่ตรงกันจึงล้มเหลวอย่างดังแทนที่จะสร้างขยะอย่างเงียบๆ

อัลกอริธึมที่รองรับ ได้แก่ RSA (RSASSA-PKCS1-v1_5), EC บนเส้นโค้ง P-256/P-384/P-521 และ — ตำแหน่งที่เบราว์เซอร์ใช้งาน — Ed25519 และ X25519 การสนับสนุนเบราว์เซอร์สำหรับ Ed25519/X25519 ใน Web Crypto ยังคงไม่สอดคล้องกันในเอ็นจิ้นต่างๆ ดังนั้นแทนที่จะคาดเดาจากสตริงตัวแทนผู้ใช้ เครื่องมือจะรันโพรบ crypto.subtle.generateKey() จริงสำหรับเส้นโค้งที่เลือก และบอกคุณอย่างชัดเจนว่าไม่รองรับที่นี่ แทนที่จะส่งคืนผลลัพธ์ที่ประดิษฐ์ขึ้น

ทุกการแปลงยังถอดรหัสข้อมูลเมตาที่แท้จริงของคีย์ด้วย: สำหรับคีย์ RSA ความยาวบิตโมดูลัสและอัลกอริธึมแฮชตรงจากออบเจ็กต์ CryptoKey สำหรับคีย์ EC และ OKP เส้นโค้งที่มีชื่อ และสำหรับทุกคีย์ รหัสประจำตัว RFC 7638 JWK — แฮช SHA-256 ของสมาชิกที่ต้องการของ JWK ตามลำดับพจนานุกรมที่เข้มงวด (e/kty/n สำหรับ RSA, crv/kty/x/y สำหรับ EC, crv/kty/x สำหรับ OKP/Ed25519/X25519) รหัสประจำตัวนี้คือสิ่งที่หลายระบบใช้เป็นตัวระบุ "ลูก" ของคีย์ และการสั่งสมาชิกผิดจะทำให้เกิดแฮชที่แตกต่างออกไปโดยสิ้นเชิง ซึ่งเป็นข้อผิดพลาดประเภทที่การใช้งานด้วยมือมีแนวโน้มที่จะเกิดขึ้น

เนื่องจากทุกอย่างทำงานผ่าน crypto.subtle ในแท็บเบราว์เซอร์ของคุณเอง เนื้อหาของคีย์ส่วนตัวจึงไม่เคยออกจากอุปกรณ์ของคุณ ไม่มีเซิร์ฟเวอร์ ไม่มีการอัปโหลด และไม่มีการเรียก API ภายนอกที่เกี่ยวข้อง ณ จุดใด ๆ ของการแปลง