Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat e?

From: "Tom Gindin" <[email-masked]>
Date: Mon, 11 Mar 2002 07:32:48 -0500

Peter:

      Since this "purchase limit" is intended as a constraint on signed
orders, and those are signed by PKC's rather than AC's, the constraint
needs to go into the PKC.  I also don't think the syntax is very complex
(currency designator and amount - the only choice you need to make is
whether to encode amount as Numeric String, Integer, or Real).
PolicyQualifier would make the most sense if it weren't for the conflict
between the existing use of criticality in CertificatePolicies and its use
for this feature.  If PolicyQualifiers are to remain deprecated for uses
like these, IMHO the only places for these to go are a new extension or
SubjectAltName OTHER-NAME, and it really isn't a naming attribute.
      Does profiling a new extension in new-part1 make sense?

            Tom Gindin

"Yee, Peter" <[email-masked]>@mail.imc.org on 03/08/2002 02:45:51 PM

Sent by:    [email-masked]

To:    "'Tim Polk'" <[email-masked]>, Roberto Opazo Gazmuri
       <[email-masked]>
cc:    "PKIX (Grupo de la IETF)" <[email-masked]>
Subject:    RE: Q: Where should do I put a max amount in a X.509v3
       certificat e?

Tim suggests using a policy qualifier, private extension, or
subject directory attribute.  (And OCSP, with which I really have
to disagree respectfully).  I'll offer another alternative: attribute
certificates.  These seem to be a natural fit and were suggested for
just such a purpose.

Sure, I'm glossing over the plethora of software that actually
supports ACs, but most of the other suggestions aren't implemented
either. :-)

-Peter Yee

[email-masked]

---

From: Juergen Brauckmann <[email-masked]>
Date: Mon, 11 Mar 2002 15:01:54 +0100

Hello.

> whether to encode amount as Numeric String, Integer, or Real).

ETSI has an monetaryLimit statemtent for use with the qCStatement
extension defined in RFC3039.

The ETSI document id is "ETSI TS 101 862 V1.2.1". The document can be
obtained from pda.etsi.org, but basically it goes like this:

MonetaryValue::= SEQUENCE {
currency Iso4217CurrencyCode,
amount INTEGER,
exponent INTEGER}
-- value = amount * 10^exponent

Iso4217CurrencyCode ::= CHOICE {
	alphabetic PrintableString (SIZE 3), -- Recommended
	numeric INTEGER (1..999) }
-- Alphabetic or numeric currency code as defined in ISO 4217
-- It is recommended that the Alphabetic form is used

Regards
    Juergen

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Mar 2002 14:10:08 +0000

Tom,

> needs to go into the PKC.  

That's wrong (even ignoring the careless language). The requirement is
presumably that the amount is somehow attested to by an authority.
That doesn't distinguish an AC-based from a PKC-based solution.

>       Does profiling a new extension in new-part1 make sense?

IMO, No - and not until there'll be a *lot* of RP s/w that pays 
attention.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: "todd glassey" <[email-masked]>
Date: Mon, 11 Mar 2002 07:12:28 -0800

So perhaps PKIX should embrace this structure as a basic method of
representing a monetary value.  The more we all come to structural agreement
about what our variously protocols are to do, the easier it will be to make
the interoperable.

Todd

> -- It is recommended that the Alphabetic form is used

The only thing it doesn't support is an internal "Policy Of Use" statement
or OID. That means that anything that uses this financial value designator
may need a larger container structure to contain the Policy

---

From: Michael Ströder <[email-masked]>
Date: Mon, 11 Mar 2002 15:55:22 +0100

> needs to go into the PKC.  I also don't think the syntax is very complex

I'd suggest to thoroughly discuss a business model first before thinking 
about technical aspects (not on PKIX list off course). From some discussion 
I remember that most drafts for something like this just didn't fit into how 
financial institutions are working (although the institutions were committed 
to use this particular PKI ;-).

So defining technical specifications was completely useless because there 
was no working business model behind it.

Ciao, Michael.

---

From: "todd glassey" <[email-masked]>
Date: Mon, 11 Mar 2002 11:02:42 -0800

I would propose that there are a number of simple functions or
representational Data Structures to represent these various things missing
from PKIX.  Further that this WG has a number of common points of service or
functionality between a number of protocols and that for whatever reason
that have been ignored till now.

What I suggest that we need is a standard form of:

    1)    representing a light-weight token that can convey a statement as
to policy or indemnity limits

    2)    representing a token that in and of itself is cash or can carry
cash

    3)    representing status of a verification event. - This would be a
common calling form and return messaging for all PKIX routines. Maybe
something like a CDSA top-end for the PKIX protocols.

Todd