ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Opening up the debate on PKI / WoT / future of OpenPGP

2015-04-24 14:51:31
What I would like to see is a clear semantic and syntactic separation
between first and third party assertions.

I am aware that Symantec bought PGP, but it is still the name of Phil
Z.'s model.


PKIX and OpenPGP both conflate the two. But there is a big difference
between them when it comes to trust issues. A first party assertion
such as a PKIX root signing an intermediate is a direct assertion and
can be modeled in the same manner as a finger print. The only
assumptions I am making are that the crypto isn't broken and the key
holder has not lost control of their key.

Third party assertions are much more complex and problematic. We get
into recursion issues and fixed points on contraction mappings and all
the math stuff.


Neither PKIX nor OpenPGP really provide the end user with the full set
of tools needed to do comprehensive key management. The PKIX model is
that the user does not have a persistent key history at all, the CA is
the only party managing this. OpenPGP takes the UNIX/C attitude of
give the users a sharp knife and blame them when they cut themselves.


On Fri, Apr 24, 2015 at 3:09 PM, Jon Callas <jon(_at_)callas(_dot_)org> wrote:
Okay, turning off my smartass mode for a moment.

PGP does this. By the way, PGP is registered trademark owned by Symantec. 
They presently call that software "Symantec Endpoint Encryption" and 
"Symantec Encryption Management Server" but that's PGP.

OpenPGP is an IETF standard for describing crypto syntax and protocols.

X.509 and OpenPGP are isomorphic to each other. You can do anything in one of 
them that you can do in the other. If you take an OpenPGP key, you can 
express the same thing with a set of X.509 certificates. It works. We did it. 
PGP does OpenPGP, X.509, CMS and S/MIME.

You can do it. You just have to want to.

Yep. And I suspect that pretty much anyone that is doing a key
management app will do the same.

It is really easy to roll the same set of assertions in multiple
syntaxes. And that is necessary to solve a lot of real world use
cases. I have just bought a QNAP server, it has SSL but does not have
a CA issued cert so I get browser warnings.

I should be able to snap that server into my personal PKI keychain and
have it 'just work' and the protocol for doing that should be no
different to the protocol for setting up my email client or my Web
browser. And I should be able to do that without having to wait for
S/MIME or PGP to win the email format wars or TLS to support PGP
certs.


It is quite possible to express the full functionality of PKIX in a
far more compact form. That is what I was originally commissioned to
do by VeriSign in what became XKMS and SAML. TAXI was only about 30
pages long and it did everything the WebPKI does using PKIX. Just
instead of OCSP and SCVP and CRLs these were all expressed as
assertion validity conditions.

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp