Subject: Re: Trivial PKI Question

From: [email-masked]
Date: Tue, 4 Mar 2003 09:44:32 +0000

> A "TRIVIAL" PKI QUESTION
> -----------------------------------

> Assume that you have a business message like a purchase order

   <Order>
       <From name="Big Buyer Corp.">
          <OurRef name="John Doe"/>
       </From>
       <To name="MegaCar International"/>
       <Item>10 Medium-sized SUVs</Item>
       <Comment>Make it quick please!</Comment>
   </Order>

> Now assume that "Big Buyer Corp." is an advanced organization
> using digital signatures.

> ==============================================
> Question:  How should the identity as expressed in the document
> relate to the identity as expressed by the signer's certificate?
> ==============================================

There may be no relationship at all. Their identity as a private
individual may be irrelevant, subjugated by their role as the person
in Big Buyer Corp who authorises such payments digitally. Also,
the creator of the order may not be the person who is authorised
to digitally sign it.

> Among the complications we find

  > 1.  The PKI-identity is presumably "strong" as it is vouched for by a
  > CA, while the identity in the business document is only "claimed"
  > by the entity itself.  ==> The PKI identity is governing?

In being authorised to digitally sign the order prior to dispatch it
behoves the signer (the risk carrier) to validate the order and the
identity of the creator of the order prior to sign and send

> 2.  The hierarchical naming system used by PKI (X.500) is completely
> different to the various naming schemes used in businesses.

That only affects the publication of the certificate into a browsable
location. It can still be revoked and will be present in whatever CRLs
the CA issues. The trust therefore remains.

> 3.  Some PKI-folks claim that signatures should be tied to individuals.
> Does this mean that the signer's certificate in the sample should
> identify John Doe of Big Buyer Corp.?

Only if John Doe is both creator of the order and authoriser of the
purchase. John is also more likely to be using the certificate issued
to him by Big Buyer Corp or its CA rather than his government (or
whatever) issued personal identity. The two are likely to contain
different certificatePolicies.

> My own conclusion is that PKI was created to support e-mail where
> these questions do not arise.

As a basic mechanism whereby you can identify an individual I believe
certification and PKI work very well. Mistakes are made in trying to
build application specific knowledge into the PKI.

> The drawback is that this will be found out by a *human*, and usually
> only *after* a malpractice has been performed.

All security can be undone by bad practice and PKI wont prevent this.
But then PKI is not a security mechanism, it is an identity mechanism
that can be used to support a security mechanism, automating some parts
of it and making others easier to implement

> A LONG-TERM REMEDY
> -------------------------------

> To create a foundation for more frictionless PKI-secured e-business,
> I think that there *long-term* should be a one-to-one mapping between
> [basic] business message identities and certificate identities.

A kind of time-stamped intersection entity that comes between person
and process ? A signed transaction ? Isn't this what Notaries were
supposed to be for ?

> As the business community is never going to adopt X.500 naming, as
> well as having their own naming problems, this will likely require
> changes on both sides.  A possible scheme using the currently only
> globally functioning naming system (DNS/URIs), is that entities are
> uniquely defined by two elements:

> - A naming domain (name space) based on a URI like: "http://www.visa.com/cc"

Microsoft use DC components to do this. I would prefer to see
one of AIA or CDP made a standard certificate component. I agree
with your implication that the cert MUST have something in it
that allows the relying party to trace the physical address of
the issuer. At present is does not.

> - A local identifier in that domain like: 4555-5555-2244-8888

Microsoft presume a unique MS domain email address. Not a bad
idea but hardly reliable beyond the edge of the MS network. But
then it is also unrealistic IMO to expect us to wander through
the eUniverse with a single identity when in the course of everyday
life we perform more than one role

I don't think that there is any problem with someone using a
multiple certs or even certs with unpublishable DNs. The fact
remains that the CA should have issued such certs under Policies.
The Policy describes what weight the relying party should give
to the signature when they encounter it. The technology itself is
not the be-all and end-all solution to true eBusiness. It is
merely a part and should always be there to support real-world
processes with a legal foundation.

Chris

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 5 Mar 2003 12:53:34 +0100

Chris,
Thanx for your answers.  Here are some replies.

>in Big Buyer Corp who authorizes such payments digitally. Also,
>the creator of the order may not be the person who is authorized
>to digitally sign it.

This "works" in the paper-world as people are "flexible".  Automated
receivers OTOH are very unlikely to be able handle arbitrary schemes.
Using a business system as a mid-tier eliminates the need to move the
arbitrary-ness of the paper-world into the e-world.

Taken from another field:  I'm pretty sure that no e-government program
will ever consider accepting anything but a one-to-one match between
a citizen's ID (as they see it) and what a citizen certificate contains.  But
they also have to build special purpose RP software (due to the dys-
functional X.500 naming system) in order to do that.  In addition to
requiring CAs to follow their _hard-coded_ naming conventions.

<snip>

> The two are likely to contain different certificatePolicies.

<CertificatePolicyRant>
It is interesting to note that CPSs are frequently mentioned in this context
in spite of the fact that none of the major crypto-packages (Windows
and Java) offers any way to specify CPSs as a part of a CA trust acceptance
process.  The reason for this is simple: Computers don't understand
legal matters and CPSs are deployment-wise anything but standardized.
Peter Gutman's term "Kitchen sink extensions" is a fair description of
the value of CPSs for practical purposes.  Do "SysAdmins" ever
bother about the CPS of their VeriSign web-server certificates?
My Thawt web-server cert does not even have a CPS extension and
I haven't missed it that much.  CPSs were designed by lawyers for
lawyers.  But lawyers do not run e-business systems, write application
software packages, or know how to handle a Java keystore.
</CertificatePolicyRant>

<snip>

>and process ? A signed transaction ? Isn't this what Notaries were

Before PKI (I mean as things are today...), business systems authenticated
outgoing messages using various techniques (leased lines, VPNs, shared
secrets).  Why should this time-proven principle be changed due to the
introduction of PKI?

Although some believe this is "unethical", even the EU are now actively
discussing how automated processes featuring legal-entity-only certificates
and keys can legally sign invoices etc.  Several countries including Sweden,
now fully support this idea.   I.e. there is no point in making a one-to-one
translation of the paper-world into the e-world, as then you only inherit
the disadvantages of the paper-world, as well as being unable to exploit
the possibilities offered by the e-world.  However, it took the
EU ten years (!), to realize that "digital signatures" have many other
qualities, outside of replacing the hardly readable ink-blobs that you
occasionally have to put on various papers.  The majority of "manual
signatures" are BTW not made with more "intent" and "consideration",
than when hitting the OK-button of a typical business application!

<snip>

As as final note, I would like to express a whish that the S/MIME and
PKIX WGs start looking a bit above the ASN.1-level, to also address
deployment issues and shrink-wrap SW support.  There must be more than
one reason why practically no app outside of e-mail offer built-in PKI support.

Regards
Anders R

---

From: Steve Hanna <[email-masked]>
Date: Mon, 10 Mar 2003 17:01:48 -0500

I've been meaning to correct a comment you made in an
earlier message:

> software packages, or know how to handle a Java keystore.

You're confusing a Certification Practice Statement (CPS)
with a Certificate Policy. A CPS is typically written by
lawyers for lawyers and can't be evaluated by a machine.
But that doesn't mean that the Certificate Policies
extension isn't useful or supported. It's a completely
different beast.

The Certificate Policies extension allows a CA to include
OIDs in a PKC indicating the policy (or policies) under
which the PKC was issued. This is especially important when
there's more than one certificate policy in use within a
group of CAs (high assurance, low assurance, or whatever).
The relying party needs to distinguish which certificate
policy (or policies) applies to each certificate.

J2SE 1.4 and later allows applications to specify which
certificate policy OIDs are acceptable when they request
validation of a certification path. And we handle policy
mapping properly. I don't know how many applications use
these features, but they are provided.

As for whether it's useful or important to include a CPS Pointer
in a certificate, I don't know. I'll leave that up to the
lawyers.

Thanks,

Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 10 Mar 2003 18:46:38 -0500

Steve:

CPS is not necessarily written by lawyers.  A CPS is a description of
procedures used to meet the CP requirements.  If one is following RFC 2527
framework, lawyers may write legal sections within Chapter 2.  Rest of the
CPS is better written by systems folks who know about the operating
procedures and security controls.

The CPS pointer is provided in the certificate in case the relying party
wants to review the controls used in generation and revocation of a
certificate.

I agree with you in terms of policy OIDs in the certificates.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Steve Hanna
Sent: Monday, March 10, 2003 5:02 PM
To: Anders Rundgren
Cc: [email-masked]; [email-masked]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)

You responded:

> <CertificatePolicyRant>
> It is interesting to note that CPSs are frequently mentioned in this 
> context in spite of the fact that none of the major crypto-packages 
> (Windows and Java) offers any way to specify CPSs as a part of a CA 
> trust acceptance process.  The reason for this is simple: Computers 
> don't understand legal matters and CPSs are deployment-wise anything 
> but standardized. Peter Gutman's term "Kitchen sink extensions" is a 
> fair description of the value of CPSs for practical purposes.  Do 
> "SysAdmins" ever bother about the CPS of their VeriSign web-server 
> certificates? My Thawt web-server cert does not even have a CPS 
> extension and I haven't missed it that much.  CPSs were designed by 
> lawyers for lawyers.  But lawyers do not run e-business systems, write 
> application software packages, or know how to handle a Java keystore. 
> </CertificatePolicyRant>

You're confusing a Certification Practice Statement (CPS)
with a Certificate Policy. A CPS is typically written by lawyers for lawyers
and can't be evaluated by a machine. But that doesn't mean that the
Certificate Policies extension isn't useful or supported. It's a completely
different beast.

The Certificate Policies extension allows a CA to include
OIDs in a PKC indicating the policy (or policies) under
which the PKC was issued. This is especially important when there's more
than one certificate policy in use within a group of CAs (high assurance,
low assurance, or whatever). The relying party needs to distinguish which
certificate policy (or policies) applies to each certificate.

J2SE 1.4 and later allows applications to specify which certificate policy
OIDs are acceptable when they request validation of a certification path.
And we handle policy mapping properly. I don't know how many applications
use these features, but they are provided.

As for whether it's useful or important to include a CPS Pointer in a
certificate, I don't know. I'll leave that up to the lawyers.

Thanks,

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 11 Mar 2003 09:17:42 +0100

Guys,

I'm sorry that I mixed CP and CPS but I would like to extend
the scope of my previous "policy-rant" to include all legal
information inserted in EE-certificates whatever it is called
and whatever its purpose may be.

I look on this issue from a pragmatic point of view.

In case you are interested in how hands-on thinking works here is
some of this admittedly "low-brow" stuff.   The advantage with
"low-brow" solutions is that they are robust and can be understood
by people who do not have a degree in informatics.

Coping with different policies according to the real-world 
------------------------------------------------------------------

All commercial CAs of any significance have selected the same
method which is to have a separate CA for each "product" as run-time
checks of policies only complicates things for their customers (and is
in no way standardized). 

That is, Policy <==> CA.  No more, no less.

Coping with different policies according to PKIX (?)
------------------------------------------------------------

I hope that you at least acknowledge that in order to use [1] policy
extensions in a wider scope where numerous CAs are involved,
they must all adhere to the same definitions.  But, AFAIK it is
- very hard to standardize "information" & "content" in general
- likely to be magnitudes harder to standardize legal stuff

Question: If policy extensions only work within rather limited 
circles why use [1] such at all?  

1] "use" in this case refers to application SW reading policy 
extensions and "acting" differently depending on what they got.
Note: To put legal stuff in EE-certificates essentially only to please
lawyers or management is completely outside of this discussion.

In case you think I am wrong, I suggest you take on the completely 
death-defying task to make the UN create standard policy profiles.

OTOH I believe Kofi Annan has some more urgent real-world
business to cater for.  And "our" problem has de-facto already
been solved, although using another method than originally planned.

cheers,
Anders

----- Original Message ----- 
From: "Santosh Chokhani" <[email-masked]>
To: "'Steve Hanna'" <[email-masked]>; "'Anders Rundgren'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 11, 2003 00:46
Subject: RE: Certificate Policies (was Re: Trivial PKI Question)

Steve:

-----Original Message-----

Thanks,

Steve

---

From: "Joel S. Kazin" <[email-masked]>
Date: Tue, 11 Mar 2003 09:18:11 -0500

RFC 3280 allows a CA to include both the OID of the CP and the OID of the 
CPS within a certificate. I specify this when writing CP and CPS 
documents.  While I would not recommend it, and one attorney actually asked 
for it, the CA can also include the full text of a user notice within the 
certificate. From RFC 3280.

id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }

    anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }

    certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

    PolicyInformation ::= SEQUENCE {
         policyIdentifier   CertPolicyId,
         policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                 PolicyQualifierInfo OPTIONAL }

    CertPolicyId ::= OBJECT IDENTIFIER

    PolicyQualifierInfo ::= SEQUENCE {
         policyQualifierId  PolicyQualifierId,
         qualifier          ANY DEFINED BY policyQualifierId }

    -- policyQualifierIds for Internet policy qualifiers

    id-qt          OBJECT IDENTIFIER ::=  { id-pkix 2 }
    id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
    id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }

    PolicyQualifierId ::=
         OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

    Qualifier ::= CHOICE {
         cPSuri           CPSuri,
         userNotice       UserNotice }

>procedures and security controls.

I agreed with Santosh. With a few exceptions, mostly the ABA-ISC folks and 
a few legal firms, attorneys at large corporations deploying a PKI do not 
initially know what a CP is and would not be ready to write one.  Writing a 
CPS is a job for someone with a background in IT controls and 
operations.  One of the major delays in implementing a large PKI is getting 
the organization's attorneys to review and approve the CP and CPS 
documents.  Getting approval for RFC 2527bis will help a bit as it keeps 
the legal sections of the "framework" together.

>certificate, I don't know. I'll leave that up to the lawyers.

Senior Consultant
Technical Consulting Practice, Northeast Region
Schlumberger Network Solutions

[email-masked]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  +1 914-769-8780
Mobile  +1 914-645-5598

---

From: Steve Hanna <[email-masked]>
Date: Tue, 11 Mar 2003 10:16:55 -0500

Thanks to Santosh and Roger for correcting me on the
CP/CPS distinction. I apologize for my error. I don't
claim to be an expert on CP/CPS. For that, I defer to
Santosh and others.

