Subject: Issue 8: Certificate details review by Pasi and Valtteri

From: "James Kempf" <[email-masked]>
Date: Mon, 15 Sep 2003 13:32:28 -0700

Issue 8 concerns feedback from review board members Pasi and Valtteri, and
it contains a variety of subissues. Considering we've decided to go with
draft-ietf-pkix-x509-as-extn-01.txt instead of attribute certificates, some
of the subissues have been superceded. I list the subissues below together
with suggested resolutions.

Please send comments and preferences if you have any. If you want to have
deeper discussion on a particular subissue, please start a separate thread
with the subissue number in the title.

                    jak

------------------------------------------------

Issue 8a:
"The certificate transport is relatively straight-forward, but the
description of certificate chains could benefit from some clarifications and
examples showing at least one valid certificate chain."

Suggested resolution:
Since jak has been primarily been handling certificates, he will try to come
up with an example.

Issue 8b:
"Also, if certificates are used for both RD and non-CGA ND, any differences
should be described (e.g., in the ND case, would a PKC chain ending in an
iPAddress subjectAltName be sufficient, or do we also need the AC?)"

Suggested resolution:
1) The example doesn't apply, since PKCs with the IP prefix and address
range extensions as per draft-ietf-pkix-x509-as-extn will be used.
2) At the Vienna meeting, the WG decided to move non-CGA ND out of the base
spec, since there are no longer any IPR considerations for CGA, so the issue
doesn't apply to the base spec.

Issue 8c:
"Especially the selection of Attribute Authorities (valid AC issuers) seems
a bit strange.  The "trusted root" refers to valid PKC issuers, right? And
then all CAs (PKC issuers) in the PKC path (from the trust anchor to the
router's PKC) are also considered AAs.  Unfortunately, RFC 3281 (section
4.5) explicitly forbids this!  If this is done  anyway, it should be at
least well explained and justified.

Another aspect that requires clarification is the requirements placed on the
PKC chain.  At the minimum, the spec should say what requirements are placed
on subjectName, subjectAltName, and keyUsage.  Preferably the spec should
also give some recommendations for interoperability (see
draft-ietf-ipsec-pki-profile-02 for example).  Also, when specifying this,
the SEND spec should probably refer to the PKIX profile (RFC 3280) rather
than X.509 itself."

Suggested resolution: Superceded by using draft-ietf-pkix-x509-as-extn.

Issue 8d:
"o  Section 6.3 (editorial): In PKIX-speak, the correct term would probably
be 'trust anchor', not 'trusted root'."

Suggested resolution: Jari has said in an initial followup email that he
will make the change.

Issue 8e:
"o  Sections 6.3 and 6.6 (technical): Presumably, the 'trusted root' should
contain the issuer of the first certificate in the chain But for X.509
certs, that's a Distinguished Name, not FQDN.  So should the "trusted root"
option contain a DER-encoded Issuer DN instead of FQDN?

Using AltSubjectName (correct spelling is subjectAltName, BTW) seems to make
it more difficult for the router to decide which certificate to send, since
its own certificate doesn't necessarily have the CA's dNSName (though it may
be included in issuerAltName extension).

o  Section 6.5.1: The definition of the Holder field is a bit vague, and
goes against the recommendations of RFC3281 (if this intentional, at least
the reasons for doing so should be documented).  Our interpretation is that
RFC3281, in this particular scenario would strongly recommend using the
baseCertificateID syntax (instead of entityName or objectDigestInfo).

Also, even if entityName or objectDigestInfo is used, RFC3281 recommends
using only one of them, and recommends using only one entityName (not
multiple), and says that if entityName is used, it MUST match the PKC
certificate.

o  Section 6.5.1: If objectDigestInfo is used with
digestedObjectType=publicKey, RFC3281 already specifies how objectDigest
field must be calculated (section 7.3)."

Suggested resolution: These issues are superceded by use of
draft-ietf-pkix-x509-as-extn.

Issue 8f:
"o  Section 6.5.1: Normative reference to an expired Internet-Draft (for the
AuthorizedSubnetPrefix) probably isn't a good idea.  Since it seems that the
pkix-x509-ipaddr-as-extn draft is dead, either the relevant definitions
should be copied here, or documented in a new, separate internet draft."

Suggested resolution: The draft is not dead, it just passed through WG Last
Call in the PKIX WG, and will be the basis for a certificate hierarchy for
routing address range delegations, including for SEND, when it is approved
by the IESG.

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