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

[lynn.wheeler@xxxxxxxxxxxxx]

not just a matter of churning the certificate credential as the "signing
limit" is changed .... but also a return to pre-80s offline transactions
where there is no aggregation (month to date, qtr to date, year to date),
velocity, rate, acceleration, SKU-based limits (pencils, gasoline, tires,
computers), MCC-based limits, etc.

... aka even simple credit limit or daily limit ... isn't single
transaction value but aggregation of transactions.

credential/certificate limits like checks with signing value limits was
old-fashion, offline, non-electronic solution ... but much of the
infrastructure has moved to online with minimum of simple real-time
aggregation making the old fashion offline credential/certificate limits
superfulous and redundant.

random refs:
http://www.garlic.com/~lynn/aadsmail.htm#fraud Human Nature ... a little
cross-posting
http://www.garlic.com/~lynn/aadsmail.htm#law dbts: More on law vs economics
http://www.garlic.com/~lynn/aadsmore.htm#hcrl3 Huge CRLs
http://www.garlic.com/~lynn/aadsmore.htm#killer1 Killer PKI Applications
http://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1
vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#01 superfulous & redundant (addenda)
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsm6.htm#ppsem3 Payment Processing Seminars
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards?
(addenda)
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate?
(addenda)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
http://www.garlic.com/~lynn/aepay6.htm#pkimort2 problem with the death of
X.509 PKI (forwarded)
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1
Specification for Mobile Commerce
http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
http://www.garlic.com/~lynn/aadsm10.htm#limit Q: Where should do I put a
max amount in a X.509v3 certificat e?



degustafson@xxxxxxxxxxxx on 3/11/2002 8:26 am wrote:


Hi Peter,

Actually, similar things are suggested in "Planning for PKI, Best
Practices for deploying the PKI" by Russ Housley and Tim Polk -- see the
section subtitled "Attribute Certificates", pp 274 - 277.  Note that the
entire chapter is titled "Future Developments" so, presumably, one needs
to proceed with appropriate caution.

In any event, the rationale for placing such an attribute within a
separate Attribute Certificate is clearly spelled out:

1) a Certification Authority is most likely "not authoritative" for this
kind of information

2) this kind of information is also likely to change frequently which
would cause highly undesirable certificate churn if included in x.509 v3
ID certificates.

In contrast, an application-specific attribute could be certified by an
authoritative AA and carried in an Attribute Certificate.  The AC is
defined as an extension of a suitable ID certificate.  Such would be
necessary but perhaps not sufficient for general use of ACs to convey
application-specific user priviledges.  For example, since much attribute
information is not disclosed outside a well-defined group of relying
parties, there would also need to be a (general purpose?) mechanism to
limit access to AC information exchanged.

Best Regards,

Dale Gustafson