Subject: Re: [pkix] End-entity self-signed certs

From: Peter Gutmann <[email-masked]>
Date: Thu, 17 Nov 2011 16:14:07 +1300

"Miller, Timothy J." <tmiller at mitre.org> writes:

>The only trustable content in a self-signed certificate is the public key,
>and only when that key is verified by the signature.
>
>*Nothing* else in that cert has any meaning.  The signer can lie about
>everything *except* his possession of the private key.

What a strange view of trust.  If I get a certificate directly from you, I
know that what's in there is exactly what you choose to put in there, and I
can trust it as much as I trust you.  If I get a certificate purporting to be
yours from a CA then all I can be sure of is that at some point a payment to
the CA cleared, possibly from a stolen credit card or bank account.

Nothing in a CA-issued cert has much meaning (because the card used to buy it
could be stolen, I can't even be sure that payment was made).  OTOH I can
trust everything in a self-signed cert obtained from you as much as I trust
you, which seems to be a good match.

Peter.

PS: For anyone who thinks CA certs are more trustworthy than self-signed ones,
    I have a little executable I can send you that you can run on your 
    personal PC/laptop.  You can trust it, it's been signed with a CA-issued 
    cert for the Malaysian government.

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 17 Nov 2011 09:06:23 -0500

Sorry, but I'd trust the certs on Tim's CA-issued common access card
before I'd trust something Tim handed me himself.  Nothing personal, you
understand; I'm sure the feeling is mutual :-).

Most PGP keys aren't obtained at a key-signing party, and most
self-signed X.509 certs aren't obtained face-to-face, but at the end of
a path in a TLS handshake.  If there are out-of-band means of trust
(such as f2f, or an independent-channel fingerprint), great.  If not,
the cert isn't worth a warm bucket of spit.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Gutmann
Sent: Wednesday, November 16, 2011 10:14 PM
To: [email-masked]
Subject: Re: [pkix] End-entity self-signed certs

"Miller, Timothy J." <tmiller at mitre.org> writes:

>The only trustable content in a self-signed certificate is the public 
>key, and only when that key is verified by the signature.
>

What a strange view of trust.  If I get a certificate directly from you,
I know that what's in there is exactly what you choose to put in there,
and I can trust it as much as I trust you.  If I get a certificate
purporting to be yours from a CA then all I can be sure of is that at
some point a payment to the CA cleared, possibly from a stolen credit
card or bank account.

Nothing in a CA-issued cert has much meaning (because the card used to
buy it could be stolen, I can't even be sure that payment was made).
OTOH I can trust everything in a self-signed cert obtained from you as
much as I trust you, which seems to be a good match.

Peter.

PS: For anyone who thinks CA certs are more trustworthy than self-signed
ones,
    I have a little executable I can send you that you can run on your 
    personal PC/laptop.  You can trust it, it's been signed with a
CA-issued 
    cert for the Malaysian government.

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 17 Nov 2011 15:41:55 +0000

>understand; I'm sure the feeling is mutual :-).

I don't trust the certs I issue myself either; I've always been told I'm
too clever for my own good.  Plus they're all software certs anyway, and
we all know how current platforms suck at protecting those keys.  :)

-- T

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 18 Nov 2011 09:49:00 +1300

"Kemp, David P." <[email-masked]> writes:

>Sorry, but I'd trust the certs on Tim's CA-issued common access card before 
>I'd trust something Tim handed me himself.  Nothing personal, you understand; 
>I'm sure the feeling is mutual :-).

That's a rather unusual special case because the issuer is Tim's employer (or 
connected to his employer) and thus has direct knowledge of him and his work 
role.  For the vast majority of commercial certs from public CAs the CA 
wouldn't know the cert-holder from Adam (or, since this is the Internet, from 
Fido), and vice versa.

>If there are out-of-band means of trust (such as f2f, or an independent-
>channel fingerprint), great.  If not, the cert isn't worth a warm bucket of 
>spit.

Yup, and that's pretty much the problem statement for public CAs (with various 
extensions, e.g. if you do actually run into a CA that refuses to sell you a 
cert you just keep trying other CAs until you find one that'll take your 
stolen credit card, as e.g. malware authors after code-signing certs have been 
doing for awhile now).

In any case, regardless of whether the info in a cert has any validity or not, 
it's still needed to establish a crypto connection (for SSL).  Given that all 
the phishing, UX, and other data we've collected to date indicates that they 
have zero effect on phishing so that using them has the same effect as 
anon-DH, they're still useful for something.  So you'd really need to say "the 
*contents* of the cert aren't worth ...", since the cert itself still serves 
as a crypto ignition key for anon-DH done with RSA.

