Subject: Re: [pkix] Certificate enrollment at Beijing IETF?

From: Massimiliano Pala <[email-masked]>
Date: Thu, 04 Nov 2010 10:17:20 -0400

On 11/04/2010 05:27 AM, Peter Gutmann wrote:
> Massimiliano Pala<[email-masked]>  writes:
>
>> (1) Analyze what of the CMP&  CMC standards we could reasonably save.
>
> We'd also need to look at where CMP/CMC went wrong and SCEP didn't.  I think
> the main one is that SCEP is really simple to implement (take anything that
> does PKCS #10 and PKCS #7 and you have about 95% of what you need to do SCEP
> already done for you), while the CM*s are incredibly complex and hard to get
> right, including (at least for CMP) features that make no sense and/or whose
> interpretation no two people can agree on.
[...]

I agree. The success of SCEP is its simplicity and availability of code
supporting the message format in every crypto stack.

>> (2) Provide a simple (updated version of SCEP) and an advanced (taylored
>>     vesion of CMP/CMC) enrollment protocols in two new working items.
>
> All we really need is SCEP updated to handle signature-only algorithms
> (DSA/ECDSA).  In theory there's DH/ECDH, but how many of those certs have you
> seen, ever?  Currently SCEP requires encrypt + sign, the sig-only version
> would just send signed-only data.

+1

>> (a) One thing that is lacking from current enrollment environment is the
>>    possibility for a client application to query the CA for the required
>>    data to be submitted when requesting a certificate (that can be data
>>    to be put in the DN and/or other data that will not be present in the
>>    final certificate)
>
> This is just adding needless complexity again... for pretty much the entire
> history of interactive cert issue (meaning to browsers, mail clients, web
[...]
> people a basic cert-provisioning protocol and you'll keep 99% of users happy
> with a minimum of fuss.  Anyone that wants more can choose to use CMP/CMC.

Here I disagree. Well, I am probably thinking about non-interactive environments.
When you talk about browsers, the "list of required data to submit" during the
request process is the form that the user fills in before generating the
cert request. Most of the time there's more data in the form than what goes
actually in the PKCS#10 one.. or in the final certificate.

What I am proposing here (and I *TOTALLY AGREE ON THE NEED TO KEEP IT SIMPLE*)
is to add the same feature for non-interactive applications.

For example, I have my data somewhere (and I input them only once), when an
application (browser, mail, word-processor, game, etc...) wants to request a
cert it could check if the required data is already available and, if not, it
can ask the user and submit a valid request. The alternative is for the client
to have to get a HTML form, extract the fields, etc.. too complicated!

Cheers,
Max

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 04 Nov 2010 21:46:28 +0100

Massimiliano Pala wrote:
<snip>
 > can ask the user and submit a valid request. The alternative is for the
 > client to have to get a HTML form, extract the fields, etc.. too complicated!

For me this is almost completely gibberish.  It may be me being plain stupid
or that you haven't made any attempt to describe things in more detail.  It
also possible that your interest is more leanings toward edge cases and research
than mine.  Anyway, this is what pop up:

- Why do you suddenly need a certificate?
- How do you locate the CA?
- How do you authenticate to the CA?
- Why do you need additional data, and how does the CA verify this data?

Let me take a real-world example.  Blizzard apparently offers
a strong authentication option for serious WoW (World of Warcraft)
gamers.  They get it by purchasing an OTP token in a web-shop:
http://eu.blizzard.com/store/search.xml?q=authenticator

Then I *assume* that after you get the token associate it with your
account (using the web) which turns the account in "strong auth mode".

Now lets dress this in PKI.

1. When you start WoW there could be a link saying
For strong authentication get your BlizzardCert.

2. This would take you to the Blizzard CA (using the browser) which
would get the WoW userid/password encrypted in the URL.  After that the
enrollment will start.  If successful there will be a Blizzard key in
the Windows keystore and the account will be set in "strong auth mode".

3. The next time the user starts WoW it will automatically
discover the BlizzardCert and just use it.

Summary: 2-3 clicks is all you need to put a userid/password to rest!

The advantages of using a browser are plenty:

- Arbitrary enrollment processes
- Arbitrary authentication method (email-roundtrip, uid/pw, OTP, SMS, PKI, biometry, etc.)
- Flexible backend system integration
- Minimal need for application upgrades due to use of PKI

So what's stopping us?  Horrible stuff like CertEnroll, and compared
to the OTP token (which is pre-provisioned), no functioning way of
doing on-line provisioning of PKI tokens.

Anders

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Thu, 04 Nov 2010 23:46:07 +0200

> discover the BlizzardCert and just use it.
oh really? How about providing some kind of proof of control? It's as 
much "automatic" as you accept the risk (maybe not much risk for WoW 
type things).

Thanks,
M.D.
cell: +370-699-26662

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

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 05 Nov 2010 09:54:40 +0100

<snip>

> much "automatic" as you accept the risk (maybe not much risk for WoW 

So you mean that an ever increasing set of userid/password combinations
(or reused such which many people including myself degenerate to),
is a more future-proof concept?

In a lot of commercial settings like the WoW case, you don't even need
vetted identities, the alias "Terminator" and your account number
is fully sufficient.  I call this "account integrity" which is very
different from eID which is more like "absolute identity" (whatever
that is...).

However, the proposed and published scheme is in fact equally adapted to
PIV and eID (without surface personalization NB), but that is something
that also relies on other infrastructural things, most notably NFC.

Anyway, I didn't from your question fully understood what your concerns are about.

Regards
Anders Rundgren

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 05 Nov 2010 10:59:21 -0400

On 11/04/2010 04:46 PM, Anders Rundgren wrote:
> Massimiliano Pala wrote:
> <snip>
>  > What I am proposing here (and I *TOTALLY AGREE ON THE NEED TO KEEP IT
[...]
> complicated!
[...]

Sorry you missed the point, I though it was quite clear.

> - Why do you need additional data, and how does the CA verify this data?

Read this (work that I planned on porting to the PKNG WG.. if it is not going
to be closed soon):

    http://portal.acm.org/citation.cfm?id=1750389.1750404

Cheers,
Max

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 05 Nov 2010 18:09:16 +0100

Massimiliano Pala wrote:
> Read this (work that I planned on porting to the PKNG WG.. if it is not 
> going to be closed soon):
> 

I believe this was the missing link; we are talking about a *research*
effort that address uses of PKI that do not exist today.  I don't
understand this idea but I wish you good luck!

My interest is simply making PKI "a better password" which according
to most people in this space either is impossible or should be done
by vendors like Gemalto, Microsoft and Apple.

Anders