messages if you could say something about how you fit into
the openpgp universe (e.g. "I wrote the foo implementation"
I run a thing with 50-200 people using PGP, all scattered GnuPG
implementations. At some level I care about GnuPG cross-version
compatibility, and have little need for a standard for today's needs.
I would like to have an OpenPGP-like standard for authentication and
secrecy of detached objects---for example, for subresource integrity on
the Web, and in ways that support and cooperate with TLS trust models.
I am hopeful but not optimistic about JOSE getting this right in its
first years.
Both of those would be improved by standardized support for modern
cryptographic choices, and for getting past some of the older choices
that haven't held up well.
Therefore, I prefer option 2. I'd be happy with the eventual results of
option 3, but I expect it to take an awfully long time. I don't think
option 4 is helped by standardization---yet.
option 2t: option 2 + add some trust model/key management
option 3t: option 3 + add some trust model/key management
option 4t: option 4 + add some trust model/key management
I value having a *different* trust model than X.509/TLS in the space of
available designs.
I'm not sure whether that means (t): it's good to have a standard way of
endorsing a binding of name to key, and it's good to have a standard
language for use in describing names. A finer grain for user ID packets
would be nice. If that's a (t) conversation, then I think [2t,3t] is
wise. Otherwise, [2,3], in that order.
-Brian
For options 3, 3t, 4 or 4t I do think we'd likely need to
have a face-to-face BoF meeting as there'd be a lot to
consider and pin down and higher bandwidth is much better
for that. In that case, the important date is June 5th
which is the next cutoff date for requesting such a meeting
for the Prague IETF to be held July 19-24. [1] (June 5th
might seem like a long way off, but it's not really so if
we needed such a meeting then starting to work towards that
soon would be much better than doing so late.)
Also, some of this can be done sequentially. For example,
as an area director I'm very happy re-chartering existing
working groups to add more tasks where those groups have
demonstrated the ability to be productive. In my experience
that can work better than starting out with the hard/ambitious
stuff as the very first thing to do. That might argue for
starting with option 2 and then, if all goes well, discussing
whether or how to tackle option 3 or 4. (We could even charter
a group to do the maintenance work for option 2 and when that's
done to then discuss how to re-charter for one of the more
complicated choices.) I'd suggest however, we ignore such
sequential processing for now, see what folks prefer as a
goal, and then think about whether there's a way to get to
what people want via sequencing things cleverly. So, just
for now, please don't suggest "2, followed by 3" even if
that's something you like the sound of - I think folks'
initial responses will probably make it obvious if we need
a chat about that.
And lastly, please let's not have an IETF process discussion
or a discussion about why the IETF is great or crap. If we
see that there's IETF stuff folks want to do and if those
folks are willing and able to implement/deploy the results
then that's enough to be going on with.
Thanks,
S.
[1] https://www.ietf.org/meeting/important-dates-2015.html#ietf93
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
--
Brian Sniffen
Akamai Technologies
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp