Re: [pkix] Delegating certificate revocation

["Erik Andersen" <[e-mail]>]

Hi Wen-Cheng,

 

That makes sense. Thanks for the clarification.

 

Erik

 

Fra: pkix [mailto:[e-mail]] På vegne af ???
Sendt: 08 July 2015 15:37
Til: 'Directory list'; 'PKIX'
Emne: Re: [pkix] Delegating certificate revocation

 

Eric,

 

For the security reason, delegated ACRL issuer should be an entity in the same domain with the AA. Therefore, I think the public-key certificate of the delegated ACRL issuer should be issued by the same CA which issued the public-key certificate of the AA or SOA.

 

Wen-Cheng Wang

 

From: Erik Andersen [mailto:[e-mail]] 
Sent: Wednesday, July 08, 2015 9:15 PM
To: 王文正; 'Directory list'; 'PKIX'
Subject: SV: [pkix] Delegating certificate revocation

 

Hi Wen-Cheng,

 

Thank you very much for your input.

 

What public-key certificate is then used for signing the ACRL?

 

Kind regard,

 

Erik

 

Fra: pkix [mailto:[e-mail]] På vegne af ???
Sendt: 08 July 2015 14:47
Til: Directory list; PKIX
Emne: Re: [pkix] Delegating certificate revocation

 

Eric,

 

I think an AA can do that.

 

Actually, there is a paragraph describes how a CA authorizes a different entity to perform revocation.

 

Only a CA that is authorized to issue CRLs may choose to delegate that authority to another entity. If this delegation is

done, it shall be verifiable at the time of certificate/CRL verification. The cRLDistributionPoints extension can be

used for this purpose. The cRLIssuer field of this extension would be populated with the name(s) of any entities, other

than the certificate issuer itself, that have been authorized to issue CRLs concerning the revocation status of the

certificate in question.

 

The same method can be used by an AA. You can simply replace “CA” with “AA”, “CRL” with “ACRL”, “certificate” with “attribute certificate” and done.

 

Only a AA that is authorized to issue ACRLs may choose to delegate that authority to another entity. If this delegation is

done, it shall be verifiable at the time of attribute certificate/ACRL verification. The cRLDistributionPoints extension can be

used for this purpose. The cRLIssuer field of this extension would be populated with the name(s) of any entities, other

than the attribute certificate issuer itself, that have been authorized to issue ACRLs concerning the revocation status of the

attribute certificate in question.

 

That means the AA can include a cRLDistributionPoints extension in attribute certificates and use the cRLIssuer field of this extension to specify the name of the delegated ACRL issuer.

 

Wen-Cheng Wang

 

From: pkix [mailto:[e-mail]] On Behalf Of Erik Andersen
Sent: Wednesday, July 08, 2015 6:05 PM
To: Directory list; PKIX
Subject: [pkix] Delegating certificate revocation

 

Clause 7.10 of X.509 on Certificate revocation lists states:

 

“the certificate-issuing authority authorizes a different entity to perform revocation.”

 

Can an AA do that, and if yes, how?

 

Regards,

 

Erik 



本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.