Subject: RE: NEW Data type for certificate selection ?

From: Stefan Santesson <[email-masked]>
Date: Mon, 12 Oct 1998 23:40:34 +0200

Sarbari,

As I see it I would not rule out any select criteria and say that in
general that criteria is better than another.

So personally I recognize your criteria solution as a very valid one in
some situations, as I also recognize Dwights policy OID as a valid criteria
in other cases.

To your question. Does the X.500 matching rule cover selection by issuer
name according to your scheme?
My conclusion is that it does. You can specify any set of Issuer name
attributes you want and you get a match as long as your presented
attributes matches those of the target certificate.
(If any X.500 expert have another opinion, I would like to here it.)

And as you see (Dwight), the policy OID is also covered by this structure.

The certificateMatch has the following structure (X.509 section 12.7.2):

certificateMatch MATCHING-RULE ::= {
   SYNTAX           CertificateAssertion
   ID               id-mr-certificateMatch }

CertificateAssertion ::= SEQUENCE {
   serialNumber            [0] CertificateSerialNumber OPTIONAL,
   issuer                  [1] Name                    OPTIONAL,
   subjectKeyIdentifier    [2] SubjectKeyIdentifier    OPTIONAL,
   authorityKeyIdentifier  [3] AuthorityKeyIdentifier  OPTIONAL,
   certificateValid        [4] Time                    OPTIONAL,
   privateKeyValid         [5] GeneralizedTime         OPTIONAL,
   subjectPublicKeyAlgID   [6] OBJECT IDENTIFIER       OPTIONAL,
   keyUsage                [7] KeyUsage                OPTIONAL,
   subjectAltName          [8] AltNameType             OPTIONAL,
   policy                  [9] CertPolicySet           OPTIONAL,
   pathToName              [10] Name                   OPTIONAL }

AltNameType ::= CHOICE { 
   builtinNameForm	ENUMERATED {
                         rfc822Name                (1),
                         dNSName                   (2),
                         x400Address               (3),
                         directoryName             (4),
                         ediPartyName              (5),
                         uniformResourceIdentifier (6),
                         iPAddress	                 (7),
                         registeredId              (8) },
   otherNameForm         OBJECT IDENTIFIER }
CertPolicySet ::= SEQUENCE (1..MAX) OF CertPolicyId
 
The following is defined in X.509, concerning Issuer name and policy OID:

     This matching rule returns TRUE if all of the components 
     that are present in the presented value match the corresponding 
     components of the attribute value, as follows:

     b)  issuer matches if the value of this component in the 
         attribute value equals that in the presented
         value;
     j)  policy matches if all of the policy elements identified 
         in one of the presented values are contained in the set of 
         policyElementIds in any of the policyInformation values in 
         the certificate policies extension in the stored attribute 
         value;  there is no match if there is no certificate policies 
         extension in the stored attribute value;

/Stefan

