RE: RE: 3280bis: CRL validation

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Denis,

We may be solving different problems.  I am solving the problem of names not
being unique.  There is no need or benefit to adding a new extension.

May be you are proposing to list the names of the CA's in the path in this
extension.  If so, the solution does not fit today's extensions and lacks
agility of the algorithm I proposed and has the same or greater complexity.

It will not reduce the complexity since the same matching will be requiring.

You saying that you do not understand my posting is akin to turning a deaf
ear to a discussion.

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On
Behalf Of Denis Pinkas
Sent: Friday, June 10, 2005 12:55 PM
To: ietf-pkix@xxxxxxxx; Santosh Chokhani
Subject: Re: RE: 3280bis: CRL validation



 >Denis,

>What is your solution?

There are two cases to consider for CRL issuers.

  a) the CRL Issuer issues revocation information for a single CA;
  b) the CRL Issuer issues revocation information for more than one CA.

Case a) is simple, while case b) is more much complex (this is the "zillions
of cases").

We may have a simple and secure rule for case a). 
The certificateIssuer extension from a certificate is defined as :

     certificateIssuer ::= GeneralNames

with 

     certificateIssuer ::= GeneralNames

with

     GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

In that case the name(s) contained in certificateIssuer MUST be certified by
the CA 
that has issued the certificate where the extension appears.

This means that the CRL Issuer can only be nominated by the CA that has
issued the certificate.

Denis

>-----Original Message-----
>From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
>Sent: Friday, June 10, 2005 10:42 AM
>To: Santosh Chokhani
>Cc: ietf-pkix@xxxxxxxx
>Subject: Re: 3280bis: CRL validation
>
>
>Santosh,
>
>> Denis Pinkas.
>>  
>> You wrote:
>>  
>> "Note that I am personally against Santosh's proposal which is 
>> over-complex."
>>  
>> Let us look at what is "over-complex" about it.  I would use two 
>> standard metrics for complexity: software and computational.  I would 
>> add two personally defined complexity metrics: intellectual and
>analytical.
>
>Don't continue: I am lost.
>
>> I define intellectual complexity as the ability to understand the 
>> algorithm.  In this area, the semiformal approach I used may have 
>> confused some.  But, all the algorithm is saying is that after 
>> ignoring self-issued certificates, both paths should match in terms 
>> of issuer and subject.  To me that seems simple.
>>  
>> I define analytical complexity as the ability to analyze the security 
>> property.  Again, in this area, all the algorithm is ensuring is that 
>> at each level the same subject is referred to ensuring that even if 
>> names are not unique globally, the correct CRL is obtained.
>>  
>> As you know software complexity is defined in the software 
>> engineering literature as the ability to comprehend and maintain the 
>> implementation.  It is measured using metrics such as cyclometric and 
>> there are tools that can be run against the code to capture this.  
>> While I have not implemented the algorithm and can not say what the 
>> actual number is, I suspect it will be low.
>>  
>> As you know computational complexity is defined as the computation
>> power
>> used to execute the algorithm.  I suspect if employed during path 
>> validation only, it is simply name matching in linear space.  So, it 
>> will not have any exponential problem (so called NP problems); it will 
>> be linear and matching two names is not an expensive proposition.  Now, 
>> if the algorithm is used to guide path development, you will see 
>> actually improvement in performance by eliminating paths that are not 
>> relevant or should not be used.
>
>> In summary, my analysis shows it is not "over-complex".
>
>It is simply not understandable.
>
>> It would help
>> if you proposed an alternative that is secure and less complex.  Feel
>> free to provide definitions and metrics for complexity.
>
>I am unable to provide metrics for complexity, but I have already 
>provided a
>
>simple solution to a simpler problem.
>
>Denis
>
>> Santosh Chokhani
>> Orion Security Solutions, Inc.
>> 1489 Chain Bridge Road, Suite 300
>> McLean, Virginia 22101
>> (703) 917-0060  Ext. 35 (voice)
>> (703) 917-0260 (Fax)
>> chokhani@xxxxxxxxxxxx
>> Visit our Web site
>> http://www.orionsec.com <http://www.orionsec.com/>
>>  
>
>
>

Regards,

Denis Pinkas