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 12:21:22 -0500

The following contribution to this discussion is being posted on
behalf of Francois Rousseau.

---------------------- Forwarded by Tom Gindin/Watson/IBM on 03/11/2002
12:20 PM ---------------------------

[email-masked] on 03/11/2002 11:48:30 AM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [email-masked], [email-masked], [email-masked],
       [email-masked]
Subject:    RE: Q: Where should do I put a max amount in a X.509v3
       certificat e?

Tom,

I totally agree with Peter's suggestion on this one since this was the
whole
reason for adding the Signing Certificate Attribute within the Enhanced
Security Services for S/MIME [RFC2634].  It was meant to bound an attribute
certificate to a signed transaction as required here by Roberto.  If the
authorized max amount will change more often than the private signing key
of
the individual, than attribute certificates are certainly more interesting
than the using a policy qualifier, private extension, or the subject
directory attribute.

Feel free to distribute this comment and your response on the mailing list
since I am not currently a member of the PKIX list, but only monitor its
status on the web site.

Regards,

Francois
---------------------------------
Francois Rousseau
IT Standards, Senior Advisor - CSE
Conseiller Superieur, Normes TI - CST
[email-masked]
(613) 991-8364
Edward Drake Building
1500 Bronson, Ottawa, Ontario, K1G 3Z4

> From: "Tom Gindin" <[email-masked]>
>
>      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
>

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 11 Mar 2002 14:56:51 -0500

Money is very complicated.  We should not try to invent our own syntax to
specify monetary amounts.  I suggest we steal one that is already in use:

     -- CurrencyAmount specifies the currency and a monetary value.
     -- Currency codes are defined in ISO 4217.  The monetary value
     -- is: amount * (10 ** amtExp10), and the exponent MUST be the
     -- minor unit of currency specified in ISO 4217.

     CurrencyAmount  ::=  SEQUENCE  {
       currency             INTEGER (1..999),
       amount               INTEGER (0..MAX),
       amtExp10             INTEGER (0..MAX)  }

Russ 

-----Original Message-----
From: Tom Gindin
To: Yee, Peter
Cc: 'Tim Polk'; Roberto Opazo Gazmuri; PKIX (Grupo de la IETF)
Sent: 3/11/02 7:32 AM
Subject: RE: Q: Where should do I put a max amount in a X.509v3 certificat
e?

      Peter:

            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: Peter Williams <[email-masked]>
Date: Mon, 11 Mar 2002 13:25:29 -0800

In practice, people are modifying the PK-cert borne
authorization via the OCSP response, whose extension 
contains a form of (unsigned) AC. Once AC syntax becomes
popular, the trend will be to express the
privilege in AC syntax, rather than adhoc. For
now, folks need something that works. As cert
validation need not use any source of revocation
notices, one needs base authorization in
the PK cert, and a properly defined privilege
scheme that controls how one processes privileges
from two sources, one of which is the PK cert. (essentially, 
follow the X.509 rules on controlling privlege delegation, when
using the PK cert's subjectDirectoryAttributes for 
base privilege expression)

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Monday, March 11, 2002 12:17 PM
To: Tom Gindin; [email-masked]
Cc: Yee, Peter; 'Tim Polk'; Roberto Opazo Gazmuri; PKIX (Grupo de la
IETF)

Tom, all:

Perhaps the following design principle is well understood but in
the context of this thread I think it bears repeating.  Namely,
the more authorization type attributes bound into a PK cert, the
more likely that PK cert will be revoked prior to its
expiration.  Hence ACs.

Mike

---

From: "Yee, Peter" <[email-masked]>
Date: Mon, 11 Mar 2002 13:47:36 -0800

Tom,
	I wasn't suggesting that complexity was the hangup in implementing
a purchase limit in either PKCs or ACs -- simply that most commercial
products don't deal with many "unusual" extensions.

	I'll also agree with others who note that tying a hard limit in
to an identity certificate is likely to result in expiration of these
certificates unless used in very constained cases -- those with limits
that don't change and where the authorization to use those limits matches
the lifetime of the identity certificate.  Those constraints seem
artificially
narrow to me.  Certainly, if you can find an application that works within
those limits (and others), then putting the purchase limit in the PKC has
its
merits.

						-Peter

>From: Tom Gindin [mailto:[email-masked]]
>Sent: Monday, March 11, 2002 4:33 AM
certificate?
>between the existing use of criticality in CertificatePolicies and its use
>            Tom Gindin>

---

From: "Yee, Peter" <[email-masked]>
Date: Mon, 11 Mar 2002 11:48:30 -0500

Since this topic is generating a fair number or interesting responses, I'm
forwarding this message from Francois Rousseau to the list.  Make sure you
include him on any response so he gets a direct copy of the e-mail (he's
not currently subscribed to PKIX).  Thanks.

							-Peter Yee
							[email-masked]

----------------------------------------------------------------------------

Tom,

I totally agree with Peter's suggestion on this one since this was the whole
reason for adding the Signing Certificate Attribute within the Enhanced
Security Services for S/MIME [RFC2634].  It was meant to bound an attribute
certificate to a signed transaction as required here by Roberto.  If the
authorized max amount will change more often than the private signing key of
the individual, than attribute certificates are certainly more interesting
than the using a policy qualifier, private extension, or the subject
directory attribute.

Regards,

Francois

---

From: "Yee, Peter" <[email-masked]>
Date: Mon, 11 Mar 2002 14:04:50 -0800

I have to agree with Michael on this point -- although we're having an
interesting discussion on the technical means by which a purchase limit
can be accomplished, if we're getting down to the case at hand, Roberto
needs to specify many things, among them:

   o  Is the limit delegated?
   o  By whom?
   o  Does the lifetime in which the limit may be used correspond to
      the lifetime of the PKC of the "user" of the purchase limit, or
      to some other period?
   o  Does the purchase limit need to be understood within an open or
      closed community?
   o  Is the CA authoritative for more than name-to-key bindings?

I'm sure there are other questions to ask.  Without answering them, we're
sort of stuck talking in generalized terms.

						-Peter Yee
						[email-masked]

>From: Michael Ströder [mailto:[email-masked]]
>Sent: Monday, March 11, 2002 6:55 AM
>Subject: Re: Q: Where should do I put a max amount in a X.509v3
certificate?
>
>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: "Yee, Peter" <[email-masked]>
Date: Mon, 11 Mar 2002 17:03:23 -0800

Dr S N Henson wrote
>"Yee, Peter" wrote:

>ACs might be more widely supported if a few public examples of them
>and their usage existed. I had a long search a while ago and couldn't
>find a single sample.

Working on it.  You didn't think I posted my attribute certificate drafts
for fun, did you. :-)

						-Peter Yee
						[email-masked]