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 .