[openpgp] What to put in a JSContact entry

--===============8752506178351695625==
Content-Type: multipart/alternative; boundary="00000000000073ea440652d3182e"

--00000000000073ea440652d3182e
Content-Type: text/plain; charset="UTF-8"

CALEX has adopted my draft to improve representation of public keys in
contact files. JSContact borrows its approach from vCard which was designed
long ago when OpenPGP was only used for email. Today OpenPGP is used for
many things and a contact card entry should allow the user as much
flexibility as they need.

Since JSContact is JSON Contacts, it seems best to me that we use the
greater expressivity of JOSE to describe keys. Another very critical change
is that a JSContact can specify a signature key for verifying updates to
the contacts and one or more means of retrieving them. What this means is
that if Alice and Bob exchange contact information once, they get
authenticated updates forever.

https://www.ietf.org/archive/id/draft-hallambaker-jscontact-00.html

Rather than design it myself and get it wrong, I would prefer that the WG
tells me what the ideal representation should be in their view.

Another change is that we are now doing PQC and so public keys are a lot
larger. One approach to addressing that is the EARL mechanism I have also
proposed which allows an encrypted static document to be linked by means of
a compact URL. I will come back to that in a moment.

Some use cases to clarify:

Alice uses OpenPGP to secure her emails and sign commits to her personal
GItHub repo. She has a Primary Key which she only uses to sign subkeys and
separate keys for each task, all signed by the primary.

Bob has a similar setup to Alice but he is a member of multiple projects
and uses a separate signature key for each.These are maintained as separate
hierarchies with a different primary key for each one.

So there are thedesign challenges as I see it:

1) What OpenPGP information to provide, key? fingerprint? certificate?
1a) If information is abbreviated, how to tell applications what they will
get if they resolve a link to a package containing more information.

2) How to label keys for different application purposes.

On the first, I think we want as much information as possible so that goes
to certificates.

On the second, I am thinking the JSContact emails and onlineService objects
are the containers to use. We may want to extend the onlineServices object
to specify an identifier from a registry of applications.

Will try to get some examples out to maybe clarify things but am trying not
to bias the approach.


Comments?

--00000000000073ea440652d3182e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">CAL=
EX has adopted my draft to improve representation of public=C2=A0keys in co=
ntact files. JSContact borrows=C2=A0its approach from vCard which was desig=
ned long ago when OpenPGP was only used for email. Today OpenPGP is used fo=
r many things and a contact card entry should allow the user as much flexib=
ility as they need.</div><div class=3D"gmail_default" style=3D"font-size:sm=
all"><br></div><div class=3D"gmail_default" style=3D"font-size:small">Since=
 JSContact=C2=A0is JSON Contacts, it seems best to me that we use the great=
er expressivity=C2=A0of JOSE to describe keys. Another very critical change=
 is that a JSContact can specify a signature key for verifying updates to t=
he contacts and one or more means of retrieving them. What this means is th=
at=C2=A0if Alice and=C2=A0Bob exchange contact information once, they get a=
uthenticated updates forever.</div><div class=3D"gmail_default" style=3D"fo=
nt-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size:sm=
all"><a href=3D"https://www.ietf.org/archive/id/draft-hallambaker-jscontact=
-00.html">https://www.ietf.org/archive/id/draft-hallambaker-jscontact-00.ht=
ml</a></div><div class=3D"gmail_default" style=3D"font-size:small"><br></di=
v><div class=3D"gmail_default" style=3D"font-size:small">Rather than design=
 it myself and get it wrong, I would prefer that the WG tells me what the i=
deal representation should be in their view.</div><div class=3D"gmail_defau=
lt" style=3D"font-size:small"><br></div><div class=3D"gmail_default" style=
=3D"font-size:small">Another change is that we are now doing PQC and so pub=
lic keys are a lot larger. One approach to addressing that is the EARL mech=
anism I have also proposed which allows an encrypted static document to be =
linked by means=C2=A0of a compact URL. I will come back to that in a moment=
.</div><div class=3D"gmail_default" style=3D"font-size:small"><br></div><di=
v class=3D"gmail_default" style=3D"font-size:small">Some use cases to clari=
fy:</div><div class=3D"gmail_default" style=3D"font-size:small"><br></div><=
div class=3D"gmail_default" style=3D"font-size:small">Alice uses OpenPGP to=
 secure her emails and sign commits to her personal GItHub repo. She has a =
Primary Key which she only uses to sign subkeys and separate keys for each =
task, all signed by the primary.</div><div class=3D"gmail_default" style=3D=
"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size=
:small">Bob has a similar setup to Alice but he is a member of multiple pro=
jects and uses a separate signature key for each.These are maintained as se=
parate hierarchies with a different primary key for each one.</div><div cla=
ss=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"gmai=
l_default" style=3D"font-size:small">So there are thedesign challenges as I=
 see it:</div><div class=3D"gmail_default" style=3D"font-size:small"><br></=
div><div class=3D"gmail_default" style=3D"font-size:small">1) What OpenPGP =
information to provide, key? fingerprint? certificate?</div><div class=3D"g=
mail_default" style=3D"font-size:small">1a) If information is abbreviated, =
how to tell applications what they will get if they resolve a link to a pac=
kage containing more information.</div><div class=3D"gmail_default" style=
=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-s=
ize:small">2) How to label keys for different application purposes.</div><d=
iv class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=
=3D"gmail_default" style=3D"font-size:small">On the first, I think we want =
as much information as possible so that goes to certificates.</div><div cla=
ss=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"gmai=
l_default" style=3D"font-size:small">On the second, I am thinking the=C2=A0=
JSContact emails and onlineService=C2=A0objects are the containers to use. =
We may want to extend the onlineServices object to specify an identifier fr=
om a registry of applications.</div><div class=3D"gmail_default" style=3D"f=
ont-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size:s=
mall">Will try to get some examples out to maybe clarify things but am tryi=
ng not to bias the approach.</div><div class=3D"gmail_default" style=3D"fon=
t-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size:sma=
ll"><br></div><div class=3D"gmail_default" style=3D"font-size:small">Commen=
ts?</div><div class=3D"gmail_default" style=3D"font-size:small"><br></div><=
/div>

--00000000000073ea440652d3182e--


--===============8752506178351695625==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt
YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt
YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK

--===============8752506178351695625==--