[cabfpub] WAS: RE: [cabfman] Update of Yngve's BR 1.1 issues + #10

Steve Roylance steve.roylance at globalsign.com
Thu May 31 00:50:03 MST 2012


Hi Carsten.

My understanding here is that we are talking about 'technical'
implementations in section 13.2.5 rather than business scenarios where a
CA is the Product/Hierarchy and not the Business Entity.

i.e. You can use direct signing using the same "key material" or by key
material of a CA that signed the CA.

Does that help your understanding of this section?

Steve




On 30/05/2012 17:40, "Carsten.Dahlenkamp at t-systems.com"
<Carsten.Dahlenkamp at t-systems.com> wrote:

>Yngve, All,
>
>
>This is not related to your suggested changes in the first place, I was
>wondering about this item before - hopefully someone can help :-)
>
>>  10.  The Subordinate CA ceases operations for any reason and has not
>>made
>>  arrangements for another CA to provide revocation support for the
>>Certificate;
>>
>>  11.  The Subordinate CA¹s right to issue Certificates under these
>>  Requirements expires or is revoked or terminated, unless the
>>Subordinate CA
>>  has made arrangements to continue maintaining the CRL/OCSP Repository;
> 
>
>This item seems to allow, that a CA "A" ceasing their operation may
>"hand-over" their revocation infrastructure (CRLs, OCSP) to another CA
>"B" - so there is no need to revoke all the still valid EE certs issued
>by "B" (let's assume "A" was not compromised and therefore there is no
>need to revoke EE certificates).
>
>
>How would this be compliant to the BR's section 13.2.5 OCSP Signing:
>
><snip> OCSP responses MUST either:
>1. Be signed by the CA that issued the Certificates whose revocation
>status is being checked, or
>2. Be signed by an OCSP Responder whose Certificate is signed by the CA
>that issued the Certificate whose
>revocation status is being checked
>
>
>Maybe I'm totally wrong, but as far as I understand item 1. is not an
>allowed scenario here (unless "A" and "B" are operated by the same
>organization), because it would mean that "A"'s private key is
>handed-over to "B", which is defined as key compromise leading to revoke
>"A"'s CA certificate.
>
>I'm not quite sure how item 2. could work. Is it something like:
>- "A" signs an OSCP responder certificate
>- "B" is running this OCSP responder on behalf of "A"
>
>Ignoring the question whether "A" is allowed to issue an OCSP responder
>certificate to be operated by "B" (private key must be available to "B"),
>I am wondering what SHALL or SHOULD happen with "A"'s CA
>certificate/private key. If "A" ceases operation I would expect that at
>least the private key SHALL be destroyed. But from my understanding the
>OCSP responder certificate would be no longer valid, too.
>I'm aware, that for OCSP responses the chain of trust is not validated,
>but as far as I understand this is more a performance issue.
>
>
>Maybe there's a quite simply answer and my argumentation is not correct.
>I would really appreciate someone pointing me to the mistake I made :-)
>
>
>Thanks
>   Carsten
>
>
>Carsten Dahlenkamp
>T-Systems International GmbH
>Trust Center Applications
>Untere Industriestraße 20, 57250 Netphen, Germany
>+49 271 708-1643 (Tel.)
>E-Mail: carsten.dahlenkamp at t-systems.com
>http://www.t-systems.com, http://www.telesec.de
>
>_______________________________________________
>Public mailing list
>Public at cabforum.org
>http://cabforum.org/mailman/listinfo/public




More information about the Public mailing list