Subject: Comments on okid-01

From: "Blake Ramsdell" <[email-masked]>
Date: Fri, 1 Mar 2002 16:06:45 -0800

Section 2 -- I recommend that both MAY recommendations for receiving
implementations be changed to SHOULD.

Table 1 last column heading is truncated ("Charac" not "Character").

I'm not sure about the utility of the first two characters identifying the
certificate type (EE vs. CA, specifically).  This creates a binding between
the intended use of the certificate to the actual contents of the
certificate.  Since the entire certificate is now being hashed, it seems
like it is just another integrity field and does not seem to have any other
useful purpose.  My worry is that this will introduce conflict for
conforming implementations that might have allowed root keys without the CA
flag set, but have an OCKID implementation that enforces the check and
forces the user to modify the leading CA to be EE to satisfy the integrity
check.  If it is desired to include the type identifier for human reasons,
then I recommend that the comparison against the CA field in the certificate
be optional, or that a generic certificate identifier be introduced.  I may
not understand the goals of this identifier, however, so be gentle...

Blake
--
Blake Ramsdell
Brute Squad Labs http://www.brutesquadlabs.com

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 4 Mar 2002 10:10:07 -0500

Blake:

I would like to preserve the "CA" and "EE" labels.  Since many root
certificates are X.509v1, they do not include an extension that identifies
them as CA certificates.  I think that the ability to mark a X.509V1
certificate as a CA or EE is quite useful.

Russ

-----Original Message-----
From: Blake Ramsdell
To: [email-masked]; Paul Hoffman
Sent: 3/1/02 7:06 PM
Subject: Comments on okid-01

I'm not sure about the utility of the first two characters identifying
the
certificate type (EE vs. CA, specifically).  This creates a binding
between
the intended use of the certificate to the actual contents of the
certificate.  Since the entire certificate is now being hashed, it seems
like it is just another integrity field and does not seem to have any
other
useful purpose.  My worry is that this will introduce conflict for
conforming implementations that might have allowed root keys without the
CA
flag set, but have an OCKID implementation that enforces the check and
forces the user to modify the leading CA to be EE to satisfy the
integrity
check.  If it is desired to include the type identifier for human
reasons,
then I recommend that the comparison against the CA field in the
certificate
be optional, or that a generic certificate identifier be introduced.  I
may
not understand the goals of this identifier, however, so be gentle...

Blake