In any case, we all agree that relying party software
cannot read and evaluate the text of the CP or CPS.
That's why the Certificate Policies extension uses OIDs
to identify policies in a machine-readable manner.

> and whatever its purpose may be.

Since this is just a rant, I should ignore it. And I'm
no legal expert, so I can't say why lawyers want to
refer to the text of a CP or CPS in a certificate. But
as long as they don't use too many bits for it (by
including the actual text instead of a URL), I don't mind.

Anders also stated that "all commercial CAs of any
significance" use a separate CA for each policy. This
is probably true. So far, most relying party software
doesn't support the Certificate Policies extension. It
would be pointless or even dangerous for large commercial
CAs to ignore this. But that doesn't mean it must always
be so. If we refuse to work on anything that's not already
widely deployed, we'll have to stop all innovation.
Instead, we must continue to address real problems with
real solutions. If customers see value in these solutions,
they will be implemented by vendors.

Certificate policies have definite utility. Several
communities are piloting their use, such as the U.S.
Government. Without certificate policies, they would
need to maintain a separate network of CAs for every
policy and require identical policies throughout each
network. Using certificate policies allows them to
have a single network of CAs with various policies
in use, some within only a subnetwork.

Anders also said it is very hard to "standardize legal
stuff". I agree. That's one reason why PKI deployment
has been slow. In some contexts, it's not necessary to
agree on what a certificate means. But in most of the
contexts that really care about security, it *is*
necessary to agree. That's when CPs and CPSs become
important.

One emerging solution is to have a consortium develop
a common CP and run a bridge CA. When organizations ask
to cross-certify with the bridge, they must agree to the
CP and demonstrate that they have a CP and CPS that is
stringent enough for the bridge CA to accept it as
equivalent. This is a time when policy mapping becomes
especially important.

As I said above, I should probably just ignore statements
on this list that are misinformed, misguided, or misleading.
That's what most people on the list seem to do. But I
worry that leaving such statements unchallenged will lead
people to conclude they are correct. So I'll try my best
to answer these comments, when I can find the time. Please
correct me if my answers are wrong.

Thanks,

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 11 Mar 2003 19:50:32 +0100

Steve,

We apparently do not agree on the value of policy extensions
in certificates.  I have some additional comment and questions.

>If we refuse to work on anything that's not already

Even if the method described in my previous message already is
deployed, pretty universal, and works with all existing software?

X.509 Attribute certificates have also been touted as an
important addition to PKI technology.  I don't think even the
authors believe that anymore.  At least not in private.  

>they will be implemented by vendors.

But how are they going to rollout this particular stuff?
StarOffice will add such settings?  It seems to me to be
yet an additional way to fail with PKI.

>Certificate policies have definite utility. Several communities 
>are piloting their use, such as the U.S. Government. 

See question above.

Although government PKIs like to position themselves as being
in the forefront technically, I believe they are only in the forefront
in terms of complexity and costs.  If they had considered using high-
level PKI models, they would never have had to use bridge CAs either.  

<snip>

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 12 Mar 2003 07:19:59 +0100

Hi Steve,
there is no reason to get excited :-)

>The method you described (having a separate CA network
>for each policy) is cumbersome. So, yes, I do think we
>should work on getting support for certificate policies
>into relying party software.

I know little about the systems that you indirectly refer to, but
may I put some questions here?

- What does separate CA networks mean more than multiple keys
  (which should be piece of cake if you have proper CA SW)?

- What do these policies imply (function: web-server/e-mail or
  legal: hi-value/lo-value)? This is IMO a pretty broken part
  of  policy extensions.  And very hard to "repair" as well

- How does these guys plan to communicate outside of their
  tightly matched (unique) system?

>Stop taking unsupported potshots at other technology.

You want more proofs?  Ok, here is some (see attribute cert):
   http://www.imc.org/ietf-pkix/mail-archive/msg05855.html
An AC author's disillusioned view: 
  http://www.imc.org/ietf-pkix/mail-archive/msg05195.html

Regarding the "ad hominem attack" on the US GOV PKI programs:
In case you are interested in how you can reduce the need for
building systems constituting of:
- Tightly matched private (or community-based) X.500 directories
- Bridge CAs
- Policy extensions as a part of client software

The following are the cornerstones of such an alternative system.
- Communicate only through nodes using "authority stamp signatures".
  Eliminates person-to-person PKI on the client level completely
- Use SAML for intranet access.  Directories only support tree-
  shaped "boring" information, the intranet supports anything

If you look in "server-PKI" in the aforementioned rationale
there is an almost unbearable amount of additional information
on this topic :-)

To get rid of directories, I believe is a major issue for
successful PKI adaption.  Phill H-B, P Gutman agrees to that as
well.  As the directory is the center of most (not the Swedish
one actually) public sector PKI programs, I think we have a
"little" problem in the making here.

