Subject: Re: Rename Qualified Certificates?

From: Graham Klyne <[email-masked]>
Date: Mon, 10 May 1999 12:31:36 +0100

At 08:15 07/05/99 +0200, Hans Nilsson wrote:

>I would therefore like to propose that the PKIX term is changed to something
>else, and possibly more descriptive. My suggestion is "identity
>certificates", but there may be other good suggestions.

"Identity" seems reasonable, and more descriptive than "qualified".  But I
note from section 2.1 the draft, it must:

   - Be issued to a natural person (living human being).

To me, this suggests "personal certificate".

If these certificates were to be extended to other legal entities
(companies, etc.) then I think "identity" would be more apposite.

#g

------------
Graham Klyne
([email-masked])

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 19 May 1999 11:34:54 -0600

Nick,

In this connection, you might want to take a look at the certificate quality 
attributes that are contained in Novell Security Attributes extension
that we include in all certificates generated by Novell and/or Novell's
Public Key Infrastructure Services (PKIS) CA, a no charge component
of NetWare 5 , and available very soon on NT and Solaris. See
http://developer.novell.com/repository/attributes/certattrs_v10.htm. 

In particular, the type of CA (whether it is licensed or not) is indicated in 
the Certificate Class (due diligence) subattribute of the CA's certificate -- 
see Appendix D, code values 220=Accredited CA, 225=Governmentally licensed 
or accredited CA, and 240=Government CA.  If those definitions don't
quite fit the specific requirements, I'd be more than happy to add new
ones in that range, or tod discuss minor semantic changes.

Likewise, the same Certificate Class subattribute defines the type
of individual entity, which can range from completely anonymous
(the subject ore gloves to avoid leaving any fingerprints on the knob
of the vending machine where he bought his cert), up through
various locally known unambiguous names, globally unambiguous 
names, electronic pseudonyms, disambiguated names, organizational
persons, registered legal name, publically traded enterprise, chartered 
institutions, quasi-governmental organizations, tribal (semi-autonomous)
authorities, etc.  Again, I think that virtually all of the problems you are
facing have already been addressed, but if not, I'd be happy to 
wok with you to refine the definitions as might be required.

Finally, a Reliance Limit is defined in the same document that 
can be applied on a per transaction or an aggregate, per certificate 
basis (perhaps using something like an extended OCSP which would
accumulate reliance limits per validation), or both.  The Reliance Limit
is coded in such a way to permit denomination in any of the world's
officially recognized currencies, including the Euro, plus gold, silver, 
platinum, and palladium, and various special bond market units, 
special settlement currencies, the multi-national currencies used in
Africa -- CFA Franc BCEAO, operated by the Banque Centrale des 
Etats de l'Afrique de l'Ouest, CFA Franc BEAC, operated by Banque 
des Etats de l'Afrique Centrale, and a code that is specifically
reserved for test purposes. The country codes conform to ISO 4217, 
currency and funds code list, at least as of August, 1998.

BTW, the referred-to document has been circulated within the ECC
and several European countries, and may have helped to define some
of the capabilities they are currently seeking.

Regards,

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> "Nick Pope" <[email-masked]> 05/19/99 03:01AM >>>
Stefan,

To expand further on my comment regarding the Directive requirements for
Qualified Certificates not being met by the current QC draft. The specific
requirements which I believe ar not met are:

(x)	an indication that the certificate is issued as a qualified certificate;

I consider this include the fact that the certificate is issued by a CA (CSP
in directive terms) which meets the (annex II) requirement of the directive.
Hence, I recognize that this is may be outside the scope of the PKIX work.

(b)	the name of the holder or a pseudonym which shall be identified as such;

I agree that the QC says that it supports pseudonyms.  However, it doesn't
define how it "shall be identified as such".

(i)	limitations on the value of transactions for which the certificate can
be used if applicable.

From discussions with members of the Commission they require this to be
explicit, not through reference to a practice statement.  Hence this
requires a specific extension.

I may have got this wrong, and would very much welcome your views on how
these requirements are met.  However, I do not see how a CSP wanting to meet
these requirements can do the above in a standard way based on the QC draft.
I would not expect the QC draft to require that fields supporting all these
functions are always present, but if it is to claim the title of "qualified"
from the European viewpoint it should define how these functions can be
supported.

I would very happy to see the QC document did define ways of meeting these
requirements.  However, if it doesn't then I would object to the word
"qualified" appearing in the title.  Whether followed by the word "Profile"
or "identity" or whatever.

Independent of the what we call it I would like to know whether it is your
aim to meet the requirements of the Directive in this document, from the
point of view of interoperability as you describe below.

> Thank you for sharing your thoughts, but I think you got i a
> little bit wrong.
>
What do I have wrong.  That the QC document aims to meet the requirements of
the Directive to support an equivalent to hand-written signatures, or my
understanding of what is supported by the QC document.

..
>
> The PKIX specification is a technical standard for interoperability. It's
> purpose it so supply you with tools to understand the information
> stored in
> such certificates. IT DOES NOT SAY WHAT MAKES A CERTIFICATE "QUALIFIED" OR
> NOT.
>
I would hope that it facilitates interoperability between systems conforming
to the Directive.  I agree, from the European viewpoint the definition of
what is "qualified" comes from the Directive.

> >
> >Also, unless it is issued by a CA which also meets the annex II it cannot
> >claim to meet the full requirements of qualified electronic
> signatures which
> >are equivalent to hand-written signatures under clause 5.1 of
> the directive.
> >
>
> Again the PKIX profile is a TECHNICAL profile FOR Qualified Certificates.
> It's purpose is NOT to state any functional or other requirements. It's
> purpose is only to provide technical interoperability between "Qualified
> Certificates". E.g. so that the information put into an Italian "Qualified
> Certificate", can be displayed and understood by a German, English or
> American software.
>
That would be my aim also.  Where the Italian qualfied certificate conforms
to the Directive and the American software follows the QC document.

..

Hope this helps to clarify my concerns.

Nick

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 20 May 1999 17:12:29 -0600

Steve, as I replied to Nick off list, I think we have to differentiate
between attributes such as currency type and maximum liability,
which may have to be negotiated individually with the user, rather than
being CA-centric, vs. an indication of approval authority, which is certainly 
static and hence could go in the policy qualifier if necessary.

I confess to being averse to policy qualifiers that are not by themselves
meaningfully machine readable, which is why I lean towards including
such Trust In Advertising details in the certificate itself, where it will
be very readily visible, even at the cost of a few more bytes in the certificate.

Bob

>>> Stephen Kent <[email-masked]> 05/20/99 03:57PM >>>
Nick,

>I agree with the aim of not over-loading a certificate.  However, I don't
>want to go too far the other way and overload the policy id so that a new
>policy id is required for any minor variation on the use certificates within
>a common overall policy.

Fair comment.  One might use a new extension, as Bob Junenman suggested,
although when I look at policy qualifiers I see a ready made place to plug
in a range of values for approval authority, currency and max value for
liability, etc.

Steve

---

From: [email-masked]
Date: Thu, 20 May 1999 19:23:20 -0700

hello, i rarely stick my oar into these conversations but this is an
important point to me.

steve's proposal is what i thought we intended so long ago when we designed
the public key certificate policy information. i have been somewhat bemused
with certificates holding long human consumable text strings (long enough
without even being localized).

i had hoped that for example, a certificate policy might specify that the
certificate can only be used in support of a transaction whose value did
not exceed a value contained in the policy qualifier (which may hold a
structure with that value specified in several currencies) and that the
relying party software would inforce the policy rule, not the humans using
the system.

 some time ago at an aba information security committee meeting, i proposed
a briefly explored idea that a standard form contract could be identified
in the cp while modifications to that contract, e.g. excluded clauses,
would be specified in the qualifier. i believe the significant value  is
not that some consumer can study the contract, but that the relying
application can understand how each value in the policy qualifier affects
what the application will do (assuming we move beyond limited browser
handling of the certificate and its policy - mobile code seems to be the
enabler for this)

i am not happy with overloaded certificates but my first target would be
eliminating long text strings. i know this requires a program that can
intelligently handle the values in the certificate. then i believe that it
is possible that some information, common across a large number of
certificates, could be contained in a separate signed structure, e.g.
another certificate. but i also want to avoid giving the relying party any
more signed structures to verify than necessary. what if i reduce the size
of the public key certificate but am required to verify two certificates
instead of one.

i don't beleive we can avoid some of those structures however. for example,
if we want to identify a policy with an object id, then assuming the rely
party can get to that policy and supporting mobile code, how does the
relying party know it is working with the intended policy definition? one
approach is a standardized structure that holds the object id of the
policy, names of and pointers to mobile code, and other relevant
information. that structure would be signed by the CA that issued the
certificate or by some other entity whose relationship to the issuing CA is
specified. however, the retrieval, verification,  and evaluation of this
structure shouldn't have to be done for every transaction but only in the
initialization of support for the identified policy.

