Re: I-D ACTION:draft-ietf-pkix-okid-01.txt

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Paul,

Thank you for your *very* quick answer.

(some text deleted)
 
> So, here is where we get into the discussion of enforcing good
> security policy. My wording had the bulleted list as MUSTs. You have
> reduced them past SHOULD to MAY. The result of this is that few
> implementations will tell end users the effects of what they are
> doing (a SHOULD would probably do more).
> 
> I think this reduction is dangerous in that it does not tell the end
> user enough about the effects of her or his actions; other people
> would say that it is not our responsibility to insist on telling the
> end user this.
> 
> Quite frankly, there are probably lots of implementors who use PKIX
> toolkits who don't realize all the ramifications of using a trust
> anchor are. Forcing them to tell their users will make them much more
> aware of their responsibility.

Many people do not have your or my education in PKI. They are told to
install a new root. They only need to know how to install it properly. They
do not even know which key they are installing. They got a URL where to
fetch the self-sigend certificate and then must be sure that what they get
matches the hash. That's all. They have not the simplest idea of what means:

 - the policies used by the issuer of this certificate to issue subordinate
   certificates,

 - the basic constraints placed on the issuer of this certificate, 

 - the depth of subordinate chain that can be issued under this certificate,
 
 - the types of names for which the issuer of this certificate can create
   certificates,
  
 - the policy constraints placed on the issuer of this certificate.

I believe that the debate should now be between SHOULD and MAY.

Denis


 
> --Paul Hoffman, Director
> --Internet Mail Consortium