Re: WG Last Call: Son-of-2459

[Steve Hanna <steve.hanna@xxxxxxx>]

For the record, I do not agree with these comments and I do not think
that any changes should be made to new-part1 because of them. My
responses are interspersed.

Denis Pinkas wrote:
> ... but, in section 6, there is nearly no text on name constraints.

The text on name constraints in section 6 is perfectly adequate, when
combined with the text in section 4.2.1.11.

> I have found some time to take a look at section 6 from the long awaited
> Son-of-2459, and I am disappointed. We spent quite an hour sitting
> together with you during the Pittsburgh meeting to add the name constraints
> to section 6.2 and I can't find that text. :-(

Substantial changes to IETF working group documents should be the result
of open discussions on the mailing list so that rough consensus can be
judged. Clarifications and simple corrections can be made by the
document editor on the basis of private conversations, but any
significant changes should at least be announced to the mailing list to
see if they reflect rough working group consensus before incorporating
them into the document. I haven't seen these changes (some rather
substantial) discussed before on the list, so I'm not surprised that
they didn't make it into the document.

> So let us go one by one at the changes that are required, and a few more
> that we did not discuss. This makes 14 change proposals altogether:

I will address only some of the change proposals. This does not mean
that I agree with the ones I omit.

> 2. Page 58. Current text:
> 
>    The
>    binding is limited by constraints which are specified in the
>    certificates which comprise the path and the initial state variables
>    which are specified by the relying party.
> 
> Proposed change:
> 
>    The binding is limited both by constraints which are specified in
>    the certificates which comprise the path and the initial state
>    variables which are specified by the relying party, such as
>    certificate policy and name constraints.
> 
> Rational: name constraints were missing.

First, the text you quote as "current text" is actually from
draft-ietf-pkix-new-part1-03.txt. In draft-ietf-pkix-new-part1-04.txt,
this sentence has been changed to read "The binding is limited by
constraints which are specified in the certificates which comprise the
path and inputs which are specified by the relying party." The state
variables are initialized based on the relying party's inputs in the
initialization phase (section 6.1.2).

Second, in the basic validation algorithm described in section 6.1, the
relying party does not supply name constraints. Name constraints are
only provided by intermediate CA certificates. Some implementations may
extend the algorithm described in section 6.1 (using various techniques
such as those described in section 6.2), but I will argue strongly that
we should not include name constraints as an input to the basic
validation algorithm described in section 6.1. This is an unusual
feature and not commonly useful. It would be too great a burden to
require all implementations of the PKIX validation algorithm to include
support for it. That's why it belongs in section 6.2 and not in section
6.1. And, actually, it's not clear to me that it needs to be in section
6.2. Anyone is welcome to add support for specifying name constraints on
for each trust anchor or policy constraints or EKU constraints or
whatever they want. We don't need to describe how all of that would
work. We just need to describe the required algorithm and a few common
extensions (like multiple trust anchors).

> 6. Page 60. Current text:
> 
>    However, a CA may issue a
>    certificate to itself to support key rollover or changes in
>    certificate policies.
> 
> Proposed change:
> 
>    However, a CA may issue a certificate to itself to support either
>    public key rollover, both public key rollover and changes in
>    certificate policies and/or name constraints.
> 
> Rational: name constraints were missing.

Including name constraints in a self-issued certificate is pretty
unusual (and not likely to be very effective). In general, I suggest
finding a trusted CA (or a small number) and having them issue cross
certificates (with name constraints and any other fancy stuff). This
avoids the problem of having many trust anchors with various name
constraints, which must be replaced manually if the constraints change
(due to marketing, mergers, etc.).

-Steve