Re: [IETF-PKIX] RFC 822 names in SubjectAltName and otherextensions

[Robert Jueneman <BJUENEMAN@xxxxxxxxxx>]

Steve, I agree with that burying Non-verified Subscriber Informatioon (NVI/ NSI?) in a CPS won't do.  But on the other hand, there is a clear and compelling need for NSI, especially for proprietary attributes.

It would certainly be nice if we had a convenient indicator, much like the Critical indicator.

Perhaps someone can think of a good way of extending the standard to facilitate this?

Bob

>>> Stephen Kent <kent@bbn.com> 03/14/98 01:18PM >>>
Paul,

Sorry to have let this languish in my inbox.  When last we discussed this
issue we had resolved that we were in opposite camps re inclusion of
non-verified data in certs, in general, so the matter of including comments
along with the portion of the mailbox name that is used to control delivery
is just one example of this difference of opinion. I'm not sure we have
discussed the NVI matter as much on PKIX ad it had been discussed on PEM in
the past, but there never seems to be complete resolution.  In general, I
think that if a CA does elect to include NVI in a cert, it ought to be
included in extensions that don't have widespread use and a common
interpretation that could result in users being mislead.  Private
extensions are the obvious examples.

As you point out, the CPS for a CA can state whether the more "user
friendly" part of a mailbox name has been verified or not, just as it
states other aspects of the authenitcation process. However, I fear this is
begging the question.
Most folks will not read a CPS, especially if it goes into that level of
detail, and thus what the fine print says will not matter unless one
litigates a dispute.

I argue that we ought to be careful to not foster a situation that unduly
creates an opportunity for confusion.  While 822 addresses (and DNS names)
have a suitable infrastructure for establishing accuracy and uniqueness,
once one adds other, informal identifiers added to them pose more of a
problem. If one wants to include this other info in a cert, how about
including it as a common name component of a DN?

Steve