diff --git a/spec/dictionary.txt b/spec/dictionary.txt
index fc8250e..6a60eea 100644
--- a/spec/dictionary.txt
+++ b/spec/dictionary.txt
@@ -3,13 +3,17 @@ Ack
ACK
acknowledgement
acknowledgements
+ASN
BCP
+BPSec
BPv
+bundleSecurity
Burleigh
CAs
CBOR
ciphersuite
CLA
+clientAuth
ClientHello
codepoints
Conv
@@ -18,15 +22,19 @@ dbus
DCCP
decodable
deconflict
+digitalSignature
DNS
+dod
dtn
DTN
+EKU
encodings
endian
extensibility
FFF
HostName
IANA
+IEC
IESG
IETF
incrementing
@@ -35,10 +43,15 @@ interoperation
IPADDR
iPAddress
IPv
+iso
+ITU
keepalive
Keepalive
KEEPALIVE
KEEPALIVEs
+keyAgreement
+keyEncipherment
+kp
LLC
misconfigured
MRU
@@ -51,6 +64,7 @@ PCH
pipelining
Pipelining
PKI
+pkix
PKIX
plaintext
pre
@@ -68,12 +82,15 @@ RTT
SDNV
Seg
SEGMENTs
+serverAuth
SESS
+SMI
SNI
SSL
STARTTLS
subjectAltName
substate
+TBD
TCP
TCPCL
TCPCLOSE
@@ -88,6 +105,8 @@ uniformResourceIdentifier
untrusted
URI
UTF
+wireshark
+Wireshark
xEF
xF
XFER
diff --git a/spec/draft-ietf-dtn-tcpclv4.xml b/spec/draft-ietf-dtn-tcpclv4.xml
index 54d2e16..ed148f7 100644
--- a/spec/draft-ietf-dtn-tcpclv4.xml
+++ b/spec/draft-ietf-dtn-tcpclv4.xml
@@ -1121,7 +1121,7 @@ Including key identifiers simplifies the work of an entity needing to assemble a
Unless prohibited by CA policy, a TCPCL end-entity certificate SHALL contain a NODE-ID which authenticates the Node ID of the peer.
When assigned one or more stable DNS names, a TCPCL end-entity certificate SHOULD contain DNS-ID which authenticates those (fully qualified) names.
-When assigned one or more stable network addresss, a TCPCL end-entity certificate MAY contain IPADDR-ID which authenticates those addresses.
+When assigned one or more stable network addresses, a TCPCL end-entity certificate MAY contain IPADDR-ID which authenticates those addresses.
This document defines a PKIX Extended Key Usage key purpose "id-kp-bundleSecurity" in which can be used to restrict a certificate's use.
@@ -1221,7 +1221,7 @@ Indicating that one or more such claims are present and none match the peer iden
Certificate Path and Purpose Validation
For any peer end-entity certificate received during TLS handshake, the entity SHALL perform the certification path validation of up to one of the entity's trusted CA certificates.
-If enabled by local policy, the entity SHALL perform an OCSP check of each certificate providing OCSP authoritiy information in accordance with .
+If enabled by local policy, the entity SHALL perform an OCSP check of each certificate providing OCSP authority information in accordance with .
If certificate validation fails or if security policy disallows a certificate for any reason, the entity SHALL fail the TLS handshake with a "bad_certificate" alert.
Leaving out part of the certification chain can cause the entity to fail to validate a certificate if the left-out certificates are unknown to the entity (see ).
@@ -2421,7 +2421,7 @@ Finally, an attacker or a misconfigured entity can cause issues at the TCP conne
Mandatory-to-Implement TLS
Following IETF best current practice, TLS is mandatory to implement for all TCPCL implementations but TLS is optional to use for a given TCPCL session.
-The recommended configuration of is to always enable TLS, but entites are permitted to disable TLS based on local configration.
+The recommended configuration of is to always enable TLS, but entities are permitted to disable TLS based on local configuration.
The configuration to enable or disable TLS for an entity or a session is outside of the scope of this document.
The configuration to disable TLS is different from the threat of TLS stripping described in .