Subject: Re: Trying again: Unsettled topics, Qualified Certificates.

From: [email-masked]
Date: Wed, 26 May 1999 12:08:00 -0700

i apologize for the breadth of my response. i just wanted to make clear
that policy qualifier is a possible candidate for your requirement but i
got carried away and addressed all the points in the email.

i don't care if you choose to do an extension as long as that does not
restrict a policy being defined where such constraints more tailored to
that policy could be defined in policy qualifier. of course the policy
could specify that the extension be present and be followed.

i do have one  concern. what if the limit is different for different types
of transactions, e.g. the liquidity of the asset being acquired may effect
the limit - i can agree to rent a $1000 a month apartment but i can't buy a
$1000 diamond?

i don't like the use of printable string in the german version. it seems
difficult to constrain the possibilities. the currency flag in the novell
proposal seems a better choice (although it should be ENUMERATED not
INTEGER)

   hoyt

Stefan Santesson <[email-masked]> on 05/26/99 12:44:08 AM

To:   PKIX <[email-masked]>
cc:    (bcc: Hoyt Kesterson/US/BULL)
Subject:  Trying again: Unsettled topics, Qualified Certificates.

Gentlemen,

Please stick to the subject. If you want to argue pro or against the
EU-directive, then I suggest you direct that to the EU-commission.

I want suggestions and comments on the discussed techniques and that is:

1) Should we add a recommendation to include explaining text in commonName
when storing a pseudonym name

2) Should we use policy qualifiers or a new extension to specify a maximum
reliance limit.

We have to solve these issues and now is the chance to influence the
outcome of this.
I would also like to present 2 different proposals on extensions for
reliance limits.

Proposal 1 from Germany PKI specifications:

monetaryLimit  EXTENSION ::= {
SYNTAX    MonetaryLimitSyntax
IDENTIFIED BY  id-sigi-at-monetaryLimit }
id-sigi-at-monetaryLimit OBJECT IDENTIFIER    ::= {1 3 36 8 3 4}
MonetaryLimitSyntax ::=  SEQUENCE {
  currency     PrintableString (SIZE(3)),
  amount  INTEGER,
  exponent     INTEGER }

Proposal 2 from Bob Juneman, Novell:

RelianceLimits ::= SEQUENCE   {
               perTransactionLimit       MonetaryValue,
               perCertificateLimit MonetaryValue }

          MonetaryValue ::= SEQUENCE {  -- from SET and draft ANSI X9.45
                    currency Currency,
                    amount INTEGER,
                    amtExp10 INTEGER}
                         -- value is amount * (10** amtExp1),
                         -- an exact representation

          Currency ::= INTEGER (1..999)
               -- currency denomination from ISO 4217
               -- US Dollar (USD) is  840.
               -- Euro (EUR) is 978.

My personal suggestion to issue 1 and 2 are:
Issue 1 - Do nothing (no explaining text in commonName)
Issue 2 - Define an optional extension according to the German proposal (I
don't like two different values according to the Novell proposal. It adds
to much confusion).

But this can change.

/Stefan

