Title:                               SV8, SV4 - SSO-GetCertificatePath Target

PDR Reference:                       M2090002

Originator Reference:                SB3W0615 SE-1

SARPs Document Reference:            Sub-Volume VIII 8.6.3.7
                                     Sub-Volume IV 4.8.5.2.2.3.1

CAMAL Document Reference:            Draft Part V Chapter 4, 4.7.6.7

P/OICS Document Reference            -

Status:                              ACCEPTED

Impact:                              B

PDR Revision Date:                   23 Sep 2002 (Accepted)
				     16 Sep 2002 (SUBMITTED)
                                     04 Sep 2002 (Draft for SGB3 discussion)

Submitting State/Organization:             CIVAL Consulting Ltd

Submitting Author Name:                    A J Kerr

Submitting Author E-mail Address:          tony.kerr@cival.co.uk

Submitting Author Supplemental Contact Information: Tel: +44 (0)1252 724386

SARPs Date:                                Doc 9705 Ed 3 (Jul 02)

P/OICS Date:                                                 -

SARPs Language:                            English

Summary of Defect:

In CM Logon Response processing, the Security ASO (as a component of the ground CM application entity) invokes SSO-GetCertificatePath in 4.8.5.2.2.3.1 to get the compressed certificate path containing its own public key agreement key.  A certificate path from the aircraft's State CA to ground entity's key agreement public key is required.  This is so that the airborne side can verify the certificate path without needing to know the public signing key of every ground entity's CA.

With SSO-GetCertificatePath as currently specified, the certificate path would be signed by the ground entity's CA.

Assigned SME:                              Sub-Volume VIII SME

Proposed SARPs amendment:

It seems that an additional SSO-GetCertificatePath input parameter is needed, such as:

Target Entity Identification     C

This parameter identifies the entity that will receive and verify the compressed certificate path.  It is an abstract value of an AP-Title or PSAP.  If the parameter is specified, the certificate path will be retrieved from and signed by the target entity's CA. If not specified, the certificate path will by default be signed by the CA of the entity that invoked SSO-GetCertificatePath.

The SSO-GetCertificatePath processing description will then have to include functionality to determine the correct CA corresponding to the target and to retrieve the required uncompressed certificate path signed by that CA.

The Security ASO invocation of SSO-GetCertificatePath in SV4 will need to be updated to align with the SV8 SSO definition.

In 4.8.5.2.2.1.1 Bullet b, add new row to end of Table 4.8-4:
Target Entity Identification		Called EntityID

In 4.8.5.2.2.1.1 Bullet c, add new row to end of Table 4.8-5:
Target Entity Identification		Called EntityID

In 4.8.5.2.2.3.1 Bullet b, add new row to end of Table 4.8-11:
Target Entity Identification		Calling EntityID


Initial SME Comment:
I'd say that SSO-GetCertificatePath is ambiguous on who the end CA would be. It makes no mention at all.

I agree with adding another parameter.  Will we require a second PDR for SV4 then, or would you just fold the SV4 change into this one?

I think this PDR will add something like the following processing to replace 8.6.3.7.a (Entity ID = Subject and Target Entity ID = Recipient):

a)  When the Recipient is specified:
             1)  Retrieve the cert path from the SSO's CA (it must know
this) to the
Recipient.
             2)  Extract the Recipient's CA from the cert path.
             3)  Retrieve the cert path from the Recipient's CA to the Subject.
b)  When the Recipient is not specified, retrieve the cert path from the SSO's CA to the Subject.



Impact on interoperability:

Without the proposed amendment, an airborne CM entity will be unable to verify the authenticity of the ground system's public keys, so interoperability will fail.


PDR Validation Status:

SME Recommendation to CCB:

CCB Decision: