Another important reference:
http://groups.csail.mit.edu/cis/theses/kohnfelder-bs.pdf
This first invention of a “certificate” assumes a single naming authority
and does not introduce any notion of name constraints.
PKI also was heavily influenced by X.501 and the whole master directory
in the sky concept (originally from Xerox). This was a very formal public
mail like system where your name and address had to come from a higher
authority.
PKI can be made to work for elected vertical applications with great effort.
A workable “modern” trust system should have be more easily tuned to
allow arbitrary attributes to be the authenticated information.
Too much emphasis in X.509 PKI is placed on unique name space because
these “names” serve as unique “identities”. Names are just one type of
attribute
that can be assigned to a key. Breaking away from the PKI notion of
a single set of “authorities” is critical to supporting a more easily tuned and
more secure trust infrastructure. PKI provides a single “tree” defined by
many equal root CAs. A more flexible model that would support arbitrary
attributes and trust constraints is a “forest” model. The local trust is
a data structure with many “root’s” each with different attribute spaces
and constraints.
For example, we may want Alice and Bob to have authority of a specific
constrained attribute range where each entity controls
a specific subset of the attribute range. For email these trust statements
might look like:
--
trust: *alice
for:
- email address range: *@alice.com
--
trust: *bob
for:
- email address range: *@bob.com
The data structures above are expressed in a subset of YAML. ASN.1, JSON,
XML , S-Expressions or other encodings could be used. I’m partial to YAML
since need to be able to have the best possible human readability for
any of the expressions that would be part of a new system.
Paul
On Apr 27, 2014, at 8:20 AM, Arshad Noor <arshad.n...@strongauth.com> wrote:
> On 04/27/2014 07:43 AM, ianG wrote:
>>
>> There is a slight problem with goals here. PKI was never designed for
>> ordinary users. If you read the original documentation of how PKI was
>> organised before the web-PKI was invented, it talks about how each
>> relying party has to enter into a contract and verify that the CPS
>> provides the answer they are looking for.
>>
>> In this context, it was reasonable to talk about the relying party
>> trusting the results, because they had actually gone through the process
>> of developing that trust. According to the theory.
>>
>> When they did the web-PKI however they threw away all of the reliance
>> contract requirements, or buried them, but kept the language of trust.
>> As you point out, they had to do this because ordinary users won't go
>> through the process of CPS and contract review.
>>
>> So the result was trust-but-no-trust. We are not using PKI as it was
>> designed and theorised.
>
> I concur. If you consider that the early writings on PKI had more legal
> language and lawyers involved [1], [2] and [3], it becomes clear that
> PKI was designed more for B2B transactions than B2C. That it is being
> contorted for B2C transactions - without the consumer being sufficiently
> educated to understand the technology, personal responsibility and
> implications - is where PKI went down a slippery slope.
>
> The dozens of PKIs I have setup over the last 15 years have been fairly
> successful, primarily because the RP is also the issuer of the digital
> certificates (they are closed PKIs for internal use only). In those
> rare cases where PKI is being used for TLS ClientAuth across companies,
> it has been for B2B transactions where preexisting contracts exist.
>
> Arshad Noor
> StrongAuth, Inc.
>
> [1]
> http://www.americanbar.org/content/dam/aba/events/science_technology/2013/dsg_tutorial.authcheckdam.pdf
> [2]
> http://www.amazon.com/Secure-Electronic-Commerce-Infrastructure-Signatures/dp/0130272760
> [3] https://www.ietf.org/rfc/rfc3647.txt
> _______________________________________________
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