At 10:52 AM 5/25/99 -0700, [email-masked] wrote:
>
>
>i disagree entirely with your statement that "Certificate policy could
>specify liability but that does not have anything to do with the sums you
>transact or protect." certificates state how they are to be used. key
usage
>is a simplified statement of the constraint on a certificate's use. the
>certificate's policy also describes how the certificate is to be used and
>allows that description to be more precise than key usage. (when this
stuff
>was being defined, i argued that we did not need key usage but a set of
>standardized policies instead. the others agreed in concept but felt key
>usage would be more readily deployable in the start-up phase. )
>
>
>
>certificate policy is intended to control the use to which a certificate
>can be put. liability issues are a strong factor in determining that
>constraint but liability need not be specified in the cp. i suspect that
>you may be confused about the difference between cp and cps
>
>
>
>i don't understand your statement "Of course you can have any number of
>optional items but if people start to actually use them you will pretty
>soon run into severe problems." qualifiers are associated with a specific
>policy. if an implementation (or a human user), understands the policy, it
>must understand the qualifiers that are associated with that policy. i
>agree that a policy with a large number of qualifiers and complex
>interworking may be difficult to deploy, but not more difficult than
>supporting the large number of policies each of which embody the one of
the
>combinations of qualifiers and qualifier values within the policy itself.
>
>
>
>on your recommendation to "ignore", i think such implementors would have a
>difficult day in court when being questioned about the conformance of
their
>product to the accepted business practice. i believe that the courts would
>consider EU regulation as a strong guideline to the acceptable business
>practice.
>
>Where law and technology intersect, the engineers "yes/no" view must adapt
>to the court's "maybe" view. the policies and guidelines may not be
perfect
>and they are sure to be refined by case law. but i would like to have as
>good a technological stake in the ground as possible rather than having
>some judge start with a blank page when determining the acceptablity of a
>digital signature.
>
>     hoyt
>
>
>
>
>
>Anders Rundgren <[email-masked]> on 05/25/99 08:35:59 AM
>
>To:   PKIX <[email-masked]>, "'Stefan Santesson'" <[email-masked]>
>cc:    (bcc: Hoyt Kesterson/US/BULL)
>Subject:  RE: Unsettled topics, Qualified Certificates.
>
>
>
>
>Stefan,
>
><snip>
>>Issue 2) Storage of maximum value per transaction.
>
>>The directive requires that a certificate, if applicable, shall contain
>>information about a maximum monetary amount per transaction that the
>>certificate should support.
>
>My comment to this is that the EU directive seems to try to solve all
>business problems with
>certificates.  This is IMO a bad idea and will only delay things.
>
>Let's say that you open a door with a cert.  How can you possibly say how
>much value you have behind the door?
>
>And what is the true value of a signed business contract?
>
>For monetary transactions it is up to the relying party (the bank, the
>selling organization) to
>set proper limits and to your organization as well.  To do this in a
static
>certificate
>(probably issued by a TTP) is lunacy.
>
>>This could be done by defining a new extension (like the Germans already
>>have done in their interoperability specifications), or alternatively
just
>>say that this shall be solved by a certificate policy, possibly in
>>combination with a policy qualifier.
>
>Certificate policy could specify liability but that does not have anything
>to do
>with the sums you transact or protect.
>
>>Arguments has been raised that Policy qualifiers are not suitable for
>>automatic interpretation but that is not confirmed.
>
>Of course you can have any number of optional items but if people start to
>actually use them you will pretty soon run into severe problems.
>
>So my advice is to put tons of OPTIONAL "crap" in QC-draft (to keep some
>people happy) but
>just IGNORE them in real implementations.  This is the proper (only) way
to
>handle EU bureaucracy :-)  :-)
>
>Anders Rundgren
>http://www.mobilephones-tng.com
>
>
>
>

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. +46-40 108588
211 20  Malmö                   Fax. +46-40 150790
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 27 May 1999 10:22:14 (NZST)

[email-masked] writes:

>At the risk of repeating myself, here is my proposed policy qualifier
>syntax for financial amounts, which could be used for purchase limit 
>whenever the specific policy qualifier OID indicates purchase limit:
>
>FinancialAmount     ::=  SEQUENCE
>{    fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,

Is there any reason for having that field (both the field as a whole,
and the weird tagging)?

>    currency  PrintableString,          -- e.g. "USD" for U.S. Dollar
>    CHOICE    {
>         amount         NumericString,  -- usually including a decimal point
>         value          INTEGER         -- no need for floating-point
>     }

Although a particular "feature" of the ANSI/SET monetary amount encoding 
method rates a comment in the style guide (see the bit at the end of the 
message), it does represent a well-established way of doing this so I don't 
think it's a good idea to invent an incompatible new way when there's already 
an existing way to do it.

Peter.

Extract from the style guide:

>Although the
>ANSI/SET provision for handling currencies which may be present in amounts
>greater than 10e300 (requiring the amtExp10 field to extend the range of the
>ASN.1 INTEGER in the amount field) is laudable, it leads to nondeterministic
>encodings in which a single value can be represented in a multitude of ways,
>making it impossible to produce a guaranteed, repeatable encoding.

(Yes, I'm aware of the rationale for it, but it could have been done better).

---

From: [email-masked]
Date: Wed, 26 May 1999 19:28:51 -0400

Stefan Santesson <[email-masked]> on 05/26/99 06:31:57 PM

To:   Tom Gindin/Watson/IBM@IBMUS, [email-masked]
cc:   [email-masked]
Subject:  Re: Trying again: Unsettled topics, Qualified Certificates.

Tom (and Hoyt),

I like the logic in using a policy qualifier.
There has however been raised a number of problems with that. This is mainly:

1) A qualifier can't be marked critical (eventhough I fail to see the
problem with that)

2) RFC 2459 strongly recommends the use of qualifiers should be restricted
to use of 2 defined qualifier types and none of them seems to fit the
reliance limit case. The best one of them is aimed for textual messages and
does not suit automatic processing.

Viewed from issue 2 it doesn't seam that your proposal haromize with the
recommendation in RFC 2459. I.e. Your proposal doesn't fit into the
recommended types.

[Tom Gindin]   Last week, this same topic came up, and several contributors
suggested that certificate policy qualifiers are a good place for fields
qualifying such things as signature authority amounts.  So, even though RFC 2459
section 4.2.1.5 "strongly recommends that use of qualifiers be limited to those
identified in this section", of which there are only two, I submitted some
proposed generic qualifier syntaxes for discussion, of which this was the
smallest and most specific.  Since I believe that the reason why qualifiers are
discouraged is because of interoperability difficulties in handling newly
defined qualifiers, I proposed some quite large and general qualifiers so that
they could be added to the standard definition of a qualifier and implementors
could ordinarily find any type they might need in the standard definition.  If
parameterized policies are being blocked mainly because of ASN.1 compiler
problems, perhaps it would be better to add to the list of standardized
qualifier types while continuing to deprecate non-standard ones.

Do you have any comment to these problems.

[Tom Gindin]   Unless RFC 2459 is amended to allow some new qualifier types, my
suggestion would not be permitted within PKIX.  RFC 2459 isn't very enthusiastic
about new critical extensions either, but it's less hostile to them ("caution
should be exercised") than to new policy qualifiers.

/Stefan

At 16:11 1999-05-26 -0400, [email-masked] wrote:
>syntax for financial amounts, which could be used for purchase limit whenever
>the specific policy qualifier OID indicates purchase limit:
>
>     It would be perfectly reasonable to define "currency" as:
>     currency  CHOICE    {
>          currencyName        PrintableString,     -- e.g. "USD" for U.S.
>Dollar
>          currencyID          Currency   -- integer from ISO 4217
>     }
>
>     with Currency defined as in the Novell proposal, copied below:
>
>Currency ::= INTEGER (1..999) -- currency denomination from ISO 4217
>          Tom Gindin

---

From: [email-masked]
Date: Thu, 27 May 1999 01:51:46 -0700

hello stefan

since i did nor participate in the development of 2459, i do not know the
rational for the restriction you mentioned and i will not presume to
propose amendments to it.

i do have an response to your question 1.

i don't believe that a policy qualifier needs to be marked critical. the
qualifier is in support of the policy. if one doesn't understand the
policy, then there is no need to understand the policy qualifier. if one
understands the policy then one understands the qualifier. if support of
the policy is critical, recognizing and supporting the policy is what
should be made critical.

i'm fond of criticality (having created the approach for x500 and
certificates) but i agree that marking something critical should be
considered carefully if one's goal is to issue a certificate that will
processable by the largest number of relying parties possible.

it is possible to have specialize relying party software that is performing
a task that critically needs specific information from the certificate. the
issuer could put that information in a special extension but not mark it
critical. the certificate would be usable in normal relying party software
which would ignore the unknown extension. the special relying party
software would not perform the special function unless the extension were
present, critical or not.

this approach carries over into policy. a certificate may indicate that it
can be used in policy x (as well as other policies). a relying party which
supports policy x knows that certain information must be in the
certificate, either in qualifiers or extensions, to properly process the
requested function under policy x. those extensions need not be marked
critical.

note that even though i can recommend where to place the structures you
have been proposing, i am still concerned that a common approach may not be
generally applicable to the specific needs of many different policies.

    hoyt

Stefan Santesson <[email-masked]> on 05/26/99 03:31:57 PM

To:   [email-masked], Hoyt Kesterson/US/BULL
cc:   [email-masked]
Subject:  Re: Trying again: Unsettled topics, Qualified Certificates.

Tom (and Hoyt),

I like the logic in using a policy qualifier.
There has however been raised a number of problems with that. This is
mainly:

to use of 2 defined qualifier types and non of them seams to fit the

/Stefan

>syntax for financial amounts, which could be used for purchase limit
whenever
>          amount         NumericString,       -- usually including a
decimal
>point

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 27 May 1999 10:17:54 -0400

>    currency  PrintableString,          -- e.g. "USD" for U.S. Dollar

ISO spec 4217 defines a standard for currency names; the
value should be constrained to that.