1) It is a tool = designed to serve a specific, limited set of purposes.

2) It is a toolkit that can be used= to address multiple purposes.

As far as IETF adoption goes, we could choose to adopt none, part or = all as WG items. However there are some constraints. Since part 5 depends o= n part 4, 4 on 3, and 3 on 2, it is not possible to choose to do part 4 wit= hout also doing 3 and 2.

= One of my greatest disappointments on the Web was that by the time Tim asse= mbled to team at CERN to fix HTTP, the exponent had already kicked in and w= e were prisoners of the user base. So I have been holding off deployment un= til at least I was happy with the way the system worked together. This is n= ow the third major redesign.=C2=A0

We will have to have some users before we can be sure we have a = useful spec. And having users does not mean we can't make breaking chan= ges but we will at least have to give them an upgrade path. So if anyone ha= s a big idea that is going to cause breaking changes, if they propose it no= w, there will be no need for an upgrade plan which will make it simpler.

Since UDF is the simplest o= f the proposals and the others depend on it, I suggest we start by looking = at that first.

--000000000000d4f33c059001dfa8-- From nobody Tue Aug 13 09:49:44 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF98312024E for ; Tue, 13 Aug 2019 09:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auv9FubwWKh3 for ; Tue, 13 Aug 2019 09:49:40 -0700 (PDT) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5931200D6 for ; Tue, 13 Aug 2019 09:49:40 -0700 (PDT) Received: by mail-ot1-f41.google.com with SMTP id c7so2493354otp.1 for ; Tue, 13 Aug 2019 09:49:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6/sYNxmnnyUAVNEJ8zI+whA2yiaaXMXZ/iQEhZb43bo=; b=mvGwgVR+OKkp3o6szDpEILxRcHD5nmCeck4bDDi4nwFTCD5B8WFQuAWf07YR+CE+aC fBGH+q/V/UyD2mGVhjQIkBnTkaPhUISSSCI1NzuBXhqjct1ANS3c/B7xTBXiGJRR2HI2 7jrVWOTanXqq5kIPy7WSf4d3zockb8ZxQZpbnFE4cFFbjYnOi66InmI7Kx2EVxlU8gMz NnITT9GmdLEEPpl/fRX9IdcWm3F395ih6IJ5gKNscenjRdK4cNBgkP2f1fXaBnq95oEV /avXNZbJnPdZ4dySJ3sh8UsP9F5HGWrwyv/yfxRZjyYE2aKl0ijffRkg1Xd6EpPJr+Vt KlIA== X-Gm-Message-State: APjAAAWNMpx0UsouhePEy14wEYSw7FRTKIJl7lbTEu/1vpmgVbOcvLuZ ETbU13nP3QWOVVx/laUda9kLYV8sksHlUtQn3NrEUMsp X-Google-Smtp-Source: APXvYqxNxTfPUhJ/+hhyxOtnv+iQrFoqPSGoHpOpFZ1sDeZLcELPZECFVgZ1cJRCqeWrbYHvv1yY9X7RrU3+tWNuYSo= X-Received: by 2002:a9d:5a11:: with SMTP id v17mr15790535oth.87.1565714979723; Tue, 13 Aug 2019 09:49:39 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Tue, 13 Aug 2019 12:49:02 -0400 Message-ID: To: mathmesh@ietf.org, Christian Huitema Content-Type: multipart/alternative; boundary="0000000000002fae6d0590026df3" Archived-At: Subject: [Mathmesh] UDF Design notes X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 16:49:43 -0000 --0000000000002fae6d0590026df3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Discussing: http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html I try to avoid giving explanations in documents that contain normative text as this can be a source of ambiguity. So I will try to summarize the design concerns here. The original starting point was the need for a 'better PGP fingerprint'. In particular, I wanted a digest representation that was: * Reasonably compact in both printed and voiced form. * Supported use of SHA2 * Could be expressed at varying precision as the application needs demanded * Could be upgraded to make use of new algorithms if absolutely necessary * Could be input via a keyboard * Could be compared for equality * Could be used to create a fingerprint of any type of data (not just keys) * Support use in QR codes, DNS labels, etc. After a while I quickly realized I would also need to ensure that * UDFs could not be confused with OpenPGP fingerprints * A UDF of a key could not be confused with a UDF of a document or executable This led to the construct described in the document, i.e. * A binary UDF is an octet stream in which the first octet describes the digest algorithm used to create it. * The binary UDF is canonically presented in BASE32 The choice of Base32 comes from the observation that fingerprints are frequently read out aloud and having to distinguish case makes the process tedious and error prone. So it cant be Base64 but Base32 gives us five bits per char instead of four. The Type Identifiers for SHA-2 and SHA-3 are chosen so as to cause the first letter of a SHA-2 digest to always be an M (for Merkle-Damgard and to remind us of the Rivest/MD5 legacy) and tthe first letter of a SHA-3 digest will always be a K for Keccak. I have tried various groupings of digits and ended up choosing 4 because it makes the code least complex. A UDF content digest is a digest of a typed content sequence. First the Content Digest Value (CDV) is determined by applying the digest algorithm to the content data: CDV =3D H()) Then the Typed Content Digest Value (TCDV) is determined by applying the digest algorithm to the content type identifier and the CDV: TCDV =3D H ( + =E2=80=98:=E2=80=99 + CDV) The reason for this two step process is that while there are tens of thousands of content types in use, 99% of documents out there are of less than 50 content types. So if we have a fingerprint of a file and we are not sure what content type was intended, we can check the 50 most likely content types as quickly on a 1GB file as on a 1KB file. Finally, I started seeing that people have Bitcoin addresses of the form faceb-ookds-lkjh or whatever. Pretty kewl huh, the first letters of my key tells you who owns it? Erm no, what people have done there is provide a new attack vector because most people will only remember the first ten digits of an address at most and this mnemonic is encouraging people to assume from memory. Anyone who wants to impersonate the above, just needs to search for a public key whose first eight digits match and they will probably trick enough people to be interesting. So I decided to encourage people not to do this and then thought, what if they could have a shorter fingerprint that was just as strong. There is IETF precedent for this as Christian Huitema (ccd) can explain. There is unfortunately a patent to Microsoft. It is not clear that the MSFT patent covers my approach however and since they allowed a royalty free etc. license in the past, they might well in this instance. Having developed a spec for content digests, I quickly realized that my code was also generating a number of ASCII outputs that look like UDF fingerprints but were not content digests. So I decided to assign code points for the following: * Nonces (N) * Encryption keys (E) * MAC results (A) * Shamir Secret Share (S) These are the features I use in the Mesh and so I have a fairly good understanding of at least a partial set of requirements. But it is not necessarily a complete list. The two use cases that I am most tempted to add are representations for public and private key literals. PRO: One spec fits all. CON: Even 25519 keys are long do we read them out over the phone? Perhaps we should consider Base64? I have not decided on this yet and I don't have a use case. But I might when I get to thinking about TLS SNI encryption type things. I currently have two possible ways forward. The first is to add a Type indicator PKIX (112 =3D P) which would be followed by a PKIX KeyInfo block. This would be encoded in Base32. This would look something like this for an Ed25519 key: PB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4-SAQQ-RY7F-Q7UU-URHU-VCDB-HALY-LNCG The second would be to do the above in Base64 but use a type indicator that gives an initial letter in Base64: x-Z4lAx9fFvhzLO3a9RHGDPgtcwapxVCo_XdlAj1s1CPI I have no strong vies on this either way. --0000000000002fae6d0590026df3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dis= cussing:

http://mathmesh.c= om/Documents/draft-hallambaker-mesh-udf.html=C2=A0

=C2=A0

I try to avoid giving explanations in d= ocuments that contain normative text as this can be a source of ambiguity. = So I will try to summarize the design concerns here.

The original starting point was the need for a = 'better PGP fingerprint'. In particular, I wanted a digest represen= tation that was:

* Reason= ably compact in both printed and voiced form.

* Supported use of SHA2

* Could be expressed at varying pre= cision as the application needs demanded

* Could be upgraded to make use of new algorithms= if absolutely necessary

* Could be input via a keyboard

* Could be compared for equality

* Could be used to create a fi= ngerprint of any type of data (not just keys)

* Support use in QR codes, DNS labels, etc.<= /div>

After a while I quickly r= ealized I would also need to ensure that

* UDFs could not be confused with OpenPGP fingerprints

* A UDF of a key co= uld not be confused with a UDF of a document or executable

This led to the construct described in t= he document, i.e.

* A bin= ary UDF is an octet stream in which the first octet describes the digest al= gorithm used to create it.

* The binary UDF is canonically presented in BASE32=C2=A0

The choice of Base32 comes fro= m the observation that fingerprints are frequently read out aloud and havin= g to distinguish case makes the process tedious and error prone. So it cant= be Base64 but Base32 gives us five bits per char instead of four.

The=C2=A0Type Identifiers for SHA= -2 and SHA-3 are chosen so as to cause the first letter of a SHA-2 digest t= o always be an M (for Merkle-Damgard and to remind us of the Rivest/MD5 leg= acy) and tthe first letter of a SHA-3 digest will always be a K for Keccak.=

I have tried various gro= upings of digits and ended up choosing 4 because it makes the code least co= mplex.

A UDF content digest is a di= gest of a typed content sequence. First the=C2=A0Content Digest Value (CDV)= is determined by applying the digest algorithm to the content data:

<= div class=3D"gmail_default" style=3D"font-size:small">

CDV =3D H(<Data>))

Then the=C2=A0Typed Conten= t Digest Value (TCDV) is determined by applying the digest algorithm to the= content type identifier and the CDV:

TCDV =3D H (<Content-ID> + =E2=80=98:=E2=80=99 + CDV)

The reason for this two= step process is that while there are tens of thousands of content types in= use, 99% of documents out there are of less than 50 content types. So if w= e have a fingerprint of a file and we are not sure what content type was in= tended, we can check the 50 most likely content types as quickly on a 1GB f= ile as on a 1KB file.

Fin= ally, I started seeing that people have Bitcoin addresses of the form faceb= -ookds-lkjh or whatever. Pretty kewl huh, the first letters of my key tells= you who owns it?

Erm no,= what people have done there is provide a new attack vector because most pe= ople will only remember the first ten digits of an address at most and this= mnemonic is encouraging people to assume from memory. Anyone who wants to = impersonate the above, just needs to search for a public key whose first ei= ght digits match and they will probably trick enough people to be interesti= ng.

<= div class=3D"gmail_default" style=3D"font-size:small">So I decided to encou= rage people not to do this and then thought, what if they could have a shor= ter fingerprint that was just as strong.

There is IETF precedent for this as Christian Huitema (ccd)= can explain. There is unfortunately a patent to Microsoft. It is not clear= that the MSFT patent covers my approach however and since they allowed a r= oyalty free etc. license in the past, they might well in this instance.

Having developed a spec for content digests, I q= uickly realized that my code was also generating a number of ASCII outputs = that look like UDF fingerprints but were not content digests. So I decided = to assign code points for the following:

* Nonces (N)

* Encryption keys (E)

* MAC results (A)=C2=A0 =C2=A0

* Shamir Secret Share (S)

These are the features I use in the M= esh and so I have a fairly good understanding of at least a partial set of = requirements. But it is not necessarily a complete list.

