Subject: RE: Question:Authority Information Access

From: "Hiroyuki Sakakibara" <[email-masked]>
Date: Thu, 25 Nov 1999 21:23:51 +0900

Mr. Khaja E. Ahmed

Thank you for your quick reply.

>All the burden you are placing on the client to check multiple places
should
>really not be necessary.  It should be possible for the client to go to a
>single location indicated by either the DP or the AIA extension and
*depend*
>on it being there just as much as you depends on the availability of the
>network itself.  Revocation status checking service should have the same

"It should be possible for the client to go to a single location ... "

The reason is that if a client communicates multiple servers( OCSP
servers and CRL DP servers) for checking the revocation status
of one certificate, the path processing will be heavy, right ?

>availability / dependability of something like DNS.  If you suddenly lose
>access to DNS service you have lost access to a mission critical service
and
>are essentially "down" or severely hobbled in your functionality.  That is
>why DNS service is designed to be highly available and dependable.

The environment where a OCSP server is always available is convinient.
However, eventhough a OCSP system has high availability and
dependability like DNS, it is not 100% perfect.
So I think, it is good that
a certificate is checked automatically
in another optional way, CRL DPs, when a OCSP system is down.

Again, in RFC2459 specification,  are following "[1] and [2] "
legal or illegal ?

----------------------------------------------------------------------------
----------------
[1] AIA + CRL DPs
1st:  OCSP server-1 ( described in AIA )
2nd: CRL DPs( described in CRL DPs )

or

[2]  AIA
1st : AccessDescription-1  "OCSP server-1"
2nd : AccessDescription-2  "use CRLs ( indicated by OBJID ),
                                                 located here( indicated by
GenelalName)"
----------------------------------------------------------------------------
----------------

Do these make sense ? No ?

Hioryuki Sakakibara

=========================================================
>> -----Original Message-----
>> From: Hiroyuki Sakakibara [mailto:[email-masked]]
>> Sent: Tuesday, November 23, 1999 7:02 PM
>> To: [email-masked]
>> Subject: Question:Authority Information Access
>>
>>
>> Hello
>>
>> I have questions about RFC2459 Authority Information Access extension .
>> In RFC2459, this extension is defined as
>>
>> "The authority information access extension indicates how to access CA
>>    information and services for the issuer of the certificate in which
>>    the extension appears. Information and services may include on-line
>>    validation services and CA policy data.  (The location of CRLs is not
>>    specified in this extension; that information is provided by the
>>    cRLDistributionPoints extension.)  This extension may be included in
>>    subject or CA certificates, and it MUST be non-critical." ...
>>
>>
>> Question 1.
>> If a certificate path verification function of a secure application
>> finds a certificate which includes BOTH Authority Information Access(AIA)
>> extension and CRL DP extension,
>> which extension will the function use ?
>>
>> Question 2.
>> I assume the following situations "case1, case2, case3".
>> I think that case1 and case2 are OK.
>> But, how about case3 ?
>> In example2, I think that AIA and CRL DPs are not available ...
>> I think that "priority" descriptions are needed in somewhere ... ???
>>
>> *****************************************
>> case 1:
>> In this case, the application policy is
>> "at first, a certificate is checked by OCSP server-1.
>> If OCSP server-1 is not available, then it will be checked by
>> OCSP server-2."
>>
>> 1st.       OCSP server-1
>> 2nd.      OCSP server-2
>>
>> -> use AIA extension only.
>>
>> case 2:
>> In this case, the application policy is
>> "at first, a certificate is checked by CRL DP-1.
>> If CRL DP-1 is not available, then it will be checked by
>> CRL DP-2."
>>
>> 1st.       CRL DP-1
>> 2nd.      CRL DP-2
>>
>> -> use CRL DPs extension only
>>
>> case 3:
>>  In this case, the application policy is
>> "a certificate is checked by OCSP servers and CRL DPs.
>>
>> example1
>>
>> 1st.       OCSP server-1
>> 2nd.      OCSP server-2
>> 3rd.      CRL DP-1
>> 4th.      CRL DP-2
>>
>> example2
>>
>> 1st.        OCSP server-1
>> 2nd.       CRL DP-1
>> 3rd.       OCSP server-2
>> 4th.       CRL DP-2
>>
>> etc ...
>>
>> *****************************************
>>
>> =========================================
>> Hiroyuki Sakakibara
>> Research Engineer
>> Information Security Department
>> Mitsubishi Electric Corporation
>> Information Technology R&D Center
>> 5-1-1 Ofuna, Kamakura, Kanagawa, 247-8501, Japan
>> PHONE: +81-467-41-2183
>> FAX: +81-467-41-2185
>> ==========================================
>>
>
>