Subject: RE: Unsettled topics, Qualified Certificates.

From: [email-masked]
Date: Tue, 25 May 1999 10:52:44 -0700

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

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 26 May 1999 09:44:08 +0200

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

>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: "Todd S. Glassey - ELN" <[email-masked]>
Date: Wed, 26 May 1999 06:50:41 -0700

I concur with Stefan's observations...