The two use cases that I am most tempted to= add are representations for public and private key literals.=C2=A0

PRO: One spec fits all.=C2=A0<= /div>

CON: Even 25519= keys are long do we read them out over the phone? Perhaps we should consid= er Base64?

I have not dec= ided on this yet and I don't have a use case. But I might when I get to= thinking about TLS SNI encryption type things. I currently have two possib= le ways forward.

The firs= t is to add a Type indicator PKIX (112 =3D P)=C2=A0 which would be followed= by a PKIX KeyInfo block. This would be encoded in Base32. This would look = something like this for an Ed25519 key:

PB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4-SAQQ-RY7F-Q7UU-URHU-VCDB-= HALY-LNCG

<= br>

The second = would be to do the above in Base64 but use a type indicator that gives an i= nitial letter in Base64:

= x-Z4lAx9fFvhzLO3a9RHGDPgtcwapxVCo_XdlAj1s1CPI

I have no strong vies on this either way.

--0000000000002fae6d0590026df3-- From nobody Wed Aug 14 16:45:19 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E36E120901 for ; Wed, 14 Aug 2019 16:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i37uz7bXDCQm for ; Wed, 14 Aug 2019 16:45:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E5D1208E6 for ; Wed, 14 Aug 2019 16:45:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E57073818C for ; Wed, 14 Aug 2019 19:44:24 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 05FEFA8A for ; Wed, 14 Aug 2019 19:45:13 -0400 (EDT) From: Michael Richardson To: mathmesh@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Mathmesh] UDF Design notes X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 23:45:17 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker wrote: > The original starting point was the need for a 'better PGP fingerprint'. In > particular, I wanted a digest representation that was: > * Reasonably compact in both printed and voiced form. > * Supported use of SHA2 > * Could be expressed at varying precision as the application needs demanded > * Could be upgraded to make use of new algorithms if absolutely necessary > * Could be input via a keyboard > * Could be compared for equality > * Could be used to create a fingerprint of any type of data (not just keys) > * Support use in QR codes, DNS labels, etc. I think that this was a rather ambitious set of requirements :-) > The choice of Base32 comes from the observation that fingerprints are > frequently read out aloud and having to distinguish case makes the process > tedious and error prone. So it cant be Base64 but Base32 gives us five bits > per char instead of four. I agree with your use. I wonder if we can train people not to need to mention the case as they compare. I should look again if you specify upper-case only. > The Type Identifiers for SHA-2 and SHA-3 are chosen so as to cause the > first letter of a SHA-2 digest to always be an M (for Merkle-Damgard and to > remind us of the Rivest/MD5 legacy) and tthe first letter of a SHA-3 digest > will always be a K for Keccak. This was very cute. > Erm no, what people have done there is provide a new attack vector because > most people will only remember the first ten digits of an address at most > and this mnemonic is encouraging people to assume from memory. Anyone who > wants to impersonate the above, just needs to search for a public key whose > first eight digits match and they will probably trick enough people to be > interesting. > So I decided to encourage people not to do this and then thought, what if > they could have a shorter fingerprint that was just as strong. Interesting observation. > The two use cases that I am most tempted to add are representations for > public and private key literals. > PRO: One spec fits all. > CON: Even 25519 keys are long do we read them out over the phone? Perhaps > we should consider Base64? No, but being able to scan QR codes with public keys is important. DPP needs/uses this already. > The first is to add a Type indicator PKIX (112 = P) which would be > followed by a PKIX KeyInfo block. This would be encoded in Base32. This > would look something like this for an Ed25519 key: On the subject of Subject Key Identifier, which you have created a MIME type, RFC7469, section 2.4 also gets close to this. > PB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4-SAQQ-RY7F-Q7UU-URHU-VCDB-HALY-LNCG > The second would be to do the above in Base64 but use a type indicator that > gives an initial letter in Base64: I don't think that reading base64 over the phone will ever be a thing. Validating (visually) that a QR scan worked right will be a thing. I prefer to keep it all in base32. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1UnQgACgkQgItw+93Q 3WWScgf/WtLLf7Pg2cMxl729YnfB+WYjjwCpPU7MmTtcez8Fr9vedbayr/hwsoXu y37+pLlgT2CYaCMwVOdZ9xhdxVSNjqLCBQHuNAOytF34B76wXuUdwvXliQlSPCJ1 HizNqIsSLgnEsVx7NWGDSE4PuOw773Kp1wR1JnKSercVwGwtNXwh5QpLpt9NgqvH mrvdW3qQOtpFM2isLcHwHp/evEFpk8Ml3eJnbuzzP6laqu8drvFFfE7j8+9qJ3aq BE6hXa8WgDXkpZVzuioGV9dY55Dhq9YiKw+A4++axP/T3GUdF8JLlWFGZmiL+X+p /14v/+17tTi/Pms+agSZZcnADk/Ruw== =eDiW -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 14 16:54:59 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CB9120917 for ; Wed, 14 Aug 2019 16:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeuY3iEJzEgx for ; Wed, 14 Aug 2019 16:54:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489A4120901 for ; Wed, 14 Aug 2019 16:54:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C51B63818C; Wed, 14 Aug 2019 19:54:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DE9A9A8A; Wed, 14 Aug 2019 19:54:55 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker cc: mathmesh@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Mathmesh] Lets get started X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 23:54:59 -0000 --=-=-= Content-Type: text/plain Phillip Hallam-Baker wrote: > One of my greatest disappointments on the Web was that by the time Tim > assembled to team at CERN to fix HTTP, the exponent had already kicked in > and we were prisoners of the user base. So I have been holding off > deployment until at least I was happy with the way the system worked > together. This is now the third major redesign. > We will have to have some users before we can be sure we have a useful > spec. And having users does not mean we can't make breaking changes but we > will at least have to give them an upgrade path. So if anyone has a big > idea that is going to cause breaking changes, if they propose it now, there > will be no need for an upgrade plan which will make it simpler. I agree. We need running code to figure out if it works. So, a critical thing is to figure out what code should do when it sees version > expected-version. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1Un08ACgkQgItw+93Q 3WUo6wf/U0VWDUXpISwwjGA2O91TE4WUv+sV41IOu+G1HdK7XiTMUT2MGz7+F3zt 1xbxcAptjP9A/AWTpb3rbsoVhWxjoowo1FTkhxJjBLDLBEeygVWozU+guJbXTNvM 7hst7ympAoWZKSTdsBLvJplv2jcSJUH+/WL2d6EAv3Ogjv9TvbhIiSLw6KOeGT2J v2//ABS9GcO07wiXUBpU7K7XngbDixR4F9tKNTb6+Bd9VlHR78nMJNtijL8KxCYe nSb1YdUlOM8Gubk7NHJWQkJxxXsRYydt2tfN1mq5eh5WcYWO9cZNVkbVuW72Pl0E MEME9BWd0UbD+wQvrl0DvSe9z/phJw== =ypj5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 15 10:09:23 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F091200C1 for ; Thu, 15 Aug 2019 10:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxFAwXTTEHpu for ; Thu, 15 Aug 2019 10:09:20 -0700 (PDT) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186E7120074 for ; Thu, 15 Aug 2019 10:09:20 -0700 (PDT) Received: by mail-ot1-f51.google.com with SMTP id w4so7014796ote.11 for ; Thu, 15 Aug 2019 10:09:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bdF33XyAuCU/4AI08CnFonpIzGvQADVpC7fUrV/gj4A=; b=TBOtSnmQxev0AbQ2JD5Ug7Z4wm3susZvmC+t+1B9VeryrARv2GVwQA5uqusuMCi/zj nWAuL1xJjcGLJI056TtyFQjCzBxd21TgSf3XIvYCa3gSpBZfpCl8sS77z9Ine2TQD7pu h3RaH1D9tq+gYj/bSmq5y7lpZO4H6xKLyE0FAVVTfVMiHp7P3l8gnMmTaZwwuMIb8rab kwA3Csr4uZh9aaA2Njxq2sKraVe0D1dOixg6z8yqJWPEumEc5U+FlnxTOiGGf1IfLMfh OWnZFzVcpAQS0ibTk4vNbum7v9/zw6MOAnRI+mIIRygCS74Ns0Vfpt0hrFI6NDpQ8uvm HX9Q== X-Gm-Message-State: APjAAAX3qf0m8KCdgwzU0+7p8I5am2gvIvGLLYqgbgtRZLyUSv3qqSNu jXhwn9vFGzKb+kiCDfUZc/9GYFh9r6crx0cVsYg= X-Google-Smtp-Source: APXvYqy06J0McJa4qmuSmdh80JekFtI7Uh2vvvoQl7qRlj/UX6PmEb7a790GnBL0gENTKi6E3kJf8Sns/myj9YeChJ8= X-Received: by 2002:a05:6830:1e0f:: with SMTP id s15mr4586018otr.231.1565888959345; Thu, 15 Aug 2019 10:09:19 -0700 (PDT) MIME-Version: 1.0 References: <30023.1565826313@localhost> In-Reply-To: <30023.1565826313@localhost> From: Phillip Hallam-Baker Date: Thu, 15 Aug 2019 13:09:08 -0400 Message-ID: To: Michael Richardson Cc: mathmesh@ietf.org Content-Type: multipart/alternative; boundary="0000000000002dfbe705902aef42" Archived-At: Subject: Re: [Mathmesh] UDF Design notes X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 17:09:22 -0000 --0000000000002dfbe705902aef42 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 14, 2019 at 7:45 PM Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > The original starting point was the need for a 'better PGP > fingerprint'. In > > particular, I wanted a digest representation that was: > > > * Reasonably compact in both printed and voiced form. > > * Supported use of SHA2 > > * Could be expressed at varying precision as the application needs > demanded > > * Could be upgraded to make use of new algorithms if absolutely > necessary > > * Could be input via a keyboard > > * Could be compared for equality > > * Could be used to create a fingerprint of any type of data (not > just keys) > > * Support use in QR codes, DNS labels, etc. > > I think that this was a rather ambitious set of requirements :-) > Unless the requirements actually conflict, I would much rather make a decision for a reason even if it is not a very strong one than flip a coin. I don't have strong feelings on whether we should group the characters in blocks of 4, 5 or 3/5 or whatever. > > The choice of Base32 comes from the observation that fingerprints are > > frequently read out aloud and having to distinguish case makes the > process > > tedious and error prone. So it cant be Base64 but Base32 gives us > five bits > > per char instead of four. > > I agree with your use. > I wonder if we can train people not to need to mention the case as they > compare. I should look again if you specify upper-case only. > I am aiming for case insensitive because case is lost in a lot of contexts. The QR code spec specifies upper case (I think) but the tools almost invariably convert to lower. > > The Type Identifiers for SHA-2 and SHA-3 are chosen so as to cause > the > > first letter of a SHA-2 digest to always be an M (for Merkle-Damgard > and to > > remind us of the Rivest/MD5 legacy) and tthe first letter of a SHA-3 > digest > > will always be a K for Keccak. > > This was very cute. > The design constraint was that the fingerprints must not start with a hex digit so that UDF and PGP fingerprints remain distinct. > > > The two use cases that I am most tempted to add are representations > for > > public and private key literals. > > > PRO: One spec fits all. > > CON: Even 25519 keys are long do we read them out over the phone? > Perhaps > > we should consider Base64? > > No, but being able to scan QR codes with public keys is important. > DPP needs/uses this already. > If you want QR codes of the public keys, that would probably mean we should go for Base32. I would have to actually try it out but I think it turns out that Base32 maps onto the supported QR code encodings more efficiently than Base64. I don't think that reading base64 over the phone will ever be a thing. > Validating (visually) that a QR scan worked right will be a thing. > I prefer to keep it all in base32. > That is certainly my preference. I will add it into the draft once I have the sync bug I am chasing sorted. Given the existing code, I think I can probably hammer it out in a few hours because the code I use to take fingerprints of public keys is already using the PKIX keyinfo format. Lets break this out into a separate thread. Can you suggest the data flow? I am assuming here that this is so I can make a secure connection to a device over WiFi without Internet connectivity so the connection mechanism described in the doc isn't exactly going to work :). --0000000000002dfbe705902aef42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Aug 14, 2019 at 7:45 PM Michael Richardson = <mcr+ietf@sandelman.ca>= ; wrote:

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=C2=A0 =C2=A0 > The original starting point was the need for a 'bett= er PGP fingerprint'. In
=C2=A0 =C2=A0 > particular, I wanted a digest representation that was:
=C2=A0 =C2=A0 > * Reasonably compact in both printed and voiced form. =C2=A0 =C2=A0 > * Supported use of SHA2
=C2=A0 =C2=A0 > * Could be expressed at varying precision as the applica= tion needs demanded
=C2=A0 =C2=A0 > * Could be upgraded to make use of new algorithms if abs= olutely necessary
=C2=A0 =C2=A0 > * Could be input via a keyboard
=C2=A0 =C2=A0 > * Could be compared for equality
=C2=A0 =C2=A0 > * Could be used to create a fingerprint of any type of d= ata (not just keys)
=C2=A0 =C2=A0 > * Support use in QR codes, DNS labels, etc.

