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

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Aug 2003 15:12:51 -0700

Francis Dupont raised several issues about the certificate format in his
review of the SEND draft. Rather than address these specific issues,
however, I'd like to open the discussion somewhat wider, to include exactly
what SEND should do w.r.t. a certificate profile for certifying advertised
subnet prefixes by routers.

A certificate profile for SEND seems advisable, since interoperability for
certification verification is otherwise not assured, and such profiles have
been necessary in other cases (example: TLS).

The approach taken in draft-ietf-send-ipsec was to use RFC 3281 Attribute
Certificates. The text in that draft specified certain conventions in using
Attribute Certificates for SEND that would allow a host to determine whether
a router was certified by a trusted intermediary to advertise a collection
of subnet prefixes. Francis' comments addressed certain of the details
specified in the draft that involved adapting Attribute Certificates to
SEND. The specification in the draft did not include any support for
certified prefix delegation. RFC 3281 forbids Attribute Certificate chains,
so the specification included identity certification delegation through a
chain of Identity Certificates, with the chain ending in an Attribute
Certificate signed by the holder of the key certified in the last Identity
Certificate. The host could certify the public key and thereby determine
that the router was authorized to route the prefixes in the Attribute
Certificate, but it couldn't trace back the prefix delegation.

Subsequent discussion on the list and in Vienna established that some WG
members wanted the ability to trace prefix delegation back to the trusted
intermediary. There was some discussion in Vienna and on the list about
modifying RFC 3281 to allow Attribute Certificate chains for this purpose.
An alternative would be an Identity Certificate chain along with a set of
paired Attribute Certificates for each prefix delegation.

Russ Housley, AD for Security, recently advised Pekka and I that the PKIX WG
 has been dealing with the same issue in the context of SBGP. The goal there
is to allow any entity that receives a prefix delegation - ISPs,
enterprises, routers, etc. - to verify the delegation. The solution is
described in draft-ietf-pkix-x509-ipaddr-as-extn-01.txt. This draft is now
in Last Call in the PKIX WG.

In this solution, no Attribute Certificates are used. Instead, the
delegating entity adds a few attributes to a standard Identity Certificate
and signs the certificate, thereby certifying the prefix delegation. The
draft supports a variety of delegation designations, one being a prefix
format similar to that specified in draft-ietf-send-ipsec. In Appendix C,
the draft goes on to argue that Attribute Certificates are the wrong
mechanism for address prefix delegation because:

1) The certificates used for prefix delegation are used exclusively for that
purpose, so their lifetimes would match exactly that of an Identify
Certificate used to certify identity. One reason for using Attribute
Certificates cited in RFC 3281 is that the lifetimes of the attribute
certification and identity certification would differ.

2) The certificate hierarchy is constructed so that the certificate issuer
is also authoritative for the prefix delegation authorization. For example,
if an ISP receives a certified delegation from an RIR, then the RIR is both
the certificate issuer and the source of certification for the prefix
delegation authorization. Another reason for using Attribute Certificates
cited in RFC 3281 is that the issuer of the Identity Certificate and
Attribute Certificate are different.

Appendix C goes on to list several other requirements for applicability of
Attribute Certificates in RFC 3281 that it claims are not applicable to
certifying prefix delegation.

With reference to the above discussion, the following are possible
alternatives for generating a certificate profile:

A) We could ignore prefix delegation and even prefix certification entirely,
and just have the host certify the router's identity. The certificate
profile would specify standard RFC 3280 Identity Certificates with perhaps
some conventions on the name used for identity determination, but no special
prefix attributes. Later, if prefix certification or delegation
certification becomes important, the modified profile could be specified in
a separate draft.

B) We could ignore prefix delegation but provide support for prefix
certification by using Attribute Certificates, as in draft-ietf-send-ipsec.
Again, if delegation certification proved important, it could later be
specified in a separate draft.

C) We could support delegation using a parallel Attribute Certificate chain,
along with the Identity Certificate chain. Each Attribute Certificate would
be signed by the public key certified by the holder of the delgeating
authority's Identity Certificate. Note that this might require a change in
the DCA mechanism to handle the increased (potentially double) certificate
exchange load.

D) We could talk to Russ and Steve Bellovin about opening up RFC 3281 to
allow Attribute Certificate chains to support prefix delegation
certification. We would probably have to specify the certificate profile for
SEND in a separate draft if we did this, since modifications for RFC 3281
might take a while.

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

Comment from the WG on these options, preferences, and any additional
options that might have been missed is invited.

            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
--------------------------------------------------------------------