(I'm not sure if we're still talking about SSL certs here, since I doubt Tim's 
CAC gets used in a web server).

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 17 Nov 2011 16:19:45 -0500

I'm not going to defend public CAs, since I'm in the
federation-of-organizational-CAs camp.

However, this thread is not about CAs at all, it's about non-PKI usage
of X.509 data structures and the development of standard processing
rules for non-PKI certificates to ensure that they do not create
PKI-related application vulnerabilities.

Regardless of what voodoo you go through before accepting a peer-to-peer
(self-signed EE) cert, it should be separate from and not confusable
with the voodoo required to enable a PKI trust anchor.

Dave

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]] 

Yup, and that's pretty much the problem statement for public CAs ...

---

From: Tom Gindin <[email-masked]>
Date: Tue, 22 Nov 2011 08:05:18 -0500

I think it might be helpful to think in terms of assurance levels 
for individual users when discussing a TLS client's use of a self-signed 
certificate.  Using SP 800-63's four levels, no self-signed certificate 
should ever be treated as a Level 3 or 4 credential any more than a 
password should.  Correspondingly, a self-signed certificate is among the 
strongest likely possibilities for a Level 1 credential, where there is no 
identity proofing requirement.  I believe that once a user has established 
a Level 2 credential (a process which is in no way helped by a self-signed 
certificate), the replacement of a password by a self-signed certificate 
strengthens the server's reason to trust the user, but only slightly.  The 
absence of a revocation facility for self-signed certificates is a 
weakness compared to publicly issued certificates, but not compared to 
passwords or other shared secrets.
        In the above, I am assuming that a typical Level 2 password is 
stored associated with a user ID in a repository controlled by the server, 
and that putting a certificate in that same repository does not change the 
security-relevant characteristics of that repository.
        Likewise, the storage of a self-signed certificate in a local 
address book entry in which the presence of any certificate at all is 
optional is similar in many ways to level 2 above.  The user of the mail 
client (not the originator of the certificate) chooses whether to store 
the certificate or not.  In this case, however, the sender may think he 
has better assurance of encryption than he actually has while in the Level 
2 case the server is not permitting the user any actions beyond those 
authorized by a password.

Tom Gindin

From:   "Kemp, David P." <[email-masked]>
To:     <[email-masked]>, 
Date:   11/17/2011 04:21 PM
Subject:        Re: [pkix] End-entity self-signed certs
Sent by:        [email-masked]

Dave

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 22 Nov 2011 10:24:49 -0500

Yes, it's very helpful to think in terms of certificate assurance
levels.  However, I think the password model has a closer relationship
to PKI than to self-signed certificates, at least in cases where two
parties are involved with passwords.  It would be great if users had the
choice, when signing up for Yahoo or gmail or Facebook, to get a cert,
or a password (or both).  And if NYTimes wants to allow users to sign in
with Facebook-issued Level 1 or Level 2 certs, it could do so without
users exposing all their Facebook data to the Times.

You could certainly bootstrap a password into a user-signed cert, but
that doesn't help with federation - each RP has to do its own assurance
on the user-supplied content or get supplemental information from the
password issuer.

Dave

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2011 8:05 AM
To: Kemp, David P.
Cc: [email-masked]
Subject: Re: [pkix] End-entity self-signed certs

        I think it might be helpful to think in terms of assurance
levels for individual users when discussing a TLS client's use of a
self-signed certificate.  Using SP 800-63's four levels, no self-signed
certificate should ever be treated as a Level 3 or 4 credential any more
than a password should.  Correspondingly, a self-signed certificate is
among the strongest likely possibilities for a Level 1 credential, where
there is no identity proofing requirement.  I believe that once a user
has established a Level 2 credential (a process which is in no way
helped by a self-signed certificate), the replacement of a password by a
self-signed certificate strengthens the server's reason to trust the
user, but only slightly.  The absence of a revocation facility for
self-signed certificates is a weakness compared to publicly issued
certificates, but not compared to passwords or other shared secrets.
        In the above, I am assuming that a typical Level 2 password is
stored associated with a user ID in a repository controlled by the
server, and that putting a certificate in that same repository does not
change the security-relevant characteristics of that repository.
        Likewise, the storage of a self-signed certificate in a local
address book entry in which the presence of any certificate at all is
optional is similar in many ways to level 2 above.  The user of the mail
client (not the originator of the certificate) chooses whether to store
the certificate or not.  In this case, however, the sender may think he
has better assurance of encryption than he actually has while in the
Level
2 case the server is not permitting the user any actions beyond those
authorized by a password.