I think that this was a rather ambitious set of requirements :-)

Unless the requirements actually conflict, I would much rather make a= decision for a reason even if it is not a very strong one than flip a coin= .

I don't have strong= feelings on whether we should group the characters in blocks of 4, 5 or 3/= 5 or whatever.

=C2=A0

=C2=A0 =C2=A0 > The choice of Base32 comes from the observation that fin= gerprints are
=C2=A0 =C2=A0 > frequently read out aloud and having to distinguish case= makes the process
=C2=A0 =C2=A0 > tedious and error prone. So it cant be Base64 but Base32= gives us five bits
=C2=A0 =C2=A0 > per char instead of four.

I agree with your use.
I wonder if we can train people not to need to mention the case as they
compare.=C2=A0 I should look again if you specify upper-case only.

I am aiming for case insensitive because case is lost in a lot of c= ontexts. The QR code spec specifies upper case (I think) but the tools almo= st invariably convert to lower.

=C2=A0
=C2=A0 =C2=A0 > The Type Identifiers for SHA-2 and SHA-3 are chosen so a= s to cause the
=C2=A0 =C2=A0 > first letter of a SHA-2 digest to always be an M (for Me= rkle-Damgard and to
=C2=A0 =C2=A0 > remind us of the Rivest/MD5 legacy) and tthe first lette= r of a SHA-3 digest
=C2=A0 =C2=A0 > will always be a K for Keccak.

