Figure 15. Guillard-Quisquater (GQ) Identity Scheme Figure 16. Mu-Varadharajan (MV) Identity Scheme Figure 10. NTP Header Format Figure 14. Schnorr (IFF) Identity Scheme Figure 11. NTP Extension Field Format Figure 12. Private Certificate (PC) Identity Scheme Figure 13. Trusted Certificate (TC) Identity Scheme Appendix A. Packet Formats The NTP packet consists of a number of fields made up of 32-bit (4 octet) words in network byte order. The NTPv4 packet consists of three components, the header, one or more optional extension fields and an optional message authentication code (MAC). A.1 Header Field Formats The NTP header format is shown in Figure 10, where the size of some fields is shown in bits if not the default 32 bits. The header extends from the beginning of the packet to the end of the Transmit Timestamp field. The format and interpretation of the header fields are backwards compatible with the NTPv3 header fields as described in [11]. A non-authenticated NTP packet includes only the header, while an authenticated one contains in addition a MAC consisting of the Key ID and Message Digest fields. The format and interpretation of the NTPv3 MAC is described in [11] when using the Digital Encryption Standard (DES) algorithm operating in Cipher-Block Chaining (CBC) node. This algorithm and mode of operation is no longer supported in NTPv4. The preferred replacement in both NTPv3 and NTPv4 is the Message Digest 5 (MD5) algorithm, which is included in both reference implementations. For MD5 the Message Digest field is 4 words (16 octets) and the Key ID field is 1 word (4 octets). A.2 Extension Field Formats In NTPv4 one or more extension fields can be inserted after the header and before the MAC, which is always present when an extension field is present. The extension fields can occur in any order; however, in some cases there is a preferred order which improves the protocol efficiency. While previous versions of the Autokey protocol used several different extension field formats, in version 2 of the protocol only a single extension field format is used. An extension field contains a request or response message in the format shown in Figure 11. All extension fields except the last is zero-padded to a word (4 octets) boundary, while the last is zero-padded to a doubleword (8 octets) boundary. The Length field covers the entire extension field, including the Length and Padding fields. While the minimum field length is 4 words (16 octets), a maximum field length remains to be established. The reference implementation discards any packet with a field length more than 1024 octets. The presence of the MAC and extension fields in the packet is determined from the length of the remaining area after the header to the end of the packet. The parser initializes a pointer just after the header. If the length is not a multiple of 4, a format error has occurred and the packet is discarded. The following cases are possible based on the remaining length in words. 0 The packet is not authenticated. 1 The packet is an error report or crypto-NAK resulting from a previous packet that failed the message digest check. The 4 octets are presently unused and should be set to 0. 2, 3, 4 The packet is discarded with a format error. 5 The remainder of the packet is the MAC. >5 One or more extension fields are present. If an extension field is present, the parser examines the Length field. If the length is less than 4 or not a multiple of 4, a format error has occurred and the packet is discarded; otherwise, the parser increments the pointer by this value. The parser now uses the same rules as above to determine whether a MAC is present and/or another extension field. An additional implementation- dependent test is necessary to ensure the pointer does not stray outside the buffer space occupied by the packet. In the Autokey Version 2 format, the 8-bit Code field specifies the request or response operation, while the 4-bit Version Number (VN) field is 2 for the current protocol version. There are four flag bits: bit 0 is the Response Flag (R) and bit 1 is the Error Flag (E); the other two bits are presently unused and should be set to 0. The remaining fields will be described later. In the most common protocol operations, a client sends a request to a server with an operation code specified in the Code field and both the R bit and E bit dim. The Association ID field is set to the value previously received from the server or 0 otherwise. The server returns a response with the same operation code in the Code field and lights the R bit. The server can also light the E bit in case of error. The Association ID field is set to the association ID of the server as a handle for subsequent exchanges. If for some reason the association ID value in a request does not match the association ID of any mobilized association, the server returns the request with both the R and E bits lit. Note that it is not necessarily a protocol error to send an unsolicited response with no matching request. In some cases not all fields may be present. For requests, until a client has synchronized to a proventic source, signatures are not valid. In such cases the Timestamp and Signature Length fields are 0 and the Signature field is empty. Responses are generated only when the responder has synchronized to a proventic source; otherwise, an error response message is sent. Some request and error response messages carry no value or signature fields, so in these messages only the first two words are present. The Timestamp and Filestamp words carry the seconds field of an NTP timestamp. The Timestamp field establishes the signature epoch of the data field in the message, while the filestamp establishes the generation epoch of the file that ultimately produced the data that is signed. A signature and timestamp are valid only when the signing host is synchronized to a proventic source; otherwise, the timestamp is zero. A cryptographic data file can only be generated if a signature is possible; otherwise, the filestamp is zero, except in the ASSOC response message, where it contains the server status word. Appendix B. Cryptographic Key and Certificate Management This appendix describes how cryptographic keys and certificates are generated and managed in the NTPv4 reference implementation. These means are not intended to become part of any standard that may be evolved from this report, but to serve as an example of how these functions can be implemented and managed in a typical operational environment. The ntp-keygen utility program in the NTP software library generates public/private key files, certificate files, identity parameter files and public/private identity key files. By default the modulus of all encryption and identity keys is 512 bits. All random cryptographic data are based on a pseudo-random number generator seeded in such a way that random values are exceedingly unlikely to repeat. The files are PEM encoded in printable ASCII format suitable for mailing as MIME objects. Every file has a filestamp, which is a string of decimal digits representing the NTP seconds when the file was created. The file name is formed from the concatenation of the host name, filestamp and constant strings, so files can be copied from one environment to another while preserving the original filestamp. The file header includes the file name and date and generation time in printable ASCII. The utility assumes the host is synchronized to a proventic source at the time of generation, so that filestamps are proventic data. This raises an interesting circularity issue that will not be further explored here. The generated files are typically stored in NFS mounted file systems, with files containing private keys obscured to all but root. Symbolic links are installed from default file names assumed by the NTP daemon to the selected files. Since the files of successive generations and different hosts have unique names, there is no possibility of name collisions. Public/private keys must be generated by the host to which they belong. OpenSSL public/private RSA and DSA keys are generated as an OpenSSL structure, which is then PEM encoded in ASN.1 syntax and written to the host key file. The host key must be RSA, since it is used to encrypt the cookie, as well as encrypt signatures by default. In principle, these files could be generated directly by OpenSSL utility programs, as long as the symbolic links are consistent. The optional sign key can be RSA or DSA, since it is used only to encrypt signatures. Identity parameters must be generated by the ntp-keygen utility, since they have proprietary formats. Since these are private to the group, they are generated by one machine acting as a trusted authority and then distributed to all other members of the group by secure means. Public/ private identity keys are generated by the host to which they belong along with certificates with the public identity key. Certificates are usually, but not necessarily, generated by the host to which they belong. The ntp- keygen utility generates self-signed X.509v3 host certificate files with optional extension fields. Certificate requests are not used, since the certificate itself is used as a request to be signed. OpenSSL X.509v3 certificates are generated as an OpenSSL structure, which is then PEM encoded in ASN.1 syntax and written to the host certificate file. The string returned by the Unix gethostname() routine is used for both the subject and issuer fields. The serial number and begin time fields are derived from the filestamp; the end time is one year hence. The host certificate is signed by the sign key or host key if a sign key is not present. An important design goal is to make cryptographic data refreshment as simple and intuitive as possible, so it can be driven by scripts on a periodic basis. When the ntp-keygen utility is run for the first time, it creates by default a RSA host key file and RSA-MD5 host certificate file and necessary symbolic links. After that, it creates a new certificate file and symbolic link using the existing host key. The program run with given options creates identity parameter files for one or more IFF, GQ or MV identity schemes. The parameter files must then be securely copied to all other group members and symbolic links installed from the default names to the installed files. In the GQ scheme the next and each subsequent time the ntp-keygen utility runs, it automatically creates or updates the private/public identity key file and certificate file using the existing identity parameters. Appendix C. Autokey Error Checking Exhaustive examination of possible vulnerabilities at the various processing steps of the NTPv3 protocol as specified in [11] have resulted in a revised list of packet sanity tests. There are 12 tests in the NTPv4 reference implementation, called TEST1 through TEST12, which are performed in a specific order designed to gain maximum diagnostic information while protecting against an accidental or malicious clogging attacks. These tests are described in detail in the NTP software documentation. Those relevant to the Autokey protocol are described in this appendix. The sanity tests are classified in four tiers. The first tier deflects access control and message digest violations. The second, represented by the autokey sequence, deflects spoofed or replayed packets. The third, represented by timestamped digital signatures, binds cryptographic values to verifiable credentials. The fourth deflects packets with invalid NTP header fields or out of bounds time values. However, the tests in this last group do not directly affect cryptographic protocol vulnerability, so are beyond the scope of discussion here. C.1 Packet Processing Rules Every arriving NTP packet is checked enthusiastically for format, content and protocol errors. Some packet header fields are checked by the main NTP code path both before and after the Autokey protocol engine cranks. These include the NTP version number, overall packet length and extension field lengths. Extension fields may be no longer than 1024 octets in the reference implementation. Packets failing any of these checks are discarded immediately. Packets denied by the access control mechanism will be discarded later, but processing continues temporarily in order to gather further information useful for error recovery and reporting. Next, the cookie and session key are determined and the MAC computed as described above. If the MAC fails to match the value included in the packet, the action depends on the mode and the type of packet. Packets failing the MAC check will be discarded later, but processing continues temporarily in order to gather further information useful for error recovery and reporting. The NTP transmit and receive timestamps are in effect nonces, since an intruder cannot effectively guess either value in advance. To minimize the possibility that an intruder can guess the nonces, the low order unused bits in all timestamps are obscured with random values. If the transmit timestamp matches the transmit timestamp in the last packet received, the packet is a duplicate, so the DUP bit is lit. If the packet mode is not broadcast and the last transmit timestamp does not match the originate timestamp in the packet, either it was delivered out of order or an intruder has injected a rogue packet, so the LBK bit is lit. Packets with either the DUP or LBK bit will be discarded later, but processing continues temporarily in order to gather further information useful for error recovery and reporting. Further indicators of the server and client state are apparent from the transmit and receive timestamps of both the packet and the association. The quite intricate rules take into account these and the above error indicators They are designed to discriminate between legitimate cases where the server or client are in inconsistent states and recoverable, and when an intruder is trying to destabilize the protocol or force consumption of needless resources. The exact behavior is beyond the scope of discussion, but is clearly described in the source code documentation. Next, the Autokey protocol engine is cranked and the dances evolve as described above. Some requests and all responses have value fields which carry timestamps and filestamps. When the server or client is synchronized to a proventic source, most requests and responses with value fields carry signatures with valid timestamps. When not synchronized to a proventic source, value fields carry an invalid (zero) timestamp and the signature field and signature length word are omitted. The extension field parser checks that the Autokey version number, operation code and field length are valid. If the error bit is lit in a request, the request is discarded without response; if an error is discovered in processing the request, or if the responder is not synchronized to a proventic source, the response contains only the first two words of the request with the response and error bits lit. For messages with signatures, the parser requires that timestamps and filestamps are valid and not a replay, that the signature length matches the certificate public key length and only then verifies the signature. Errors are reported via the security logging facility. All certificates must have correct ASN.1 encoding, supported digest/signature scheme and valid subject, issuer, public key and, for self-signed certificates, valid signature. While the begin and end times can be checked relative to the filestamp and each other, whether the certificate is valid relative to the actual time cannot be determined until the client is synchronized to a proventic source and the certificate is signed and verified by the server. When the protocol starts the only response accepted is ASSOC with valid timestamp, after which the server status word must be nonzero. ASSOC responses are discarded if this word is nonzero. The only responses accepted after that and until the PRV bit is lit are CERT, IFF and GQ. Once identity is confirmed and IFF is lit, these responses are no longer accepted, but all other responses are accepted only if in response to a previously sent request and only in the order prescribed in the protocol dances. Additional checks are implemented for each request type and dance step. C.2 Timestamps, Filestamps and Partial Ordering When the host starts, it reads the host key and certificate files, which are required for continued operation. It also reads the sign key and leapseconds file, when available. When reading these files the host checks the file formats and filestamps for validity; for instance, all filestamps must be later than the time the UTC timescale was established in 1972 and the certificate filestamp must not be earlier than its associated sign key filestamp. In general, at the time the files are read, the host is not synchronized, so it cannot determine whether the filestamps are bogus other than these simple checks. In the following the relation is Lamport’s “happens before” relation, which is true if event A happens before event B. When timestamps are compared to timestamps, the relation is false if ; that is, false if the events are simultaneous. For timestamps compared to filestamps and filestamps compared to filestamps, the relation is true if . Note that the current time plays no part in these assertions except in (6) below; however, the NTP protocol itself insures a correct partial ordering for all current time values. The following assertions apply to all relevant responses: 1. The client saves the most recent timestamp T0 and filestamp F0 for the respective signature type. For every received message carrying timestamp T1 and filestamp F1, the message is discarded unless and . The requirement that is the primary defense against replays of old messages. 2. For timestamp T and filestamp F, ; that is, the filestamp must happen before the timestamp. If not, this could be due to a file generation error or a significant error in the system clock time. 3. For sign key filestamp S, certificate filestamp C, cookie timestamp D and autokey timestamp A, ; that is, the autokey must be generated after the cookie, the cookie after the certificate and the certificate after the sign key. 4. For sign key filestamp S and certificate filestamp C specifying begin time B and end time E, ; that is, the valid period must not be retroactive. 5. A certificate for subject S signed by issuer I and with filestamp C1 obsoletes, but does not necessarily invalidate, another certificate with the same subject and issuer but with filestamp C0, where . 6. A certificate with begin time B and end time E is invalid and can not be used to verify signatures if or , where t is the current proventic time. Note that the public key previously extracted from the certificate continues to be valid for an indefinite time. This raises the interesting possibility where a truechimer server with expired certificate or a falseticker with valid certificate are not detected until the client has synchronized to a clique of proventic truechimers. Appendix D. Security Analysis This section discusses the most obvious security vulnerabilities in the various Autokey dances. First, some observations on the particular engineering parameters of the Autokey protocol are in order. The number of bits in some cryptographic values are considerably smaller than would ordinarily be expected for strong cryptography. One of the reasons for this is the need for compatibility with previous NTP versions; another is the need for small and constant latencies and minimal processing requirements. Therefore, what the scheme gives up on the strength of these values must be regained by agility in the rate of change of the cryptographic basis values. Thus, autokeys are used only once and seed values are regenerated frequently. However, in most cases even a successful cryptanalysis of these values compromises only a particular association and does not represent a danger to the general population. Throughout the following discussion the cryptographic algorithms and private values themselves are assumed secure; that is, a brute force cryptanalytic attack will not reveal the host private key, sign private key, cookie value, identity parameters, server seed or autokey seed. In addition, an intruder will not be able to predict random generator values or predict the next autokey. On the other hand, the intruder can remember the totality of all past values for all packets ever sent. D.1 Protocol Vulnerability While the protocol has not been subjected to a formal analysis, a few preliminary assertions can be made. The protocol cannot loop forever in any state, since the watchdog counter and general reset insure that the association variables will eventually be purged and the protocol restarted from the beginning. However, if something is seriously wrong, the timeout/restart cycle could continue indefinitely until whatever is wrong is fixed. This is not a clogging hazard, as the timeout period is very long compared to expected network delays. The LBK and DUP bits described in the main body and Appendix C are effective whether or not cryptographic means are in use. The DUP bit deflects duplicate packets in any mode, while the LBK bit deflects bogus packets in all except broadcast mode. All packets must have the correct MAC, as verified with correct key ID and cookie. In all modes the next key ID cannot be predicted by a wiretapper, so are of no use for cryptanalysis. As long as the client has validated the server certificate trail, a wiretapper cannot produce a convincing signature and cannot produce cryptographic values acceptable to the client. As long as the identity values are not compromised, a middleman cannot masquerade as a legitimate group member and produce convincing certificates or signatures. In server and symmetric modes after the preliminary exchanges have concluded, extension fields are no longer used, a client validates the packet using the autokey sequence. A wiretapper cannot predict the next Key IDs, so cannot produce a valid MAC. A middleman cannot successfully modify and replay a message, since he does not know the cookie and without the cookie cannot produce a valid MAC. In broadcast mode a wiretapper cannot produce a key list with signed autokey values that a client will accept. The most it can do is replay an old packet causing clients to repeat the autokey hash operations until exceeding the maximum key number. However, a middleman could intercept an otherwise valid broadcast packet and produce a bogus packet with acceptable MAC, since in this case it knows the key ID before the clients do. Of course, the middleman key list would eventually be used up and clients would discover the ruse when verifying the signature of the autokey values. There does not seem to be a suitable defense against this attack. During the exchanges where extension fields are in use, the cookie is a public value rather than a shared secret and an intruder can easily construct a packet with a valid MAC, but not a valid signature. In the certificate and identity exchanges an intruder can generate fake request messages which may evade server detection; however, the LBK and DUP bits minimize the client exposure to the resulting rogue responses. A wiretapper might be able to intercept a request, manufacture a fake response and loft it swiftly to the client before the real server response. A middleman could do this without even being swift. However, once the identity exchange has completed and the PRV bit lit, these attacks are readily deflected. A client instantiates cryptographic variables only if the server is synchronized to a proventic source. A server does not sign values or generate cryptographic data files unless synchronized to a proventic source. This raises an interesting issue: how does a client generate proventic cryptographic files before it has ever been synchronized to a proventic source? [Who shaves the barber if the barber shaves everybody in town who does not shave himself?] In principle, this paradox is resolved by assuming the primary (stratum 1) servers are proventicated by external phenomenological means. D.2 Clogging Vulnerability There are two clogging vulnerabilities exposed in the protocol design: an encryption attack where the intruder hopes to clog the victim server with needless cookie or signature encryptions or identity calculations, and a decryption attack where the intruder attempts to clog the victim client with needless cookie or verification decryptions. Autokey uses public key cryptography and the algorithms that perform these functions consume significant processor resources. In order to reduce exposure to decryption attacks the LBK and DUP bits deflect bogus and replayed packets before invoking any cryptographic operations. In order to reduce exposure to encryption attacks, signatures are computed only when the data have changed. For instance, the autokey values are signed only when the key list is regenerated, which happens about once an hour, while the public values are signed only when one of them changes or the server seed is refreshed, which happens about once per day. In some Autokey dances the protocol precludes server state variables on behalf of an individual client, so a request message must be processed and the response message sent without delay. The identity, cookie and sign exchanges are particularly vulnerable to a clogging attack, since these exchanges can involve expensive cryptographic algorithms as well as digital signatures. A determined intruder could replay identity, cookie or sign requests at high rate, which may very well be a useful munition for an encryption attack. Ordinarily, these requests are seldom used, except when the protocol is restarted or the server seed or public values are refreshed. Once synchronized to a proventic source, a legitimate extension field with timestamp the same as or earlier than the most recent received of that type is immediately discarded. This foils a middleman cut-and-paste attack using an earlier AUTO response, for example. A legitimate extension field with timestamp in the future is unlikely, as that would require predicting the autokey sequence. In either case the extension field is discarded before expensive signature computations. This defense is most useful in symmetric mode, but a useful redundancy in other modes. The client is vulnerable to a certificate clogging attack until declared proventic, after which CERT responses are discarded. Before that, a determined intruder could flood the client with bogus certificate responses and force spurious signature verifications, which of course would fail. The intruder could flood the server with bogus certificate requests and cause similar mischief. Once declared proventic, further certificate responses are discard, so these attacks would fail. The intruder could flood the server with replayed sign requests and cause the server to verify the request and sign the response, although the client would drop the response due invalid timestamp. An interesting adventure is when an intruder replays a recent packet with an intentional bit error. A stateless server will return a crypto-NAK message which the client will notice and discard, since the LBK bit is lit. However, a legitimate crypto-NAK is sent if the server has just refreshed the server seed. In this case the LBK bit is dim and the client performs a general reset and restarts the protocol as expected. Another adventure is to replay broadcast mode packets at high rate. These will be rejected by the clients by the timestamp check and before consuming signature cycles. In broadcast and symmetric modes the client must include the association ID in the AUTO request. Since association ID values for different invocations of the NTP daemon are randomized over the 16-bit space, it is unlikely that a bogus request would match a valid association with different IP addresses, for example, and cause confusion. Appendix E. Identity Schemes The Internet infrastructure model described in [1] is based on certificate trails where a subject proves identity to a certificate authority (CA) who then signs the subject certificate using the CA issuer key. The CA in turn proves identity to the next CA and obtains its own signed certificate. The trail continues to a CA with a self-signed trusted root certificate independently validated by other means. If it is possible to prove identity at each step, each certificate along the trail can be considered trusted relative to the identity scheme and trusted root certificate. The important issue with respect to NTP is the cryptographic strength of the identity scheme, since if a middleman could compromise it, the trail would have a security breach. In electric mail and commerce the identity scheme can be based on handwritten signatures, photographs, fingerprints and other things very hard to counterfeit. As applied to NTP subnets and identity proofs, the scheme must allow a client to securely verify that a server knows the same secret that it does, presuming the secret was previously instantiated by secure means, but without revealing the secret to members outside the group. While the identity scheme described in RFC-2875 [14] is based on a ubiquitous Diffie-Hellman infrastructure, it is expensive to generate and use when compared to others described in this appendix. There are five schemes now implemented in the NTPv4 reference implementation to prove identity: (1) private certificate (PC), (2) trusted certificate (TC), (3) a modified Schnorr algorithm (IFF aka Identify Friendly or Foe), (4) a modified Guillou-Quisquater algorithm (GQ), and (5) a modified Mu-Varadharajan algorithm (MV). The available schemes are selected during the key generation phase, with the particular scheme selected during the parameter exchange. The IFF, GQ and MV schemes involve a cryptographically strong challenge-response exchange where an intruder cannot learn the group key, even after repeated observations of multiple exchanges. These schemes begin when the client sends a nonce to the server, which then rolls its own nonce, performs a mathematical operation and sends the results along with a message digest to the client. The client performs a second mathematical operation to produce a digest that must match the one included in the message. To the extent that a server can prove identity to a client without either knowing the group key, these schemes are properly described as zero-knowledge proofs. E.1 Certificates Certificate extension fields are used to convey information used by the identity schemes, such as whether the certificate is private, trusted or contains a public identity key. While the semantics of these fields generally conforms with conventional usage, there are subtle variations. The fields used by Autokey Version 2 include: 1. Basic Constraints. This field defines the basic functions of the certificate. It contains the string “critical,CA:TRUE”, which means the field must be interpreted and the associated private key can be used to sign other certificates. While included for compatibility, Autokey makes no use of this field. 2. Key Usage. This field defines the intended use of the public key contained in the certificate. It contains the string “digitalSignature,keyCertSign”, which means the contained public key can be used to verify signatures on data and other certificates. While included for compatibility, Autokey makes no use of this field. 3. Extended Key Usage. This field further refines the intended use of the public key contained in the certificate and is present only in self-signed certificates. It contains the string “Private” if the certificate is designated private or the string “trustRoot” if it is designated trusted. A private certificate is always trusted. 4. Subject Key Identifier. This field contains the public identity key used in the GQ identity scheme. It is present only if the GQ scheme is configured. E.2 Private Certificate (PC) Scheme The PC scheme shown in Figure 12 involves the use of a private certificate as group key. A certificate is designated private by a X509 Version 3 extension field when generated by utility routines in the NTP software distribution. The certificate is distributed to all other group members by secure means and is never revealed outside the group. A client is marked trusted in the Parameter Exchange and authentic when the first signature is verified. This scheme is cryptographically strong as long as the private certificate is protected; however, it can be very awkward to refresh the keys or certificate, since new values must be securely distributed to a possibly large population and activated simultaneously. The PC scheme uses a private certificate as group key. A certificate is designated private for the purpose of the this scheme if the CIS Private bit is lit. The certificate is distributed to all other group members by secret means and never revealed outside the group. There is no identity exchange, since the certificate itself is the group key. Therefore, when the parameter exchange completes the VAL, IFF and SGN bits are lit in the server status word. When the following cookie exchange is complete, the PRV bit is lit and operation continues as described in the main body of this report. E.3 Trusted Certificate (TC) Scheme All other schemes involve a conventional certificate trail as shown in Figure 13. As described in RFC-2510, each certificate is signed by an issuer one step closer to the trusted host, which has a self-signed trusted certificate, A certificate is designated trusted by a X509 Version 3 extension field when generated by utility routines in the NTP software distribution. A host obtains the certificates of all other hosts along the trail leading to a trusted host by the Autokey protocol, then requests the immediately ascendant host to sign its certificate. Subsequently, these certificates are provided to descendent hosts by the Autokey protocol. In this scheme keys and certificates can be refreshed at any time, but a masquerade vulnerability remains unless a request to sign a client certificate is validated by some means such as reverse-DNS. If no specific identity scheme is specified in the Identification Exchange, this is the default TC scheme. The TC identification exchange follows the parameter exchange in which the VAL bit is lit. It involves a conventional certificate trail and a sequence of certificates, each signed by an issuer one stratum level lower than the client, and terminating at a trusted certificate, as described in [1]. A certificate is designated trusted for the purpose of the TC scheme if the CIS Trust bit is lit and the certificate is self-signed. Such would normally be the case when the trail ends at a primary (stratum 1) server, but the trail can end at a secondary server if the security model permits this. When a certificate is obtained from a server, or when a certificate is signed by a server, A CIS for the new certificate is pushed on the certificate list, but only if the certificate filestamp is greater than any with the same subject name and issuer name already on the list. The list is then scanned looking for signature opportunities. If a CIS issuer name matches the subject name of another CIS and the issuer certificate is verified using the public key of the subject certificate, the CIS Sign bit is lit in the issuer CIS. Furthermore, if the Trust bit is lit in the subject CIS, the Trust bit is lit in the issuer CIS. The client continues to follow the certificate trail to a self-signed certificate, lighting the Sign and Trust bits as it proceeds. If it finds a self-signed certificate with Trust bit lit, the client lights the IFF and PRV bits and the exchange completes. It can, however, happen that the client finds a self-signed certificate with Trust bit dark. This can happen when a server is just coming up, has synchronized to a proventic source, but has not yet completed the Sign exchange. This is considered a temporary condition, so the client simply retries at poll opportunities until the server certificate is signed. E.4 Schnorr (IFF) Scheme The Schnorr (IFF) identity scheme is useful when certificates are generated by means other than the NTP software library, such as a trusted public authority. In this case a X.509v3 extension field might not be available to convey the identity public key. The scheme involves a set of parameters which persist for the life of the scheme. New generations of these parameters must be securely transmitted to all members of the group before use. The scheme is self contained and independent of new generations of host keys, sign keys and certificates. Certificates can be generated by the OpenSSL library or an external public certificate authority, but conveying an arbitrary public value in a certificate extension field might not be possible. The TA generates IFF parameters and keys and distributes them by secure means to all servers, then removes the group key and redistributes these data to dependent clients. Without the group key a client cannot masquerade as a legitimate server. The IFF parameters are generated by OpenSSL routines normally used to generate DSA keys. By happy coincidence, the mathematical principles on which IFF is based are similar to DSA, but only the moduli p, q and generator g are used in identity calculations. The parameters hide in a DSA cuckoo structure and use the same members. The values are used by an identity scheme based on DSA cryptography and described in [15] and [16] p. 285. The p is a 512-bit prime, g a generator of the multiplicative group Zp* and q a 160-bit prime that divides and is a qth root of 1 mod p; that is, mod p. The TA rolls a private random group key b (0 < b < q), then computes public client key mod p. The TA distributes (p, q, g, b) to all servers using secure means and (p, q, g, v) to all clients not necessarily using secure means. The IFF identity scheme is shown in Figure 14. The TA generates a DSA parameter structure for use as IFF parameters. The IFF parameters are identical to the DSA parameters, so the OpenSSL library DSA parameter generation routine can be used directly. The DSA parameter structure shown in Table 1s written to a file as a DSA private key encoded in PEM. Unused structure members are set to one. IFF DSA Item Include p p modulus all q q modulus all g g generator all b priv_key group key server v pub_key client keys client Table 1. IFF Identity Scheme Parameters Alice challenges Bob to confirm identity using the following protocol exchange. 1. Alice rolls random r (0 < r < q) and sends to Bob. 2. Bob rolls random k (0 < k < q), computes mod q and mod p, then sends (y, hash(x)) to Alice. 3. Alice computes mod p and verifies hash(z) equals hash(x). If the hashes match, Alice knows that Bob has the group key b. Besides making the response shorter, the hash makes it effectively impossible for an intruder to solve for b by observing a number of these messages. The signed response binds this knowledge to Bob’s private key and the public key previously received in his certificate. On success the IFF and PRV bits are lit in the server status word. E.5 Guillard-Quisquater (GQ) Scheme The Guillou-Quisquater (GQ) identity scheme is useful when certificates are generated using the NTP software library. These routines convey the GQ public key in a X.509v3 extension field. The scheme involves a set of parameters which persist for the life of the scheme and a private/ public identity key, which is refreshed each time a new certificate is generated. The utility inserts the client key in an X.509 extension field when the certificate is generated. The client key is used when computing the response to a challenge. The TA generates the GQ parameters and keys and distributes them by secure means to all group members. The scheme is self contained and independent of new generations of host keys and sign keys and certificates. The GQ parameters are generated by OpenSSL routines normally used to generate RSA keys. By happy coincidence, the mathematical principles on which GQ is based are similar to RSA, but only the modulus n is used in identity calculations. The parameters hide in a RSA cuckoo structure and use the same members. The values are used in an identity scheme based on RSA cryptography and described in [3] and [16] p. 300 (with errors). The 512-bit public modulus , where p and q are secret large primes. The TA rolls random group key b (0 < b < n) and distributes (n, b) to all group members using secure means. The private server key and public client key are constructed later. The GQ identity scheme is shown in Figure 15. When generating new certificates, the server rolls new random private server key u (0 < u < n) and public client key its inverse obscured by the group key mod n. These values replace the private and public keys normally generated by the RSA scheme. In addition, the public client key is conveyed in a X.509 certificate extension. The updated GQ structure shown in Table 2 is written as an RSA private key encoded in PEM. Unused structure members are set to one. GQ RSA Item Include n n modulus all b e group key server u p server key server v q client key client Table 2. GQ Identity Scheme Parameters Alice challenges Bob to confirm identity using the following exchange. 1. Alice rolls random r (0 < r < n) and sends to Bob. 2. Bob rolls random k (0 < k < n) and computes mod n and mod n, then sends (y, hash(x)) to Alice. 3. Alice computes mod n and verifies hash(z) equals hash(x). If the hashes match, Alice knows that Bob has the group key b. Besides making the response shorter, the hash makes it effectively impossible for an intruder to solve for b by observing a number of these messages. The signed response binds this knowledge to Bob’s private key and the public key previously received in his certificate. Further evidence is the certificate containing the public identity key, since this is also signed with Bob’s private key. On success the IFF and PRV bits are lit in the server status word. E.6 Mu-Varadharajan (MV) Identity Scheme The Mu-Varadharajan (MV) scheme was originally intended to encrypt broadcast transmissions to receivers which do not transmit. There is one encryption key for the broadcaster and a separate decryption key for each receiver. It operates something like a pay-per-view satellite broadcasting system where the session key is encrypted by the broadcaster and the decryption keys are held in a tamper proof set-top box. We don’t use it this way, but read on. The MV scheme is perhaps the most interesting and flexible of the three challenge/response schemes. It can be used when a small number of servers provide synchronization to a large client population where there might be considerable risk of compromise between and among the servers and clients. The TA generates an intricate cryptosystem involving public and private encryption keys, together with a number of activation keys and associated private client decryption keys. The activation keys are used by the TA to activate and revoke individual client decryption keys without changing the decryption keys themselves. The TA provides the server with a private encryption key and public decryption key. The server adjusts the keys by a nonce for each plaintext encryption, so they appear different on each use. The encrypted ciphertext and adjusted public decryption key are provided in the client message. The client computes the decryption key from its private decryption key and the public decryption key in the message. In the MV scheme the activation keys are known only to the TA. The TA decides which keys to activate and provides to the servers a private encryption key E and public decryption keys and which depend on the activated keys. The servers have no additional information and, in particular, cannot masquerade as a TA. In addition, the TA provides to each client j individual private decryption keys and , which do not need to be changed if the TA activates or deactivates this key. The clients have no further information and, in particular, cannot masquerade as a server or TA. The MV values hide in a DSA cuckoo structure which uses the same parameters, but generated in a different way. The values are used in an encryption scheme similar to El Gamal cryptography and a polynomial formed from the expansion of product terms , as described in [12]. The paper has significant errors and serious omissions. The MV identity scheme is shown in Figure 16. The TA writes the server parameters, private encryption key and public decryption keys for all servers as a DSA private key encoded in PEM, as shown in the Table 3. MV DSA Item Include p p modulus all q q modulus server E g private encrypt server priv_key public decrypt server pub_key public decrypt server Table 3. MV Identity Scheme Server Parameters The TA writes the client parameters and private decryption keys for each client as a DSA private key encoded in PEM. It is used only by the designated recipient(s) who pay a suitably outrageous fee for its use. Unused structure members are set to one, as shown in Table 4. MV DSA Item Include p p modulus all priv_key private decrypt client pub_key private decrypt client Table 4. MV Identity Scheme Client Parameters The devil is in the details. Let q be the product of n distinct primes (j = 1...n), where each , also called an activation key, has m significant bits. Let prime , so that q and each divide mod p. Let be the multiplicative group Zp*; that is, gcd(g, ) = 1 and mod p. We do modular arithmetic over Zq and then project into Zp* as powers of g. Sometimes we have to compute an inverse of random b in Zq, but for that purpose we require gcd(b, q) = 1. We expect M to be in the 500-bit range and n relatively small, like 30. The TA uses a nasty probabilistic algorithm to generate the cryptosystem. 1. Generate the m-bit primes , which may have to be replaced later. As a practical matter, it is tough to find more than 30 distinct primes for or 60 primes for . The latter can take several hundred iterations and several minutes on a Sun Blade 1000. 2. Compute modulus , then modulus . If p is composite, the TA replaces one of the primes with a new distinct prime and tries again. Note that q will hardly be a secret since p is revealed to servers and clients. However, factoring q to find the primes should be adequately hard, as this is the same problem considered hard in RSA. Question: is it as hard to find n small prime factors totalling M bits as it is to find two large prime factors totalling M bits? Remember, the bad guy doesn’t know n. 3. Associate with each an element sj such that mod q. One way to find an sj is the quotient . The student should prove the remainder is always zero. 4. Compute the generator g of Zp using a random roll such that gcd and mod p. If not, roll again. Once the cryptosystem parameters have been determined, the TA sets up a specific instance of the scheme as follows. 1. Roll n random roots xj for a polynomial of order n. While it may not be strictly necessary, Make sure each root has no factors in common with q. 2. Expand the n product terms to form n + 1 coefficients ai mod q in powers of x using a fast method contributed by C. Boncelet. 3. Generate mod p for all i and the generator g. Verify mod p for all i, j. Note the exponent is computed mod q, but the gi is computed mod p. Also note the expression given in the paper cited is incorrect. 4. Make master encryption key mod p. Keep it around for awhile, since it is expensive to compute. 5. Roll private random group key b (0 < b < q), where gcd(b, q) = 1 to guarantee the inverse exists, then compute mod q. If b is changed, all keys must be recomputed. 6. Make private client keys mod q and mod q for all j. Note that the keys for the jth client involve only sj, but not or s. The TA sends (p, , ) to the jth client(s) using secure means. 7. The activation key is initially q by construction. The TA revokes client j by dividing q by . The quotient becomes the activation key s. Note we always have to revoke one key; otherwise, the plaintext and cryptotext would be identical. The TA computes E = As, mod p, mod p and sends (p, E, , ) to the servers using secure means. Alice challenges Bob to confirm identity using the following exchange. 1. Alice rolls random r (0 < r < q) and sends to Bob. 2. Bob rolls random k (0 < k < q) and computes the session encryption key mod p and public decryption key mod p and mod p. He encrypts mod p and sends (hash(x), , ) to Alice. 3. Alice computes the session decryption key mod p, recovers the encryption key mod p, encrypts mod p, then verifies that hash(z) = hash(x). E.7 Interoperability Issues A specific combination of authentication scheme (none, symmetric key, Autokey), digest/ signature scheme and identity scheme (PC, TC, IFF, GQ, MV) is called a cryptotype, although not all combinations are possible. There may be management configurations where the servers and clients may not all support the same cryptotypes. A secure NTPv4 subnet can be configured in several ways while keeping in mind the principles explained in this section. Note however that some cryptotype combinations may successfully interoperate with each other, but may not represent good security practice. The cryptotype of an association is determined at the time of mobilization, either at configuration time or some time later when a packet of appropriate cryptotype arrives. When a client, broadcast or symmetric active association is mobilized at configuration time, it can be designated non- authentic, authenticated with symmetric key or authenticated with some Autokey scheme, and subsequently it will send packets with that cryptotype. When a responding server, broadcast client or symmetric passive association is mobilized, it is designated with the same cryptotype as the received packet. When multiple identity schemes are supported, the parameter exchange determines which one is used. The request message contains bits corresponding to the schemes it supports, while the response message contains bits corresponding to the schemes it supports. The client matches the server bits with its own and selects a compatible identity scheme. The server is driven entirely by the client selection and remains stateless. When multiple selections are possible, the order from most secure to least is GC, IFF, TC. Note that PC does not interoperate with any of the others, since they require the host certificate which a PC server will not reveal. Following the principle that time is a public value, a server responds to any client packet that matches its cryptotype capabilities. Thus, a server receiving a non-authenticated packet will respond with a non-authenticated packet, while the same server receiving a packet of a cryptotype it supports will respond with packets of that cryptotype. However, new broadcast or manycast client associations or symmetric passive associations will not be mobilized unless the server supports a cryptotype compatible with the first packet received. By default, non- authenticated associations will not be mobilized unless overridden in a decidedly dangerous way. Some examples may help to reduce confusion. Client Alice has no specific cryptotype selected. Server Bob supports both symmetric key and Autokey cryptography. Alice’s non-authenticated packets arrive at Bob, who replies with non-authenticated packets. Cathy has a copy of Bob’s symmetric key file and has selected key ID 4 in packets to Bob. If Bob verifies the packet with key ID 4, he sends Cathy a reply with that key. If authentication fails, Bob sends Cathy a thing called a crypto-NAK, which tells her something broke. She can see the evidence using the utility programs of the NTP software library. Symmetric peers Bob and Denise have rolled their own host keys, certificates and identity parameters and lit the host status bits for the identity schemes they can support. Upon completion of the parameter exchange, both parties know the digest/signature scheme and available identity schemes of the other party. They do not have to use the same schemes, but each party must use the digest/signature scheme and one of the identity schemes supported by the other party. It should be clear from the above that Bob can support all the girls at the same time, as long as he has compatible authentication and identification credentials. Now, Bob can act just like the girls in his own choice of servers; he can run multiple configured associations with multiple different servers (or the same server, although that might not be useful). But, wise security policy might preclude some cryptotype combinations; for instance, running an identity scheme with one server and no authentication with another might not be wise. Appendix F. File Examples This appendix shows the file formats used by the OpenSSL library and the reference implementation. These are not included in the specification and are given here only as examples. In each case the actual file contents are shown followed by a dump produced by the OpenSSL asn1 program. F.1 RSA-MD5cert File and ASN.1 Encoding # ntpkey_RSA-MD5cert_whimsy.udel.edu.3236983143 # Tue Jul 30 01:59:03 2002 -----BEGIN CERTIFICATE----- MIIBkTCCATugAwIBAgIEwPBxZzANBgkqhkiG9w0BAQQFADAaMRgwFgYDVQQDEw93 aGltc3kudWRlbC5lZHUwHhcNMDIwNzMwMDE1OTA3WhcNMDMwNzMwMDE1OTA3WjAa MRgwFgYDVQQDEw93aGltc3kudWRlbC5lZHUwWjANBgkqhkiG9w0BAQEFAANJADBG AkEA2PpOz6toSQ3BtdGrBt+F6cSSde6zhayOwRj5nAkOvtQ505hdxWhudfKe7ZOY HRLLqACvVJEfBaSvE5OFWldUqQIBA6NrMGkwDwYDVR0TAQH/BAUwAwEB/zALBgNV HQ8EBAMCAoQwSQYDVR0OBEIEQEVFGZar3afoZcHDmhbgiOmaBrtWTlLHRwIJswge LuqB1fbsNEgUqFebBR1Y9qLwYQUm7ylBD+3z9PlhcUOwtnIwDQYJKoZIhvcNAQEE BQADQQAVZMiNbYV2BjvFH9x+t0PB9//giOV3fQoLK8hXXpyiAF4KLleEqP13pK0H TceF3e3bxSRTndkIhklEAcbYXm66 -----END CERTIFICATE----- 0:d=0 hl=4 l= 401 cons: SEQUENCE 4:d=1 hl=4 l= 315 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 13:d=2 hl=2 l= 4 prim: INTEGER :-3F0F8E99 19:d=2 hl=2 l= 13 cons: SEQUENCE 21:d=3 hl=2 l= 9 prim: OBJECT :md5WithRSAEncryption 32:d=3 hl=2 l= 0 prim: NULL 34:d=2 hl=2 l= 26 cons: SEQUENCE 36:d=3 hl=2 l= 24 cons: SET 38:d=4 hl=2 l= 22 cons: SEQUENCE 40:d=5 hl=2 l= 3 prim: OBJECT :commonName 45:d=5 hl=2 l= 15 prim: PRINTABLESTRING :whimsy.udel.edu 62:d=2 hl=2 l= 30 cons: SEQUENCE 64:d=3 hl=2 l= 13 prim: UTCTIME :020730015907Z 79:d=3 hl=2 l= 13 prim: UTCTIME :030730015907Z 94:d=2 hl=2 l= 26 cons: SEQUENCE 96:d=3 hl=2 l= 24 cons: SET 98:d=4 hl=2 l= 22 cons: SEQUENCE 100:d=5 hl=2 l= 3 prim: OBJECT :commonName 105:d=5 hl=2 l= 15 prim: PRINTABLESTRING :whimsy.udel.edu 122:d=2 hl=2 l= 90 cons: SEQUENCE 124:d=3 hl=2 l= 13 cons: SEQUENCE 126:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption 137:d=4 hl=2 l= 0 prim: NULL 139:d=3 hl=2 l= 73 prim: BIT STRING 214:d=2 hl=2 l= 107 cons: cont [ 3 ] 216:d=3 hl=2 l= 105 cons: SEQUENCE 218:d=4 hl=2 l= 15 cons: SEQUENCE 220:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 225:d=5 hl=2 l= 1 prim: BOOLEAN :255 228:d=5 hl=2 l= 5 prim: OCTET STRING 235:d=4 hl=2 l= 11 cons: SEQUENCE 237:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage 242:d=5 hl=2 l= 4 prim: OCTET STRING 248:d=4 hl=2 l= 73 cons: SEQUENCE 250:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Identifier 255:d=5 hl=2 l= 66 prim: OCTET STRING 323:d=1 hl=2 l= 13 cons: SEQUENCE 325:d=2 hl=2 l= 9 prim: OBJECT :md5WithRSAEncryption 336:d=2 hl=2 l= 0 prim: NULL 338:d=1 hl=2 l= 65 prim: BIT STRING F.2 RSAkey File and ASN.1 Encoding # ntpkey_RSAkey_whimsy.udel.edu.3236983143 # Tue Jul 30 01:59:03 2002 -----BEGIN RSA PRIVATE KEY----- MIIBOgIBAAJBANj6Ts+raEkNwbXRqwbfhenEknXus4WsjsEY+ZwJDr7UOdOYXcVo bnXynu2TmB0Sy6gAr1SRHwWkrxOThVpXVKkCAQMCQQCQpt81HPAws9Z5NnIElQPx Lbb5Sc0DyF8rZfu9W18p4Zb5UH3KYqZfAO4K0GTmxuriFphgS9bELSw5L6ow4t6D AiEA7ACLlKZtCp91CaDohViPhs7KBdRVq7DG9n88z9MM/gMCIQDrXRQMb2dqR/ww PHJ7aljkhhTE78mxLpn2Po82PfYI4wIhAJ1VsmMZngcU+LEV8FjltQSJ3APi48fL L07/fd/iCKlXAiEAnOi4CEpE8YVSytL2/PGQmFljLfUxIMm7+X8KJClOsJcCICgU 1w07kRO2ycicL2QRVh8J8vQL68VfH53H+oobKDCd -----END RSA PRIVATE KEY----- 0:d=0 hl=4 l= 314 cons: SEQUENCE 4:d=1 hl=2 l= 1 prim: INTEGER :00 7:d=1 hl=2 l= 65 prim: INTEGER : 74:d=1 hl=2 l= 1 prim: INTEGER :03 77:d=1 hl=2 l= 65 prim: INTEGER : 144:d=1 hl=2 l= 33 prim: INTEGER : 179:d=1 hl=2 l= 33 prim: INTEGER : 214:d=1 hl=2 l= 33 prim: INTEGER : 249:d=1 hl=2 l= 33 prim: INTEGER : 284:d=1 hl=2 l= 32 prim: INTEGER : F.3 IFFpar File and ASN.1 Encoding # ntpkey_IFFpar_whimsy.udel.edu.3236983143 # Tue Jul 30 01:59:03 2002 -----BEGIN DSA PRIVATE KEY----- MIH4AgEAAkEA7fBvqq9+3DH5BnBScMkruqH4QEB76oec1zjWQ23gyoP2U+L8tHfv z2LmogOqE1c0McgQynyfQMSDUEmxMyiDwQIVAJ18qdV84wmiCGmWgsHKbpAwepDX AkA4y42QqZ8aUzQRwkMuYTKbyRRnCG1TJi5eVJcCq65twl5c1bnn24xkbl+FXqck G6w9NcDtSzuYg1gFLxEuWsYaAkEAjc+nPJR7VY4BjDleVTna07edDfcySl9vy8Pa B4qArk51LdJlJ49yxEPUxFy/KBIFEHCwRZMc1J7z7dQ/Af26zQIUMXkbVz0D+2Yo YlG0C/F33Q+N5No= -----END DSA PRIVATE KEY----- 0:d=0 hl=3 l= 248 cons: SEQUENCE 3:d=1 hl=2 l= 1 prim: INTEGER :00 6:d=1 hl=2 l= 65 prim: INTEGER : 73:d=1 hl=2 l= 21 prim: INTEGER : 96:d=1 hl=2 l= 64 prim: INTEGER : 162:d=1 hl=2 l= 65 prim: INTEGER : 229:d=1 hl=2 l= 20 prim: INTEGER : Appendix G. ASN.1 Encoding Rules Certain value fields in request and response messages contain data encoded in ASN.1 distinguished encoding rules (DER). The BNF grammar for each encoding rule is given below along with the OpenSSL routine used for the encoding in the reference implementation. The object identifiers for the encryption algorithms and message digest/signature encryption schemes are specified in [2]. The particular algorithms required for conformance are not specified in this report. G.1 COOKIE request, IFF response, GQ response, MV response The value field of the COOKIE request message contains a sequence of two integers (n, e) encoded by the i2d_RSAPublicKey() routine in the OpenSSL distribution. In the request, n is the RSA modulus in bits and e is the public exponent. RSAPublicKey ::= SEQUENCE { n ::= INTEGER, e ::= INTEGER } The IFF and GQ responses contain a sequence of two integers (r, s) encoded by the i2d_DSA_SIG() routine in the OpenSSL distribution. In the responses, r is the challenge response and s is the hash of the private value. DSAPublicKey ::= SEQUENCE { r ::= INTEGER, s ::= INTEGER } The MV response contains a sequence of three integers (p, q, g) encoded by the i2d_DSAparams() routine in the OpenSSL library. In the response, p is the hash of the encrypted challenge value and (q, g) is the client portion of the decryption key. DSAparameters ::= SEQUENCE { p ::= INTEGER, q ::= INTEGER, g ::= INTEGER } G.2 CERT response, SIGN request and response The value field contains a X509v3 certificate encoded by the i2d_X509() routine in the OpenSSL distribution. The encoding follows the rules stated in [4], including the use of X509v3 extension fields. Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } The signatureAlgorithm is the object identifier of the message digest/signature encryption scheme used to sign the certificate. The signatureValue is computed by the certificate issuer using this algorithm and the issuer private key. TBSCertificate ::= SEQUENCE { version EXPLICIT v3(2), serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, extensions EXPLICIT Extensions OPTIONAL } The serialNumber is an integer guaranteed to be unique for the generating host. The reference implementation uses the NTP seconds when the certificate was generated. The signature is the object identifier of the message digest/signature encryption scheme used to sign the certificate. It must be identical to the signatureAlgorithm. CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } The notBefore and notAfter define the period of validity as defined in Appendix E. SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } The AlgorithmIdentifier specifies the encryption algorithm for the subject public key. The subjectPublicKey is the public key of the subject. Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING } Name ::= SEQUENCE { OBJECT IDENTIFIER commonName PrintableString HostName } For all certificates, the subject HostName is the unique DNS name of the host to which the public key belongs. The reference implementation uses the string returned by the Unix gethostname() routine (trailing NUL removed). For other than self-signed certificates, the issuer HostName is the unique DNS name of the host signing the certificate.