Subject: Resolution of Issue 20: Francis Dupont's certificate issue and the general issue of a Certificate Profile

From: "James Kempf" <[email-masked]>
Date: Wed, 10 Sep 2003 10:04:46 -0700

The email on proposed solutions to Issue 20 generated no comment from the
WG. In the interest of having a unified IETF certificate profile for routing
certificates, I'd suggest we go forward with proposal E:

  Support delegation through using the mechanism described in
draft-ietf-pkix-x509, with perhaps some minor specification of conventions
to satisfy SEND requirements.

This will set up a normative reference dependency between the SEND drafts
and draft-ietf-pkix-x509, requiring that draft to advance to PS before SEND
does.

Since I took the action item in Vienna to look into the cert profile, I will
study draft-ietf-pkix-x509 and see whether any additional specification is
required for SEND. If so, I will provide Jari with text describing it. If
not, the section on the SEND certificate profile will have a single
sentence, referring to draft-ietf-pkix-x509.

            jak

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 19 Sep 2003 11:34:37 +0300

[An old message resent; this never game through.]

James Kempf wrote:

> The email on proposed solutions to Issue 20 generated no
> comment from the WG. 

After having thought about this for quite a while, and considering
the long and short term pros and cons of different approaches,
I have come to the following conclusions:

> A) We could ignore prefix delegation and even prefix certification '
> entirely, and just have the host certify the router's identity.

A) would be pretty bad from the security point of view, and it
would not fulfil many of the goals in the psreq draft.

> B) We could ignore prefix delegation but provide support for prefix
> certification by using Attribute Certificates,

B) would be acceptable to me.  On the other hand, we would have
to understand the scalability consequences.

> C) We could support delegation using a parallel Attribute
> Certificate chain, along with the Identity Certificate chain.

C) would be close to the "right" approach, but result in very complex
operations in the hosts.  I don't like that kind of unnecessary
complexity.

> D) We could talk to Russ and Steve Bellovin about opening up
> RFC 3281 to allow Attribute Certificate chains to support
> prefix delegation certification.

In my opinion, D) would be the architecturally right choice.  However,
this would take quite a long time, and might even fail.

> E) We could support delegation through using the mechanism
> described in draft-ietf-pkix-x509,

Even though I don't like E) from an architectural point of view,
it looks acceptable.  It is simple enough to define, simple enough
to implement, secure, and scales appropriately.  It also delegates
the hard problem of setting up the infrastructure to another WG.

> In the interest of having a unified IETF certificate profile for routing

Based on my conclusions above, I find this proposal good.

--Pekka Nikander