This was very cute.

The design constraint was that the fing= erprints must not start with a hex digit so that UDF and PGP fingerprints r= emain distinct.

If you want QR codes of the pu= blic keys, that would probably mean we should go for Base32. I would have t= o actually try it out but I think it turns out that=C2=A0Base32=C2=A0 maps = onto the supported QR code encodings more efficiently than Base64.

I don't think that reading base64 over the phone will ever be a thing.<= br> Validating (visually) that a QR scan worked right will be a thing.
I prefer to keep it all in base32.

That is certainly my pre= ference. I will add it into the draft once I have the sync bug I am chasing= sorted. Given the existing code, I think I can probably hammer it out in a= few hours because the code I use to take fingerprints of public keys is al= ready using the PKIX keyinfo format.

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 algorithm=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AlgorithmIdentifier,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 subjectPublicKey=C2=A0=C2=A0=C2=A0=C2=A0 BIT STRING=C2=A0 }

OK = so here is an Ed25519 key (including the algorithm identification OID) :

OAYC-4MAH-AYBS-WZLQ-AUAA-GI= YA-AQQE-E7UO-6QMY-7EGD-C63V-TROP-P2W5-HX6E-IDBE-YVJW-B4SY-GM5U-T2LF-7HQ

Presented in a QR code, we c= an drop the separators:

OAYC4= MAHAYBSWZLQAUAAGIYAAQQEE7UO6QMY7EGDC63VTROPP2W5HX6EIDBEYVJWB4SYGM5UT2LF7HQ= =C2=A0=C2=A0

The QR c= ode is reasonably compact either way.

I added this to the draft and pushed the new version:

http://mathmesh.com/Docu= ments/draft-hallambaker-mesh-udf.html=C2=A0=C2=A0