At 11:28 AM 10/12/98 -0400, Sarbari Gupta wrote:
>I have been following this thread with great interest. Since the thread
>was rekindled, I wanted to offer another usage model that needs a
>slightly different selection criterion. I was not sure whether this
>model was discussed before on this list.
>
>One of the certificate selection mechanisms in use today is based on
>matching the issuer name. SSL implementations allow this form of
>selection. There is another variant of this model that may also be
>useful. In this variant, the certificate selection is based on a prefix
>of the issuer name. For example, the selection may be done based only on
>the country name and the organization name components of the issuer DN.
>Thus, if a large organization has multiple CAs, the selection criteria
>may logically be "a certificate issued by the organization" instead of
>the more restrictive "a certificate issued by a particular CA within the
>organization".  
>
>Do the X.500 matching rules support this kind of selection? This model
>may be useful for SSL connections. It will certainly be useful for
>S/MIME implementations; if the peer's certificate is part of an
>organization-specific PKI, the S/MIME implementation could conceivably
>select an appropriate certificate (for the user) based on a prefix of
>the issuer DN of the peer's certificate. Ideally, the S/MIME
>implementation would support a configurable set of prioritized selection
>criteria that allows the automatic selection of one amongst a set of
>user certificates. 
>
>- Sarbari Gupta 
>=============================
>Sarbari Gupta
>CygnaCom Solutions
>(703)848-0883 ext 217
>[email-masked]
>=============================
>
>> -----Original Message-----
>> From:	Dwight Arthur [SMTP:[email-masked]]
>> Sent:	Friday, October 09, 1998 3:31 PM
>> To:	Stefan Santesson; Alan Lloyd; [email-masked];
>> [email-masked]; [email-masked]
>> Subject:	RE: NEW Data type for certificate selection ?
>> 
>> I apologize for posting this after the thread has been summarized and
>> closed. The summary did not mention the part of the discussion that
>> suggested policy oids as the basis for a solution. I would like to
>> expand on
>> this.
>> 
>> Selecting the right certificate is an instance of the general problem
>> of
>> building the right chain. This problem, in turn, needs to be closely
>> aligned
>> with the trust model being used. Many or most of the examples given
>> were
>> drawn from the so-called "open" or public model in which parties with
>> no
>> prior relationship (NPR) establish a (very low) level of trust because
>> someone in the public CA business has issued a certificate asserting
>> that
>> the subject produced documentary evidence of a certain identity.
>> 
>> Other models, imho more suitable for significant business use, are:
>> 
>> a. The parties have an existing business relationship and one of the
>> parties
>> has issued the other a certificate as a token of that relationship.
>> This
>> certificate is then to be used for access control and signing in
>> facilities
>> offered by the issuer. I believe that Netscape's crypto.signText()
>> function
>> provides a fully satisfactory method of saying, "I will only accept
>> certificates I issued." In addition, the emerging AADS approach
>> supports
>> this without requiring actual certificates.
>> 
>> b. The parties share a relationship with an intermediary (bank,
>> finance
>> company, expeditor, factor, etc) who guarantees (for a fee) the
>> parties to
>> each other. Again, crypto.signText() or equivalents could be used to
>> say, "I
>> am looking for a certificate issued by MonsterBank" or a slightly more
>> complex form of AADS could be used.
>> 
>> c. The parties share membership in an organization which, through
>> member
>> agreements, binds all parties to acceptable business terms and risk
>> management procedures. Similar procedures can be used as in (b): "I am
>> looking for your certificate issued by S.W.I.F.T."
>> 
>> d. Each party has a relationship with an intermediary that's a member
>> of an
>> organization such as described in (c). Now we are looking for
>> something more
>> complex, like, "I will accept and debit card issued by any bank that
>> participates in NYCE or CIRRUS but not STAR." These relationships
>> should
>> imho _not_ be recorded in the client certificates as the data may
>> change
>> during the life of the certificate. Nor, imho, should the server send
>> a list
>> of the thousands of member banks as a part of its signing request.
>> Instead,
>> CIRRUS etc should each establish a certificate policy and form
>> contracts
>> with each participating bank binding it to the policy. It should
>> register
>> the policy and obtain an OID, then allow each member bank to issue
>> certificates bearing the OID. Your bank may then issue a certificate
>> to you
>> carrying the CIRRUS and STAR oids. I may send a signing request
>> calling for
>> certificates bearing NYCE or CIRRUS OIDs. Your browser would then
>> respond
>> with your bank certificate because the CIRRUS OID matched. If you have
>> several matching certificates (because, for example, you have several
>> bank
>> cards) the browser would ask you to chose, but the list of
>> alternatives
>> would be only your CIRRUS or NYCE bank cards and would exclude your
>> drivers
>> license, your library card, etc. Fraudulent certificates issued by
>> BongoCerts with the NYCE OID would be defeated either by (1) OCSP to
>> the
>> NYCE responder, or (2) your browser sends a certificate chain
>> including your
>> certificate from your bank and your bank's certificate from NYCE.
>> 
>> e. Finally, the model that I personally believe will account for the
>> most
>> profitable segment of eCommerce: the employee card. I do not want to
>> offer
>> my employee a certificate for accessing our bank, a separate
>> certificate for
>> accessing our broker, a separate certificate for accessing our office
>> supplies vendor, and a separate certificate for accessing her 401K
>> plan.
>> (Too much overhead, doesn't fit on a smartcard, too much risk that we
>> l miss
>> one when it's time to revoke.) Instead, I want to offer every employee
>> a
>> certificate that says, "this is an employee of this company" that
>> allows
>> access to the benefits plans, the ability to initiate (but not
>> authorize)
>> office supplies purchases, and access to the appropriate gender
>> washrooms. I
>> may also offer some employees a different certificate (or an attribute
>> certificate that supplements the identity certificate) that includes a
>> policy OID that says, this is an officer, the company stands behind
>> and
>> honors commitments made by this person. In my cross-certification with
>> the
>> office supplies vendor, I can map my "this is an officer" policy with
>> the
>> vendor's "authorized approver of purchases" policy. Further, I could
>> map my
>> "this is an officer" policy to my bank's "authorized signer" policy or
>> I
>> could create a different "authorized for high value financial
>> transactions"
>> policy and map it to the appropriate policies of my bank and my
>> broker.
>> (Note, I am not inventing this policy mapping stuff, it's straight out
>> of
>> X.509) Now, when some other bank sends my employee a signing request
>> it asks
>> for something like "a certificate bearing the authorized signer OID
>> issued
>> by a bank that's a member of some ACH network." In this case, it is
>> necessary but not sufficient to select the right certificate. It is
>> further
>> necessary to build a chain of certificates, leading back to some
>> appropriate
>> root, with the specifies policies (or mapped policies) at every
>> certificate
>> in the chain.
>> 
>> Note that I am _not_ advocating roles or authorizations in the
>> certificate.
>> I am advocating policies, represented by OIDs, that specify issues
>> like
>> acceptable uses of certificates, applicable communities of interest,
>> etc.
>> where all subjects, issuers, and authorized relying parties are bound
>> by
>> contract to the policy.
>
>
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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

---

From: David Boyce <[email-masked]>
Date: Tue, 13 Oct 1998 13:09:54 +0100

I have a couple of questions regarding the X.509 definition of
CertPolicySet which Stefan quoted.

>CertificateAssertion ::= SEQUENCE {
    ...
>   policy                  [9] CertPolicySet           OPTIONAL,
    ...

>CertPolicySet ::= SEQUENCE (1..MAX) OF CertPolicyId

Can anyone shed light on why this is called a CertPolicy*Set* when it's
defined as a SEQUENCE OF ?

The only thing I can think of is that the nature of the data is 'SET
OF', with the name reflecting that nature, but that 'SEQUENCE OF' has
been used in the definition of the type in order to avoid introducing
DER-encoding hassles.

>         extension in the stored attribute value;

Is there mismatch between this description and the defined syntax for
CertPolicySet here?  The presence of the phrase 'in one of the presented
values' seems to indicate a different syntax to the one defined.

It looks to me as if the author had in mind a definition of
CertPolicySet along the lines of

    CertPolicySet ::= SET (1..MAX) OF CertPolicyPresentedValues

    CertPolicyPresentedValues ::= SET (1..MAX) OF CertPolicyId

(SET OF being regarded as equivalent to SEQUENCE OF for the purposes of 
this discussion).

If not, then surely CertPolicySet would comprise the entire 'presented 
value', making the phrase 'identified in one of the presented values' 
misleading.

Or am I just reading something into the description which isn't there?

David.
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
Email:	[email-masked]	Isode's WWW: http://www.isode.com/

---

From: David Boyce <[email-masked]>
Date: Tue, 13 Oct 1998 13:08:10 +0100

>(If any X.500 expert have another opinion, I would like to here it.)

That appears to be broadly correct.  Bear in mind that in order to match
against a set of Issuer names, you will have to be able to specify
multiple matching rules (one for each Issuer you wish to match against);
a DAP/LDAP search filter allows you to do this, but in the specific
context of this discussion (selection mechanisms for certificates) this
may not apply.

Sarbari also asked about matching against the prefix of the Issuer name.
 The short answer appears to be that that is not possible using the
current definition of certificateMatch Matching Rule, since it always
uses an equality match of the Issuer name.  A new Matching Rule (or the
present one modified) would have to be defined to support matching a
prefix.

If such a new prefix matching rule were defined, one way forward is to
adapt either an X.501 SubtreeSpecification or X.509
NameConstraintsSyntax to define the limits of matching.  The latter,
being X.509 based anyway, is probably the better choice since it also
caters for similar matching against subjectAltName and issuerAltName.

(I don't believe specifying 'prefix of Name' is adequate, since it may
not be acceptable to match an Issuer at some greater depth than
intended.  Both SubtreeSpecification and NameConstraintsSyntax permit
limits to be placed on the depth of the matching, and also permit the
explicit exclusion of Names which would otherwise match.)

>And as you see (Dwight), the policy OID is also covered by this 
structure.

Correct;  although I have some questions about its definition which I 
raise separately, they don't appear to affect this.

David.

-- 
David Boyce