[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: NEW Data type for certificate selection ?
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
>sgupta@cygnacom.com
>=============================
>
>> -----Original Message-----
>> From: Dwight Arthur [SMTP:dwightarthur@mindspring.com]
>> Sent: Friday, October 09, 1998 3:31 PM
>> To: Stefan Santesson; Alan Lloyd; ietf-pkix@imc.org;
>> list@seis.nc-forum.com; cert-talk@structuredarts.com
>> 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 <stefan@accurata.se>
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
-------------------------------------------------------------------