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

[Dean Povey <povey@xxxxxxxxxxxxxxx>]

>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.

There is a 5th option, create a non-critical comment extension:

id-ce-comment OBJECT IDENTIFIER ::= { ... }

Comment ::= SEQUENCE OF Extension

The Comment Extension has the semantics that anything defined under the
Comment extension is not verified.

Just my $0.02.





--
Dean Povey,                             |  Email: povey@dstc.qut.edu.au
Research Scientist, Security Unit,      |  Phone: +61 7 3864 2799
CRC for Distributed Systems Technology  |  Fax:   +61 7 3864 1282
Brisbane, Australia                     |  http://www.dstc.qut.edu.au/MSU/