Subject: [pkix] A simple solution to the Internet's identity crisis

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 21 Mar 2011 22:04:27 -0700 (Pacific Daylight Time)

Esteemed members of the PKIX working group,

I have come up with a simple solution to the Internet's identity crisis.  It uses PKIX as its basis.  It resolves every privacy complaint with e.g. TLS's non-DHE ciphers, which utilize the PKIX-specified data formats.

The upsides:
- consumer can take control of protecting his own identity -- no more need to rely on the server to support DHE to protect the initial handshake
- consumer can leverage existing copyright law to provide a solid foundation from which to protect his privacy
- consumer doesn't have to worry about Eve -or- Mallory
- business can have and rely upon multiple credentials (including signed credit reports or private club memberships) provided by consumer, as well as state identity
- proposed solution utilizes cryptographic protection throughout
- Involves verifying a complete chain of signatures

The downside:
- It involves self-signed certificates

The upside to the downside:
- any consumer of PKIX certificates will automatically fail validation of certificates utilizing this method, making this safely backward-compatible

I present the method (that I'm calling "secure evidence bundle internet protocol"):

Alice has:
- a privacy policy
- a single-transaction (nonce) keypair
- one or more certificates, asserting identity and/or authorization
- all of the private keys to those certificates
- one or more other things (invoices, scans/PDFs of signed contracts, etc), asserting whatever else she wants to assert (the stuff that Judy, the Judge, is going to want in case of dispute)

Bob has:
- identity certificate

1. Alice obtains Bob's certificate (current WWW-server practices).
2. Alice creates a set containing her privacy policy, Bob's certificate, the public key to the nonce keypair, all of the certificate chains she wishes to assert, current OCSP responses for those certificate chains, and all of the other things she wants to include.
3. Alice creates another set containing #2, and signatures over the previous set by every private key that she is claiming that she holds including the nonce private key.
4. Alice encrypts #3 to Bob's public key.
5. Alice creates a new set containing #3, and her privacy policy.
6. Alice encrypts #5 to Bob's public key.
7. Alice creates a TBSCertificate structure with SubjectPublicKeyInfo of the nonce keypair, and #6 as an extension therein.
8. Alice signs #7 with the nonce private key.

On receipt of Alice's #8, Bob:
1. Verifies the self-signature.
2. Decrypts (with his private key) Alice's #6 to obtain Alice's #5
3. Is presented with Alice's privacy policy (i.e., copyright license), which he must choose whether he wants to comply with.
4. Iff he accepts, he decrypts Alice's #4, obtaining Alice's #3 and Alice's #2.
5. Scans through Alice's #2, to compare the nonce public key with the SubjectPublicKeyInfo in the outer certificate.
6. Verifies the signature of that public key over Alice's #2, to prove that this is not a replay attack.
7. Analyzes Alice's #2, and determines every certificate that he needs a signature to prove.
8. Verifies Alice's #3 against the public keys contained in Alice's #2.

Eve and Mallory see:
- nonce public key
- Alice's doubly-encrypted information

Important Notes:
- current path validation rules stay precisely the same, in the verifications of Alice's certificate chains.
- the identity asserted by the CA for Alice's key is protected under 2 layers against Eve and Mallory
- the identity asserted by the CA for Alice's key is protected under 1 layer against Bob
- the copyright license presentment makes this a click-wrap license, with enforceable penalties for violating it
- the identities that Alice wishes to assert belong to her, and she can choose whether to proffer them or not
- Alice is not the authority for any specific aspect of her identity or reputation, only the set of all of them
- Alice proves that the nonce private key is her own (a self-signed certificate).
- Alice proves that the holder of that private key knew what was going into the bundle (signature over plaintext)
- Alice proves that the holders of every certificate she asserts as hers knew what was going into the bundle
- The protection against Bob is also Bob's only evidence that she did in fact let him use her information, and under what terms
- The things that Alice wants to provide can include certificate signing requests, permitting secure key enrollment
- The things that Alice wants to assert can include other information which she used to decide to transact with Bob, encrypted so that he can't figure out what she used, but Alice can decrypt the committed bits for Judy the Judge
- This allows Alice to assert not only her state identity, but also context-specific identities and reputations
- This utilizes the most ubiquitous and most thoroughly-vetted cryptographic protocols currently deployed

Why I'm not writing this up as an I-D:
- I don't know how
- I can't guarantee that as "the author" I'll continue to be available
- PKIX is a much more collectively intelligent body than I could ever hope to be
- PKIX is full of people who have much experience in deployment in different scenarios
- PKIX is full of people who understand the standards better than I do
- PKIX is full of people who write standards better than I ever could

Why PKIX should take this up:
- PKIX created Internet standards for the Certificate and OCSP, but never tied them together
- TLS is the wrong place to solve OCSP stapling
- The Consumer is the authority over who to show his driver's license or his club membership card to
- Other protocols fail to permit the secure assertion of multiple certificates/credentials
- PKIX never created a way for Alice to protect her own identity
- PKIX standards haven't been really examined under post-Wassennar Arrangement rules, which don't require transmitting the certified identity in the clear to tag encrypted streams with their owners' information
- PKIX faces a set of challenges which have not been simply or neatly addressed
- PKIX is the only body with a chance of preventing any single private organization from having ownership of any individual's identity

Thank you for your time and attention.  I hope that this abstract protocol meets with your approval.

If you need an explicit license for this information: I hereby dedicate this work to the public domain.  I'd appreciate credit though.

I am aware of no intellectual property claims which are infringed by this protocol, and I have no pending intellectual property claims which would be infringed by this protocol.

-Kyle Hamilton

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 22 Mar 2011 22:16:07 +0100

Hi Kyle,
Interesting subject line.  I like it!

However, I'm a little bit skeptical as well...

First I think you have turned to the wrong forum.
There are virtually *tons* of other groups trying
to solve the "identity crisis".  Kantara is one.

Next, I don't get the use-case.  I may have read the
spec. in too much haste but it seems to be incompatible
with both TLS and S/MIME.

As I understand IIS can create an encrypted channel
before doing client auth.  If IIS can do that any
server should be able to do it as well.

IMHO, the identity crisis really has to do with S/MIME.
But S/MIME is only pushed by some government agencies
and security geeks.

I don't see that your solution even if adopted by mail
agents would make "secure email" in reach for the masses.

Skype have in spite of the somewhat flawed model, effectively
provided end-to-end-security in a transparent way to hundreds
of millions of users.  Personally, I have no faith in off-line
methods like S/MIME or PGP.

Although the following scheme does not meet your requirements,
it seems like an interesting way to achieve a truly scalable PKI:
http://www.w3.org/wiki/Foaf%2Bssl

BTW, this space is already littered with failures:
http://www.craigburton.com/?p=3131

Anders

On 2011-03-22 06:04, Kyle Hamilton wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 22 Mar 2011 18:17:12 -0700 (Pacific Daylight Time)

> to solve the "identity crisis".  Kantara is one.

I was using the term in a very tongue-in-cheek fashion.  There are many reasons why I believe PKIX is the correct place to solve it, as PKIX is the only real way to convey identity with a universally ubiquitous footprint.

> with both TLS and S/MIME.

TLS client authentication: the client can take control of the transmission and protection of his own information.  It utilizes the X.509 parser that the server already must have to support TLS client authentication, and is simply a way to provide a universe of evidence to the server.  This includes such things as "Alice obtains the OCSP responses for her certificate chain, and includes them in the information she provides to Bob."  This prevents Trent from learning that Alice is talking to Bob, because Bob would otherwise have to obtain the OCSP response himself.

More importantly, it also prevents Eve and Mallory from learning that it's Alice and not Chuck who's talking to Bob.  Only by providing the client endpoint the ability to protect its own information regardless of what the protocols state can the client endpoint truly help its user prevent his identity from being stolen and abused.

(The first encryption is to allow Alice the capacity to assert copyright protection over the contents of the bundle, by allowing Alice to impose a license on the information copied out of the structure.  The second encryption is to allow Alice to prevent Eve or Mallory from learning the content of the information-copy license, as different sites will have different requirements.)

> server should be able to do it as well.

This is true, and it's called "Ephemeral Diffie-Hellman", or DHE.  It is not sufficient for the instant problem, because it relies upon the server supporting and preferring DHE ciphers.  Currently, browsers have no feedback mechanism describing whether their credentials will be transmitted in clear-text or under cover, which prevents the client from taking appropriate security precautions and making appropriate security choices.

> IMHO, the identity crisis really has to do with S/MIME.

No, the identity crisis really has to do with "someone just sent me a credit card number and I don't know if it's a legitimate transaction by the owner of that card or fraud".  It's basically the entire problem of identity theft wrapped in one easy-to-swallow term.

In other words, the identity crisis really has to do with TLS and every other PKIX-consuming protocol, because the Distinguished Name, the IP address, the email address, and the domain name are all ultimately derived from authoritative state sources.

> agents would make "secure email" in reach for the masses.

the straw-man argument, because your assumption that the identity crisis only applies to email is flawed.

> methods like S/MIME or PGP.

...which is why this protocol is useful for TLS and other real-time protocols as well.  Think: Alice must obtain Bob's certificate, so that Alice can get Bob's public key.  This step must be performed before Alice even has an intended recipient for her information.  Alice can generate this self-signed certificate structure almost instantly on modern computers, since the key used to assert her claim to the certificate chain is used only once.  (The throwaway/nonce/single-use key is used twice.)

> http://www.w3.org/wiki/Foaf%2Bssl

I already have a plan to achieve a truly scalable, ubiquitous, and universal PKI.  It relies upon the client being able to provide multiple assertions at once (certificates and their OCSP responses, at a minimum) to make it useful.

> http://www.craigburton.com/?p=3131

I'm aware of this.  The way I see it, the largest problem inhibiting adoption is that PKIX has always been focused on the one-certificate-and-the-state-identity-is-all-you'll-ever-need mentality.  It certainly had its useful place -- but that was before the crypto export rules in the US were relaxed.  That mentality (derived from the X.509 crowd) still pervades the PKIX specs, and it's actively hindering the useful adoption of what the PKIX specs are very good for: secure and deterministic conveyance of information about an information presenter from an information authority to an information consumer.

PKIX needs to break itself out into two documents.  The first would detail the technical underpinnings of the parser and validator, and would be useful to ipsec and other state-derived identity non-consumers -- which include the TLS stacks.  The second would detail the way that identity certification authorities must encode authoritative information into their compliant certificates, so that people who need to consume identity information have a deterministic way to do so.

-Kyle H

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 22 Mar 2011 21:29:48 -0400

Without commenting on the proposal as a whole...

On Tue, 2011-03-22 at 18:17 -0700, Kyle Hamilton wrote:
> This is true, and it's called "Ephemeral Diffie-Hellman", or DHE.

That is not correct.  Regardless of the cipher suite being negotiated,
the client certificate is transmitted as a Certificate message,
encrypted only by the current TLS cipher suite, which in the case of an
initial handshake is TLS_NULL_WITH_NULL_NULL.  The trick to keep the
client certificate private is for the server to complete one handshake
without requesting a client certificate and then immediately
renegotiate, requesting the client certificate.  See RFC 4680 section 4.

> Currently, browsers have no feedback mechanism describing whether
> their credentials will be transmitted in clear-text or under cover,
> which prevents the client from taking appropriate security precautions
> and making appropriate security choices.

Indeed.  Want to file a bug against Mozilla?

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 22 Mar 2011 22:17:11 -0400

> Indeed.  Want to file a bug against Mozilla?

I went ahead: https://bugzilla.mozilla.org/show_bug.cgi?id=644020

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 22 Mar 2011 22:21:25 -0400

On Mon, 2011-03-21 at 22:04 -0700, Kyle Hamilton wrote:
> - consumer can leverage existing copyright law to provide a solid
> foundation from which to protect his privacy

Copyright law is not some magic thing you can use to place arbitrary
restrictions on the use of information.  It protects economic interests
in works of authorship.  Personal information is not a work of
authorship.  You need a different legal theory.

-- 
Matt

---

From: Stephen Wilson <[email-masked]>
Date: Wed, 23 Mar 2011 14:20:35 +1100

> authorship.  You need a different legal theory.
Right! I agree strongly.

While academics and philosophers can (and should) continue their 
inquiries into questions of ownership of information, please note that 
practical privacy protection comes from legal approaches that are immune 
to such complexities.  Modern Information Privacy Law, in Europe and 
Australia and a few other places, doesn't depend on "ownership".  
Rather, it seeks to control the flow of Personally Identifiable 
Information.  These laws don't mention ownership; they don't even use 
words like "private" for the most part.

So copyright law is definitely not a useful framework for identity 
management.

Cheers,

Steve.

Stephen Wilson
Lockstep

http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 22 Mar 2011 23:25:13 -0400

On Mon, 2011-03-21 at 22:04 -0700, Kyle Hamilton wrote:
> I have come up with a simple solution to the Internet's identity crisis.  [...]

It would help if you started by succinctly stating your goal.  Then it
would become clearer whether the goal is appropriately scoped, what
approaches might be natural and what existing technologies might apply.
I'll try:

Bind one or more client-supplied items (certificates and/or ancillary
documents) to a communication session or a nonrepudiable transaction,
and automate the foregoing while managing client privacy.

TLS supports binding one client certificate to a communication session;
it does not provide for nonrepudiation or managing privacy.  (Note well,
I am not claiming that the latter concerns are or should be in the scope
of TLS.)

Correct?

-- 
Matt

---

From: Geoff Beier <[email-masked]>
Date: Tue, 22 Mar 2011 23:28:14 -0400

> I went ahead: https://bugzilla.mozilla.org/show_bug.cgi?id=644020
I filed a similar (but not quite the same) bug against Chrome last November.
Chrome will send your client certificate to a server before validating the
server certificate. The Chrome security team closed it and set the status to
"WontFix."

http://code.google.com/p/chromium/issues/detail?id=61851

Geoff

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 22 Mar 2011 22:22:21 -0700 (Pacific Daylight Time)

> approaches might be natural and what existing technologies might apply.

My goal: As a sovereign consumer, I wish to minimize information disclosure about myself.  What is mine and relates to me is mine and relates to me, and I do not give permission for my information to flow just for the asking.  I do not give permission for a business to assert its own unilateral privacy policy over the individually-addressed information which I author (i.e., affix in tangible form).  I certainly do not give permission for any derived works from the information I provide to the recipient to be created, outside of the minimum necessary for processing my relationship with them.

By the same token, I wish to be able to give permission for individual entities to do certain things with my information, and the businesses I deal with want to be able to provide a provable record of such permission in court.

I wish to use the ubiquitous PKIX and X.509 identity management frameworks that already exist to my advantage.

I wish to use the most thoroughly-vetted and audited security code and standards available in the consumer world to my advantage.

That's my goal.

> and automate the foregoing while managing client privacy.

This is a very concise description of it, yes, though it misses a particular subtlety which explains why I believe PKIX-WG is the correct place for this:  PKIX standards have been incorporated by reference into many client protocols.  If every one of them must have standards action to work around problems in the current design and implementation of PKIX, it's incomprehensible how internet security can be improved.

This protocol permits PKIX to recognize the needs of its clients: a) the individual consumers, who compete on equal footing with corporations in the marketplace when they become sole proprietors; b) the business with whom the individual consumer interacts; and c) the state, with its need for transparency for law-enforcement purposes.

