From c37aeda351489226ddc48fc2ebf7bd25a136fb38 Mon Sep 17 00:00:00 2001 From: JeremyRand Date: Mon, 13 Jun 2016 05:16:13 +0000 Subject: [PATCH 1/4] Added Dehydrated TLS Certificates spec. --- README.md | 12 ++-- ifa-0003.md | 179 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 186 insertions(+), 5 deletions(-) create mode 100644 ifa-0003.md diff --git a/README.md b/README.md index 34f2418..a801d82 100644 --- a/README.md +++ b/README.md @@ -1,17 +1,19 @@ IFA Proposals ============= -| Number | Title | Type | Status | -|--------------|-------------------------------|----------|----------| -| [0000][0000] | Proposal Guidelines & Process | Process | Draft | -| [0001][0001] | Domain Names | Standard | Draft | -| [0002][0002] | Domain Names - Non-DNS Types | Standard | Draft | +| Number | Title | Type | Status | +|--------------|--------------------------------------------|----------|----------| +| [0000][0000] | Proposal Guidelines & Process | Process | Draft | +| [0001][0001] | Domain Names | Standard | Draft | +| [0002][0002] | Domain Names - Non-DNS Types | Standard | Draft | +| [0003][0003] | Domain Names - Dehydrated TLS Certificates | Standard | Draft | *This list does not contain proposals that have been deferred, rejected, or withdrawn.* [0000]:https://github.com/ifa-wg/proposals/blob/master/ifa-0000.md [0001]:https://github.com/ifa-wg/proposals/blob/master/ifa-0001.md [0002]:https://github.com/ifa-wg/proposals/blob/master/ifa-0002.md +[0003]:https://github.com/ifa-wg/proposals/blob/master/ifa-0003.md How-To ======= diff --git a/ifa-0003.md b/ifa-0003.md new file mode 100644 index 0000000..408f4bf --- /dev/null +++ b/ifa-0003.md @@ -0,0 +1,179 @@ +Domain Names — Dehydrated TLS Certificates +========================================== + + IFA Proposal No. 3 + Title: Domain Names — Dehydrated TLS Certificates + Status: Draft + Type: Standards Track + Created: 2016-06-12 + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. + +This document is released into the public domain. + +This document was authored by Jeremy Rand, with input from Ryan Castellucci and Hugo Landau. + + + +**Table of Contents** + +- [Introduction](#introduction) +- [Dehydrated "tls" Items](#dehydrated-tls-items) +- [Design Goals](#design-goals) +- [Changes to Processing Rules](#changes-to-processing-rules) +- [Changes to Domain Name Owner Recommendations](#changes-to-domain-name-owner-recommendations) +- [Changelog](#changelog) + + + +Introduction +------------ +This document extends the Domain Names specification, IFA-0001. It specifies an additional format of encoding the "tls" item type. This format is more suited for integrating "tls" item support into mainstream certificate trust stores, given the API limitations of those trust stores. + +Dehydrated "tls" Items +---------------------- + +A dehydrated certificate in JSON format looks like: + +``` +["MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJlmDLitmolpxbKFQxRSj5AbF7VOip9XOyAC9HfmTWibGMpODJQH7LXyEo5o/wc2fHB+7aoKcW+eZ74+3ZN+4SA==",4838688,5154336,10,"MEYCIQCtBKJDjBg3M+RuHecPWgdo99wyPASBXsLMIlG3OYKJywIhAMXPMA+mDqNhgsLGdiyLQ09hsYbwami2hkvM9ijDPJj7"] +``` + +It is a JSON list of 5 items. + +1. a base64 string representing the public key. Typically an EC public key, not RSA, because EC is much more compact. The public key is not compressed, because compressed EC public keys are not widely supported by libraries (particularly the Golang standard library). +2. an integer representing the "not before" part of the validity period, in units of 5 minutes. 5 minutes essentially divides the number by 300, which eliminates slightly more than 1 byte. +3. an integer representing the "not after" part of the validity period, in units of 5 minutes. 5 minutes essentially divides the number by 300, which eliminates slightly more than 1 byte. +4. an integer representing the signature algorithm. Typically ECDSA with SHA256. +5. a base64 string representing the signature. Typically ECDSA with SHA256. + +These 5 items are chosen for 3 reasons: + +1. A valid certificate can be rehydrated from these 5 items (plus a domain name). This means that TLS applications that require possessing a full certificate (not just a public key hash) in order to set up an override can be configured without out-of-band retrieval of a certificate. +2. These items are much smaller than the rehydrated certificate would be, and therefore can comfortably fit into a datastore where storage is expensive (e.g. a Namecoin value). +3. Rehydrated certificates are minimally trusted. For example, rehydrated certificates cannot be valid for other domain names or uses (via SAN, the CA flag, etc.) than the one which the user retrieving a TLSA record expects. As a result, these certificates can be added to a root CA trust store with minimal security implications. + +To rehydrate into a full certificate, construct a self-signed certificate with the following fields: + +* NotBefore: based on dehydrated data, after converting units. +* NotAfter: based on dehydrated data, after converting units. +* KeyUsage: KeyUsageDigitalSignature +* ExtKeyUsage: ExtKeyUsageServerAuth +* BasicConstraintsValid: true +* SignatureAlgorithm: based on dehydrated data +* PublicKey: based on dehydrated data +* Signature: based on dehydrated data +* Subject Organization: the .bit domain in use +* Subject SerialNumber: "Namecoin TLS Certificate" +* DNSNames: the .bit domain in use +* SerialNumber: first 19 bytes of SHA256(SHA256(the .bit domain in use) | SHA256(PublicKey) | SHA256(big-endian int64 of NotBefore in units of 5 minutes) | SHA256(big-endian int64 of NotAfter in units of 5 minutes)) + +The certificate shown above in JSON, for the domain name "www.veclabs.bit", looks like this: + +``` +$ cat cert.pem | openssl x509 -text +Certificate: + Data: + Version: 3 (0x2) + Serial Number: + 3a:f7:1d:51:bc:af:96:ca:96:a7:a7:2e:28:65:18:dc:dc:f9:8d + Signature Algorithm: ecdsa-with-SHA256 + Issuer: O=www.veclabs.bit/serialNumber=Namecoin TLS Certificate + Validity + Not Before: Jan 1 00:00:00 2016 GMT + Not After : Jan 1 00:00:00 2019 GMT + Subject: O=www.veclabs.bit/serialNumber=Namecoin TLS Certificate + Subject Public Key Info: + Public Key Algorithm: id-ecPublicKey + Public-Key: (256 bit) + pub: + 04:26:59:83:2e:2b:66:a2:5a:71:6c:a1:50:c5:14: + a3:e4:06:c5:ed:53:a2:a7:d5:ce:c8:00:bd:1d:f9: + 93:5a:26:c6:32:93:83:25:01:fb:2d:7c:84:a3:9a: + 3f:c1:cd:9f:1c:1f:bb:6a:82:9c:5b:e7:99:ef:8f: + b7:64:df:b8:48 + ASN1 OID: prime256v1 + X509v3 extensions: + X509v3 Key Usage: critical + Digital Signature + X509v3 Extended Key Usage: + TLS Web Server Authentication + X509v3 Basic Constraints: critical + CA:FALSE + X509v3 Subject Alternative Name: + DNS:www.veclabs.bit + Signature Algorithm: ecdsa-with-SHA256 + 30:46:02:21:00:ad:04:a2:43:8c:18:37:33:e4:6e:1d:e7:0f: + 5a:07:68:f7:dc:32:3c:04:81:5e:c2:cc:22:51:b7:39:82:89: + cb:02:21:00:c5:cf:30:0f:a6:0e:a3:61:82:c2:c6:76:2c:8b: + 43:4f:61:b1:86:f0:6a:68:b6:86:4b:cc:f6:28:c3:3c:98:fb +-----BEGIN CERTIFICATE----- +MIIBzTCCAXKgAwIBAgITOvcdUbyvlsqWp6cuKGUY3Nz5jTAKBggqhkjOPQQDAjA9 +MRgwFgYDVQQKEw93d3cudmVjbGFicy5iaXQxITAfBgNVBAUTGE5hbWVjb2luIFRM +UyBDZXJ0aWZpY2F0ZTAeFw0xNjAxMDEwMDAwMDBaFw0xOTAxMDEwMDAwMDBaMD0x +GDAWBgNVBAoTD3d3dy52ZWNsYWJzLmJpdDEhMB8GA1UEBRMYTmFtZWNvaW4gVExT +IENlcnRpZmljYXRlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJlmDLitmolpx +bKFQxRSj5AbF7VOip9XOyAC9HfmTWibGMpODJQH7LXyEo5o/wc2fHB+7aoKcW+eZ +74+3ZN+4SKNRME8wDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMB +MAwGA1UdEwEB/wQCMAAwGgYDVR0RBBMwEYIPd3d3LnZlY2xhYnMuYml0MAoGCCqG +SM49BAMCA0kAMEYCIQCtBKJDjBg3M+RuHecPWgdo99wyPASBXsLMIlG3OYKJywIh +AMXPMA+mDqNhgsLGdiyLQ09hsYbwami2hkvM9ijDPJj7 +-----END CERTIFICATE----- +``` + +Note that a canonical implementation (in Go) of this scheme is being added to ncdns. Because the signatures will fail if the certificate is not constructed deterministically, the canonical implementation of certificate construction takes precedence over this spec and any examples. (Please report any inconsistencies.) + +An IFA-0001-based JSON value which uses the above dehydrated certificate looks like this: + +``` +{ + "map":{ + "www":{ + "map":{ + "_tcp":{ + "map":{ + "_443":{ + "tls":[ + [ + "d8", + 0, + 0, + [ + "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJlmDLitmolpxbKFQxRSj5AbF7VOip9XOyAC9HfmTWibGMpODJQH7LXyEo5o/wc2fHB+7aoKcW+eZ74+3ZN+4SA==", + 4838688, + 5154336, + 10, + "MEYCIQCtBKJDjBg3M+RuHecPWgdo99wyPASBXsLMIlG3OYKJywIhAMXPMA+mDqNhgsLGdiyLQ09hsYbwami2hkvM9ijDPJj7" + ] + ] + ] + } + } + } + } + } + } +} +``` + +The "d8", 0, 0 before the certificate data is a magic indicator that this is a dehydrated certificate rather than a format based on RFC 6698 (DANE). "d8" is an abbreviation for how "dehydrate" is pronounced in English, and will not collide with future revisions to DANE because DANE uses an integer here while this spec uses a string. The latter 0 is intended as a version field. The former 0 is reserved, and is only present so that the number of elements in a "tls" record is constant regardless of whether it's dehydrated or DANE-based. + +Design Goals +------------ + +The primary goal is to fit comfortably into a Namecoin value (which is limited to 520 bytes) when combined with IP addresses or other data. We believe that it achieves this. The goal is **not** to achieve optimal compression at this time. We expect to improve on the scalability of Namecoin values in the future, via proposals such as CBOR encoding, value compression, and segregated name values; improvements in dehydrated certificate encoding (e.g. compressed public keys and removing the overhead of base64 and decimal encoding) are fair game for those future efforts. We are choosing not to fully optimize at this time because we believe that the current proposal is currently sufficient, and future revisions to this spec are affected by ecosystem elements out of the scope of this proposal, including uncertainty about the above scalability improvements, and also including uncertainty about how TLS implementations may change their requirements in the future (for example, Mozilla's WebExtensions spec is still up in the air). + +Changes to Processing Rules +--------------------------- + +There are no changes to item suppression or other processing rules. + +Changes to Domain Name Owner Recommendations +-------------------------------------------- + +Dehydrated "tls" items are more widely compatible with currently deployed TLS implementations, e.g. Google Chrome and Mozilla Firefox. However, because their encoding contains more data than a public key hash, dehydrated "tls" items will incur higher storage costs than the encoding specified in IFA-0001. Domain name owners are advised to consider the tradeoffs between compatibility and storage costs when choosing how to encode their "tls" items. It is our belief that, in most publicly deployed website configurations, the improved compatibility of dehydrated "tls" items makes their usage preferable, and that their increased storage costs are negligible in such configurations. + +Changelog +--------- + + - 20160612: Initial revision. From d9de3fd469ae9cc99725d457eadbe739aee7c188 Mon Sep 17 00:00:00 2001 From: JeremyRand Date: Tue, 13 Jun 2017 07:36:04 +0000 Subject: [PATCH 2/4] Update IFA-0003. --- ifa-0003.md | 108 +++++++++++++++++++++++++++------------------------- 1 file changed, 57 insertions(+), 51 deletions(-) diff --git a/ifa-0003.md b/ifa-0003.md index 408f4bf..3d5cee1 100644 --- a/ifa-0003.md +++ b/ifa-0003.md @@ -28,29 +28,37 @@ This document was authored by Jeremy Rand, with input from Ryan Castellucci and Introduction ------------ -This document extends the Domain Names specification, IFA-0001. It specifies an additional format of encoding the "tls" item type. This format is more suited for integrating "tls" item support into mainstream certificate trust stores, given the API limitations of those trust stores. +This document extends the Domain Names specification, IFA-0001. It specifies an additional format of encoding the `tls` item type. This format is more suited for integrating `tls` item support into mainstream certificate trust stores, given the API limitations of those trust stores. -Dehydrated "tls" Items +Extensible Alternate Encoding for `tls` Items +--------------------------------------------- + +IFA-0001 specifies that a TLS item is a JSON list. This specification redefines TLS items to instead be a JSON object, of the form `{encoding: data}`. *encoding* can be `"dane"`, in which case `data` is a JSON list in the form specified by IFA-0001. *encoding* can also be `"d8"`, in which case `data` is in the form specified below. If multiple *encoding* keys exist for a single TLS item (e.g. both `dane` and `d8` are available), then implementations MUST pick one of their choice. Implementations MAY assume that all *encoding* options for a TLS item are equivalent. If a TLS item that contains a JSON list instead of a JSON object is encountered, implementations MUST treat the list `list` as the JSON object `{"dane": list}`, which ensures backward-compatibility with IFA-0001. + +Dehydrated `tls` Items ---------------------- A dehydrated certificate in JSON format looks like: -``` -["MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJlmDLitmolpxbKFQxRSj5AbF7VOip9XOyAC9HfmTWibGMpODJQH7LXyEo5o/wc2fHB+7aoKcW+eZ74+3ZN+4SA==",4838688,5154336,10,"MEYCIQCtBKJDjBg3M+RuHecPWgdo99wyPASBXsLMIlG3OYKJywIhAMXPMA+mDqNhgsLGdiyLQ09hsYbwami2hkvM9ijDPJj7"] -``` +~~~ +{"d8":[1,"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEGm0zZlzrnwEYvub3BG3+VTKjvXWdMntoTanw3cwGAqcb0ALFrt5MdChT9t4josaefnGdVHa+ZBNmSEIaNZNhnw==",4944096,5154336,10,"MEUCIQCEkb4Q+AV8FsQgRoWSZ3S+1Ww/SySl4238SjTv5d/WAgIgX2rAhfCQ3gGG1Abhme8mDTG641vIYHJuz8d6m7IrgJo="]} +~~~ -It is a JSON list of 5 items. +It is a JSON object of the form `{"d8":list}`, where `list` is a JSON list of 6 items. -1. a base64 string representing the public key. Typically an EC public key, not RSA, because EC is much more compact. The public key is not compressed, because compressed EC public keys are not widely supported by libraries (particularly the Golang standard library). -2. an integer representing the "not before" part of the validity period, in units of 5 minutes. 5 minutes essentially divides the number by 300, which eliminates slightly more than 1 byte. -3. an integer representing the "not after" part of the validity period, in units of 5 minutes. 5 minutes essentially divides the number by 300, which eliminates slightly more than 1 byte. -4. an integer representing the signature algorithm. Typically ECDSA with SHA256. -5. a base64 string representing the signature. Typically ECDSA with SHA256. +1. an integer representing a version number. Currently `1` is the only defined version. Dehydrated certificates with an unknown version MUST be ignored. +2. a base64 string representing the public key. Typically an EC public key, not RSA, because EC is much more compact. The public key is not compressed, because compressed EC public keys are not widely supported by libraries (particularly the Golang standard library). +3. an integer representing the "not before" part of the validity period, in units of 5 minutes. 5 minutes essentially divides the number by 300, which eliminates slightly more than 1 byte. +4. an integer representing the "not after" part of the validity period, in units of 5 minutes. 5 minutes essentially divides the number by 300, which eliminates slightly more than 1 byte. +5. an integer representing the signature algorithm. Typically ECDSA with SHA256. +6. a base64 string representing the signature. Typically ECDSA with SHA256. -These 5 items are chosen for 3 reasons: +`d8` is an abbreviation for how "dehydrate" is pronounced in English. -1. A valid certificate can be rehydrated from these 5 items (plus a domain name). This means that TLS applications that require possessing a full certificate (not just a public key hash) in order to set up an override can be configured without out-of-band retrieval of a certificate. -2. These items are much smaller than the rehydrated certificate would be, and therefore can comfortably fit into a datastore where storage is expensive (e.g. a Namecoin value). +These 6 items are chosen for 3 reasons: + +1. A valid certificate can be rehydrated from these 6 items (plus a domain name). This means that TLS applications that require possessing a full certificate (not just a public key hash) in order to set up an override can be configured without out-of-band retrieval of a certificate. +2. These items are much smaller (they are circa 255 bytes of JSON) than the rehydrated certificate would be, and therefore can comfortably fit into a datastore where storage is expensive (e.g. a Namecoin value). 3. Rehydrated certificates are minimally trusted. For example, rehydrated certificates cannot be valid for other domain names or uses (via SAN, the CA flag, etc.) than the one which the user retrieving a TLSA record expects. As a result, these certificates can be added to a root CA trust store with minimal security implications. To rehydrate into a full certificate, construct a self-signed certificate with the following fields: @@ -63,7 +71,7 @@ To rehydrate into a full certificate, construct a self-signed certificate with t * SignatureAlgorithm: based on dehydrated data * PublicKey: based on dehydrated data * Signature: based on dehydrated data -* Subject Organization: the .bit domain in use +* Subject CommonName: the .bit domain in use * Subject SerialNumber: "Namecoin TLS Certificate" * DNSNames: the .bit domain in use * SerialNumber: first 19 bytes of SHA256(SHA256(the .bit domain in use) | SHA256(PublicKey) | SHA256(big-endian int64 of NotBefore in units of 5 minutes) | SHA256(big-endian int64 of NotAfter in units of 5 minutes)) @@ -76,23 +84,24 @@ Certificate: Data: Version: 3 (0x2) Serial Number: - 3a:f7:1d:51:bc:af:96:ca:96:a7:a7:2e:28:65:18:dc:dc:f9:8d + 51:06:10:fe:12:53:81:e5:cd:ed:9a:38:7d:19:25:42:34:10:54 Signature Algorithm: ecdsa-with-SHA256 - Issuer: O=www.veclabs.bit/serialNumber=Namecoin TLS Certificate + Issuer: CN=www.veclabs.bit/serialNumber=Namecoin TLS Certificate Validity - Not Before: Jan 1 00:00:00 2016 GMT + Not Before: Jan 1 00:00:00 2017 GMT Not After : Jan 1 00:00:00 2019 GMT - Subject: O=www.veclabs.bit/serialNumber=Namecoin TLS Certificate + Subject: CN=www.veclabs.bit/serialNumber=Namecoin TLS Certificate Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: - 04:26:59:83:2e:2b:66:a2:5a:71:6c:a1:50:c5:14: - a3:e4:06:c5:ed:53:a2:a7:d5:ce:c8:00:bd:1d:f9: - 93:5a:26:c6:32:93:83:25:01:fb:2d:7c:84:a3:9a: - 3f:c1:cd:9f:1c:1f:bb:6a:82:9c:5b:e7:99:ef:8f: - b7:64:df:b8:48 + 04:1a:6d:33:66:5c:eb:9f:01:18:be:e6:f7:04:6d: + fe:55:32:a3:bd:75:9d:32:7b:68:4d:a9:f0:dd:cc: + 06:02:a7:1b:d0:02:c5:ae:de:4c:74:28:53:f6:de: + 23:a2:c6:9e:7e:71:9d:54:76:be:64:13:66:48:42: + 1a:35:93:61:9f ASN1 OID: prime256v1 + NIST CURVE: P-256 X509v3 extensions: X509v3 Key Usage: critical Digital Signature @@ -103,21 +112,21 @@ Certificate: X509v3 Subject Alternative Name: DNS:www.veclabs.bit Signature Algorithm: ecdsa-with-SHA256 - 30:46:02:21:00:ad:04:a2:43:8c:18:37:33:e4:6e:1d:e7:0f: - 5a:07:68:f7:dc:32:3c:04:81:5e:c2:cc:22:51:b7:39:82:89: - cb:02:21:00:c5:cf:30:0f:a6:0e:a3:61:82:c2:c6:76:2c:8b: - 43:4f:61:b1:86:f0:6a:68:b6:86:4b:cc:f6:28:c3:3c:98:fb + 30:45:02:21:00:84:91:be:10:f8:05:7c:16:c4:20:46:85:92: + 67:74:be:d5:6c:3f:4b:24:a5:e3:6d:fc:4a:34:ef:e5:df:d6: + 02:02:20:5f:6a:c0:85:f0:90:de:01:86:d4:06:e1:99:ef:26: + 0d:31:ba:e3:5b:c8:60:72:6e:cf:c7:7a:9b:b2:2b:80:9a -----BEGIN CERTIFICATE----- -MIIBzTCCAXKgAwIBAgITOvcdUbyvlsqWp6cuKGUY3Nz5jTAKBggqhkjOPQQDAjA9 -MRgwFgYDVQQKEw93d3cudmVjbGFicy5iaXQxITAfBgNVBAUTGE5hbWVjb2luIFRM -UyBDZXJ0aWZpY2F0ZTAeFw0xNjAxMDEwMDAwMDBaFw0xOTAxMDEwMDAwMDBaMD0x -GDAWBgNVBAoTD3d3dy52ZWNsYWJzLmJpdDEhMB8GA1UEBRMYTmFtZWNvaW4gVExT -IENlcnRpZmljYXRlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJlmDLitmolpx -bKFQxRSj5AbF7VOip9XOyAC9HfmTWibGMpODJQH7LXyEo5o/wc2fHB+7aoKcW+eZ -74+3ZN+4SKNRME8wDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMB +MIIBzDCCAXKgAwIBAgITUQYQ/hJTgeXN7Zo4fRklQjQQVDAKBggqhkjOPQQDAjA9 +MRgwFgYDVQQDEw93d3cudmVjbGFicy5iaXQxITAfBgNVBAUTGE5hbWVjb2luIFRM +UyBDZXJ0aWZpY2F0ZTAeFw0xNzAxMDEwMDAwMDBaFw0xOTAxMDEwMDAwMDBaMD0x +GDAWBgNVBAMTD3d3dy52ZWNsYWJzLmJpdDEhMB8GA1UEBRMYTmFtZWNvaW4gVExT +IENlcnRpZmljYXRlMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEGm0zZlzrnwEY +vub3BG3+VTKjvXWdMntoTanw3cwGAqcb0ALFrt5MdChT9t4josaefnGdVHa+ZBNm +SEIaNZNhn6NRME8wDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMB MAwGA1UdEwEB/wQCMAAwGgYDVR0RBBMwEYIPd3d3LnZlY2xhYnMuYml0MAoGCCqG -SM49BAMCA0kAMEYCIQCtBKJDjBg3M+RuHecPWgdo99wyPASBXsLMIlG3OYKJywIh -AMXPMA+mDqNhgsLGdiyLQ09hsYbwami2hkvM9ijDPJj7 +SM49BAMCA0gAMEUCIQCEkb4Q+AV8FsQgRoWSZ3S+1Ww/SySl4238SjTv5d/WAgIg +X2rAhfCQ3gGG1Abhme8mDTG641vIYHJuz8d6m7IrgJo= -----END CERTIFICATE----- ``` @@ -125,7 +134,7 @@ Note that a canonical implementation (in Go) of this scheme is being added to nc An IFA-0001-based JSON value which uses the above dehydrated certificate looks like this: -``` +~~~ { "map":{ "www":{ @@ -134,18 +143,16 @@ An IFA-0001-based JSON value which uses the above dehydrated certificate looks l "map":{ "_443":{ "tls":[ - [ - "d8", - 0, - 0, - [ - "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJlmDLitmolpxbKFQxRSj5AbF7VOip9XOyAC9HfmTWibGMpODJQH7LXyEo5o/wc2fHB+7aoKcW+eZ74+3ZN+4SA==", - 4838688, + { + "d8":[ + 1, + "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEGm0zZlzrnwEYvub3BG3+VTKjvXWdMntoTanw3cwGAqcb0ALFrt5MdChT9t4josaefnGdVHa+ZBNmSEIaNZNhnw==", + 4944096, 5154336, 10, - "MEYCIQCtBKJDjBg3M+RuHecPWgdo99wyPASBXsLMIlG3OYKJywIhAMXPMA+mDqNhgsLGdiyLQ09hsYbwami2hkvM9ijDPJj7" + "MEUCIQCEkb4Q+AV8FsQgRoWSZ3S+1Ww/SySl4238SjTv5d/WAgIgX2rAhfCQ3gGG1Abhme8mDTG641vIYHJuz8d6m7IrgJo=" ] - ] + } ] } } @@ -154,9 +161,7 @@ An IFA-0001-based JSON value which uses the above dehydrated certificate looks l } } } -``` - -The "d8", 0, 0 before the certificate data is a magic indicator that this is a dehydrated certificate rather than a format based on RFC 6698 (DANE). "d8" is an abbreviation for how "dehydrate" is pronounced in English, and will not collide with future revisions to DANE because DANE uses an integer here while this spec uses a string. The latter 0 is intended as a version field. The former 0 is reserved, and is only present so that the number of elements in a "tls" record is constant regardless of whether it's dehydrated or DANE-based. +~~~ Design Goals ------------ @@ -171,9 +176,10 @@ There are no changes to item suppression or other processing rules. Changes to Domain Name Owner Recommendations -------------------------------------------- -Dehydrated "tls" items are more widely compatible with currently deployed TLS implementations, e.g. Google Chrome and Mozilla Firefox. However, because their encoding contains more data than a public key hash, dehydrated "tls" items will incur higher storage costs than the encoding specified in IFA-0001. Domain name owners are advised to consider the tradeoffs between compatibility and storage costs when choosing how to encode their "tls" items. It is our belief that, in most publicly deployed website configurations, the improved compatibility of dehydrated "tls" items makes their usage preferable, and that their increased storage costs are negligible in such configurations. +Dehydrated `tls` items are more widely compatible with currently deployed TLS implementations, e.g. Google Chrome and Mozilla Firefox. However, because their encoding contains more data than a public key hash, dehydrated `tls` items will incur higher storage costs than the encoding specified in IFA-0001. Domain name owners are advised to consider the tradeoffs between compatibility and storage costs when choosing how to encode their `tls` items. It is our belief that, in most publicly deployed website configurations, the improved compatibility of dehydrated `tls` items makes their usage preferable, and that their increased storage costs are negligible in such configurations. Changelog --------- + - 20170613: Revisions based on feedback. - 20160612: Initial revision. From 938c44f60000ae546e0bf19e3228ea45954cbd2e Mon Sep 17 00:00:00 2001 From: JeremyRand Date: Tue, 13 Jun 2017 07:37:10 +0000 Subject: [PATCH 3/4] Update ToC for IFA-0003. --- ifa-0003.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ifa-0003.md b/ifa-0003.md index 3d5cee1..f20d9f0 100644 --- a/ifa-0003.md +++ b/ifa-0003.md @@ -18,7 +18,8 @@ This document was authored by Jeremy Rand, with input from Ryan Castellucci and **Table of Contents** - [Introduction](#introduction) -- [Dehydrated "tls" Items](#dehydrated-tls-items) +- [Extensible Alternate Encoding for `tls` Items](#extensible-alternate-encoding-for-tls-items) +- [Dehydrated `tls` Items](#dehydrated-tls-items) - [Design Goals](#design-goals) - [Changes to Processing Rules](#changes-to-processing-rules) - [Changes to Domain Name Owner Recommendations](#changes-to-domain-name-owner-recommendations) From 13e925f5f439473fe7b68ff2d5c7292a11f0fdd6 Mon Sep 17 00:00:00 2001 From: JeremyRand Date: Tue, 13 Jun 2017 07:41:22 +0000 Subject: [PATCH 4/4] IFA-0003 formatting fix. --- ifa-0003.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ifa-0003.md b/ifa-0003.md index f20d9f0..f042e0c 100644 --- a/ifa-0003.md +++ b/ifa-0003.md @@ -77,7 +77,7 @@ To rehydrate into a full certificate, construct a self-signed certificate with t * DNSNames: the .bit domain in use * SerialNumber: first 19 bytes of SHA256(SHA256(the .bit domain in use) | SHA256(PublicKey) | SHA256(big-endian int64 of NotBefore in units of 5 minutes) | SHA256(big-endian int64 of NotAfter in units of 5 minutes)) -The certificate shown above in JSON, for the domain name "www.veclabs.bit", looks like this: +The certificate shown above in JSON, for the domain name `www.veclabs.bit`, looks like this: ``` $ cat cert.pem | openssl x509 -text