Regards
Anders

---

From: Steve Hanna <[email-masked]>
Date: Wed, 12 Mar 2003 09:28:24 -0500

Apparently, this email (which I sent yesterday) was not
posted to the PKIX list. I am resending it now. Apologies
for any duplicates.

-Steve

-------- Original Message --------
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
Date: Tue, 11 Mar 2003 17:18:40 -0500
From: Steve Hanna <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: Santosh Chokhani
<[email-masked]>,[email-masked], [email-masked]
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani>
<[email-masked]> <00b401c2e7ff$183fb420$0500a8c0@arport>

Anders Rundgren wrote:
> in certificates.

Yes, so it seems.

Stop taking unsupported potshots at other technology.
It doesn't help your case.

> yet an additional way to fail with PKI.

I think you're asking how end users will configure which
certificate policies they want to require. I suspect that
there will be some button labelled "Advanced" or some
configuration file where they will specify this. But most
users won't use this feature, just as they don't use any
of the security-related user interface. They'll just use
whatever their system administrator has configured. Which
should be fine. Some programs (like email applications)
may have an option to display the certificate policy
associated with the sender (mapping it to a string like
"High Security" via a configuration file).

Another important way that these policies might be used
is that server software might require a "High Security"
certificate policy for clients or peer servers.

And, of course, you managed to slip in another negative
comment about PKI. Again, this does not advance your argument.

> in the forefront technically, I believe they are only in the
> forefront in terms of complexity and costs.  If they had
> considered using high-level PKI models, they would never have
> had to use bridge CAs either.

An ad hominem attack.

I suggest you focus your attention on making a convincing
technical argument. So far, the only argument I have heard
from you is that certificate policies are complicated and
not supported by most current software. Therefore, people
should set up a separate CA network (or hierarchy) for
each policy. That's not very convincing.

-Steve

---

From: Steve Hanna <[email-masked]>
Date: Wed, 12 Mar 2003 10:38:46 -0500

> there is no reason to get excited :-)

I'm not excited, just trying to redirect the conversation
away from unsubstantiated attacks and toward solid technical
analysis.

> may I put some questions here?

Yes, this is good. We're having a real dialog, exchanging
information! As I said before, I'm not an expert on
certificate policies. However, I'll try to answer your
questions. Anyone who knows more about certificate policies
should feel free to jump in at any time. I also suggest
that you (Anders) might want to read RFC 2527 or the
Internet Draft that is being prepared to succeed it:
draft-ietf-pkix-ipki-new-rfc2527-01.txt. This describes
certificate policies in some detail.

>   (which should be piece of cake if you have proper CA SW)?

This is the system currently used by most commercial CAs.
They typically have a separate root CA for each class of
certificates (certificate policy). This root CA may certify
subordinate CAs, which are also typically separated by class
of certificate. Not only do you need a separate key pair
for each class of certificate, you typically use a different
CA name and have a separate set of CRLs. And, of course, the
number of trust anchors in relying party software increases
by a factor equal to the number of policies.

>   of  policy extensions.  And very hard to "repair" as well

As RFC 2527 and X.509 say, a certificate policy typically
"indicates the applicability of a certificate to a particular
community and/or class of application with common security
requirements." Among other things, it might say what applications
the certificate can be used for or what warranties are provided.
So both "function" and "legal", in your terms.

Could you elaborate on why you think this is broken?

Personally, I'm concerned that the expense and inconvenience
of defining certificate policies and agreeing on them between
all the parties in a PKI is slowing down PKI deployment. I'm
interested in working on possible solutions to that problem:
standard CPs, minimal CPs, and other ideas. But this problem
arises regardless of whether you use the certificate policies
extension or establish a separate CA network for each policy.

Maybe your objection is to certificate policies in
general and not to the certificate policies extension
in particular. If so, how do you propose that CAs and
relying parties would agree on what the certificates
mean? And why should you object if some people want
to identify certificate policies in the certificate?
Nobody will force you to do so and it addresses their
requirements.

>   tightly matched (unique) system?

An application that requires one particular certificate
policy generally won't accept another policy unless policy
mapping has established that the other is acceptable.
For these applications, maintaining security is apparently
more important than being able to accept any certificate.
Other applications might not have such a requirement.

As for the merits of attribute certificates, directories,
the U.S. Government, etc., let's set that discussion aside
for now and focus on certificate policies. We can work on
those topics some other time.

Thanks,

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 13 Mar 2003 08:04:48 +0100

Steve,
As PKI is too complex not only for IS-departments, but
even for [all of] us who claim we are experts on the subject,
I only take out one item, although a "favorite" :-)

>Could you elaborate on why you think this is broken?

Regardless of what I think of policy extensions I would
never mix information that does not belong to each other.
This is semantic overloading (AKA "smart" coding).
It _seems_ like a revision in "legal" would affect "function"
as well, as they are expressed as a single object.   This is
what I, while wearing my system architect cap, would
characterize as "broken beyond repair". 

