Requesting last call on proxy certificate draft

[Von Welch <welch@xxxxxxxxxxx>]

Steve and I would like to bring the Proxy Cert draft to a conclusion
in PKIX, either by agreeing to drop it or by pushing it forward to
last call. The informal straw poll on the draft indicated enough
positive feedback (I counted 6 or 7 positive votes with 1 or 2
negitive votes) with this approach that we would like to go ahead and
request that it be put it up for a last call by the working group
chairs.

In preparation for this we have resubmitted the draft:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-03.txt
(This now has corrected section numbers, btw.)

I've also listed the issues raised in previous conversation on the
email list and given our responses to them below. As we've expressed
before, we are interested in any feedback on the details of the
document and are quite willing to let this group influence them. But
at this point we feel we have addressed all of the input we have
received, so in the absence of further input we feel the draft is
ready to push forward to last call.

Steve's summary of the draft is available at:
http://www.imc.org/ietf-pkix/mail-archive/msg04466.html

Von

--
Issues raised and our responses:

* Why not just issue subordinate CA certificates with name constraints
to all users who want to issue proxy certificates?

Two reasons: First, none of the CA operators we've talked with would
do such a thing. Second, name constraints seem to be largely
unimplemented, with some implementations completely ignoring them. So
this approach would take large changes in the both CA operations to
issue such certificates and the installed code base to correctly
support name constraints.

Further, given that most current implementations do not have name
constraints support, it would be more dangerous to go this route,
because implementations that do not have name constraints could be
easily spoofed.  With our proxy cert approach, a proxy cert will be
rejected by any existing implementation because of both the CA bit
check, and the critical extension check.  (If an existing
implementation does not support at least one of these checks, then
proxy certs do not add any additional vulnerability.)

* Can we support proxy certificates by addition to path validation
instead of change to path validation?

The issue was raised if proxy certificates could be supported with
only additions to path validation instead of changes:
http://www.imc.org/ietf-pkix/mail-archive/msg04568.html
http://www.imc.org/ietf-pkix/mail-archive/msg04477.html

To recap, proxy certifications don't work with current path
validation code since we would need the keyCertSign bit asserted in
end-entity certificates that are allowed to issue proxy
certificates. Unfortunately RFC 3280, section 4.2.1.10, prohibits the
keyCertSign bit from being set in non-CA certificates. This leaves us
with the options of either issuing subordinate CA certificates
(previous issue) or setting the keyCertSign bit independant of the CA
bit and being non-compliant with 3280.

In the authors opinion that while it is possible to implement proxy
certificates with additions to path validation, it is easier to do so
by making modifications to current path validation code as described
in the draft. This has been reinforced with our experience with doing
the implementation in GSI.