--0000000000009be60f05902f5321-- From nobody Thu Aug 15 17:24:12 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E708F120103; Thu, 15 Aug 2019 17:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDHDAWoQK-cz; Thu, 15 Aug 2019 17:24:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509B41200F3; Thu, 15 Aug 2019 17:24:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E2E563818C; Thu, 15 Aug 2019 20:23:14 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8C852788; Thu, 15 Aug 2019 20:24:04 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker cc: SPASM , mathmesh@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Mathmesh] pkix-keyinfo content type X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 00:24:10 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker wrote: > In brief, the idea is to allow a single fingerprint format to be used > to encode any content type without semantic substitution attacks. So = to > take the digest of a public key, we first generate the PKIX > SubjectPublicKeyInfo : > SubjectPublicKeyInfo ::=3D SEQUENCE { > algorithm AlgorithmIdentifier, > subjectPublicKey BIT STRING } > Then we take this octet stream and calculate: > H ( "application/pkix-keyinfo:" + H() ) > Where + is concatenation. This is not consistent with rfc5280 suggestion on how to create SubjectKeyI= dentifier. I've just been through how to specify a non-SHA-1 bound version of that, and RFC7469 section 2.4 has suggestions. As SubjectKeyIdentifier can be calculated by any suitable way and used if it is present, it's only for the case that it is not present that is a problem. Typically only CA:TRUE certificates are supposed to have it present. I'd like it to be present for all certificates. So your construction would be: H ( "application/pkix-keyinfo:" + SubjectKeyIdentifier ) and I think that is fine, as long as it does not cause confusion. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1V96QACgkQgItw+93Q 3WWonAgAhiDoEvKsQsqad13iAJLljqDCZrlbUtKvh6c/Nq4fhWd3zfNGgg9LjUeW 9jWzBEHYARFtQUsSziADExDVRV4mUvHg6g9d6/FXE9Peg8DbxSM60UhMm4WIrmxn AW51I+K81HlQpS+u8olNKBsaK6F3haDhpDzejLyReaXHeaJjzj6bhM/8XCAaPAtN abCqj07UA+BK9QDAwaF8P+R7/b/t26KErX3VPlYDiJC+4XnJ6y/tnIpb5aRG4aVL tZSIkaAQ98c1DVGIiyGFMmZaypOBfzMPVwXN7L6ePRe2t6KQ7O8GY2abe84Kxwv9 2HoYZ6/HQxr3VNuYshoAuIC8OPtNKw== =eTpn -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 15 17:32:32 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325B8120105 for ; Thu, 15 Aug 2019 17:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK1VTJdvoMhk for ; Thu, 15 Aug 2019 17:32:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1573D120103 for ; Thu, 15 Aug 2019 17:32:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6A5E43818C; Thu, 15 Aug 2019 20:31:38 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 173C3788; Thu, 15 Aug 2019 20:32:28 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker cc: mathmesh@ietf.org In-Reply-To: References: <30023.1565826313@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Mathmesh] UDF for onboarding X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 00:32:31 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker wrote: > Lets break this out into a separate thread. Can you suggest the data > flow? I am assuming here that this is so I can make a secure > connection to a device over WiFi without Internet connectivity so the > connection mechanism described in the doc isn't exactly going to work > :). DPP is https://www.wi-fi.org/discover-wi-fi/wi-fi-easy-connect and google can find you a copy of the document if you don't like their form. It is already defined. I am extending it in draft-richardson-anima-smarkaklink-01. I don't think that I (or Wi-Fi Alliance) have the opportunity to change to UDF at this point. Where I think it might still be useful is where the goal is not WiFi onboarding, but rather a proximity authorization. For instance, getting access to the thermostat or TV in a hotel room.=20 You won't get ownership, rather you'll get authorization to do some stuff. Some devices won't have screens that can display the QR code, and instead, a QR code will be printed on paper an attached. Yes, they will need to be changed regularly, but maybe UDF can help here. Being able to type the UDF into a computer, and/or read it over the phone would have some advantages, although I'm hard pressed to come up with a non-TV-computer-security-plot-theatre situation where that makes sense. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1V+ZsACgkQgItw+93Q 3WWraAgAsNONfPNfUO/8+JYHvbvjxfDiLikxF0C5is+XSbRy9zz3xVy3XXNGlZXb atG5AhmhdpMEW0Ow1cYeT4BxkUJeO037Wb8i8DF0GzW5iNq2EnJjKkbAe6A4LJP+ lq/bhaiGeRKA4rDD7bPBMhU2mf56hcst2oOMFiZ5zcYJryB6tj7d5Q06lVA4KzFJ 3+UlKMRnSyyIH0+w+flcdmh72MjIZ+61FGqCxYzyP9EFK74FDlw6Nzv4nO8pHC6F 3chm8T6qmrSD1TBuKi9q3BSHt+cuFYi7Wual+dgmPNYcnZVAZcVW6eMMWgsz6UxE 7ekHWtgZWo7qTx3/FmVSSR90jBlfxA== =fo/o -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 21 13:31:01 2019 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16551200A4; Wed, 21 Aug 2019 13:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TO_NO_BRKTS_PCNT=2.499, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INInJyQ7jscN; Wed, 21 Aug 2019 13:30:57 -0700 (PDT) Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C135120098; Wed, 21 Aug 2019 13:30:57 -0700 (PDT) Received: by mail-oi1-f193.google.com with SMTP id t24so2612391oij.13; Wed, 21 Aug 2019 13:30:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vWOcvxvMhRmDkEngm8f9l8v1JURhhJVlWZUUCaSteL4=; b=NdsK4y5X1Lfqrg/Jm9RuUxkPPf8mkWMG/BdCSQuag9PZNG+iWZjqFF41MyTQOungG6 RxeTDAco8aD+EV3pxelD7XeMeKJkVbaMoytBqiPIVQ0y0XYugXmJ8qZNSoVfu42iKWwr FTmeHzkcDVfEmMeeNGkpw/v6DzGdy8Jc6DqEXNCooPjZPMQNB5ZWjYOpqHZilExIXXYT uFEDbPIFfPC6yw/TX1BANtPtPuVkSKoWTsHjQKWhKNlO4XWRIOZf3TU7qJ+Wx9nIjANf siKFy/fnbgaqChE1NUYhfOiQyH6txYfMrcHp8G63cpUWlKbmQx4QERhW+qR3Py2SbvtA GyoA== X-Gm-Message-State: APjAAAVSEjl+sWqcJUDABeiI2KUF9PUt54N+fL3VdAubHBs52SOUn3Kj 440n1trL2Y4v5CWrlgezL9fPcYrtCe1OKqZzL6Y8VEVh X-Google-Smtp-Source: APXvYqx6eITPpSWAxj1PI5NHqzpMdcQIY0tdjI8WpZ7qWE/lQ+6lNWEaXeMU4GPx9vK9Ep/tkr6yDytqBCUJyMARIyY= X-Received: by 2002:aca:2818:: with SMTP id 24mr1442749oix.100.1566419456454; Wed, 21 Aug 2019 13:30:56 -0700 (PDT) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Wed, 21 Aug 2019 16:30:44 -0400 Message-ID: To: mathmesh@ietf.org, jose@ietf.org Content-Type: multipart/alternative; boundary="0000000000004575a80590a67335" Archived-At: Subject: [Mathmesh] DARE: PKCS#7, Blockchain in JSON/JOSE X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 20:31:00 -0000 --0000000000004575a80590a67335 Content-Type: text/plain; charset="UTF-8" [cc's to the JOSE list since this is extending JOSE] UDF is one of the Mesh technologies that could be used independently to build other systems. DARE is another. The spec is available from the IETF tools or in HTML form as: http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html This format is used within the Mesh protocols to support authentication at the Message and presentation layers. It is also used as the basis for the Mesh persistence stores such as an end-to-end encrypted password catalog. Using append only logs authenticated by means of a Merkle tree as the basis for the persistence model turns out to be very powerful. Devices, Passwords, Tasks are added to or removed from a catalog by adding entries to a log. The same approach is used to implement message spools, the approach bearing some similarity to ideas used in the IBM CICS system (or at least my interpretation of said system as described in a conversation mediated by many pints of Marstons) The same approach could be applied to many other applications. For test purposes only, I developed a ZIP archive type format out of it which seems to be functional. I am also planning to use this format to encrypt the logs kept by Mesh Services. The incremental encryption scheme avoids the need to perform a key agreement for every incremental update which would slow down reading and writing greatly and bloat the log size. A process need only perform a key exchange when it starts writing to the log and refresh it as policy dictates (e.g hourly). Also two different processes can write to the same log simultaneously, encrypting their entries under different key agreements. The starting point for the design was the observation that the Mesh needs a PKCS#7/CMS type cryptographic envelope and a Merkle Tree type authentication mechanism. As I worked on the two independently, I realized that instead of there being two systems, these needed to be designed to work together so that a series of envelopes could be concatenated in an append only log to make a stack or container. The result is DARE which applies the work of JSON Signature and Encryption but with some restrictions. I am a big fan of the Rails part of Ruby on Rails. Sticking to one way to identify things and applying it consistently is very powerful. DARE requires that every key be identified by its UDF fingerprint and only its UDF fingerprint. Any other information (certificates, SAML assertions, the key value etc. is merely provided to assist). So first design decision, why JSON? 1) No matter how much argument is made, a solid majority of IETF-ers despise ASN.1 and will refuse to do any new project based on ASN.1 2) JSON is clearly the favorite data serialization at present and has clear advantages over XML while allowing for a document-friendly text encoding. 3) The main drawback to JSON is the lack of a binary encoding. This is not actually much of a problem for the Mesh as the data items are actually quite small. So the decision made was to make use of JSON and address the encoding efficiency issue by proposing an OPTIONAL extension to JSON encoding that drops in length/ prefixed data sequences for binary and character data: http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html The reason I prefer extending JSON to moving to CBOR is that extending JSON means that an implementation can use a single decoder for JSON and JSON-B. That greatly simplifies the design of the code and removes the need to negotiate encodings and the number of different code paths to test. Another, secondary issue is that I wanted to be able to encode streams of data without buffering. This meant I had to extend any of the options on offer io The second big concern was how to support separate encryption of a content body and related content data in a secure and flexible fashion. Consider the S/MIME problem of encrypting the subject line on a message with a powerpoint document of 3MB. It is obvious we want to encrypt the subject line for security. It is also obvious that we don't want to have to decrypt the whole document just to read the subject line. And for proper hygiene, I want each piece of data encrypted under a completely different key. The approach I took was to make use of KDF to generate encryption keys, MAC keys and IVs. One concern that was raised is that it is frequently desirable to erase information such as a file from a container. Overwriting a 3MB powerpoint file with zeros means modifying a large chunk of the file and does not provide atomicity. Most O/S will guarantee that a 32KB file update is atomic but no more. To overcome this issue, I introduced the option of adding in a nonce as a mix-in to the KDF. If a process needs to delete an entry, they only need to erase the nonce and the whole encrypted file becomes unrecoverable. This in turn lead to the idea of incremental encryption. If I have a sequence of envelopes, I can use a single key exchange to generate a master key which is then used together with a unique nonce per as input to the KDF used to encrypt each envelope. The envelope format is designed to support single pass, unbuffered encoding with optional encryption and authentication. Each envelope has a header (required), a body and an optional trailer. The container format is almost just a sequence of enveloped but with one important twist. Each envelope begins and ends with a length indicator. And the final length indicator is written in reverse (another break with CBOR). This approach makes it possible to read containers in either the forward or reverse direction with equal efficiency. This is very useful because 90% of the time, the most interesting material in an append only log file is to be found at or near the end. The spec proposes that processes could periodically add indexes to a container allowing O(1) retrieval of specific records by index. This has not (yet) been implemented. While the DARE format was originally designed to allow the use of the meta-cryptography techniques I am using in the Mesh, it does not actually introduce any new crypto. This is because the split key techniques I use affect the implementation of decryption. The encryption approach is unchanged. --0000000000004575a80590a67335 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

