Subject: Re: Changes to RFC2459

From: Roger Younglove <[email-masked]>
Date: Thu, 01 Apr 1999 07:11:12 -0500

I agree, when an unknown certificate is introduced into your PKI the only
safe way to accept it would be to check the Certificate Policy identified
in cert policy id. 
At 02:46 PM 3/31/99 , you wrote:
>
>-----Original Message-----
>From: Jim Schaad (Exchange) <[email-masked]>
>To: 'Stephen Kent' <[email-masked]>; Moshe Litvin <[email-masked]>
>Cc: [email-masked] <[email-masked]>
>Date: Wednesday, March 31, 1999 3:04 PM
>Subject: RE: Changes to RFC2459
>
>
>>Steve,
>>
>I think it is important to note that
>>there is nothing in a certificate that says I am PKIX compliant.  This
>>certificate could have been issued by somebody following the boondogle X509
>>certificate profile,:) and we are interpreting it under a different
>profile.
>>If we make sure the profile can make explicit statements then we don't have
>>this issue.
>
>
>
>The cert policy id field is surely usable as a CA-signal that a profile is
>in use,
>and its assurances enable one to trust that a cert conforms to a
>profile. relying parties require particular extension schemas etc, by
>requiring
>particular cert policy ids, or local policy id mappings.
>

--
TTFN

Roger W. Younglove                            Blue Cross Blue Shield Michigan
Network Systems Consultant                313-225-0637 on site
International Network Services
100 Galleria Officentre Ste. 220
Southfield, MI 48034
E-mail page:
[email-masked]
Numeric page: 888.935.6755

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 6 Apr 1999 22:21:40 (NZST)

[Slightly off-topic design philosophy comments follow]
 
>Even in a v3 environment there still needs to be a process defined (possibly
>involving user interaction) which approves the operation and defines other
>operational parameters that will be associated with the CA.  Just because the
>certificate looks like a valid v3 CA doesn't me I will always believe it.
 
I don't think this will work, because it assumes (and, in a worst-case
situation, absolutely requires) that users know what they're doing.  I've
always tried to design things so that they'll still work right if used by a
lobotomized flatworm, even if this means adding redundant or unnecessary
information to data to help sort things out (eg basicConstraints in EE certs).
For an example of where the "rely on user intervention" approach falls down,
the users manual for a recently-deployed nontrivial (>100K users) project which
uses certs and which will result in considerable pain to users if there are any
problems, contains in the manual a section which says something like "You'll
see some certificate warning dialogs pop up.  Click OK to get rid of them" (to
see why this is a problem, assume the text of the dialog says "Do you want to
install a new certificate for 'Verisign Class 1 Public Primary Certification
Authority'").
 
User education won't fix this.  Even if you were to add the several pages of
text needed to explain what a certification authority was and what the user was
doing by clicking OK, virtually noone would read it (I suspect most of them
won't even read the manual as it currently stands, they just see a box with an
OK button and click it because that's what they've done 1000 times before when
they were in a situation like that).
 
Do any vendors actually perform any testing with lobotom^H^H^H^Husers?  I know
that companies like Microsoft go to some effort to test various aspects of
their user interfaces with real users (rather than the UI designers or
programmers) to make sure they get them just right, does anyone do this with
PKI-related products?
 
Peter.

---

From: "Meggison, Tim" <[email-masked]>
Date: Tue, 06 Apr 1999 11:06:25 -0400

Steve,

Your algorithm works great as long as everyone is following the rules of the
RFC.  Unfortunately, this does not hold true in practice.  When one
processes a cert, there is no indicator that it was generated according to
the RFC.  

As an implementer of a CA, it would be desirable to remove all ambiguity to
improve interoperability.  It is very easy for a cert-generator already to
set the Basic Constraints for an EE cert - this is not new technology, and
in fact is necessary to support other profiles (eg. SET).

Besides saving a few bits in a certificate, what other benefits exist by not
using the Basic Constraints to indicate an EE cert?