If I'm wrong here please pardon me, I do not claim to be
an expert in _this_ particular area of PKI.

Anders

---

From: Margus Freudenthal <[email-masked]>
Date: Thu, 13 Mar 2003 10:54:53 +0200

Although I'm not implementing or planning to implement certificate
policy support, I would like to make some points from programmer's point
of view.

> by a factor equal to the number of policies.
* Certificate policy is also trust anchor, just like CA key (in fact,
all information that is used as input to certificate verification
procedure (besides cert chain itself) is trust anchor). In one case you
have to rely on several CA keys, in the other case you have one CA key
and several policy identifiers.

* When using multiple CA-s, what prevents you from issuing multiple
certificates to the same key?

-- 
Margus

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Thu, 13 Mar 2003 13:25:04 +0100 (CET)

In message <008501c2e92e$d5de5380$0500a8c0@arport> on Thu, 13 Mar 2003 08:04:48 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> 
anders.rundgren> Steve,
anders.rundgren> As PKI is too complex not only for IS-departments, but
anders.rundgren> even for [all of] us who claim we are experts on the subject,
anders.rundgren> I only take out one item, although a "favorite" :-)
anders.rundgren> 
anders.rundgren> >> - What do these policies imply (function:
anders.rundgren> >>   web-server/e-mail or legal: hi-value/lo-value)?
anders.rundgren> >>   This is IMO a pretty broken part of  policy
anders.rundgren> >>   extensions.  And very hard to "repair" as well

A policy implies what is written in it (in the CP and the CPS).
There's nothing in a policy OID that can tell you what the function or
the legality of the policy is, you have to read the documents and
decide that for yourself accordingly.

The way I see it, it's not much different from reading the license
that comes with a program, be it the Microsoft EULA, the GPL or
whatever...  Or you might parallell it to contracts, if you feel
better about that.  Either way, you have to read them to know what
they imply, no software in the world will do that for you.

It seems like you want the implication of a contract (in this case,
certificate policies) to be determined programatically.  I believe
that's a mistake.

anders.rundgren> Regardless of what I think of policy extensions I
anders.rundgren> would never mix information that does not belong to
anders.rundgren> each other.  This is semantic overloading (AKA
anders.rundgren> "smart" coding).  It _seems_ like a revision in
anders.rundgren> "legal" would affect "function" as well, as they are
anders.rundgren> expressed as a single object.   This is what I, while
anders.rundgren> wearing my system architect cap, would characterize
anders.rundgren> as "broken beyond repair".

Uhmm, to reuse the license or contract model, they are also documents
that combine function and legality.  Are they also broken beyond
repair?

But fine, I've no problem seeing having to write a legal document and
a functional document if it came down to that.  What makes you think
I'd not have them constantly combined in whatever certificate I decide
to create, more or less as if they were a single document?  Also, what
are the implications for such a scheme when validating a certificate?
Currently, all policies along the path are regarded as single entities
that may apply alone with no regard for the other policies that may
appear on the way.  If combined policies became the thing to do, how
would validation software know what policies should be kept combined?
And oh, are those combinations only pairs, or can we have combinations
of three policy documents?  As you can see, this leads to another can
of worms, and I doubt that's what you wanted, so I'll assume I
misunderstand you and let you explain what you were thinking...

-- 
Richard Levitte     | http://richard.levitte.org/ | Spannv. 38, I
Levitte Programming | http://www.lp.se/           | S-168 35 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: Al Arsenault <[email-masked]>
Date: Thu, 13 Mar 2003 09:40:35 -0500

----- Original Message -----
From: "Margus Freudenthal" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 13, 2003 3:54 AM
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)

> certificates to the same key?

From a technical standpoint, typically nothing prevents this.  It's not
commonly done because:

    a.  There's more of a management problem; e.g., if the key is ever
compromised for whatever reason, you have to track down ALL of the
certificates it was bound to and revoke them;  and

    b.  Policies typically restrict it.

But it could easily be done (and has in some specialized cases).

                Al Arsenault
                Chief Security Architect
                Diversinet Corp.

---

From: Margus Freudenthal <[email-masked]>
Date: Fri, 14 Mar 2003 10:12:29 +0200

> certificates it was bound to and revoke them;  and
Each certificate that is issued to you brings along some kind of
liability (documents signed using that certificate are considered to be
signed by you). Therefore you'd be crazy not to keep track of all your
certificates/liabilities.

-- 
Margus

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 14 Mar 2003 10:52:22 +0100

Hi Richard,

>decide that for yourself accordingly.

So far, I am with you.

Now assuming that a single CA key/cert can create N different
policies applied to M different EE-certificates, you get a potentially
unmanageable legal/function matrix.

BTW, why do some people believe that you need a lot of 
different policies?  To keep legal departments busy?  Why do
you actually need more than one within a given "trust-network"?

