3GPP TSG-T2 #6 / ETSI SMG4
Kyongju, KOREA, 4-6 October 1999	TSGT2#6(99)803	

Agenda Item:	

Source:	Vodafone

Title:	One CDF or three?

Document for:	Discussion

___________________________________________________________________________

Emal from Tim Wright, Vodafone:

I have been thinking about whether we want 3 CDF's for op, admin and third
party (TP) certs on the SIM or one.

Constraints:

A. Space on the SIM
B. Ease and speed of access to the certs from the terminal.
C. Security of SIM data

Comments

1. There is an overhead (10-20 bytes?) per EF for just being an EF.  Having
one CDF saves one overhead (if you have both op and TP certs, and the op
cert can also be used as Admin, you save 2 overheads if separate certs are
used for op and admin).

2. But a field is then required in each cert description in the CDF to say
whether the cert is op, admin or TP.  This field could just be one
additional (not defined in PKCS15 yet) byte, or could use part of the label
as Magnus suggested.  The space required for the fields would only be
greater than two times the overhead if there were 20 plus certs on the SIM
and I don't think that is likely.

3. Having 3 CDF's requires 3 entries in the ODF in the WIM if there is one.
So another 16 bytes (8 bytes per ODF record, see PKCS15, Annex C.2.2) if we
go for 3 CDF's

4. With 1 CDF, the field must be able to indicate that a cert could be both
admin and op.  This probably means a new field and not re-use of the label.

5. If there are 3 CDF then finding cert descriptions is easier.  You know
you want a TP cert so you just go to the TP CDF and don't have to
potentially search through operator/admin cert descriptions as well as those
for TP.  However, if there are not many certs on the SIM, which is likely to
be the case, this won't be very significant.

6. In a way, one CDF with a proper, extensible way of saying what sort of
cert is being pointed to is more flexible than 3(+) CDF's.  If we define a
new domain or type of cert, we just define a new type in the "domain/role"
field in the CDF, we don't have to define a new EF.

7. The argument that we might need to have different fields for different
sorts of cert description so need separate CDF's is not valid.  If ASN.1
encoding is used then each cert description can be different.  Any rules
(e.g. if the mandatory fields are different for each type of cert) can still
be made and enforced.

8. However, if we want to be able to make certificate descriptions for TP
cert contain a validity (in terms of the CCM), then the EF has to be
modifiable by the ME.  If we have one CDF, it is all modifiable.  This is
very significant.  In spite of the fact that there is not a security risk as
such with an ME manipulating a certificate description, there is a service
availability issue.  If a cert description could be manipulated by one ME,
and the cert rendered unusable, this would mean the SIM cert could not be
used in any ME.  The manipulation could be carried out using a card reader
and CHV1 (the phone PIN), an ME is not required.  I know there is a
"modifiable" indicator in the "flags" attribute for a certificate
description but this is not enforced by the SIM but by the ME, and the ME
might be rogue.

Conclusion

The cert manipulation issue is significant and outweighs the c.40 byte
saving 1 CDF gives.  Therefore if a CCM validity field is added, there must
be separate CDF's so only the TP CDF can be manipulated.  We might want to
rule that the CCM validity field should be on the terminal so the TP cert
descriptions are protected too.  If the CCM validity field is on the
terminal, then it seems better to me to have one CDF on the SIM than 3.

Tim