StartCom Web of Trust

September 20, 2006

Perceived Value of Certs vs PGP

Filed under: Uncategorized — startssl @ 4:25 pm

I really want peoples comments on this post.

A bit of information, Class levels for certificates are loosely agreed upon by the CA market, but the checking done varies radically between CAs. That being said, certificate class levels are as follows:

  1. Email address verified.
  2. Reasonable checking
  3. Thorough checking
  4. Government level checking
  • What level of trust do you assign the different class levels of certificates?
  • Do you trust the CA to follow through?
  • Does Class 1 certification with “Community validation” mean anything, even if it has OID metadata to support this claim.
  • Does a certificate mean anything more to you than a PGP key?
  • PGP keys can show you who signed the key, does a PGP cert from CAcert or GSWoT mean anything to you?
  • Does a certificate attached to a PGP key mean anything to you?
  • Do you trust PGP or CAs more? if PGP, do you know that a CA generally insures its certificates, do you care?

All of these questions are based around the question being kicked around.  Do class 1 certs mean anything and can they be made to be meaningful?

While the PGP questions seem unrelated, my premise is that PGP keys can’t TRULY be trusted unless you validate the person yourself, otherwise it is really only good for anonymous or psuedo-anonymous transactions. And that the only possible piece of data worth being trusted on a PGP key is the email address.  This puts it (at least in my eyes) on par with a class 1 certificate.

