[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Trying again: Unsettled topics, Qualified Certificates.
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 <stefan@accurata.se> on 05/26/99 12:44:08 AM
To: PKIX <ietf-pkix@imc.org>
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, Hoyt.Kesterson@bull.com 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 <anders.rundgren@jaybis.com> on 05/25/99 08:35:59 AM
>
>To: PKIX <ietf-pkix@imc.org>, "'Stefan Santesson'" <stefan@accurata.se>
>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 <stefan@accurata.se>
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
-------------------------------------------------------------------