40 likes | 145 Vues
An idea for Instantaneous Secure Enrollment. Marco “Kiko” Carnut <kiko@tempest.com.br> 4th PKI R&D Workshop WIP session NIST, Apr/2005. 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
E N D
An idea for Instantaneous Secure Enrollment Marco “Kiko” Carnut <kiko@tempest.com.br> 4th PKI R&D Workshop WIP session NIST, Apr/2005
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
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
Thank you! Questions? Real Protection against Real Digital Threats kiko@tempest.com.br