Subject: Q: Where should do I put a max mount in a X.509v3 certificate?

From: "Roberto Opazo Gazmuri" <[email-masked]>
Date: Sun, 3 Mar 2002 13:50:51 -0300

IETF-PXIX:

I would like to ask the WG opinion about “the correct” place to indicate
that a certificate should not be used to validate electronic signatures for
a mount over a determined maximum.

Here we are delegating in de RP the responsibility of validating the
certificate content to see if there is a limit and I have not seen a good
place to put this information. We need to indicate:
1.- There is a general limit, not for a specific transaction type
2.- The mount of the limit
3.- The type of money in witch the mount is expressed

Is there a standard extension for that?

Thanks,

Opazo, Roberto ([email-masked])
CEO - www.acepta.com
Certification Authority for Chile

---

From: "todd glassey" <[email-masked]>
Date: Sun, 3 Mar 2002 10:13:52 -0800

Roberto - we went over exactly this thing in the Bar Association's
Information Security Committee and the place that the liability and claimant
requirements are codified is in a set of documents called the Certificate
Policy Statement (CPS) and Practices Statements (PS). The other side of
these is the Relying Party Agreement(RPA).  These three documents
essentially form the of a contract, which is leveraged between the terms
listed in them.structure

The CPS and PS documents state the constraints of the Certificate and how
the CA operates itself. The RPA is the other half of the picture and defines
the relying party's obligations rights, and procedures for collecting
against the indemnity provided.

The problem is that there is no real method of communicating stated policy
or negotiating inline. That is to say that without these complex legal, and
externally referenced documents the structure of the x.509 certificate
cannot by itself instantiate any level of liability per se.

I have suggested several times that that PCP (Policy Communications
Protocol) is a key missing part of any real Machine-operated PKI solution.
The machines must be given a way of negotiating the specific policies and
constraints under which they will work and they need to do this together
with the other CA's so that applications can make inline decisions as to
what they will and wont trust.

By the way, the assigning of a value to an x509 certificate turns it into a
financial token and you would need much more than just this group to approve
of that since there are then legal implications attached that are not
necessarily apparent.

Todd Glassey

----- Original Message -----
From: "Roberto Opazo Gazmuri" <[email-masked]>
To: "PKIX (Grupo de la IETF)" <[email-masked]>
Sent: Sunday, March 03, 2002 8:50 AM
Subject: Q: Where should do I put a max mount in a X.509v3 certificate?

IETF-PXIX:

I would like to ask the WG opinion about "the correct" place to indicate
that a certificate should not be used to validate electronic signatures for
a mount over a determined maximum.

Thanks,

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 3 Mar 2002 20:29:32 +0100

Roberto,

The "WG" has probably not a unified view of this issue so may I just add my
personal view on this.  Technically there are such policy OIDs although I don't
know where you can get this information.  Now I would like to take the
opportunity to (in a rather "orthogonal" way), say what I think of this idea
in general.

I think that the whole liability issue has infected PKI to an extent that is
unreasonable.  What does a money-limit indicate?  That if a CA has
certified the wrong person, the CA is liable for the entire transaction?

There are many problems with this

-  The biggest risk is actually that the certificate and key was stolen
from the proper owner, and are CAs really prepared to be liable for that?

-  A certificate used for *authentication* may be use to protect things
that does not easily measure in monetary terms.  It could be state-secrets,
your company's latest product-to-be, your latest HIV-test, or it could be used
to open a door to vault filled with gold!    As authentication in spite
of all talk of digital signatures is the PKI "killer application", I think that
these monetary limits are without much *real* value.  Particularly as
account-to-account transactions (in contrast to revealed state-secrets, and
HIV-tests), usually can be undone.

- It is BTW rather dangerous to fake an identity to get a certificate
as your traces are easy to follow compared to physical IDs.

I think that commercial CAs should put a *maximum* liability figure
in the range of $10 000 to $100 000 regardless what the certificate is
used for.  And it should only be valid for certifying incorrect entities.

It is like a lock.  It often is manufactured according to some industry norm,
but that does not guarantee that it protects $1M from a clever thief.  But
it is still worth the $500 if there are no better alternatives around!

If we are talking about CA key compromise, we are probably dealing
with processes like a drug manufacturer killing its clients.

cheers,
Anders

----- Original Message ----- 
From: "Roberto Opazo Gazmuri" <[email-masked]>
To: "PKIX (Grupo de la IETF)" <[email-masked]>
Sent: Sunday, March 03, 2002 17:50
Subject: Q: Where should do I put a max mount in a X.509v3 certificate?

IETF-PXIX:

Thanks,

---

From: "todd glassey" <[email-masked]>
Date: Mon, 4 Mar 2002 05:26:38 -0800

----- Original Message -----
From: "todd glassey" <[email-masked]>
To: "Roberto Opazo Gazmuri" <[email-masked]>
Cc: "LISTS - IETF-PKIX" <[email-masked]>
Sent: Sunday, March 03, 2002 10:13 AM
Subject: Re: Where should do I put a max mount in a X.509v3 certificate?

> essentially form the

structure (sorry for the typo)

of a contract, which is leveraged between the terms
> listed in them.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Mar 2002 16:00:18 -0500

>Certification Authority for Chile

There is no standard extension for conveying this info.  One might 
use the policy ID field and policy qualifiers to represent this info 
in a machine readable fashion, but we have generally advised folks to 
not use the policy qualifier field.

Steve

---

From: Tim Polk <[email-masked]>
Date: Fri, 08 Mar 2002 10:37:47 -0500

At 04:00 PM 3/4/02 -0500, Stephen Kent wrote:

>There is no standard extension for conveying this info.  One might use the 
>policy ID field and policy qualifiers to represent this info in a machine 
>readable fashion, but we have generally advised folks to not use the 
>policy qualifier field.
>
>Steve

Roberto,

The first question is "what is the range of uses for your 
certificates"?  Will they only be used in context of the maximum dollar 
amount, or do you expect them to be used for S/MIME, TLS, or IPsec?  Will 
they be used in a closed community - the same one that understands the 
maximum amount information - or will the community that uses the amount 
information be one of several that use the certificate?

As Steve has said, a standard method for representing the maximum amount 
hasn't been established.  Several possibilities exist; each has a different 
impact on interoperability.

(1)  It *could* be represented in a policy qualifier, although I must say I 
find that option personally distasteful.  You could place the information 
in a private qualifier, or perhaps the user notice qualifier would 
work.  Either way, you shouldn't expect other communities to accept that 
policy for their applications.  If you want interoperability, you would 
need to place multiple policies in the certificate, and represent the 
amount information in the qualifier associated with one of the certificate 
policies.

(2) It *could* be represented in a private extension.  As long as those 
extensions are non-critical, that shouldn't hinder interoperability.

(3) It might be possible to use the subject directory attributes extension 
to convey the information.  (I am not sure if a maximum amount directory 
attribute has already been established.)   Since it is always non-critical, 
this shouldn't impact interoperability.

Regardless of the path you choose, an off-the-shelf client will not 
understand the reliance information.  To support the application(s) that 
will process this information, you may need to develop a custom plug-in.

The real question is "Should that information be in the certificate?"  This 
kind of information may change over the life of a certificate.

IMHO, this is a really good place to use OCSP.  You could use the OCSP 
response to convey the most current reliance amount to relying parties that 
need the information.  Relying parties that don't care (e.g., an S/MIME 
client) can still use OCSP to get status information without requesting the 
maximum amount information.

Tim Polk