1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/security/nss/lib/pki/doc/standoc.html Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,442 @@
1.4 +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
1.5 +<html>
1.6 +<head>
1.7 +<!-- This Source Code Form is subject to the terms of the Mozilla Public
1.8 + - License, v. 2.0. If a copy of the MPL was not distributed with this
1.9 + - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
1.10 +
1.11 +
1.12 + <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
1.13 + <title>Stan Design - Work In Progress</title>
1.14 +</head>
1.15 + <body>
1.16 + <br>
1.17 + This is a working document for progress on Stan design/development.<br>
1.18 + <br>
1.19 + Current <a href="#build">build</a>
1.20 + and <a href="#test">test</a>
1.21 + instructions.<br>
1.22 + <br>
1.23 + The current set of Stan libraries.<br>
1.24 + <a href="#asn1">asn1</a>
1.25 + <br>
1.26 + <a href="#base">base</a>
1.27 + <br>
1.28 + <a href="#ckfw">ckfw</a>
1.29 + <br>
1.30 + <a href="#dev">dev</a>
1.31 + <br>
1.32 + <a href="#pki">pki</a>
1.33 + <br>
1.34 + <a href="#pki1">pki1</a>
1.35 + <br>
1.36 + <a href="#pkix">pkix</a>
1.37 + <br>
1.38 + <br>
1.39 + "Public" types below (those available to consumers of
1.40 + NSS) begin with "NSS". "Protected" types (those only available
1.41 + within NSS) begin with "nss".<br>
1.42 + <br>
1.43 + Open issues appears as numbered indents.<br>
1.44 + <br>
1.45 + <br>
1.46 +
1.47 +<hr width="100%" size="2" align="Left"><br>
1.48 +
1.49 +<h3><a name="asn1"></a>
1.50 + <a href="http://lxr.mozilla.org/mozilla/source/security/nss/lib/asn1/">
1.51 + ASN.1</a>
1.52 + </h3>
1.53 + ASN.1 encoder/decoder wrapping around the current
1.54 + ASN.1 implementation.<br>
1.55 + <br>
1.56 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSASN1EncodingType"> NSSASN1EncodingType</a>
1.57 + <br>
1.58 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssASN1Item">nssASN1Item</a>
1.59 + <br>
1.60 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssASN1Template">nssASN1Template</a>
1.61 + <br>
1.62 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssASN1ChooseTemplateFunction">
1.63 + nssASN1ChooseTemplateFunction</a>
1.64 + <br>
1.65 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssASN1Encoder">nssASN1Encoder</a>
1.66 + <br>
1.67 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssASN1Decoder">nssASN1Decoder</a>
1.68 + <br>
1.69 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssASN1EncodingPart"> nssASN1EncodingPart</a>
1.70 + <br>
1.71 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssASN1NotifyFunction">
1.72 + nssASN1NotifyFunction</a>
1.73 + <br>
1.74 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssASN1EncoderWriteFunction">
1.75 + nssASN1EncoderWriteFunction</a>
1.76 + <br>
1.77 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssASN1DecoderFilterFunction">
1.78 + nssASN1DecoderFilterFunction</a>
1.79 + <br>
1.80 + <br>
1.81 +
1.82 +<hr width="100%" size="2" align="Left">
1.83 +<h3><a name="base"></a>
1.84 + <a href="http://lxr.mozilla.org/mozilla/source/security/nss/lib/base/">
1.85 + Base</a>
1.86 + </h3>
1.87 + Set of base utilities for Stan implementation.
1.88 + These are all fairly straightforward, except for nssPointerTracker.<br>
1.89 + <br>
1.90 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSError">NSSError</a>
1.91 + <br>
1.92 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSArena">NSSArena</a>
1.93 + <br>
1.94 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSItem">NSSItem</a>
1.95 + <br>
1.96 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSBER">NSSBER</a>
1.97 + <br>
1.98 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSDER">NSSDER</a>
1.99 + <br>
1.100 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSBitString">NSSBitString</a>
1.101 + <br>
1.102 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSUTF8">NSSUTF8</a>
1.103 + <br>
1.104 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSASCII7">NSSASCII7</a>
1.105 + <br>
1.106 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssArenaMark">nssArenaMark</a>
1.107 + <br>
1.108 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssPointerTracker">nssPointerTracker</a>
1.109 + <br>
1.110 + This is intended for debug builds only.<br>
1.111 +
1.112 +<ol>
1.113 + <li>Ignored for now.<br>
1.114 + </li>
1.115 +
1.116 +</ol>
1.117 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssStringType">nssStringType</a>
1.118 + <br>
1.119 + <br>
1.120 + Suggested additions:<br>
1.121 +
1.122 +<ol>
1.123 + <li>nssList - A list that optionally uses a lock. This list would
1.124 + manage the currently loaded modules in a trust domain, etc.</li>
1.125 +
1.126 + <ul>
1.127 + <li>SECMODListLock kept track of the number of waiting threads. Will
1.128 + this be needed in the trust domain?</li>
1.129 +
1.130 + </ul>
1.131 +
1.132 +</ol>
1.133 + <br>
1.134 +
1.135 +<hr width="100%" size="2" align="Left">
1.136 +<h3><a name="ckfw"></a>
1.137 + <a href="http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/">
1.138 + CKFW</a>
1.139 + </h3>
1.140 + The cryptoki framework, used for building cryptoki tokens.
1.141 + This needs to be described in a separate document showing how
1.142 + to set up a token using CKFW. This code only relates to tokens,
1.143 + so it is not relevant here.<br>
1.144 + <br>
1.145 + <br>
1.146 +
1.147 +<hr width="100%" size="2" align="Left">
1.148 +<h3><a name="dev"></a>
1.149 + <a href="http://lxr.mozilla.org/mozilla/source/security/nss/lib/dev/">
1.150 + Device</a>
1.151 + </h3>
1.152 + Defines cryptoki devices used in NSS. This
1.153 + is not part of the exposed API. It is a low-level API allowing
1.154 +NSS to manage cryptoki devices.<br>
1.155 + <br>
1.156 + The relationship is like this:<br>
1.157 + <br>
1.158 + libpki --> libdev --> cryptoki<br>
1.159 + <br>
1.160 + As an example,<br>
1.161 + <br>
1.162 + NSSTrustDomain_FindCertificate --> NSSToken_FindCertificate -->
1.163 + C_FindObjects<br>
1.164 + <br>
1.165 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSModule">NSSModule</a>
1.166 + <br>
1.167 + Replaces the SECMOD API. The module manages a
1.168 +PRLibrary that holds a cryptoki implementation via a number of slots.
1.169 + The API should provide the ability to Load and Unload a module,
1.170 +Login and Logout to the module (through its slots), and to locate a
1.171 +particular slot/token.<br>
1.172 + <br>
1.173 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSSlot">NSSSlot</a>
1.174 + <br>
1.175 + This and NSSToken combine to replace the PK11 API parts
1.176 + that relate to slot and token management. The slot API should
1.177 + provide the ability to Login/Logout to a slot, check the login status,
1.178 + determine basic configuration information about the slot, and modify
1.179 + the password settings.<br>
1.180 +
1.181 +<ol>
1.182 + <li>Should slots also maintain a default session? This session would
1.183 + be used for slot management calls (sections 9.5 and9.6 of PKCS#11). Or
1.184 + is the token session sufficient (this would not work if C_GetTokenInfo and
1.185 + C_InitToken need to be wrapped in a threadsafe session).<br>
1.186 + </li>
1.187 +
1.188 +</ol>
1.189 + <br>
1.190 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSToken">NSSToken</a>
1.191 + <br>
1.192 + Fills in the gaps left by NSSSlot. Much of the
1.193 +cryptoki API is directed towards slots. However, some functionality
1.194 + clearly belongs with a token type. For example, a certificate
1.195 + lives on a token, not a slot, so one would expect a function NSSToken_FindCertificate.
1.196 + Thus functions that deal with importing/exporting an object
1.197 +and performing actual cryptographic operations belong here.<br>
1.198 +
1.199 +<ol>
1.200 + <li>The distinction between a slot and a token is not clear. Most
1.201 + functions take a slotID as an argument, even though it is obvious that
1.202 + the event is intended to occur on a token. That leaves various
1.203 + possibilities:</li>
1.204 +
1.205 + <ol>
1.206 + <li>Implement the API entirely as NSSToken. If the token is not
1.207 + present, some calls will simply fail.</li>
1.208 + <li>Divide the API between NSSToken and NSSSlot, as described above.
1.209 + NSSSlot would handle cryptoki calls specified as "slot management",
1.210 + while NSSToken handles actual token operations.</li>
1.211 + <li>Others?</li>
1.212 +
1.213 + </ol>
1.214 + <li>Session management. Tokens needs a threadsafe session handle
1.215 + to perform operations. CryptoContexts are meant to provide such sessions,
1.216 + but other objects will need access to token functions as well (examples:
1.217 +the TrustDomain_Find functions, _Login, _Logout, and others that do not exist
1.218 + such as NSSToken_ChangePassword). For those functions, the token could
1.219 + maintain a default session. Thus all NSSToken API functions would take
1.220 + sessionOpt as an argument. If the caller is going to provide a session,
1.221 + it sends an NSSSession there, otherwise it sends NULL and the default session
1.222 + is utilized.<br>
1.223 + </li>
1.224 +
1.225 +</ol>
1.226 + Proposed:<br>
1.227 + NSSSession<br>
1.228 + Wraps a Cryptoki session. Created from a slot. Used to manage
1.229 + sessions for crypto contexts. Has a lock field, which locks the session
1.230 + if the slot is not threadsafe.<br>
1.231 + <br>
1.232 +
1.233 +<hr width="100%" size="2" align="Left"><br>
1.234 +
1.235 +<h3><a name="pki"></a>
1.236 + <a href="http://lxr.mozilla.org/mozilla/source/security/nss/lib/pki/">
1.237 + PKI</a>
1.238 + </h3>
1.239 + The NSS PKI library.<br>
1.240 + <br>
1.241 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSCertificate">NSS</a>
1.242 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSCertificate">Certificate</a>
1.243 + <br>
1.244 +
1.245 +<ol>
1.246 + <li>The API leaves open the possibility of NSSCertificate meaning various
1.247 + certificate types, not just X.509. The way to keep open this possibility
1.248 + is to keep only generally useful information in the NSSCertificate type.
1.249 + Examples would be the certificate encoding, label, trust (obtained
1.250 + from cryptoki calls), an email address, etc. Some type of generic
1.251 +reference should be kept to the decoded certificate, which would then be
1.252 +accessed by a type-specific API (e.g., NSSX509_GetSubjectName).</li>
1.253 +
1.254 +</ol>
1.255 + <br>
1.256 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSUserCertificate">NSSUserCertificate</a>
1.257 + <br>
1.258 +
1.259 +<ol>
1.260 + <li>Should this be a typedef of NSSCertificate? This implies that
1.261 + any function that requires an NSSUserCertificate would fail when called
1.262 + with a certificate lacking a private key. </li>
1.263 +
1.264 +</ol>
1.265 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSPrivateKey">NSSPrivateKey</a>
1.266 + <br>
1.267 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSPublicKey">NSSPublicKey</a>
1.268 + <br>
1.269 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSSymmetricKey">NSSSymmetricKey</a>
1.270 + <br>
1.271 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSTrustDomain">NSSTrustDomain</a>
1.272 + <br>
1.273 + A trust domain is "the field in which certificates may
1.274 + be validated." It is a collection of modules capable of performing
1.275 + cryptographic operations and storing certs and keys. This collection
1.276 + is managed by NSS in a manner opaque to the consumer. The slots
1.277 + will have various orderings determining which has preference for a
1.278 +given operation. For example, the trust domain may order the storage
1.279 + of user certificates one way, and the storage of email certificates in
1.280 + another way [is that a good example?].<br>
1.281 + <br>
1.282 +
1.283 +<ol>
1.284 + <li> How will ordering work? We already have the suggestion
1.285 + that there be two kinds of ordering: storage and search. How
1.286 +will they be constructed/managed? Do we want to expose access
1.287 +to a token that overrides this ordering (i.e., the download of updated
1.288 +root certs may need to override storage order)</li>
1.289 + <li>How are certs cached? Nelson wonders what it means to Stan
1.290 + when a cert does not live on a token yet. Bob, Terry, and I discussed
1.291 + this. My conclusion is that there should be a type, separate
1.292 +from NSSCertificate, that holds the decoded cert parts (e.g., NSSX509Certificate,
1.293 + or to avoid confusion, NSSX509DecodedParts). NSSCertificate would
1.294 + keep a handle to this type, so that it only needs to decode the cert
1.295 +once. The NSSTrustDomain would keep a hash table of cached certs,
1.296 +some of which may not live on a token yet (i.e., they are only NSSX509DecodedParts).
1.297 + This cache could be accessed in the same way the temp db was,
1.298 +and when the cert is ready to be moved onto a token a call to NSSTrustDomain_ImportCertificate
1.299 + is made. Note that this is essentially the same as CERT_TempCertToPerm.</li>
1.300 +
1.301 + <ul>
1.302 + <li>The hashtable in lib/base (copied from ckfw/hash.c) uses the identity
1.303 +hash. Therefore, in a hash of certificates, the key is the certificate
1.304 +pointer itself. One possibility is to store the decoded cert (NSSX509DecodedParts
1.305 +above) as the value in the {key, value} pair. When a cert is decoded,
1.306 +the cert pointer and decoding pointer are added to the hash. Subsequent
1.307 +lookups have access to one or both of these pointers. This keeps NSSCertificate
1.308 +separate from its decoding, while providing a way to locate it.</li>
1.309 +
1.310 + </ul>
1.311 + <li>The API is designed to keep token details hidden from the user. However,
1.312 + it has already been realized that PSM and CMS may need special access to
1.313 +tokens. Is this part of the TrustDomain API, or should PSM and CMS
1.314 +be allowed to use "friend" headers from the Token API?</li>
1.315 + <li>Do we want to allow traversal via NSSTrustDomain_TraverseXXXX?<br>
1.316 + </li>
1.317 +
1.318 +</ol>
1.319 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSCryptoContext"><br>
1.320 + NSSCryptoContext</a>
1.321 + <br>
1.322 + Analgous to a Cryptoki session. Manages session objects only.<br>
1.323 + <br>
1.324 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSTime">NSSTime</a>
1.325 + <br>
1.326 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSUsage">NSSUsage</a>
1.327 + <br>
1.328 +
1.329 +<ol>
1.330 + <li> See Fred's <a href="http://lxr.mozilla.org/mozilla/source/security/nss/lib/pki/nsspkit.h#187">
1.331 + comments</a>
1.332 + .</li>
1.333 +
1.334 +</ol>
1.335 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSPolicies">NSSPolicies</a>
1.336 + <br>
1.337 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSAlgorithmAndParameters">
1.338 + NSSAlgorithmAndParameters</a>
1.339 + <br>
1.340 +
1.341 +<ol>
1.342 + <li> Again, Fred's <a href="http://lxr.mozilla.org/mozilla/source/security/nss/lib/pki/nsspkit.h#215">
1.343 + comments</a>
1.344 + . The old NSS code had various types related to algorithms
1.345 + running around in it. We had SECOidTag, SECAlgorithmID, SECItem's
1.346 + for parameters, CK_MECHANISM for cryptoki, etc. This type should
1.347 + be able to encapsulate all of those.</li>
1.348 +
1.349 +</ol>
1.350 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSCallback">NSSCallback</a>
1.351 + <br>
1.352 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSOperations">NSSOperations</a>
1.353 + <br>
1.354 + <br>
1.355 + <br>
1.356 +
1.357 +<hr width="100%" size="2"><br>
1.358 + <br>
1.359 + A diagram to suggest a possible TrustDomain architecture.<br>
1.360 + <br>
1.361 + <img src="./standiag.png" alt="Trust Domain Diagram" width="748" height="367">
1.362 + <br>
1.363 +
1.364 +<hr width="100%" size="2" align="Left"><br>
1.365 +
1.366 +<h3><a name="pki1"></a>
1.367 + <a href="http://lxr.mozilla.org/mozilla/source/security/nss/lib/pki1/">
1.368 + PKI1</a>
1.369 + </h3>
1.370 + <br>
1.371 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSOID">NSSOID</a>
1.372 + <br>
1.373 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSATAV">NSSATAV</a>
1.374 + <br>
1.375 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSRDN">NSSRDN</a>
1.376 + <br>
1.377 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSRDNSeq">NSSRDNSeq</a>
1.378 + <br>
1.379 + <a href="http://lxr.mozilla.org/mozilla/ident?i=NSSName">NSSName</a>
1.380 + <br>
1.381 + NSSNameChoice<br>
1.382 + NSSGeneralName<br>
1.383 + NSSGeneralNameChoice<br>
1.384 + NSSOtherName<br>
1.385 + NSSRFC822Name<br>
1.386 + NSSDNSName<br>
1.387 + NSSX400Address<br>
1.388 + NSSEdiParityAddress<br>
1.389 + NSSURI<br>
1.390 + NSSIPAddress<br>
1.391 + NSSRegisteredID<br>
1.392 + NSSGeneralNameSeq<br>
1.393 + <a href="http://lxr.mozilla.org/mozilla/ident?i=nssAttributeTypeAliasTable">
1.394 + nssAttributeTypeAliasTable</a>
1.395 + <br>
1.396 + <br>
1.397 + <br>
1.398 +
1.399 +<hr width="100%" size="2" align="Left"><br>
1.400 +
1.401 +<h3><a name="pkix"></a>
1.402 + <a href="http://lxr.mozilla.org/mozilla/source/security/nss/lib/pkix/">
1.403 + PKIX </a>
1.404 + </h3>
1.405 + There is a plethora of PKIX related types here.<br>
1.406 + <br>
1.407 +
1.408 +<hr width="100%" size="2" align="Left"><br>
1.409 +
1.410 +<h3><a name="build"></a>
1.411 + Building Stan</h3>
1.412 + <br>
1.413 + From nss/lib, run "make BUILD_STAN=1"<br>
1.414 + <br>
1.415 +
1.416 +<hr width="100%" size="2" align="Left"><br>
1.417 +
1.418 +<h3><a name="test"></a>
1.419 + Testing Stan</h3>
1.420 + A new command line tool, pkiutil, has been created to use only
1.421 + the Stan API. It depends on a new library, cmdlib, meant to replace
1.422 + the old secutil library. The old library had code used by products
1.423 + that needed to be integrated into the main library codebase somehow. The
1.424 + goal of the new cmdlib is to have functionality needed strictly for NSS
1.425 + tools.<br>
1.426 + <br>
1.427 + How to build:<br>
1.428 +
1.429 +<ol>
1.430 + <li>cd nss/cmd/cmdlib; make</li>
1.431 + <li>cd ../pkiutil; make</li>
1.432 +
1.433 +</ol>
1.434 + pkiutil will give detailed help with either "pkiutil -?" or "pkiutil
1.435 + --help".<br>
1.436 + <br>
1.437 + So far, the only available test is to list certs on the builtins token.
1.438 + Copy "libnssckbi.so" (or whatever it is) to cmd/pkiutil. Then
1.439 + run "pkiutil -L" or "pkiutil --list". The list of certificate nicknames
1.440 + should be displayed.<br>
1.441 + <br>
1.442 + <br>
1.443 +
1.444 +</body>
1.445 +</html>
