RE: PKIX Part I - Name Constraints

[Charles Moore <cmoore@xxxxxxxxxxxxx>]

> -----Original Message-----
> From:	Russ Housley [SMTP:housley@spyrus.com]
> Sent:	Tuesday, 16 September 1997 0:34
> To:	Warwick Ford
> Cc:	ietf-pkix@tandem.com
> Subject:	Re: PKIX Part I - Name Constraints
> 
> At 08:07 PM 9/13/97 -0400, Warwick Ford wrote:
> >>2.  To deal with the exception that you propose, we need to add a
> >>dependency between rfc822 alt names and X.500 Distinguished Names.
> I do
> >>not like this if we can avoide it.
> >
> >RFC822 names in altnames are not impacted.  They are treated exactly
> as in
> >the standard.  In fact, nothing related to the standard is impacted.
> What
> >I am proposing is simply one additional rule that PKIX imposes, which
> is a
> >perfectly reasonable thing for a profile to do.  If there is an
> RFC822 name
> >constraint in force, we just impose one further check on the Subject
> field.
> > Very straightforward to implement (if you are already implementing
> name
> >constraint logic).
> >
> >Without this rule, I believe that many early Name Constraints
> >implementations will have a major loophole.  I think it is a PKIX
> >obligation to provide the rules to secure the migration from the old
> ways
> >to the new ways.
> 
> [Charles Moore]  I think there are two separate issues here a) the
> attribute support within the DN and b) the support for name forms.
> 
> With regard to the first, PKIX should NOT limit support, all
> implementations should be able to support any attributes here ( it
> really not a big deal). The support for RSA SMIME is but one example
> and should not be singled out within PKIX. But I would agree that if
> there is support for the PKCS9 e-mail attribute then these should be
> constant with RFC822, but others may have a different view.
> 
> With regard to b) DN's are ok, altnames are ok as well, PKIX should
> not force a particular implementation choice, just ensure support for
> both forms is available.
> 
> 
> 
> I would like to encourage the fastest possible migration to the use of
> alt
> names.  And, I agree that we need to accomodate fielded solutions
> during
> that transition.
> 
> In addition to changes in the name constraints section, a forward
> pointer
> should probably be added to section 4.1.2.6 too.
> 
> Do you have proposed text?
> 
> Russ