1 / 4

Instantaneous Secure Enrollment: A Novel Approach to Client Certification

This document outlines a unique method for secure and instantaneous client enrollment using a two-tier certificate authority (CA) framework. The main CA generates private keys on demand while ensuring user identity verification. Clients receive single certificates that can be trusted, even if their chain is incomplete. The system aims to enhance security and performance while minimizing dependencies on large Certificate Revocation Lists (CRLs). By implementing strict policies, the proposed approach mitigates digital threats and streamlines client access to services.

edith
Télécharger la présentation

Instantaneous Secure Enrollment: A Novel Approach to Client Certification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An idea for Instantaneous Secure Enrollment Marco “Kiko” Carnut <kiko@tempest.com.br> 4th PKI R&D Workshop WIP session NIST, Apr/2005

  2. The Client’s CA • Client’s CA • Private key generated on demand by the main CA • But it’s not released until after the user’s identity is cheched • Restricted to issuing one cert only (clients should verify this) Root CA Main CA Kiko [CA] Kiko [Client] • The client app must consider my client cert as trusted even if it’s chain isincomplete. • Many don’t but... well, Kapanga does • Server web sites accept such incomplete/invalid certs by grant them only“guest-level” access • Most apps will consider their digital sigs invalid at this point, just as we want

  3. Authorization • After the CA properly identifies the user according to its policies, we release the Client’s CA on a key server • The client and everyone else fetches it • Client must enforce extra restrictions for the “single cert principle” • I’ve been using: • Kiko’s CA DN == Kiko’s Client DN • Kiko’s CA Serial == Kiko’s Client Serial • Kiko’s CA is a CA (basicConstraints:CA=TRUE) • Kiko’s Client is a Client (basicConstraints:CA=FALSE) • Now people will be able to trust my cert • Performance: kinda bad, because the CA must generate a new key • Revocation: we can have a small, single-serial CRL • No large CRLs anymore

  4. Thank you! Questions? Real Protection against Real Digital Threats kiko@tempest.com.br

More Related