Subject: [pkix] Certificate enrollment at Beijing IETF?

From: Stefan Santesson <[email-masked]>
Date: Sun, 31 Oct 2010 12:18:10 +0200

We have a relatively thin agenda for the Beijing meeting so far (I will post
a draft today)

Does anyone here have anything they would like to present on the enrollment
issue at the Beijing meeting?
Send an e-mail to me or the list if you do.

I can see a number of issues worth talking about:
- Advancement of SCEP to RFC
- What should be standardized in the enrollment space
- How should we structure the problem
- What work should be done in IETF/PKIX

/Stefan

---

From: Massimiliano Pala <[email-masked]>
Date: Sun, 31 Oct 2010 13:39:32 -0400

Hello Stefan,

First of all, I am really glad that this topic finally came along :D
But at the same time, I am bummed because I will not be able to
participate to the discussion in Beijing.. :(

If I recall correctly, SCEP has been proposed to be advanced as
standard - I was there at the IETF meeting. And the answer was,
more or less "No, we already have RFCs that cover the matter, we
don't want to move SCEP to RFC status - you might want to publish
it as Informational".

It was a pretty "firm" reply - I guess from Steve - but that was
shared by the people present. And I thought the discussion about
SCEP was actually over.

I followed the thread on the list, and I would be in favor of
having SCEP as an RFC. This said, we would go against the principle
of having duplicated protocols.

Summarizing, I guess the way forward could be:
- moving SCEP to RFC status (not likely because of duplication of
   protocols)
- updating the existing RFCs and integrate SCEP as the "simple" case
   (more likely)
- move SCEP as Informational (as it was supposed to be)

As an active developer, I really liked SCEP for its simplicity and I
continue to support it in LibPKI and future versions of OpenCA. This
said, I think a revision of the PKIX enrollment space should be done.

Related Question:

I was wondering if you are aware of popular products that implements
*ALL* of the CMC and CMP features, not only the "easy" cases.
If there are none, then we might take the opportunity to simplify the
RFCs to make them easier to implement (?). I think this is important
to allow developers to easily implement efficient enrollment systems in
their apps (not only browsers..) thus increasing the "Usability" of PKIs.

Just my 2 cents,

Cheers,
Max

On 10/31/2010 06:18 AM, Stefan Santesson wrote:
> We have a relatively thin agenda for the Beijing meeting so far (I will
> post a draft today)
>
> Does anyone here have anything they would like to present on the
> enrollment issue at the Beijing meeting?

-- 

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: Sun, 31 Oct 2010 19:34:25 +0100

Massimiliano Pala wrote:
> I think this is important

Could you elaborate a bit on what kind of "apps" that would gain by having
certificate enrollment as a built-in feature?

I personally don't see the enrollment schemes built-in browsers as a way to
provisioning PKI for browsers, but for the entire client-platform.

Anders

---

From: Massimiliano Pala <[email-masked]>
Date: Sun, 31 Oct 2010 15:31:07 -0400

Responses Inline.

> certificate enrollment as a built-in feature?

I don't really think this is the point. But I guess many. E.g., mail, webmail,
ad-hoc business apps, grid/cloud apps, etc...

> provisioning PKI for browsers, but for the entire client-platform.

I think platform-specific certs are related to platform auth, what we deal
with here, moslty, is per user/app auth. I would say that the two things are
different and both are important. For example, think about the case where the
platform is shared among different processes/users, we might want to authenticate
the user, not (only) the platform.

Cheers,

-- 

Best Regards,

	Massimiliano Pala

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 31 Oct 2010 12:58:34 -0700

>- Advancement of SCEP to RFC

If the SCEP draft isn't part of the WG, than the WG doesn't get to help or hurt such advancement.

>- What should be standardized in the enrollment space

I know! How about CMP and CMC?

>- How should we structure the problem

We could ask the implementers who have the problem (just a thought...)

>- What work should be done in IETF/PKIX

...more than what we already have?

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 31 Oct 2010 21:40:46 +0100

Paul,

Sharp and to the point as usual..

> I know! How about CMP and CMC?

Good, at least one who think that solves the problem!
And that might very well be the answer.

> We could ask the implementers who have the problem (just a thought...)

Well, I sort of just did (I hope).

> ...more than what we already have?

Yes, I kind of hoped that was obvious from the question.

/Stefan

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 31 Oct 2010 22:24:44 +0100

Massimiliano Pala wrote:
>> Could you elaborate a bit on what kind of "apps" that would gain by 
>> having certificate enrollment as a built-in feature?
> 
> I don't really think this is the point. But I guess many. E.g., mail, 
> webmail, ad-hoc business apps, grid/cloud apps, etc...

Max,
I'm trying to understand what you mean by increasing the usability of PKIs
but so far I don't get it :-(

Why would e-mail clients benefit from built-in certificate enrollment?
IMO, you would severely *cripple* a PKI by putting enrollment in
apps like e-mail.  In the end you would probably have to build a browser
into the e-mail client itself and then I don't see what they gain was.

Aren't you actually talking about server certificate enrollment?

> 
>> I personally don't see the enrollment schemes built-in browsers as a 
>> way to provisioning PKI for browsers, but for the entire client-platform.
> 
> I think platform-specific certs are related to platform auth,

I didn't refer to platform auth but to systems like Windows (and phones)
which keeps a central repository for keys.

> what we deal with here, moslty, is per user/app auth.

Yes. However, an enrollment scheme alone doesn't solve enable per/app
keys unless you actually have separate keystores or as I hope to do:
provide a means to "target" a key.

What I'm trying to say here is that this discussion seems to avoid/ignore
architectural details of the underlying keystore, something competing schemes
including GlobalPlatform addressed years ago which makes me question if PKIX
will be able to pull off anything particularly useful.  By "abstracting" interfaces,
E2ES is (AFAICT) unachievable and the enrollment system will be DoA.

I recommend PKIXers with interests in enrollment to study GlobalPlatform or
SKS/KeyGen2 and see if you after that still believe that principles
established 10-15 years ago actually are equally valid today.

It is also worth mentioning that Microsoft's enrollment system has been
rejected by the majority of the big consumer/citizen "soft" PKIs in the EU.
CertEnroll is completely useless for that purpose and it cannot provision
smart cards either.

  I would say that the two things
> are different and both are important. For example, think about the case 
> where the platform is shared among different processes/users,

Processes: see app/key
Users: a solved problem both for "soft" and "hard" (connected) keys

> we might want to authenticate the user, not (only) the platform.

The scheme I have devised doesn't have any notion of *what* you
certify, it could be you, your computer, a server, your cat,
you name it.

Anders