Tom Gindin

Dave

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 28 Nov 2011 14:52:41 +0000

On 11/22/11 7:05 AM, "Tom Gindin" <[email-masked]> wrote:

>password should.  

You're misreading 800-63.  Nothing in 800-63 says you must use the
attributes in the certificate.

Level 3 and 4 require binding the key to the person by methods appropriate
to those levels (e.g., hardware activated tokens at Level 4) *and* using
identity proofing methods appropriate to those levels.  Nothing about
these requirements actually say I have to use certificates.  I *can* use
certificates if the issuer obeys Level 3/4 and asserts policies to that
effect (e.g., FPKI Common Policy OIDs), but I'm free to use local identity
data--as long as I use Level 3 and 4 identity proofing methods to
establish that local data.

>From Section 5 (emphasis added):

"""
In this guidance, the party to be authenticated is called a claimant and
the party verifying
that identity is called a verifier.  When a claimant successfully
demonstrates possession
and control of a token in an on-line authentication to a verifier through
an authentication 
protocol, the verifier can verify that the clamant is the subscriber.  The
verifier passes on 
an assertion about the identity of the subscriber to the relying party.
That assertion 
includes identity information about a subscriber, such as the subscriber
name, an 
identifier assigned at registration, or other subscriber attributes that
were verified in the
registration process (subject to the policies of the CSP and the needs of
the application).  
Where the verifier is also the relying party, the assertion may be
implicit.  In addition, the
subscriber¹s identifying information *may* be incorporated in credentials
(e.g., public key 
certificates) made available by the claimant.  The relying party can use
the authenticated 
information provided by the verifier/CSP to make access control or
authorization 
decisions. 
"""

-- T

---

From: Tom Gindin <[email-masked]>
Date: Wed, 30 Nov 2011 08:52:21 -0500

The main point I've tried to make in this thread is the usefulness 
of self-signed certificates for level 1 and as a credential after level 2 
proofing, rather than their unsuitability for higher assurance levels. 
Nonetheless, I don't know if anyone has ever used them at higher levels 
and I don't think they should.
        The revocation requirements for levels 3 and 4 are IMHO a stronger 
reason not to use self-signed certificates at those levels than the fact 
that a self-signed certificate consists mainly of information which nobody 
except the claimant has vouched for.  The lack of revocation is irrelevant 
to level 1, relevant but not crippling for level 2, serious for 3 and even 
worse for 4.  You are right that a self-signed certificate could possibly 
represent a strong enough proofing process for level 3 or 4, although 
using one makes it hard for that fact to be conveyed between a CSP and a 
separate RP.
        Further comments below, marked by [TG].

Tom Gindin

From:   "Miller, Timothy J." <[email-masked]>
To:     Tom Gindin/Watson/IBM@IBMUS, "Kemp, David P." 
<[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>
Date:   11/28/2011 09:53 AM
Subject:        Re: [pkix] End-entity self-signed certs

[TG] There is nobody who can publish revocations for a typical self-signed 
certificate, although the mechanism proposed by "sovereign key" has some 
possibilities.  It's true that registrations being invalidated by 
replacing them in a repository is probably good enough for Level 2, 
although 800-63 doesn't say so.  It MIGHT be considered adequate at Level 
3 as well, but the requirements on the verifier suggest that it shouldn't 
be.  The certificate name need not be relevant, although many 
implementations would find it more convenient if either the DN or the SAN 
contained the account name.

"""

[TG] I'm more interested in the revocation requirements for Level 3.  From 
8.3.1.3, "Verifiers shall ensure that the tokens they rely upon are either 
freshly issued (within 24 hours) or still valid", although the next 
sentence does say "Shared secret based authentication systems may simply 
remove revoked Subscribers from the verification database".

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 30 Nov 2011 14:40:29 +0000

>and I don't think they should.

To counter, I'm trying to make the point that functionally speaking the
self-signed certificate is nothing more than a container for the public
key.  A key continuity system wouldn't even look at the certificate
attributes.  Practically speaking, however, the certificate is needed
because the *protocols on which systems are built* are built around X.509
objects.

For example, I can (and have) build a web service that uses key continuity
for authN and authZ.  However, to *use* that service the user must have a
certificate, because the TLS protocol requires certificates to function.

>using one makes it hard for that fact to be conveyed between a CSP and a

As you noted, revocation in key continuity systems are achieved by
de-authorizing the key.  I don¹t see this as a problem for LOA3/4, but it
does make the C&A job more important.

-- T