pem-dev
[Top] [All Lists]

Re: PEM Test Service

1993-02-24 12:19:00
2. Vint and Wolfgang are both correct.  RFC 1422 does tightly couple the
  naming hierarchy with the certification hierarchy.  The principal
  reason for this is a pragmatic one: distinguished names must be
  unique and unambigous.  In the absence of registration services PEM
  needed a mechanism to satisfy this requirement.

  Now, we can discuss the choice that was made, and make a motion to
  use other choices, but let us focus on the technical issue.  There
  will be opportunities to revise the RFC to allow other choices.

I've no problem with pragmatic decision made.  The discussion I've
raised centers around how well the certification hierarchy will be
coupled to the naming hierarchy.

3. In beginning our beta testing of TIS/PEM, we had to consider what to
  do about approving or disapproving an individual's or organization's
  distinguished name.  After much discussion we decided it was very
  difficult for us to pass judgement on the choice of distinguished
  names.  At most, there were names we knew were wrong but it did not
  make sense for us to decide what was right.

  Therefore, what we decided is that we would offer all the advice and
  guidance we had to the process of choosing a name, but as long as the
  name was not wrong and it was consistent with the suggestions in RFC
  1255 and it was consistent with the PEM requirements in RFC 1422, we
  would allow it.  The caveat we emphasized to all organizations and
  individuals is that *THEY* are responsible for their distinguished
  name and how it is used.  We reserve the right to tell them their
  name is wrong at some point in the future and therefore must be
  changed.

My whole argument (well most of it :-)) has been that getting the DNs
right now will mean a lot less of "you chose poorly, now fix it!" later.
In the case of organizational names in DNs, you can very well determine if
they fit in with the SD-5 scheme (assuming you care to buy into this
scheme), and you can avoid creating untenable DNs.  Sure, it is not TIS's
problem, but by pushing the problem to the user, you have still placed
yourself in a registration role -- no one else is out there avoiding
DN conflicts.  Certainly not the users who create their own DNs from the
void.  I'm not criticizing you, but merely stating that real care must
be taken now, not later.  (And I don't comment on Wolfgang's requirements
because I don't claim to understand them fully).

  Although this sounds harsh it really isn't.  We expect that this
  policy will be an element of all PCA policies.  Let face it, we're
  all learning about distinguished names.  There is a culture that
  needs to be established within the community of the "common man".  We
  should expect change as we gain more experience with this issue.

And I suggest that extra work now, to bring us all up to speed on DNs
will be well worth the investment.

  Toward this end, our PCA issues CA certificates with a 3 month
  validity period.  This allows for fairly quick changes to
  distinguished names, if necessary.

Great.  As long as no one assumes that renewal of the CA name is guaranteed
should there be a problem, this would seem to be a helpful policy.

                                                        -Peter

<Prev in Thread] Current Thread [Next in Thread>