Title:                               SV8 - ASN.1 Padding Issues

PDR Reference:                       M2090003

Originator Reference:                SB3W0615 SE-2, 3, 5

SARPs Document Reference:            Sub-Volume VIII various

CAMAL Document Reference:            Draft Part V Chapter 4, various

P/OICS Document Reference            -

Status:                              ACCEPTED

Impact:                              C

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 the past, there have been interoperability problems with edition 1 or 2 SARPs due to the presence or absence of padding bits in embedded PER-encoded BIT STRINGs (see PDR M1060001 and related discussion thread).  It is important to be precise about when BIT STRING values are padded to octet boundaries, and whether the padding occurs at the beginning or end of the BIT STRING.  Some potential problems are:

a)           SignData passed to the ASP primitive (8.5.5.2.1) is expected
to be an
OCTET STRING.  In SSO-ASP it is the PER encoding of SignData ? a bit string.

b)           User Data within the SignData type is type OCTET STRING.
Actually, it is
the PER encoding of an application APDU, for example CMAircraftMessage, or a SEQUENCE OF EXTERNAL from ACSE User-Information.  More precision is needed to ensure a canonical encoding is achieved.

c)           In SSO-AVP (8.6.3.12), User Data is expected to be an OCTET
STRING.
However, the field was mapped from the received ACSE User Information, which is defined as SEQUENCE OF EXTERNAL, and within the EXTERNAL the bitstring representation is recommended in SV4.

d)           Public keys in the CM Response data are defined as type
ECPoint, which
in SV8 is defined as OCTET STRING.  Public keys in CompressedUserCertificate (and also in X.509) are BIT STRING.  Where does the type conversion occur? Is there a padding issue?

e)           In SSO-SessionKey (8.6.3.5.3.e), the
Secured-Association-Signature (type
ATNAppendix) and Random Challenge (32 bit unsigned INTEGER) are concatenated together for input to AHASH.  How, and in what order?  Are the ASN.1 types combined, or the PER-encoded bitstrings concatenated, with or without octet alignment?

Clarification is needed for these, and possibly other, examples.

Assigned SME:                              Sub-Volume VIII SME

Proposed SARPs amendment:



Impact on interoperability:

If different implementers make different assumptions about octet alignment and embedded padding bits, then interoperability will fail.

PDR Validation Status:

SME Recommendation to CCB:

CCB Decision: