Subject: The PKC-only application security model ...

From: Thierry Moreau <[email-masked]>
Date: Wed, 23 Jul 2008 15:07:37 -0500

Dear all:

This is a two-fold announcement, big picture and specific document 
announcement. The whole thing is "for your information" as PKIX IETF wg 
participants.

A)	The big picture refers to the "PKC-only application security scheme", 
in which client-server applications may be secured with client-side 
public key pairs, but *no trusted certification authority* is involved 
(server operators are expected to maintain a trusted database of their 
clients' public keys).

B)	The specific document announcement refers to what is required to 
field the PKC-only application security scheme: explicit meaningless 
security certificates. The reference is "Explicit Meaningless X.509 
Security Certificates as a Specifications-Based Interoperability 
Mechanism", http://www.connotech.com/pkc-only-meaningless-certs.pdf

This post leaves it to your imagination and creativity about how a 
PKC-only security scheme may work in practical details, i.e. how the 
third party trust management may be replaced by first party trust 
management (first party = server operator as the relying party for 
client public keys). I have been doing some work in this area, but I 
have no results to report in a properly written document. Anyway, the 
PKC-only security scheme does not imply significant standardization for 
interoperability among independent service operators.

The document is open for discussion. It covers the minimal provisions 
for PKC-only deployment in the installed base of browsers supporting the 
TLS protocol.

Sometimes in the future, a very reduced version might be prepared as an 
Internet draft intended to the RFC editor publication route (RFC3932) 
with the experimental status (this is different from the individual RFC 
submission route in which the IESG is involved in the document 
publication process but no IETF working group is assigned an editorial 
role).

Good reading.

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 24 Jul 2008 16:37:12 +0200

Hi Thierry,

Although I consider myself pretty well-educated in PKI, I had difficulties reading your document.
I got even more puzzled when you began listing ASN.1 constructs which I fail to see how they apply to a conceptual model.
Would it be too much asking for a short-cut version?

Exactly what do you find to be a problem with the current PKI model and how does the PKC-only model address them?  BTW, the current PKI model can be broken into two rather different variants; the RP-only-model and the TTP-model.

I'm not aware of any conceptual problems with the RP-only model in which the certificate is *almost* redundant since all important data about the user is available from other [in-house] sources as well.

The TTP-model OTOH suffers from all kinds of difficulties ranging from basic issues like who is going to pay for the certificate (card), to what is actually certified, as well as to liability concerns.

Other PKI Issues

IMHO, the reason why PKI hasn't got farther is because we still lack a cheap and standardized "container" to keep private keys in, that works in most computers without installation of proprietary middleware.  I'm personally involved in solving this part of the infrastructure.  Another issue is the unavailability of a standadized scheme for on-line provisioning of PKI.  Mozilla's generateCRMFrequest() simply isn't good enough:  http://demo.webpki.org/mozkeygen

Regards
Anders Rundgren

----- Original Message ----- 
From: "Thierry Moreau" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 23, 2008 22:07
Subject: The PKC-only application security model ...

Dear all:

Good reading.

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 24 Jul 2008 10:50:29 -0400

The phrase you're looking for is "Key Continuity Management," which will net
you a lot of research and deployed systems using it as a trust technique.
If that's your route you really don't need to shoehorn it into an X.509
structure.

-- Tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thierry Moreau
Sent: Wednesday, July 23, 2008 3:08 PM
To: [email-masked]
Subject: The PKC-only application security model ...

Dear all:

A)	The big picture refers to the "PKC-only application security
scheme", 
in which client-server applications may be secured with client-side 
public key pairs, but *no trusted certification authority* is involved 
(server operators are expected to maintain a trusted database of their 
clients' public keys).

Good reading.

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 24 Jul 2008 10:08:39 -0500

Anders Rundgren wrote:

> I got even more puzzled when you began listing ASN.1 constructs which I 
> fail to see how they apply to a conceptual model.

The ASN.1 constructs are essentially "tutorial" in nature.

The shortcut version would be sections 4.1, 4.2.1, 4.2.2.1, i.e. those 
where MUST and SHOULD appear.

> Exactly what do you find to be a problem with the current PKI model and 
> how does the PKC-only model address them?  BTW, the current PKI model 
> can be broken into two rather different variants; the RP-only-model and 
> the TTP-model.

Interesting. Does the RP-only model assume that the RP (relying party) 
issues certificates with its own private key?

If yes, then the meaningless X.509 security certificates brings a 
relaxation on this requirement. It does not bring much more than this 
relaxation.

If no, then there could be redundancy and I am very interested in 
specific references to the formal specifications for the RP-only model.

Incidentally, there is no ambition to fix the PKI model. Merely to apply 
PK without the "I"!

> I'm not aware of any conceptual problems with the RP-only model in which 
> the certificate is *almost* redundant since all important data about the 
> user is available from other [in-house] sources as well.

What about privacy concerns? (Not that the meaningless certificate bring 
a definitive answer in this respect, just that privacy concerns are more 
acute with a meaningful certificate.)

> The TTP-model OTOH suffers from all kinds of difficulties ranging from 
> basic issues like who is going to pay for the certificate (card), to 
> what is actually certified, as well as to liability concerns.
>  
> Other PKI Issues
>  
> IMHO, the reason why PKI hasn't got farther is because we still lack a 
> cheap and standardized "container" to keep private keys in, that works 
> in most computers without installation of proprietary middleware.  I'm 
> personally involved in solving this part of the infrastructure.  Another 
> issue is the unavailability of a standadized scheme for on-line 
> provisioning of PKI.  Mozilla's generateCRMFrequest() simply isn't good 
> enough:  http://demo.webpki.org/mozkeygen

I agree with these concerns and the relevance of these efforts.

> Regards

Same

-- 

- Thierry Moreau

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 24 Jul 2008 10:34:18 -0500

> If that's your route you really don't need to shoehorn it into an X.509

OK, I ran a search engine on this.

If you refer to KCM for server site certificates, my document is the 
other way around, i.e. *client-side* public keys carried in meaningless 
security certificates. (I did notice the reversed similarity when doing 
the research.)

The search engine result also pointed to KCM with S/MIME, perhaps as a 
trust model unlike PKI and unlike PGP web of trust. Quite honestly, I 
didn't review these search results.

Also don't forget that the idea behind my document is to leave protocols 
  and fielded implementations untouched - as far as I know, TLS (at 
least in the leading implementations) does not support client key pairs 
without an X.509 certificate.

Can we do e-commerce applications (protected by a client key pair) in a 
plain off-the-sheld browser based on the KCM trust model? I doubt, but 
your educated input would be welcome.

Thanks for the feedback,

-- 

- Thierry Moreau

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 24 Jul 2008 11:50:09 -0400

>security certificates. (I did notice the reversed similarity when doing

KCM applies on both sides.  SSH's RSA pubkey authentication method, for
example, is using KCM concepts even though it doesn't explicitly call it
such.

>didn't review these search results.

You should read Garfinkle's "Johnny 2: A User Test of Key Continuity
Management with S/MIME and Outlook Express."

http://www.truststc.org/pubs/5.html

It's a good starting point on KCM concepts.  The follow his references for
more.  Citeseer is your friend, BTW:

http://citeseer.ist.psu.edu/

>without an X.509 certificate.

Nothing stops you from generating a self-signed cert to transport keys via
protocols that expect X.509.  Your back-end logic need not apply X.509 trust
and validation rules, however.

Remember that the key to KCM is educating participants on how it works and
what to expect.  The Johnny 2 paper backs that up, IMHO, though the point
Simson and others are trying to make is that KCM is a more intuitive model
for otherwise uninitiated users, and thus easier to use than either
hierarchical or web of trust models.

Until we have an installed base of applications using explicit KCM models
the jury will probably remain out on the subject.  Personally I think they
have a point but the industry has gone a different way and usability issues
are a small rudder on a big ship.

>your educated input would be welcome.

Yes, but when using self-signed certs clients are going to get nagged with
trust warning dialogs until they set explicit trust on the server's cert.
This goes back to the education issue.  Firefox 3's new trust ceremony
implementation makes setting trust pretty simple to do though the number of
clicks is a little high.  You may run afoul of policy restrictions with IE
depending on strictness of domain security policy, but this won't affect
home users.

-- Tim

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 24 Jul 2008 11:44:40 -0400

Hi Anders, all,

I just want to point out that the generateCRMFrequest() is kinda buggy
(at least it was some time ago...). Indeed I exchanged some emails with
Jim Schaad and at the end we figured out that they are totally mis-using
the CRMFRequest outside CMC.

Can anybody put us in contact with the people that are developing that
part of the API in Mozilla/NSS so that we could try to fix the current
mess they are doing ???

I would point out that one of the reason why PKIs have not got further
(well, despite of what the common perception, PKIs are definitely widely
used in many different environments...!!!) is tied to *USABILITY*.

It is my belief that the usability problem and the difficulties in
interacting with CAs are the real issues we should really try to address
by promoting protocols that would take USABILITY in consideration.

Another issue that I would like to draw the attention to is the fact
that we are currently stuck with browsers to be the tool to interact
with CAs. CMC & SCEP try to decouple the need to interact with CAs by
using browsers. Historically browsers were the first applications that
had support for PK Certificates, but now we are using PK in many
different environments, and the need for an easy way to interact with
CAs is a real need, e.g. small devices, general applications, or, even,
the very same Operating Systems.

Part of the work I am doing, i.e. the development of PRQP, is actually
aimed to address these issues.

Later,
Max

Anders Rundgren wrote:
> *Other PKI Issues*

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 24 Jul 2008 11:29:15 -0500

> depending on strictness of domain security policy, but this won't affect

If the goal is to improve the education issue, may I respectfully 
suggest that the above deserves clarification.

In e-commerce applications, the client act as a relying party for the 
server, and the server acts as a relying party for the client (when 
protected by a client key pair). It is not clear to me in which role 
(relying party vs digital signatory) the client
a) gets nagged with trust warning dialog,
b) proceeds through the Firefox 3's new trust ceremony, and
c) runs afoul of policy restrictions with IE.

If the answer to a) b) and c) is "the cient as the relying party for the 
server's authentication", then it brings us to the very first role 
reversal identified in my reply: KCM in Firefox browser assists the user 
in her relying party role, while the PKC-only application security 
scheme cares about the user as a digital signatory.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 24 Jul 2008 14:15:33 -0400

Hi Timothy,

I find interesting that you think that the new Firefox 3 interface is
somewhat usable. I really think that they changed the original interface
to imitate IE behavior. In my experience, the new way to actually browse
an https website certified by a CA that is not part of the trust anchors
is totally unusable. The average response of the user is: this website
does not work. They really have no idea of what (and why should they?)
they have to do when this situation happens. The very same thing applies
to IE and their page with the red-shield "continue" option.

It is interesting that https connections to "untrusted" anchors are
treated with less trust than http connection. *WHY* ? Just to get more
money to have the trust anchors embedded into the applications ? In other
words: what makes an untrusted https connection more dangerous than an
untrusted http ?

This is just another example of how developers do not realize how complex
the trust management can be for the user, and the average level of awareness
about security. Presenting complex interfaces just to say that an https
connection is, indeed, at the same level of trust as an http connection
leaves the user with a frustrating experience (and distrust about security
in general).

Later,
Max

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 24 Jul 2008 20:14:24 +0200

Massimiliano Pala wrote:
> [...]
>[...]

You can use either the newsgroup
http://groups.google.com/group/mozilla.dev.tech.crypto/topics
or the mailing list
https://lists.mozilla.org/listinfo/dev-tech-crypto

Note that generateCRMFrequest is PSM code (the glue code between Fx and 
NSS) on which about nobody is working, but the part that formats the 
CRMF request is inside NSS, on which they are a number of Sun and Red 
Hat developpers working. If the problem is on the asn1 format, or 
support of the functionnalities they should listen.
Changes to the current format might require downward compatiblity or 
synchronisation with the Dogtag project, though :
http://pki.fedoraproject.org/wiki/PKI_Main_Page

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 24 Jul 2008 23:18:40 +0200

Hi Max,

IMO it doesn't help if Mozilla fixes bugs in
generateCRMFrequest()
because it is inferior anyway.  Lets say an issuer wanted to
specify
that a user must assign a PIN-code following some kind of policy
there is no place for that in CRMF AFAIK.

If you look on a more recent effort like IETF's KEYPROV, it
indeed supports a set of useful of key add-ons.  Unfortunately
KEYPROV does neither support PKI, nor support browsers.

A glaring omission in the current crop of PKI provisioning
schemes is the ability indicating that the private key is
generated
and stored in a TPM or similar.  Due to this and similar
disconnects, 99% (or more) of the TPMs featured in
mid-to-high-end laptops are never activated.

Regards
Anders Rundgren

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; "Scott Rea" <[email-masked]>
Sent: Thursday, July 24, 2008 17:44
Subject: Re: The PKC-only application security model ...

Hi Anders, all,

I just want to point out that the generateCRMFrequest() is kinda
buggy
(at least it was some time ago...). Indeed I exchanged some
emails with
Jim Schaad and at the end we figured out that they are totally
mis-using
the CRMFRequest outside CMC.

Can anybody put us in contact with the people that are
developing that
part of the API in Mozilla/NSS so that we could try to fix the
current
mess they are doing ???

I would point out that one of the reason why PKIs have not got
further
(well, despite of what the common perception, PKIs are
definitely widely
used in many different environments...!!!) is tied to
*USABILITY*.

It is my belief that the usability problem and the difficulties
in
interacting with CAs are the real issues we should really try to
address
by promoting protocols that would take USABILITY in
consideration.

Another issue that I would like to draw the attention to is the
fact
that we are currently stuck with browsers to be the tool to
interact
with CAs. CMC & SCEP try to decouple the need to interact with
CAs by
using browsers. Historically browsers were the first
applications that
had support for PK Certificates, but now we are using PK in many
different environments, and the need for an easy way to interact
with
CAs is a real need, e.g. small devices, general applications,
or, even,
the very same Operating Systems.

Part of the work I am doing, i.e. the development of PRQP, is
actually
aimed to address these issues.

Later,
Max

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 25 Jul 2008 12:03:31 -0400

The CRMF CertRequest contains a transaction id number, a certificate
template, and a list of control attributes.  RFC 4211 itself defines six
controls, and additional controls (such as requiring PIN activation for
use of the private key) can easily be defined.  However, unless there is
some sort of integrity mechanism between the CA and the token or TPM,
such signaling is useless - the user's workstation is a
man-in-the-middle that could easily say "sure, the private key is
protected on a TPM" and then go ahead and store it on a thumb drive.

Achieving a trusted path between the key storage device and the CA is
the challenge; including suitable signaling in a provisioning protocol
(CRMF, KEYPROV, or whatever) is a non-issue.  The certificate policies
extension has always been used by DoD to indicate (among other things)
whether the private key is stored in software, wimpy ("class 3")
hardware :-), or better ("class 4") hardware.  That extension is
meaningful only because the issuing workstations and token stock are
under control of the PKI, not the end user.

I'd be interested in learning how a CA can know that it is talking to an
actual "cheap, standardized, middleware-less" private key container, and
not someone pretending to be same.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anders Rundgren
Sent: Thursday, July 24, 2008 5:19 PM
To: Massimiliano Pala
Cc: [email-masked]; Scott Rea
Subject: generateCRMFrequest() Re: The PKC-only application security
model ...

Hi Max,

Regards
Anders Rundgren

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; "Scott Rea" <[email-masked]>
Sent: Thursday, July 24, 2008 17:44
Subject: Re: The PKC-only application security model ...

Hi Anders, all,

Later,
Max

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 25 Jul 2008 21:03:23 +0200

Hi Dave,
These are good questions which I will answer as well as I can.

Essentially any protocol can be augmented with additional data.
A problem with this particular case is that no standards organization
has AFAIK *ever* taken on a security-related standard with
browser bindings like Mozilla's generateCRMFrequest() or
Microsoft's CertEnroll. That KEYPROV is about
150 pages which gives a hint of how a complex NG-
provisioning PKI protocol could be.

Regarding the TPM trust indicator, there are a couple of
approaches that have one thing in common: the TPM device
has an embedded private key and certificate.  TPM 1.2
supports an incredibly elaborate and cryptographically
cool thing called DAA which even makes the connection
to the actual TPM device hidden.   Personally, I believe in
slightly less sophisticated solutions like embedding the
PoP signature in a TPM-signature.  This solution is not
100% malware proof (DAA is) but I don't find keeping
"secure" private keys exercisable by external PINs in
infected computers a particularly interesting object anyway.

Regards
Anders Rundgren

----- Original Message ----- 
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 25, 2008 18:03
Subject: RE: generateCRMFrequest() Re: The PKC-only application security model ...

Dave

-----Original Message-----

Hi Max,

Regards
Anders Rundgren

----- Original Message ----- 
From: "Massimiliano Pala" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; "Scott Rea" <[email-masked]>
Sent: Thursday, July 24, 2008 17:44
Subject: Re: The PKC-only application security model ...

Hi Anders, all,

Later,
Max