It would be very interesting to see what purposes all this
stuff is supposed to fill in application software.

            Architecture?

            Data model?

            Links?

I occasionally look on this in a slightly "philosophical" way:
If one large user like DoD, deploys "something" but the rest of 
the market does not, using my thinking, it was a failure for this 
"something" (and long-term also for the DoD).

As not even X.500 directories and LDAP are sacred anymore
http://www.imc.org/ietf-pkix/mail-archive/msg05571.html ,
it seems that PKI technology is still to be regarded as being
highly immature.  That is, your answer is as good as mine.
And vice versa :-)

Unless somebody provides some more facts regarding PE usage
in application software, I suggest that we halt this thread a while,
and let the market do the final selection...

Anders

---

From: Richard Levitte - VMS Whacker <[email-masked]>
Date: Fri, 14 Mar 2003 12:34:11 +0100 (CET)

In message <005301c2ea0f$6c402f70$0500a8c0@arport> on Fri, 14 Mar 2003 10:52:22 +0100, "Anders Rundgren" <[email-masked]> said:

anders.rundgren> Hi Richard,
anders.rundgren> 
anders.rundgren> >A policy implies what is written in it (in the CP
anders.rundgren> >and the CPS).  There's nothing in a policy OID that
anders.rundgren> >can tell you what the function or the legality of
anders.rundgren> >the policy is, you have to read the documents and
anders.rundgren> >decide that for yourself accordingly.
anders.rundgren> 
anders.rundgren> So far, I am with you.
anders.rundgren> 
anders.rundgren> Now assuming that a single CA key/cert can create N
anders.rundgren> different policies applied to M different EE
anders.rundgren> certificates, you get a potentially unmanageable
anders.rundgren> legal/function matrix.

A CA key/ct doesn't create policies.  It may contain N different
policies, of which one (at least that's what I assume) will be used
every time an EE certificate is issued.  I don't quite understand why
that would create such a matrix, does the policy change from one EE
certificate to another?  The way I see it, you keep track of N
policies when validating a path, period.

It sounds like you're creating problems where there aren't any, or
there is something that I haven't quite grasped yet...

anders.rundgren> BTW, why do some people believe that you need a lot
anders.rundgren> of different policies?  To keep legal departments
anders.rundgren> busy?  Why do you actually need more than one within
anders.rundgren> a given "trust-network"?

More than one is obvious.  You may a have different policy for EE
certificates given to people who are supposed to use them for million
dollar transactions than the one for EE certificates given to mail
users.

Why everyone seems to need to have their own "special" policy?  Beats
me.  Why do we have all those different program licenses that
essentially express the same thing?  Why do commercial programs come
with licenses written uniquely by each vendor?  Why can't they agree
to use the exact same license?  Why does each company have it's very
own contract form for employees instead of using a standard one?

I believe the answer is "welcome to the human condition" rather than
anything really rational, perhaps except that many CPs are written for
one specific CA (mentioned by name and so on) and is therefore not
usable for other CAs.  In any case, it's a matter of keeping control
over the stuff you use and produce, and I agree that it takes silly
proportions in this case.

If you write a set of CPs and submit them to some kind of standards
commitee (I think NIST has collected a few CPs), and I like them, I've
no problem with using them instead of writing my own.  If someone else
does the work and allows me to use the work in question, why should I
waste my time redoing the work?

anders.rundgren> It would be very interesting to see what purposes all
anders.rundgren> this stuff is supposed to fill in application software.
anders.rundgren> 
anders.rundgren>             Architecture?
anders.rundgren> 
anders.rundgren>             Data model?
anders.rundgren> 
anders.rundgren>             Links?

You keep on saying that, and you seem to forget there's a human side
to this as well.  There are people with needs of control.  I believe
that's the answer to your question much more than a programmatic one.

anders.rundgren> I occasionally look on this in a slightly
anders.rundgren> "philosophical" way:  If one large user like DoD,
anders.rundgren> deploys "something" but the rest of the market does
anders.rundgren> not, using my thinking, it was a failure for this
anders.rundgren> "something" (and long-term also for the DoD).

Not really.  Within DoD and others that have used PKI for a while,
this is old stuff.  Among "common people", this is really new, and
most of them haven't even been told this exists...  It takes a while
before this becomes common knowledge.  It's almost like the Internet;
according to John Doe on the street, the Internet started somewhere
like 1994 or 1995, or perhaps even later...  It takes a while before
knowledge spreads...

anders.rundgren> As not even X.500 directories and LDAP are sacred anymore
anders.rundgren> http://www.imc.org/ietf-pkix/mail-archive/msg05571.html ,
anders.rundgren> it seems that PKI technology is still to be regarded as being
anders.rundgren> highly immature.  That is, your answer is as good as mine.

You couldn't have said it better.  It hasn't matured yet, and we're
all working to help it mature (or to reject it :-)).