5 Comments »

  1. * What level of trust do you assign the different class levels of certificates?

    It all depends on the use for the certificate. At the base level, it shows that the person I am communicating with now, is the same person I communicated with yesterday. Class 1 is more than good enough for that. Obviously this assumes the person holding the certificate is responsible for its protection, etc. If I were relying upon it for a business transaction with someone I don’t know personally, I’d want at least class 3, if not class 4 in order to trust the identity.

    * Do you trust the CA to follow through?

    It depends on the CA. There are a ton of CAs out there that don’t even require anything for ID. I can generate a certificate and technically I am then a CA. It comes down to the ability to verify their procedures.

    * Does Class 1 certification with “Community validation” mean anything, even if it has OID metadata to support this claim.

    If it is based on a point system, then as the person gains points, the chances of fraud go down. There could always be a group of people who have enough points between them to get around this, but it would likely be discovered rather quickly.

    * Does a certificate mean anything more to you than a PGP key?

    See answer to the first question, it just depends on the particular use.

    * PGP keys can show you who signed the key, does a PGP cert from CAcert or GSWoT mean anything to you?

    To me it says not only have the individual users listed signed the keys, but another (separate but not necessarily exclusive) web of trust has acknowledged the identity of the person.

    * Does a certificate attached to a PGP key mean anything to you?

    As it stands, this is primarily a function of the commercial PGP software, not GnuPG. The newer versions will support it, so time will tell. To me it would be the same as CA signing the key with its own PGP key.

    * Do you trust PGP or CAs more? if PGP, do you know that a CA generally insures its certificates, do you care?

    Well, I’m not one to put much faith in insurance companies or policies, so it really doesn’t matter much to me. There are generally so many loopholes and contradictions in insurance contracts that a claim is usually invalidated before it is submitted.

    Now if there is an insurance company behind a CA that will actually abide by the spirit of the contract and cover legitimate claims, then I would probably tend to trust the insured CA over a PGP key for any business related activity.

    As of right now, I don’t trust any keys, pgp nor x.509 certificates, for business use unless I personally have met with the person and have verified their ID. The only exception in this is if I know one (or more) of the signers of a pgp key, and trust them to properly ID the person. I guess in that aspect you could draw the conclusion that I currently trust PGP more. Now if the CAs exposed web-of-trust signatures for inspection, I could trust them equally if I trust the signers of a particular person.

    Jeremy

    Comment by Jeremy H — September 20, 2006 @ 4:57 pm

  2. > * Does Class 1 certification with “Community validation” mean anything, even if it has OID metadata to support this claim.

    >If it is based on a point system, then as the person gains points, the chances of fraud go down. There could always be a group of people who have enough points between them to get around this, but it would likely be discovered rather quickly.

    => well, it’s good reminder for a concept : programming a robot to parse the whole WoT to find out cheaters. In Thawte case, it’s a tree, you can use some algo, but in CAcert case you can do cross checking, you can get loops, then it will require (if possible) more computations to find cheaters.

    OK, back to your question : PGP (with certs) and x509 are just tools to bring/hold a certain amount of trust.

    The one or the other have interests/defects but x509 is more implemented for daily use for common people. My choice : x509

    Comment by Guillaume — September 20, 2006 @ 8:42 pm

  3. I agree with Jeremy almost word for word, here’s where I don’t:

    * What level of trust do you assign the different class levels of certificates?

    Class 1 is just an automated email ping, it’s of no value unless I know the user for real
    Class 2 good enough for most everyday uses, common purchases etc.
    Class 3 good enough for anything really.
    Class 4 overkill for most everything

    * Does Class 1 certification with “Community validation” mean anything, even if it has OID metadata to support this claim.

    It depends what you mean by “Community validation”, if you mean face-to-face like CAcert or GSWoT, then it’s no longer class 1, it’s class 3! If it’s not face-to-face then it might be class 2 if documentation is checked from a distance. “Community validation” is at least as good as a commercial CA, usually better!

    * Does a certificate mean anything more to you than a PGP key?

    It depends who signed it–could be better, could be worse. If you need a server cert then you can’t use GPG.

    * PGP keys can show you who signed the key, does a PGP cert from CAcert or GSWoT mean anything to you?

    I assume you mean a signature from GSWoT or CAcert, Yes! Absolutely! They are both far better than most commercial CA’s!

    * Does a certificate attached to a PGP key mean anything to you?

    Depends entirely on who issued the cert.

    * Do you trust PGP or CAs more? if PGP, do you know that a CA generally insures its certificates, do you care?

    I prefer GPG for communication, but servers need CA.

    Comment by Lance W. Haverkamp — September 20, 2006 @ 10:20 pm

  4. If a Notary can be trusted to do what they are supposed to, then it would be class 3 or even class 4. Considering that volunteer Notary/Assurers with no financial liability can’t be trusted to do as required, then the assertions these people make are merely suggestions. Thus the certs can’t even be called level 2, nor can they be insured that way.

    The only way assertions of volunteers could be taken seriously is if the volunteer were to buy a bond to cover the breach of contract, just exactly like a Notary Public. Errors and Omissions insurance would also be nice. However these things may be difficult to come up with outside of the US, also some people feel it is unfair to ask volunteers to do this. My opinion is that if you want me to to trust your assertion, then “put your money where your mouth is”.

    Comment by startssl — September 20, 2006 @ 10:37 pm

  5. These questions all seem to be searching for a schism between PGP and PKI. That’s a false distinction; they are both technologies that more or less provide support for statements made by one party about another party. The concept is bigger than the tech, and the tech hasn’t been able to be made big enough to fill out the concept.

    PKI (x.509/CA is what I mean by PKI) provides a hierarchical structure with CAs presumably making reliable statements. Yet, nobody knows what those statements are, so the technology doesn’t deliver what it promises. See my long long long paper on “PKI considered harmful” http://iang.org/ssl/pki_considered_harmful.html for more on how all this falls apart. Did I say it was long?

    PGP provides a network to make reliable statements. Yet, the technology doesn’t say what and where to place the statement, so the technology doesn’t deliver the promise. PGP says you can sign my key, but it doesn’t ever ask you what you mean when you sign my key — you know me? You don’t know me? I’m trustworthy? I’m married to your sister? I’m a terrorist? I’m all of them, all together?

    More fairly, PGP doesn’t deliver the PKI promise, because the PKI promise isn’t realistic to copy. PKI doesn’t deliver the PGP promise because to do so would break the hierarchical structure, something that is considered to be beyond question to the insiders.

    Where are we left in all that? The relying party is SOL. She has to read the CPS and understand the detail, so the only statements she can rely on are those that she is familiar with … which leads us inexorably to the “you trust what you know” methodology, without any objective test of what it is you might know. So, trusting Verisign works if you already trust Verisign. Trusting CAcert is equally stable, and trusting PGP WoT works fine .. if you already trust it.

    Comment by Iang — September 21, 2006 @ 4:34 am


RSS feed for comments on this post. TrackBack URI

Leave a comment

Blog at WordPress.com.