i realize that if one's focus is on non-augmented browser use, none of what
i propose is useful. my comments are based on the hope that we will move
away from such lowest common denominator use.

    hoyt

Stephen Kent <[email-masked]> on 05/20/99 02:57:49 PM

To:   "Nick Pope" <[email-masked]>
cc:   "Stephen Kent" <[email-masked]>, [email-masked] (bcc: Hoyt
      Kesterson/US/BULL)
Subject:  RE: Rename Qualified Certificates?

Nick,

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 22 May 1999 23:44:12 +0200

Hoyt,

I agree with you. I think that policy qualifiers should be used for this
purpose. Financial ammount are absolutely a matter of policy and if there
are a variable value related to a policy, then it seams to me that policy
qualifiers serves just that purpose.

/Stefan

>in a range of values for approval authority, currency and max value for

-------------------------------------------------------------------
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: Alan Lloyd <[email-masked]>
Date: Mon, 24 May 1999 08:52:50 +1000

I agree with Nick here.

Syntax is not that useful unless one understands the semantic behind it
for process and validation.

Syntax definitions should be the last part of a system design - not the
first.

regards alan

> -----Original Message-----
> From:	Nick Pope 
> Sent:	Saturday, May 22, 1999 2:52 AM
> To:	[email-masked]; Stephen Kent
> Cc:	[email-masked]; [email-masked]
> This seems to be a bit of a Blunderbus approach.  It may well hit a
> number
> of things that wasn't intended and may well miss what we were aiming
> at.
> 
> Nick
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: 21 May 1999 17:12
> > To: Stephen Kent
> > Cc: Nick Pope; [email-masked]; [email-masked]
> > I agree with Steve and Hoyt that we 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, which suggests to me
> that new
> > extensions are should be used instead, I'd like to submit some
> > proposed generic
> > qualifier syntaxes for discussion.  These are quite large to
> > reduce the number
> > of qualifiers people would need to add to their ASN.1 parsers:
> >
> > PrimitiveField      ::=  SEQUENCE  {
> >      fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
> >      CHOICE    {
> >      number         NumericString,
> >      printable PrintableString,
> >      wideChar  BMPString,
> >      universal UTF8String,
> >      hugeChar  UniversalString,
> >      ascii          IA5String,
> >      boolean   BOOLEAN,
> >      int       INTEGER,
> >      realValue REAL,
> >      boolArray BIT STRING,
> >      bitData        [29] IMPLICIT BIT STRING,
> >      blob      OCTET STRING,
> >      omitted        NULL,
> >      id        OBJECT IDENTIFIER,
> >      time      GeneralizedTime,
> >      oldTime   UTCTime
> >      }
> > }
> >
> > InternetField  ::=  SEQUENCE  {
> >      fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
> >      CHOICE    {    -- mainly extracted from GeneralName
> >      generalNames        SEQUENCE OF GeneralName,
> >      otherName      [0]  INSTANCE OF OTHER-NAME,
> >      rfc822Name          [1]  IMPLICIT IA5String,
> >      dNSName        [2]  IMPLICIT IA5String,
> >      x400Address         [3]  IMPLICIT ORAddress,
> >      directoryName       [4]  IMPLICIT Name,
> >      ediPartyName        [5]  IMPLICIT EDIPartyName,
> >      uniformResourceIdentifier     [6]   IMPLICIT IA5String,
> >      iPAddress      [7]  IMPLICIT OCTET STRING,
> >      registeredID        [8]  IMPLICIT OBJECT IDENTIFIER,
> >      TCPPort        [10] IMPLICIT INTEGER,
> >      UDPPort        [11] IMPLICIT INTEGER,
> >      OSIPSAP        [12] IMPLICIT SEQUENCE OF OCTET STRING
> >      }
> > }
> >
> > FinancialAmount     ::=  SEQUENCE
> > {    fieldID        [30] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
> >      Currency  PrintableString,               -- e.g. "USD" for
> > U.S. Dollar
> >      CHOICE    {
> >           amount         NumericString,
> >           value          INTEGER         -- no need for
> floating-point
> >      }
> > }
> >
> >      Tom Gindin
> >
> >
> >