Certificates, Trust & PKI Brian A. La. Macchia bal@cs. washington. edu bal@microsoft. com Portions © 2002 -2006, Brian A. La. Macchia. This material is provided without warranty of any kind including, without limitation, warranty of non-infringement or suitability for any 2006 February 21, purpose. This material is not guaranteed to be error free and Cryptography for instructional use only. Practical Aspects of Modern is intended 0
Certificates February 21, 2006 Practical Aspects of Modern Cryptography 0
Why do I trust the server key? v v How do I know I’m really talking to Amazon. com ? What defeats a man-in-the-middle attack? Client February 21, 2006 HTTP with SSL/TLS Mallet HTTP with SSL/TLS Practical Aspects of Modern Cryptography Web Server 3
SSL/TLS You (client) Merchant (server) Let’s talk securely. Here are the protocols and ciphers I understand. I choose this protocol and ciphers. Here is my public key and some other stuff that will make you trust this key is mine. Here is a fresh key encrypted with your key. February 21, 2006 Practical Aspects of Modern Cryptography 4
What’s the “some other stuff” How can we convince Alice that some key belongs to Bob? v Alice and Bob could have met previously & exchanged keys directly. n v Jeff Bezos isn’t going to shake hands with everyone he’d like to sell to. . . Someone Alice trusts could vouch to her for Bob and Bob’s key n February 21, 2006 A third party cancertify Bob’s key in a way that convinces Alice. Practical Aspects of Modern Cryptography 5
What is a certificate? v A certificate is a digitally-signed statement that binds a public key to some identifying information. n n v The signer of the certificate is called its issuer. The entity talked about in the certificate is the subject of the certificate. That’s all a certificate is, at the 30, 000’ level. February 21, 2006 Practical Aspects of Modern Cryptography 6
Certificates are Like Marriage By the power vested in me I now declare this text and this bit string “name” and “key. ” What RSA has joined, let no man put asunder. --Bob Blakley February 21, 2006 Practical Aspects of Modern Cryptography 7
Certs in the “real world” v A driver’s license islike a certificate n n n February 21, 2006 It is a “signed” document (sealed, tamperresistant) It is created and signed by an “issuing authority” (the WA Dept. of Licensing) It binds together various pieces of identifying information n Name n License number n Driving restrictions (must wear glasses, etc. ) Practical Aspects of Modern Cryptography 8
More certs in the real world v Many physical objects are like certificates: n n n v Any type of license – vehicle tabs, restaurant liquor license, amateur radio license, etc. Government-issued IDs (passports, green cards) Membership cards (e. g. Costco, discount cards) All of these examples bind an identity and certain rights, privileges or other identifiers n February 21, 2006 “BAL ==N 1 TJT” signed FCC Practical Aspects of Modern Cryptography 9
Why do we believe whatcerts say? v In the physical world, why do we trust the statements contained on a physical cert? n n v We believe it’s hard to forge the cert We trust the entity that “signed” the cert In the digital world we need those same two properties n n February 21, 2006 We need to believe it’s hard to forge the digital signature on a signed document We need to trust the issuer/signer not to lie to us Practical Aspects of Modern Cryptography 10
Defeating Mallet Bob can convince Alice that his key really does belong to him if he can also send along a digital certificate Alice will believe & trust Let’s talk securely. Here are the protocols and ciphers I understand. Cert Alice February 21, 2006 I choose this protocol and ciphers. Here is my public key and a certificate to convince you that the key really belongs to me. Practical Aspects of Modern Cryptography Bob 11
Getting a certificate v v v How does Bob get a certificate for his key? He goes to a Certificate Authority (CA) that issues certificates and asks for one. . . The CA issues Bob a certificate for his public key. n n February 21, 2006 CA is the issuer Bob is the subject Practical Aspects of Modern Cryptography 12
Using Certificates v v Now that Bob has a certificate, is it useful? Alice will believe Bob’s key belongs to Bob if Alice believes the certificate Bob gives her for his key. Alice will believe Bob’s key belongs to Bob if Alice trusts the issuer of Bob’s certificate to make key-name binding statements Have we made the situation any better? February 21, 2006 Practical Aspects of Modern Cryptography 13
Does Alice Trust Bob’s CA? How can we convince Alice to trust Bob’s CA? v Alice and Bob’s CA could have met previously & exchanged keys directly. n February 21, 2006 Bob’s CA isn’t going to shake hands with everyone he’s certified, let alone everyone whom Bob wants to talk to. Practical Aspects of Modern Cryptography 14
Does Alice Trust Bob’s CA? How can we convince Alice to trust Bob’s CA? v Alice and Bob’s CA could have met previously & exchanged keys directly. n v Bob’s CA isn’t going to shake hands with everyone he’s certified, let alone everyone whom Bob wants to talk to. Someone Alice trusts could vouch to her for Bob’s CA and Bob’s CA’s key n n February 21, 2006 Infinite Loop: See Loop, Infinite. Actually, it’s just a bounded recursion. . . Practical Aspects of Modern Cryptography 15
What’s Alice’s Trust Model v Alice has to implicitly trust some set of keys n v In the model used by SSL/TLS, CAs are arranged in a hierarchy n v Once she does that, those keys can introduce others to her. Alice, and everyone else, trusts one or more “root CA” that live at the top of the tree Other models work differently February 21, 2006 Practical Aspects of Modern Cryptography 16
Public Key Infrastructure February 21, 2006 Practical Aspects of Modern Cryptography 0
Certificate Authorities v v A certificate authority (CA) guarantees the connection between a key and another CA or an “end entity. ” An end entity is: n n n v A person A role (“VP of sales”) An organization A pseudonym A piece of hardware or software An account Some CA’s only allow a subset of these types. February 21, 2006 Practical Aspects of Modern Cryptography 18
CA Hierarchies v v CAs can certify other. CAs or “end entities” Certificates are links in a tree of & CAs EEs Root CA CA CA EE February 21, 2006 CA EE Practical Aspects of Modern Cryptography EE 19
BAL’s No-Frills Certs v Certificates can contain all sorts of information inside them n v We’ll talk about the details in a little bit In the abstract, though, they’re just statements by an issuer about a subject: Issuer Subject February 21, 2006 Practical Aspects of Modern Cryptography 20
Does Alice trust Bob’s Key? v Alice trusts Bob’s key if there is a chain of certificates from Bob’s key to a root CA that Alice implicitly trusts Root CA CA EE Root CA CA CA EE February 21, 2006 Practical Aspects of Modern Cryptography 21
Chain Building & Validation v “Given an end-entity certificate, does there exist a cryptographically valid chain of certificates linking it to a trusted root certificate? ” Root CA CA EE Root CA CA CA EE February 21, 2006 Practical Aspects of Modern Cryptography 22
Chaining Certificates v In theory, building chains of certificates should be easy n v “Just link them together like dominos” In practice, it’s a lot more complicated. . . February 21, 2006 Practical Aspects of Modern Cryptography 23
Chain Building Details (1) Root CA CA 1 CA 2 EE 1 EE 2 EE 3 EE 1 February 21, 2006 CA 1 EE 2 EE 3 Practical Aspects of Modern Cryptography 24
Chain Building Details (2) Root CA 1 Root CA 2 CA 1 EE 1 February 21, 2006 CA 2 EE 2 Practical Aspects of Modern Cryptography EE 3 25
Chain Building Details (3) Root CA 1 Root CA 2 CA 1 EE 1 February 21, 2006 CA 2 EE 2 Practical Aspects of Modern Cryptography EE 3 26
Chain Building Details (3) Root CA 1 EE 1 February 21, 2006 Root CA 2 Bridge CA CA 2 EE 2 Practical Aspects of Modern Cryptography EE 3 27
Chain Building Details (3) Root CA 1 EE 1 February 21, 2006 Root CA 2 Bridge CA CA 2 EE 2 Practical Aspects of Modern Cryptography EE 3 28
Chain Building Details (3) Root CA 1 EE 1 February 21, 2006 Root CA 2 Bridge CA CA 2 EE 2 Practical Aspects of Modern Cryptography EE 3 29
Chain Building Details (3) Root CA 1 EE 1 February 21, 2006 Root CA 2 Bridge CA CA 2 EE 2 Practical Aspects of Modern Cryptography EE 3 30
Chaining Certificates v How do we determine whether two certificates chain together? n n n v You’d think this was an easy problem. . . But it’s actually a question with religious significance in the security community “Are you a believer innames, or in keys? ” In order to understand the schism, we need to digress for a bit and talk about names and some history February 21, 2006 Practical Aspects of Modern Cryptography 31
PKI Alphabet Soup v v X. 509 v 3 - standard content of a certificate PKIX – IETF Working Group on PKI interoperability n v v February 21, 2006 PKIX == Public Key Infrastructure using X. 509 v 3 certificates ASN. 1 - Abstract Syntax Notation, exact description of a certificate format DER - Distinguished Encoding Rules, how to physically package a certificate Practical Aspects of Modern Cryptography 32
The X. 500 Directory Model v The model SSL/TLS uses, the X. 509 certificate model, is based on names n v v Names as principles Specifically, X. 509 is based on the X. 500 directory model X. 500 defined a global, allencompassing directory, to be run by the telcos n February 21, 2006 One directory to rule them all, one directory to define them. . . Practical Aspects of Modern Cryptography 33
X. 500 Distinguished Names v In the X. 500 model, everything has a single, unique, global, assigned name n There is a worldwide hierarchy, and you’re in it! Country C=US SP = OR State or Province SP = WA Locality L=Redmond L=Seattle Organization O=Microsoft February 21, 2006 SP = CA O=Univ. of Washington Practical Aspects of Modern Cryptography 34
DNs in Practice v v Name is unique within the scope of the CA’s name Public CAs (e. g. Verisign) typically set n n n February 21, 2006 C = CA Country O = CA Name OU = Certificate type/class CN = User name E= email address Practical Aspects of Modern Cryptography 35
Private-label DNs v If you own the CA, you get to decide what fields go in the DN n v Really varies on what the software supports Can get really strange as people try to guess values for fields that are required by software n February 21, 2006 Software requires an OU, we don’t have OUs, so I better make something up! Practical Aspects of Modern Cryptography 36
DNs in X. 509 Certificates v v The X. 509 certificate standard began as a way to associate a certificate with a node in the directory. How is the subject of a cert identified? n v How is the issuer of a cert identified? n v By its DN. How are certificates linked together? n February 21, 2006 By DNs. Practical Aspects of Modern Cryptography 37
Key fields in a certificate v The core fields of an X. 509 certificate are n n n v The subject public key The subject Distinguished Name The issuer Distinguished Name What’s missing here? February 21, 2006 Practical Aspects of Modern Cryptography 38
Key fields in a certificate v The core fields of an X. 509 certificate are n n n v The subject public key The subject Distinguished Name The issuer Distinguished Name What’s missing here? n n February 21, 2006 The issuer’s public key is not present in the certificate. You can’t verify the signature on the cert without finding a parent cert! Practical Aspects of Modern Cryptography 39
Back to Chain Building v OK, assume we’re a “relying party application” -- something that received an end-entity certificate and wants to verify it. n v Our task is to build a cert chain from that end-entity cert to one of our trusted roots How do we do that? n February 21, 2006 We start with our EE cert, and using the information contained within we look for possible parent certificates. Practical Aspects of Modern Cryptography 40
Parent certs v What’s a valid parent certificate? n n v In the raw X. 509 model, parent-child relationships are determined solely by matching Issuer DN in the child to Subject DN in the parent Recall that there’s an assumption that you have a big directory handy to find certs. If you don’t have a directory handy, you need to do the matching yourself n February 21, 2006 This is not as easy as you might think… Practical Aspects of Modern Cryptography 41
Name matching Issuer Name Subject Name February 21, 2006 Practical Aspects of Modern Cryptography 42
Matching Names v How do we determine if two DNs match? n n n February 21, 2006 “Use directory name matching rules!” Try to be mildly smart about it n Remove spaces, case-fold, etc. n Disaster… Try to be really dumb about it n Exact binary match n Less of a disaster, but there are still problems we can’t work around… Practical Aspects of Modern Cryptography 43
Unicode Names v v Are these two character equal? é é They look equal… February 21, 2006 Practical Aspects of Modern Cryptography 44
Unicode Names v v Are these two character equal? é é They look equal… …but may not be In Unicode, you can compose characters, so: n n n v “é” as one character “é” as two characters – “e” followed by non-spacing accent “é” as two characters – non-spacing accent followed by “e” Ick! February 21, 2006 Practical Aspects of Modern Cryptography 45
Even More Chain Building v Name matching is just the beginning of the chain-building process n v It is necessary that subject and issuer. DNs exactly match for twocerts to chain, but not always sufficient The chain building process is also influenced dynamically by other information contained within the certs themselves n February 21, 2006 What other information is there in certs? Practical Aspects of Modern Cryptography 46
Trusted Root Certificates v v v Who do I trust to be roots at the top of the cert chain? In theory, “anyone you want” In practice, trusted roots come from two sources n n February 21, 2006 They’re baked into your web browser or operating system They’re pushed onto your “enterprise managed desktop” Practical Aspects of Modern Cryptography 47
Trusted Root Certificates February 21, 2006 Practical Aspects of Modern Cryptography 48
Certificate Extensions February 21, 2006 Practical Aspects of Modern Cryptography 0
Exploring inside an X. 509 Cert February 21, 2006 Practical Aspects of Modern Cryptography 50
Exploring inside an X. 509 Cert February 21, 2006 Practical Aspects of Modern Cryptography 51
Exploring inside an X. 509 Cert February 21, 2006 Practical Aspects of Modern Cryptography 52
Inside an X. 509 v 3 Certificate Version Serial Number Signing Algorithm Issuer Distinguished Name Validity Period Subject Distinguished Name Subject Public Key Extensions Extension 1 Extension 2 Extension n February 21, 2006 Practical Aspects of Modern Cryptography 53
Certificate Extensions v An extension consists of three things: n n n February 21, 2006 A “critical” flag boolean) ( A type identifier A value n Format of the value depends on the type identifier Practical Aspects of Modern Cryptography 54
Certificate Extensions Critical? Key Usage Critical? Subject Key ID Authority Key ID CRL Distribution Points Critical? Authority Info Access Extended Key Usage Subject Alt Name Certificate Policies Proprietary Extension 1 Critical? Proprietary Extension n Critical? February 21, 2006 Practical Aspects of Modern Cryptography 55
Critical Flags v The “critical flag” on an extension is used to protect the issuing CA from assumptions made by software that doesn’t understand (implement support for) a particular extension n n February 21, 2006 If the flag is set, relying parties must process the extension if they recognize it, or reject the certificate If the flag is not set, the extension may be ignored Practical Aspects of Modern Cryptography 56
Critical Flags (2) v v Some questions you might be asking yourself right now. . . What does “must process the extension if they recognize it” mean? n n February 21, 2006 What does “recognize” mean? What does “process” mean? You’ve got me. . The IETF standards folks didn’t know either. . . Practical Aspects of Modern Cryptography 57
Critical Flags (3) v Actual definitions of flag usage are vague: n n February 21, 2006 X. 509: Non-critical extension “is an advisory field and does not imply that usage of the key is restricted to the purpose indicated” PKIX: “CA’s are required to support constrain extensions” but “support” is never defined. S/MIME: Implementations should “correctly handle” certain extensions Verisign: “All persons shall process the extension. . . or else ignore the extension” Practical Aspects of Modern Cryptography 58
Types of Extensions v There are two flavors of extensions n n February 21, 2006 Usage/informational extensions, which provide additional info about the subject of the certificate Constraint extensions, which place restrictions on one or more of: n Use of the certificate n The user of the certificate n The keys associated with the certificate Practical Aspects of Modern Cryptography 59
Some common extensions v Key Usage n n n February 21, 2006 digital. Signature n “Sign things that don’t look like certs” key. Encipherment n Exchange encrypted session keys key. Agreement n Diffie-Hellman key. Cert. Sign/key. CRLSign n “Sign things that look like certs” non. Repidiation Practical Aspects of Modern Cryptography 60
Non. Repudiation v The non. Repudiationbit is the black hole of PKIX n n n v It absorbs infinite amounts of argument time on the mailing list without making any progress toward understanding what it means What does it mean? How do you enforce that? No one knows. . . “Nonrepudiationis anything which fails to go away when you stop believing in it” February 21, 2006 Practical Aspects of Modern Cryptography 61
More Extensions v Subject Key ID n v Authority Key ID n v Short identifier for the issuer’s public key – useful for locating possible parent certs CRL Distribution Points n v Short identifier for the subject public key List of URLs pointing to revocation information servers Authority Info Access n February 21, 2006 Pointer to issuer cert publication location Practical Aspects of Modern Cryptography 62
Even More Extensions v Basic constraints n n v Name constraints n v Limits on types ofcerts this key can issue Policy mappings n v Is the cert a CA cert? ’ Limits on path length beneath this cert Convert one policy ID into another Policy constraints n February 21, 2006 Anti-matter for policy mappings Practical Aspects of Modern Cryptography 63
Still More Extensions v Extended Key Usage n v Private Key Usage Period n v Because Key Usage wasn’t confusing enough! CA attempt to limit key validity period Subject Alternative names n n n February 21, 2006 Everything which doesn’t fit in a DN RFC 822 names, DNS names, URIs IP addresses, X. 400 names, EDI, etc. Practical Aspects of Modern Cryptography 64
Yet Still More Extensions v Certificate policies n n n v v Information identifying the CA policy that was in effect when the cert was issued Policy identifier Policy qualifier Explicit text Hash reference (hash + URI) to a document X. 509 defers cert semantics to the CA’s issuing policy Most CA policies disclaim liability February 21, 2006 Practical Aspects of Modern Cryptography 65
Extensions and Chain Building v When you build a cert chain, you start with the EE cert and discover possible parent certificates by matching DNs n v “Build the chain from the bottom up. ” However, to verify a cert chain, you have to start and the root and interpret all the extensions that may constrain subordinate CAs (and EEs) n February 21, 2006 “Build the chain from the top down. ” Practical Aspects of Modern Cryptography 66
Certificate Lifecycle Management February 21, 2006 Practical Aspects of Modern Cryptography 0
Lifecycle Management v Certificate Enrollment n v Renewal n v Initial acquisition of a certificate based on other authentication information Acquiring a new certificate for a key when the existing certificate expires Revocation n February 21, 2006 “Undoing” a certificate Practical Aspects of Modern Cryptography 68
Certificate Enrollment is the process of obtaining a certificate from a CA. Alice generates a key pair, creates a message containing a copy of the public key and her identifying information, and signs the message with the private key (PKCS#10). v 1. n 2. February 21, 2006 Signing the message provided “proof-ofpossession” (POP) of the private key as well as message integrity CA verifies Alice’s signature on the message Practical Aspects of Modern Cryptography 69
Certificate Enrollment (2) (Optional) CA verifies Alice’s ID through out-of-band means. CA creates a certificate containing the ID and public key, and signs it with the CA’s own key 3. 4. n 5. 6. February 21, 2006 CA has certified the binding between key and ID Alice verifies the key, ID & CA signature Alice and/or the CA publish the certificate Practical Aspects of Modern Cryptography 70
Certificate Enrollment Flow Certificate Request and Installation Client CA Publish Certificate? Directory February 21, 2006 Practical Aspects of Modern Cryptography 71
More PKI Alphabet Soup v v PKCS #10 – (old) standard message format for certificate requests PKCS #7 – (old) standard message format for encrypted/signed data n n v CMC – “Certificate Management with CMS” n v Also used for certificate request responses Replaced by IETF CMS syntax Replacement for PKCS #10/PKCS#7 in a certificate management context CMP – “Certificate Management Protocols” n February 21, 2006 Alternative to CMC Practical Aspects of Modern Cryptography 72
Revocation February 21, 2006 Practical Aspects of Modern Cryptography 0
Expiration & Revocation v Certificates (at least, all the ones we’re concerned with) contain explicit validity periods – “valid from” & “expires on” n v Sometimes, though, it becomes necessary to “undo” a certificate while it is still valid n n v Expiration dates help bound the risk associated with issuing a certificate Key compromise Cert was issued under false pretenses This is called revoking a certificate February 21, 2006 Practical Aspects of Modern Cryptography 74
Status Info for Certificates v Two standards within PKIX: n n v X. 509 v 2/PKIX Part 1 Certificate Revocation Lists (CRLs) Online Certificate Status Protocol (OCSP) Both methods state: n n n February 21, 2006 Whether a cert has been revoked A “revocation code” indicating why the cert was revoked The time at which the cert was revoked Practical Aspects of Modern Cryptography 75
Certificate Revocation v A CA revokes a certificate by placing the cert on its Certificate Revocation List (CRL) n n n v Every CA issues. CRLs to cancel out issued certs A CRL is like anti-matter – when it comes into contact with a certificate it lists it cancels out the certificate Think “ 1970 s-style credit-card blacklist” Relying parties are expected to check CRLs before they rely on a certificate n February 21, 2006 “The cert is valid unless you hear something telling you otherwise” Practical Aspects of Modern Cryptography 76
The Problem with. CRLs v Blacklists have numerous problems n n n February 21, 2006 Not issued frequently enough to be effective against a serious attack Expensive to distribute (size & bandwidth) Vulnerable to simple DOS attacks n If you block on lack of CRL access, why have off-line support in the first place? Practical Aspects of Modern Cryptography 77
The Problem with. CRLs (2) v CRL design made it worse n n n February 21, 2006 CLRs can contain retroactive invalidity dates A CRL issued today can say a cert was invalid as oflast week. n Checking that something was valid at time t wasn’t sufficient! n Back-dated CRLs can appear at any time in the future If you rely oncerts & CRLs you’re screwed because the CA can change the rules out from under you later. Practical Aspects of Modern Cryptography 78
The Problem with. CRLs (3) v Revoking a CA cert is more problematic than revoking an end-entity cert n v When you revoke a CA cert, you potentially take out the entire subordinate structure, depending on what chaining logic you use How do you revoke a self-signed cert? n n n February 21, 2006 “The cert revokes itself. ” n Huh? Do I accept the CRL as valid & bounce the cert? Do I reject the CRL because the cert associated with the CRL signing key was revoked? Practical Aspects of Modern Cryptography 79
The Problem with. CRLs (4) v You can’t revoke a CRL n v What happens if you have to update the CRL while the CRL you just issued is still valid? n v Once you commit to a CRL, it’s a valid state for the entirety of its validity period You can update it, but clients aren’t required to fetch it since the one they have is still valid! Bottom line: yikes! n February 21, 2006 We need something else Practical Aspects of Modern Cryptography 80
CRLs vs. OCSP Responses v Aggregation vs. Freshness n n v CRLs combine revocation information for many certs into one long-lived object OCSP Responses designed for real-time responses to queries about the status of a single certificate Both CRLs & OCSP Responses are generated by the issuing CA or its designate. (Generally this is not the relying party. ) February 21, 2006 Practical Aspects of Modern Cryptography 81
Online Status Checking v OCSP: Online Certificate Status Protocol n n v A way to ask “is this certificate good right now? Get back a signed response from the OCSP server saying, “Yes, cert C is good at time t” n Response is like a “freshness certificate” OCSP response is like a selective CRL n n February 21, 2006 Client indicates thecerts for which he wants status information OCSP responder dynamically creates a lightweight CRL-like response for thosecerts Practical Aspects of Modern Cryptography 82
OCSP in Action OCSP Response CA OCSP Request Cert Request OCSP For Cert Transaction + Cert Relying Party End-entity Transaction Response February 21, 2006 Practical Aspects of Modern Cryptography 83
Final thoughts on Revocation v From a financial standpoint, it’s the revocation data that is valuable, not the issued certificate itself n n v For high-valued financial transactions, seller wants to know your cert is good right now Same situation as with credit cards, where the merchant wants the card authorized right now at the point-of-sale Card authorizations transfer risk from merchant to bank – thus they’re worth $$$ n February 21, 2006 Same with cert status checks Practical Aspects of Modern Cryptography 84
Using Certificates v Most certificate uses do not require any sort of directory n v Authentication protocols have the client present their certificate (or chain) to the server n n v Only needed to locate someone else’s certificate for encryption Ex: SSL, TLS, Smart card logon Rules for mapping a certificate to user account vary widely n Cert fields, name forms, binary compare Signing operations embed the certificates with the signature n February 21, 2006 How else would you know who signed it? Practical Aspects of Modern Cryptography 85
Using Certificates (2) v X. 509 and PKIX define the basic structure of certificates n v However, every protocol defines a certificate profilefor certificate use in that particular protocol n v If you understand X. 509, you can parse any certificate you’re presented Ex: TLS, S/MIME, IPSEC, WPA/WPA 2 CAs/organizations define profiles too n February 21, 2006 Ex: US Do. D Common Access Cardcerts Practical Aspects of Modern Cryptography 86
Additional Implementation Considerations v Publishing certificates n v v v How? Where? What format? Key escrow / data recovery for encryption keys/ certs Auto-enrollment (users & machines) Establishing trusts / hierarchies Protecting private keys Disseminating root certificates February 21, 2006 Practical Aspects of Modern Cryptography 87
Скачать презентацию Certificates Trust PKI Brian A La Macchia
b5d64752dab5f3fea41aab3d40559dd8.ppt