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

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: Robert Jueneman <BJUENEMAN@NOVELL.COM>
>
> 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,

I agree too that there should be a way to indicate "comment" information
that is either not verified by the CA or not intended to be acted upon
(enforced) by the relying party.   X.509 apparently recognizes this need
too; unfortunately the mechanism chosen to implement it was to overload
the meaning of the CRITICAL extension bit.

The CRITICAL bit was originally intended (when unset) to allow
implementations which do not understand a particular extension to use
the remainder of the certificate in which it appears.  However, the
description of several extensions now use that bit to modify the
meaning of the particular extension in implementations which *do*
support it.

I don't know of a good way of extending the standard to facilitate the
inclusion of Non-Verified or Non-mandatory information in certificates,
but can think of four ways with varying degrees of badness:

* Define the v4 Extension syntax to include both a CRITICAL
  bit and a COMMENT bit.  This would be non-backward compatible in
  the same sense that v3 is not compatible with v1 - the COMMENT
  bit would be DEFAULT FALSE and v4 would not be used unless some
  extension had it set TRUE.  It's probably unthinkable to do a
  version rev at this point - forget I mentioned it :-).

* Redefine the syntax of each extension (such as subjectAltName) to
  include a NVI/COMMENT/NON-REQUIRED bit, superceding the OIDs for
  the existing extensions.

* Define duplicate parallel extension OIDs, (such as subjectAltName
  and nvSubjectAltName) to denote verified/mandatory and non-verified/
  optional information.

* Continue along the current path, and overload the CRITICAL bit
  to modify the extension's meaning.  In the case of subjectAltName,
  this would not allow one portion of an RFC822 name to be verified
  and another to be non-verified; the entire extension would have the
  same status, and there can be only one instance of that extension in
  a certificate.