Adaptation of revocation mechanisms

CRLs and OCSP are the standard mechanisms to provide revocation information as described in Chapter 3. Thus, it must be possible to provide a revocation index within these data structures to enable fine grained revocation checking as described in Section 6.1.2.

In general, a revocation of a certificate is published as a CRL entry within a CRL or within an OCSP response. For the purpose to provide auxiliary data associated to a CRL entry or an OCSP response, CRL entry extensions have been defined [83]. These can be included in the crlEntryExtensions field as part of an CRL entry (cf. Listing 6.2) as well as into OCSP responses within the singleExtensions field as shown in Listing 6.3 [104]. C e r t i f i c a t e L i s t : : = SEQUENCE { t b s C e r t L i s t TBSCertList , s i g n a t u r e A l g o r i t h m A l g o r i t h m I d e n t i f i e r , s i g n a t u r e V a l u e BIT STRING } TBSCertList : : = SEQUENCE { v e r s i o n V e r s i o n OPTIONAL, −− i f p r e s e n t , MUST be v2 s i g n a t u r e A l g o r i t h m I d e n t i f i e r , i s s u e r Name , t h i s U p d a t e Time ,

nextUpdate Time OPTIONAL,

r e v o k e d C e r t i f i c a t e s SEQUENCE OF SEQUENCE { u s e r C e r t i f i c a t e C e r t i f i c a t e S e r i a l N u m b e r , r e v o c a t i o n D a t e Time , c r l E n t r y E x t e n s i o n s E x t e n s i o n s OPTIONAL −− i f p r e s e n t , v e r s i o n MUST be v2 } OPTIONAL, c r l E x t e n s i o n s [ 0 ] EXPLICIT E x t e n s i o n s OPTIONAL −− i f p r e s e n t , v e r s i o n MUST be v2 } Listing 6.2: CRL [83]

S i n g l e R e s p o n s e : : = SEQUENCE {

c e r t I D CertID ,

c e r t S t a t u s C e r t S t a t u s , t h i s U p d a t e G e n e r a l i z e d T i m e ,

nextUpdate [ 0 ] EXPLICIT G e n e r a l i z e d T i m e OPTIONAL, s i n g l e E x t e n s i o n s [ 1 ] EXPLICIT E x t e n s i o n s OPTIONAL }

Listing 6.3: OCSP single response [104]

The definition of an according extension for the revocation index enables its X.509 standard conform transmission. Listing 6.4 shows an X.509 extension and the pro- posed definition of the revocationIndex extension. An extension is associated with an OID to identify it. Optimally, the OID should be a member of the id-ce arc (2.5.29) for ISO/ITU-T jointly assigned OIDs for certificate extensions. The number represented by the placeholder ‘XXX’ needs to be requested during the standard- ization procedure.

E x t e n s i o n s : : = SEQUENCE SIZE ( 1 . .MAX) OF E x t e n s i o n

E x t e n s i o n : : = SEQUENCE {

extnID OBJECT IDENTIFIER , c r i t i c a l BOOLEAN DEFAULT FALSE , e x t n V a l u e OCTET STRING

−− c o n t a i n s t h e DER e n c o d i n g o f an ASN. 1 v a l u e −− c o r r e s p o n d i n g t o t h e e x t e n s i o n t y p e i d e n t i f i e d −− by extnID

}

i d −ce−r e v o c a t i o n I n d e x OBJECT IDENTIFIER : : = { i d −c e XXX }

R e v o c a t i o n I n d e x : : = INTEGER ( 0 . .MAX)

Listing 6.4: Revocation index extension

The revocationIndex extension is to be a non-critical extension in order to guar- antee backward compatibility. A client not supporting the extension would then ignore it and consider the complete certificate as revoked.

The revocation index needs to be identified, when a certificate is to be revoked. Considering a revocation because of a CA compromise, the identification of the revocation index depends on the type of FSS. Either, the index depends directly on the date of the compromise, or on the index of the last signature which was legitimately generated with the compromised key. Therefore, the certificate owner has to keep track of his key updates. In case of a CA, this can be done by logging the last used index with the current date to a write once memory during key update. Then, given the date of the key compromise, it is possible to determine the last index used before the compromise.