anders.rundgren> Unless somebody provides some more facts regarding PE
anders.rundgren> usage in application software, I suggest that we halt
anders.rundgren> this thread a while, and let the market do the final
anders.rundgren> selection...

Let me think about usage a bit and I'll get back to you (if I
remember).

About letting the market decide, I'm not sure I trust it very much.
Most people have a tendency to go for something cheap that works for
now, often resulting in a status quo of crap (for some definition of
"crap").  I have very little trust in the market's lookout for
quality, I've just seen too few examples of that happening.  If I'm
wrong, I'll joyfully be corrected!

---

From: Al Arsenault <[email-masked]>
Date: Fri, 14 Mar 2003 17:07:31 -0500

> certificates/liabilities.

This is certainly true in theory, but people being people, I wouldn't count
on everybody having a perfect system for tracking all of the certificates,
if there were a lot of them.  Especially if something needs to be done in a
hurry; e.g., "the private key is compromised because Mike found out he was
being laid off, used an attack against the machine to discover it, and has
posted it on the Web.  Revoke all the certs now, and don't miss any."

Yes, a good organization has policies and procedures to both defend against
and recover from such situations, but anybody who thinks they're always
going to work hasn't experienced much of the world.

        Al Arsenault

---

From: Al Arsenault <[email-masked]>
Date: Fri, 14 Mar 2003 17:17:59 -0500

Anders Rundgren wrote:

<snip>
> "something" (and long-term also for the DoD).

No.  It could mean that the DoD has different requirements than most other
people.  It could mean that the people in charge there have different
architectural views of the world, or different personal preferences.

Stripping out all the political correctness, the primary job of the "Defense
Department" of any nation is to, when the circumstances require it, kill
people and break things.  Yes, do so while preventing your own people from
being killed and your own things from being broken, but...  Not a whole lot
of other organizations have that as a mission.  So it stands to reason that
such an organization *just might* have slightly different requirements from,
say, a bank or a credit card processor or a phone company.

So the fact that a "Defense Department" deploys PKI differently from, say,
Visa International, does not necessarily mean that either organization is
wrong.

That's my biggest problem with "let the market decide".  If we say that a
technology which achieves significant market dominance, say, 75% market
share is by definition "right" and thus deserves to be the only technology
used and to have a 100% market share, we (a) kill a lot of good technologies
unnecessarily; (b) mean that certain customers with unique requirements get
blown away; and (c) possibly reward undeserving technologies, anyway,
because the "market" doesn't always choose the best solution - which might
explain tons of buffer overflows, viruses, worms, etc. (Mostly, "what
Richard Levitte said".)

                    Al Arsenault
                    Chief Security Architect
                    Diversinet Corp.

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 15 Mar 2003 16:01:19 +0100

Al,
My intention was to put this thread to rest a while but since you are
new in this discussion I make an exception :-)

The problem is that since DoD (as you say) believe they have
"unique" requirements, they are in the same league as the EU, 
the banks, the health-care sector etc etc.

Therefore there will never be a standard but a lot of profiles.
In my opinion this makes policy extensions less suitable as a
universal method for automatic decisions on trust, selection etc.

I.e. DoD may claim they are following a "standard" but from
a pragmatic point of view their system may be classified as
"proprietary", as well as likely to work badly when the DoD
is to communicate digitally with the outside world.

In addition to various organizations' claim of having "unique"
requirements, the number #1 problem is to identify a subject
in a cost-efficient and trustworthy way and then assign an 
electronic identity to it.  Since countries like the USA don't
have a working "registry", biometric methods are still in
their infancy, and there exist no generally accepted way to
name people, I don't think even a minimal technical foundation
is in place to support globally standardized policies.

I have had some contacts with US e-government reps. who still
don't seem to have a clue on how to name citizens.  This
contrasts a bit to the Swedish system which was established
some 40 years ago and PKI-fied since at least 7-8 years back.

In the mean-time (next 5-10 years) most organizations will probably
rely on the de-facto standard (CA <==> Policy), which unfortunately
makes an already unlikely future policy-based standard, even harder
to deploy.

OTOH: Shouldn't RPs be the prime target for PKI improvements
rather than CAs?  But for RPs the de-facto standard is simpler to get
a grip on than introducing yet another dimension.

To further complicate things, many of us also have "vested interests"
in certain designs and associated customers.  F.Y.I.  I can tell you,
that I am actively working on a PKI-scheme where the CA is a core
PKI-object holding policy, logotype, name-space declarations, and
a liability statement.  The point with this is to convert PKI into
self-describing objects, aligning  better to the solutions and standards
used in other IT-segments.  This scheme is explicitly designed to allow
run-time interpretation as well as supporting administrators during
CA trust decision processes.  To make this reasonable possible to
ever rollout (my main concern regarding any system, standard etc),
the proposed scheme is upwardly compatible with the de-facto standard,
effectively only converting some data from being "implicit" ("known")
to become "explicit".

Anders