[cc= 's to the JOSE list since this is extending JOSE]

UDF is one of the Mesh technologies that could= be used independently to build other systems. DARE is another. The spec is= available from the IETF tools or in HTML form as:

http://mathmesh.com/Documents/draft-hallambaker-m= esh-dare.html=C2=A0

=C2=A0

This format is used within the Mesh protocols to support authenticatio= n at the Message and presentation layers. It is also used as the basis for = the Mesh persistence stores such as an end-to-end encrypted password catalo= g.

Using append only logs= authenticated by means of a Merkle tree as the basis for the persistence m= odel turns out to be very powerful. Devices, Passwords, Tasks are added to = or removed from a catalog by adding entries to a log. The same approach is = used to implement message spools, the approach bearing some similarity to i= deas used in the IBM CICS system (or at least my interpretation of said sys= tem as described in a conversation mediated by many pints of Marstons)

The same approach could be ap= plied to many other applications. For test purposes only, I developed a ZIP= archive type format out of it which seems to be functional. I am also plan= ning to use this format to encrypt the logs kept by Mesh Services. The incr= emental encryption scheme avoids the need to perform a key agreement for ev= ery incremental update which would slow down reading and writing greatly an= d bloat the log size. A process need only perform a key exchange when it st= arts writing to the log and refresh it as policy dictates (e.g hourly). Als= o two different processes can write to the same log simultaneously, encrypt= ing their entries under different key agreements.=C2=A0

The starting point for the design was the observation = that the Mesh needs a PKCS#7/CMS type cryptographic envelope and a Merkle T= ree type authentication mechanism. As I worked on the two independently, I = realized that instead of there being two systems, these needed to be design= ed to work together so that a series of envelopes could be concatenated in = an append only log to make a stack or container.

The result is DARE which applies the work of JSON S= ignature and Encryption but with some restrictions. I am a big fan of the R= ails part of Ruby on Rails. Sticking to one way to identify things and appl= ying it consistently is very powerful. DARE requires that every key be iden= tified by its UDF fingerprint and only its UDF fingerprint. Any other infor= mation (certificates, SAML assertions, the key value etc. is merely provide= d to assist).

<= br>

So first de= sign decision, why JSON?

= 1) No matter how much argument is made, a solid majority of IETF-ers despis= e ASN.1 and will refuse to do any new project based on ASN.1