It turns out that once you get past the idea that self-signed assertions are null assertions (they're not -- they have a useful identity as "the entity which holds the private key"), you enable a -lot- of things that the consumer, the business, and the state all want.

Such as, "my users want to be anonymous but I want to be able to hold them accountable if they do anything illegal."

The business (the server) can receive an assertion from a CA that it trusts that the CA in question knows the proper DN (state identity) of the holder of the enrolled key in question.  This is all that's needed to be able to bring the state and its legal processes into play in any dispute.  If the outer key signed (internally) by the enrolled key is signed by a certified key with "state identity is available" asserted, then the server doesn't need to know the actual information to be able to help the state hold the owner accountable.  The state can use its subpoena power to request the information from the Identity CA -- but only if the Identity CA has the information.

So, given the recipient's interest in knowing if the Identity CA has the state identity information for its submitter, and since the current crop of Identity CAs has not figured out how to agree on a common technical standard for deterministically asserting the availability of correct state identity, I believe that IETF is the only logical choice for creating such.

There needs to be an extension created, containing a flag which can be asserted by the CA: "I do not know and cannot learn the state identity of the authoritative owner of this identity/domain/IP block/whatever", or "Yes, I know a way to get the correct state identity, and you can serve me process at <X> address."

That's it, that's all.  It appears to be much like basicConstraints in its need (a boolean, and possibly some additional information), but it needs to not necessarily be critical because the certificate could be interpreted correctly by a parser/validator which doesn't understand it.

> I am not claiming that the latter concerns are or should be in the scope

TLS also supports binding only one server certificate chain to a communication session.  It's a bit of a straw man argument, though, because the problem exists with other protocols too.

The issue at hand is the content and utility of the single certificate chain which can be presented in most of PKIX's client protocols.

Currently, TLS does not readily support nonrepudiation of/commitment to data, and does not readily support the client in its quest to maintain privacy.  It provides only one readily-accessible extension field for client usage, which is the certificate (chain) field(s).

It also has an information-leakage vulnerability as relates to OCSP (well, really, this isn't TLS's fault, it's PKIX's fault): CArol can learn that Alice is talking to Bob because Alice obtains OCSP for Bob's certificate when she goes to his site.  TLS addressed this with OCSP Stapling from the server.  This information-leakage vulnerability goes the other way, when you're dealing with client certificates -- CArol (or Trent, it doesn't matter which) knows that Bob is talking with Alice, because Bob requests the OCSP for Alice's certificate.  AFAIK, this is currently unaddressed.

See, Alice the Consumer wants to prevent Eve from being able to see her credentials, and wants to prevent Mallory from fraudulently using her credentials.  She wants to do so even if the server doesn't want to play along in negotiating encryption prior to demanding her credentials.  This is a legitimate interest, which has not been adequately addressed.

I believe that the most natural approach to this is to recognize this interest within the credential-provision standard.  Since TLS absolves itself of the content of the Certificate message, TLS is the wrong place to solve any particular problem with the way that the credentials and credentials-about-credentials are provided to its clients.

It follows that the group which standardized the format of the credentials and credentials-about-credentials -- the set of security-related things which must be asserted by one endpoint to the other endpoint -- must be the one to reevaluate how its discrete and improper-assumption-based formats fit together in light of this new understanding of Alice as an Authority all of her own -- she's responsible for her set of d/b/a's, but each of her d/b/a's has its own reputation (for example, a carpet cleaner has a different reputation than a little league coach).  She is authoritative for which d/b/a(s) she wishes to present.  She must be able to sign what she presents, so that she may convey limitation on the authority to copy and use what she presents.

The useful property about self-assertions that I alluded to earlier comes into play with the outermost, throwaway keypair.  The holder of the key is the only one who could assert it.  With the binding of that public key into the set #1 created by Alice, she asserts that the holders of all the keys asserted as belonging to her knew that the throwaway key for the transaction was claimed by Alice, so Alice is the authoritative source for the self-assertion.  Bob doesn't need to worry about receiving self-assertions, as long as in the end he can prove a valid, verifiable chain of signatures for everything he does need to worry about.

-Kyle H

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 25 Mar 2011 11:24:37 -0400

On Tue, 2011-03-22 at 23:28 -0400, Geoff Beier wrote: 
> I filed a similar (but not quite the same) bug against Chrome last
> November. Chrome will send your client certificate to a server before
> validating the server certificate. The Chrome security team closed it
> and set the status to "WontFix."
> 

That link gives me an error 403, but based on your description I would
agree with their decision.  I don't see how validating the server
certificate helps.  The attacker can put you through to the real server,
inject a CertificateRequest, snoop your client certificate, and then
break the connection.  The injection would not be caught until the
Finished message.

-- 
Matt

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 25 Mar 2011 19:32:47 +0100

IMO many security experts' take on privacy share two common characteristics:

- They are always in opposition to what is actually going on in the
  "real world", here thinking of Cell Phone Operator call-logging,
  DNA as universal evidence, e-mail addresses as globally unique
  static IDs, the giant databases held by the health-care sector,
  reality-TV (!), Facebook, "Cloud" services, and the list goes on and on.

- They often "prescribe" insanely complex systems doing absolutely nothing.
  An example is the TPM (Trusted Platform Module) that through the use of
  a totally over-engineered privacy-enhancing PKI-solution became useless
  as a container for authentication keys.  I.e. cost and convenience never
  seems to be a part of the plot.

Anyway, IETF's track record when it comes to privacy and PKI is not
very encouraging.  AFAIK, the identity of the sender and receiver
in an S/MIME-encrypted message are *revealed in clear text* which
nullifies at least half of the idea.

IMO, Internet's identity crisis is that we have to remember a gazillion
user-id/password combinations.  The "tres chic" recommendations we get
from the security community such as not reusing passwords, changing
passwords often, and making passwords hard is IMNSHO an example of
"Internet idiocy".

Why not give us a better system instead!  How hard can it actually be?

Personally, I have given up on SDOs (Standards Developing
Organizations), they are simply too slow (and impractical),
whereas Apple and Google operate at the speed of light and
have more powerful ways pushing out solutions that combine
security, costs, convenience and privacy than a bunch of
security nerds that only report to themselves.

Phew!  This should NOT be taken as criticism, but a as an
attempt to capture the current state of things.

Anders
"sort-of" security nerd

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 26 Mar 2011 14:49:26 +0100

Whatever people think about this proposal I believe that the
time when you wrote an I-D, waited for it to become an RFC,
and then assumed that it would be adopted has [since long] passed.

That is, IMO you must provide the whole stack in a free
implementation that runs one one or more major platforms, or
you will only add another "dust-collector" to the IETF archive.
PKIX have created several such where SCVP and TAMP appear to be
the most relevant in this context.

In fact, not even the giants have much faith in the standards
process anymore.  The spectacular success of Apple and Google
in phones forced Microsoft and Nokia into a marriage that (if
successful...) will provide the full stack at the speed we
have gotten used to.

As a inventor in this field (taking on the identity crisis
from another angle), I have come to the conclusion that my
project also requires the entire stack from browser "plugin"
to hardware token.  Some vendors are pursuing similar goals
by partnering with for example security HW vendors.  AFAIK,
the latter have shown [any number of times] that they are
NOT INTERESTED in becoming replaceable which I think will
greatly complicate adoption in the consumer space.

Anders
http://webpki.org/auth-token-4-the-cloud.html

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 30 Mar 2011 18:54:27 -0700 (Pacific Daylight Time)

>  reality-TV (!), Facebook, "Cloud" services, and the list goes on and on.

I can't argue with this.  I'm looking at the real world, and practicing secure protocol design.  (Seriously -- the only real way to have secure dynamic addressing is to make the addressing be a function of the key.)

>  seems to be a part of the plot.

This is also true.  I'm leveraging the TPM for what it's good for, and not trying to use it for what it's not.

> nullifies at least half of the idea.

This is also the case with TLS, don't forget.  This is why the certificates must be obfuscated before they're transmitted.

> passwords often, and making passwords hard is IMNSHO an example of

Internet's Identity Crisis is that we're still using usernames and passwords, 13 years after US opened up crypto export.  They're easy to forge.  They're easy to forget.  They're easy to mess up.  But most of all, they rely on the human to manage them.

The thing that's stopping widespread adoption is the overarching dogmatic view of "state identity is all you'll ever need, so state identity is all you're ever going to get".

> Why not give us a better system instead!  How hard can it actually be?

I'm developing one.  The only way to make it work, though, is to forget everything ever learned about how the PKI priesthood handles identity, and learn about how the real world handles identity.

Once you do that, it's disgustingly simple.

> security nerds that only report to themselves.

We need to stop looking at our standards with self-congratulatory reverence and start looking at them through the eye of 'now we have them, how can we use them?'.

> attempt to capture the current state of things.

I wholeheartedly agree with this appraisal, and I at least didn't perceive it as criticism.

-Kyle H

>
> Anders
> "sort-of" security nerd
>
> On 2011-03-24 09:47, Kyle Hamilton wrote:
>>
>>
>> On Wed, Mar 23, 2011 at 11:55 PM, Anders Rundgren <[email-masked]> wrote:
>>> Kyle,
>>>
>>> If you are really serious about this proposal I think you should
>>> focus on security and privacy because it simply gets a bit too
>>> fluffy for your average technologist (including myself) adding
>>> copyright considerations.  In the mind of the public, copyright
>>> is about DRM, GPL, and similar topics.
>>
>> Alright.  I'll remove that bit.
>>
>>> Assuming that the s.c. TLS privacy issue can be fixed, I'm still
>>> wondering about the use-case.
>>
>> Anders, you're working from the idea that everything must use TLS or S/MIME to be secure.  I'm working from the viewpoint of "Alice wants to include the contemporary DNBS report on the company she's about to enter into a distribution agreement with".  PKIX isn't just about the current environment, it also must be completely self-contained in how it asserts things, and provide determinism for exactly what it asserts.  It must essentially be its own packet format, encompassing all use-cases that it is indicated to support.
>>
>> This is the reason why Signed HTTP was much better than HTTP over TLS -- it permitted the server to actually attest to the content, rather than relying upon the environment to intuit that it couldn't have come from a bad source.  This means that there is no signature on sales order confirmation pages, no way to utilize the technology we have in a way which works for the benefit of every potential consumer of the specifications.
>>
>>   "Secure e-mail" doesn't work because
>>> there is no good way sending an encrypted mail without first having
>>> exchanged encryption keys OOB.
>>
>> DNS TXT records would be a good option for this.  All that any keys contained therein would assert is "if you encrypt to this key, this mailbox and only this mailbox will be able to decrypt it".
>>
>> The only reason why it's not used right now is because DNSSEC isn't mandated by ICANN, and thus it's too insecure to be practical.
>>
>>   Message encryption doesn't look
>>> like a solution to me.  In addition, trust anchor issues makes
>>> secure e-mail very difficult to use.
>>
>> Yes, in current implementation.
>>
>> No, if you discard the idea that you absolutely must have the CA's issued certificate before you send email.
>>
>> You could (for example) send a self-signed certificate containing a key which is also certified by a CA, but which other certificate is not delegated CA powers by its issuer.  You could refuse to disclose the CA certificate except under cover of encryption.
>>
>> The biggest thing is to realize that the certified key belongs to an authority in and of itself.  Even if the CA doesn't allow it to sign identity certificates, that doesn't mean that it can't be used to sign delegation certificates allowing its owner to claim authority over those processes.
>>
>>> IMNSHO, secure e-mail represents the worst security standard ever
>>> and it was indeed created by the same people who hang out in PKIX...
>>
>> ...and that's why I'm completely ignoring it. :D
>>
>>> I'm personally a little bit tempted dipping my toe in the FOAF+SSL
>>> pond because it could greatly expand the PKI territory.
>>
>> I'm writing a system which has the potential to create the universal, ubiquitous, functional, reliable, invisible PKI.
>>
>>> Maybe it could even become the foundation for "secure e-mail"!
>>> But this time for real :-)
>>
>> I'm coming at this problem space from a completely different angle than has ever been attempted before (that I can find, anyway).  Instead of thinking about protocol interactions as being... well, interactive, I'm creating a document-based system.  (Documents have their content, but they also have metadata -- Apple kinda had the right idea with its Resource Fork concept, BeOS had its filesystem attributes, and Microsoft has its multiple-stream capacity on NTFS; none of them have ever really figured out how to handle the full shebang as one huge blob that works on non-native filesystems.)  Lotus Domino/Notes is a document-based system, and it gave me the idea -- but it also has fatal flaws which make it unsuitable as-is.
>>
>> My solution recognizes the sovereignty (and authority) of the individual consumer.  This is an important concept, one which nobody's ever looked at before.
>>
>> When a person goes into business as a sole proprietor, he competes on an equal footing with corporations.  Corporations have a lot of roles spread out over many people, and have to worry about their cells (and their non-cells) telling falsehoods in bids to illicitly access resources.  Thus, the autocracy of X.500/X.509 applies perfectly to corporations, particularly Big Business.
>>
>> A sole proprietor, on the other hand, has all roles heaped on one person.  A proprietor's hand typically does not need to convey trust to his liver.  In addition, a proprietor can have many different d/b/a pseudonyms, and these d/b/as can be in wildly disparate fields.  When they're found to collide (such as "Alice the musician" and "Alice the soccer mom"), nobody blinks.  Each d/b/a has its own reputation -- maybe Alice is a lousy bass player, but she's quite efficient and organized at being the soccer mom.
>>
>> These identities, and their associated reputations, are all valuable.  They all influence how others view and interact with their holder.  They all are pieces of a much larger puzzle, the one which current deployment leaves unsolved.  The DN of the state identity doesn't and can't tell you anything about Bob the janitor or Bob the cable guy or Bob the lawyer, even if Bob the lawyer can be verified with the bar association and Bob the cable guy can be verified by calling the cable company.  The DN of the state identity doesn't capture the complexity of these state-enabling identities, and is thus incomplete and inefficient to mandate.
>>
>> I've come up with a system design which allows -all- of these needs to be met.  I'm implementing it.  I would just rather invite engineering input on the enabling protocol from other potential stakeholders. :)
>>
>> -Kyle H
>>
>>>
>>> Anders
>>>
>>>
>>> On 2011-03-24 06:17, Kyle Hamilton wrote:
>>>>
>>>>
>>>> On Tue, Mar 22, 2011 at 7:21 PM, Matt McCutchen <[email-masked]> wrote:
>>>> (I'm paraphrasing much of, but not all of, this theory from "Own Your Privacy" by Wes Kussmaul.  Also, I am not a lawyer, but the concepts appear sound to someone who's learned a lot about US copyright law.)
>>>>
>>>> The creation of the tangible form of the information disclosure (the creation of Alice's #1) is the definition of a work of authorship ('once it is affixed in a tangible form') under copyright law.  The information contained in that copyrighted tangible structure (information about identity and reputation) has economic and/or personal value which must be protected.  Copying out of a work of authorship, particularly by automated means, creates a derived work squarely within the legitimate bounds of copyright law.  It's even more obvious when that derived work is written to disk or printed out.
>>>>
>>>> It's important to note, I'm not talking solely about the identity information which is available from the authoritative public register.  For example, If I'm a member of a club which offers reciprocal benefits with a club in an area I'm traveling to, that membership is information which needs to be known only by me, my local club, and the remote club.  That information, if put in a tangible form, is copyrighted by the local club.  If the only time that information is disclosed is under the terms of a copyright license which limits redisclosure, any derived work from that information (even writing down "facts" from it) is a violation of the club's copyright license -- because the facts could not have been found without permission, and permission was contingent on that restriction being agreed upon.
>>>>
>>>> Also, I believe that identity certificates are (often, but not necessarily always) works for hire, under copyright law.  This implies that the copyrights on them (as generated by the CAs who create their works affixed in a bitstring of tangible form) transfer to the people who paid for them.  (Even if the CA retains ownership of the copyright, it must necessarily grant a license for redistribution to the subject it names, or else it is useless -- so this section applies to that case as well.)  Obtaining information from a non-publicly-performed, non-published work does not have an automatic statutory exemption from copyright.  In other words, even if they are facts, the way that the facts are encoded is copyrighted.  If the only way you could have gotten those facts was by creating a derived work, even if you use knowledge only available to you to derive that work (your private key), it's still a derived work under copyright law.
>>>>
>>>> Sure, copyright isn't going to protect me from the current masses of marketing lists that my own information is on... but copyright can protect my information from being added to any more of them.  Think of life in 20 years, where the old marketing lists have finally been destroyed.
>>>>
>>>> The consumer, as the author of the representation of encrypted bits, can restrict the creation of derived works under copyright law.  That's all that really matters here.
>>>>
>>>> I do not believe that the consumer can restrict the collection of information by the server not acting under any license, as the server can collect any information it wants to that it sees, hears, writes, and otherwise senses.  What the consumer can do, under copyright, is restrict the server from redisclosing the information which it could only have obtained after accepting a restrictive license to create a derived work.  This is not necessarily -- and will usually not be -- publicly disclosed or disclosable information.
>>>>
>>>> This is pretty much the only framework which makes sense in the US right now.  I hope the situation changes to be more like the EU.
>>>>
>>>> Since I'm talking about the end consumer in the US applying copyright law, I must mention the Digital Millennium Copyright Act.  Trying to bypass a technical protection measure on a work of authorship is a felony worth 20 years in prison.  The information which the consumer wants to protect can, in a deliciously ironic twist, suddenly be protected under the same measures which the MPAA and RIAA big businesses fought to get put in place, to protect their own tangible expressions of personally-identifiable information.
>>>>
>>>> -Kyle H
>>>>
>>>>
>>>>