2) JSON is clearly the favorite data se= rialization at present and has clear advantages over XML while allowing for= a document-friendly text encoding.

3) The main drawback to JSON is the lack of a binary encoding. T= his is not actually much of a problem for the Mesh as the data items are ac= tually quite small.

So th= e decision made was to make use of JSON and address the encoding efficiency= issue by proposing an OPTIONAL extension to JSON encoding that drops in le= ngth/ prefixed data sequences for binary and character data:

http://mathmesh.com/Documents/draft-halla= mbaker-jsonbcd.html=C2=A0=C2=A0

The reason I prefer extending JSON to moving to CBOR is that= extending JSON means that an implementation can use a single decoder for J= SON and JSON-B. That greatly simplifies the design of the code and removes = the need to negotiate encodings and the number of different code paths to t= est.

Another, secondary i= ssue is that I wanted to be able to encode streams of data without bufferin= g. This meant I had to extend any of the options on offer io

The second big concern was how to support separat= e encryption of a content body and related content data in a secure and fle= xible fashion. Consider the S/MIME problem of encrypting the subject line o= n a message with a powerpoint document of 3MB. It is obvious we want to enc= rypt the subject line for security. It is also obvious that we don't wa= nt to have to decrypt the whole document just to read the subject line. And= for proper hygiene, I want each piece of data encrypted under a completely= different key.

The appro= ach I took was to make use of KDF to generate encryption keys, MAC keys and= IVs.

One concern that wa= s raised is that it is frequently desirable to erase information such as a = file from a container. Overwriting a 3MB powerpoint file with zeros means m= odifying a large chunk of the file and does not provide atomicity. Most O/S= will guarantee that a 32KB file update is atomic but no more.=C2=A0

<= div class=3D"gmail_default" style=3D"font-size:small">

To overcome this issue, I intr= oduced the option of adding in a nonce as a mix-in to the KDF. If a process= needs to delete an entry, they only need to erase the nonce and the whole = encrypted file becomes unrecoverable.

This in turn lead to the idea of incremental encryption. If I = have a sequence of envelopes, I can use a single key exchange to generate a= master key which is then used together with a unique nonce per as input to= the KDF used to encrypt each envelope.

The envelope format is designed to support single pass, unbuffered enc= oding with optional encryption and authentication. Each envelope has a head= er (required), a body and an optional trailer.=C2=A0

The container format is almost just a sequence = of enveloped but with one important twist. Each envelope begins and ends wi= th a length indicator. And the final length indicator is written in reverse= (another break with CBOR).

This approach makes it possible to read containers in either the forward= or reverse direction with equal efficiency. This is very useful because 90= % of the time, the most interesting material in an append only log file is = to be found at or near the end.

The spec proposes that processes could periodically add indexes to a= container allowing O(1) retrieval of specific records by index. This has n= ot (yet) been implemented.

While th= e DARE format was originally designed to allow the use of the meta-cryptogr= aphy techniques I am using in the Mesh, it does not actually introduce any = new crypto. This is because the split key techniques I use affect the imple= mentation of decryption. The encryption approach is unchanged.

--0000000000004575a80590a67335--