Title / Comments on IEEE Std P1609.2 - 2006
Date Submitted / 2009-03-22
Source(s) / Angelene Wang, Chih-Hsun (Anthony) Chou
Emerging Smart Technology Institute, Institute for Information Industry
5F., No. 133, Sec. 4, Minsheng E. Rd., Taipei City, Taiwan / Voice: 886-2-27136682
E-mail: ,
Purpose / Contribution for further development of the 1609.2 standard document
New Comments
Ø Comment 1:
l If the security structure looks like the one below, we have a few questions open for discussion.
n Question 1: how WSA security entity communicates with CA management running on application layer ?
Ø Our reasoning:
The CA for WSA security and the CA for IP and WSM security are two different management entities. In other words, there is no communication between WSA security entity and application layer.
n Question 2: If WSM and IP message security is done at the application layer, should they be included in 1609.2 ?
Ø Our reasoning:
Application layer is usually not constrained in standards. If security for WSM and IP messages are put into 1609.2 standard, we doubt if this will be accepted by the public unless we make it look like a security layer, similar to SSL.
n Question 3: ” If CA management is done at the application layer, why we need fragmentation mechanism tailored for 1609.2 ?
- In section 8.5.1 on page 57, it says
“In order to maintain the system, some system data (such as CRLs or updated root certificates) needs to be made available to implementations that receive signed messages. This data may be too large to fit in a single transmission. This clause provides a framework for fragmenting and reassembling large messages….” < --- implies fragmentation is for CA communication use
- but on page 55, it says
“ Applications may make over-the-air requests for certificates using the WAVECertificateRequest
message described in 5.17. The certificate request message shall be transferred by UDP …“ ß implies CA communication is done using UDP
Ø Our reasoning:
No fragmentation needed for 1609.2. First, no communication need between WSA CA and Application layer. Then, CA management running on application layer uses UDP for communication, where fragmentation has been already taken care of by IP.
Ø Comment 2: There are many types represented by enum defined in 1609.2, and we suggest scenarios of when each type is applied should be given. For example, in 6., when to set type to certificate, when to set type to certificate_digest … etc.
1. enum {fully_specified (0), match_any_acm(1), from_issuer(2),
(2^8-1)} AIDType;
2. enum { id_only(0), id_and_expiry(1), (2^8-1) } CRLType;
3. enum { app_data(0), signed(1), (2^8-1)} EncryptedContentType;
4. enum { from_issuer(0), circle(1), rectangle(2), polygon(3),
none (4), (2^8-1)} RegionType;
5. enum { specified_in_request(0), specified_by_ca(1), (2^8-1) }
RequestScopeType;
6. enum { certificate(0), certificate_digest(1),
certificate_chain (2), self
7. enum { wsa_ca (0), ca(1), wsa_signer(2), rsu(3), psobu(4),
obu_identified(5), crl_signer(6), csr_signer(8),
root_ca(9), (2^8-1)
} SubjectType;
Old Comments, which have been reviewed
Ø Comment 3:
(Encode, Decode ) and (Encrypt, Decrypt) are two set of concepts
- Encode is not contrast to encrypt, and vice versa.
- Decode is not contrast to decrypt and vice versa.
On page 5,
Original:
3.1.27 decode: To parse an array of octets into a set of its constituent fields. Contrast: decrypt, encode.
3.1.28 decrypt: To convert unreadable, encrypted data to readable, decrypted data using an decryption
algorithm and a key. Contrast: decode, encrypt.
Modified to:
3.1.27 decode: To parse an array of octets into a set of its constituent fields. Contrast: encode.
3.1.28 decrypt: To convert unreadable, encrypted data to readable, decrypted data using an decryption
algorithm and a key. Contrast: encrypt.
On page 6,
Original:
3.1.36 encode: To convert a data structure into an array of octets. Contrast: decode, encrypt.
3.1.37 encrypt: To convert readable data to unreadable, encrypted data using an encryption algorithm
and a key. Contrast: decrypt, encode.
Modified to:
3.1.36 encode: To convert a data structure into an array of octets. Contrast: decode
3.1.37 encrypt: To convert readable data to unreadable, encrypted data using an encryption algorithm
and a key. Contrast: decrypt
Ø Comment 4:
On page 18,
u Original:
struct {
FullySpecifiedAppID application;
MessageFlags mf;
opaque application_data<2^16-1>;
if_flag_set (mf, use_generation_time) {
Time64 generation_time;
}
if_flag_set (mf, expires) {
Time64 expiry_time;
}
if_flag_set (mf, use_location) {
3DLocationAndConfidence transmission_location;
}
} ToBeSignedMessage;
u Modified to:
struct {
ApplicationID application;
MessageFlags mf;
opaque application_data<2^16-1>;
if_flag_set (mf, use_generation_time) {
Time64 generation_time;
}
if_flag_set (mf, expires) {
Time64 expiry_time;
}
if_flag_set (mf, use_location) {
3DLocationAndConfidence transmission_location;
}
} ToBeSignedMessage;
If the comment above is accepted, two other places need to be modified:
1. Figure C.4 on page 86 should be modified by adding one more ‘type’ field contained in application field.
2. In the ToBeSignedMessage Struct on page 81, ‘FullySpecifiedAppID application’ also needs to be modified to ‘ApplicationID application’;
u Reasons:
There is no type element in FullySpecifiedAppID struct on page21. Therefore, we assume application is declared as ApplicationID type to match those descriptions containing the term ‘application.type’on page 18, and step 4 in section 7.3.2 on page 38, (set the application.type to fully_specified).
If ToBeSignedMessage must be of type fully_Specified and therefore variable application is always declared as FullySpecifiedAppID type, then application.type on page 18 and page 38 needs to be taken away by rewriting those sentences containing application.type with different logic.
Ø Comment 5:
Terminology in 1609.2 needs to be consistent with PSID and PSC in 1609.3.
(1) Page 4- Section 3.1 – Definitions
l 3.1.4
Original:
application context mark (ACM)
Modified to:
Provider Service Context (PSC)
l 3.1.5
Original:
application class identifier (ACID)
Modified to:
Provider Service Identifier (PSID)
l 3.1.6
Original:
ApplicationID: A structure that contains an ACID and ACM
Modified to:
ApplicationID: A structure that contains an PSID and PSC
l 3.1.87
Original:
WAVE short message (WSM): A message sent over WSMP .... using an ACID and an ACM rather than an IP address and port.
Modified to:
WAVE short message (WSM): A message sent over WSMP .... using an PSID and an PSC rather than an IP address and port.
(2) On page 9 – section 3.2 – Abbreviation and acronyms
l In Abbreviations and acronyms section on page 9,
replace ACID and ACM with PSID and PSC.
(3) Replace every occurrenc of acm and acid with psc and psid respectively through the whole document
l Replace every occurrence of acm with psc in message structuresand descriptions:
acm à psc
match_any_acm à match_any_psc
on p21, p22, p32, p38, p39, p42, p46, p47, p49, p50, p51, p52, p53,
p54, p55, p56, p58, p66, p72, p76, p78, p83, p86, p87
l Replace every occurrence of acid with psid in message structuresand descriptions:
On p21, p22, p32, p38, p39, p42, p46, p47, p49, p51, p52, p53, p54, p55, p56, p58, p76, p78, p83, p86, p95, p96.
Ø Comment 6:
On page 42,
Original:
b) If the applications field of B is a single Application ID .....
Modified to:
b) If the applications field of B, appB, is a single Application ID ...
Reasons:
the term ‘appB’ is not defined before its first appearance.
Ø Comment 7:
On page 43,
In Section 7.4.2.1 , two terms appear without any definition given in the previous content.
l In step (c) supported_symm_algss is not defined before its first appearance.
l In step (g) FurtherSecurityProcessing is not defined before its first appearance.
Ø Comment 8:
We are thinking about proposing a figure to indicate the access points of security services mentioned in 1609.2.
After investigation, we found there are three different control flows for secured WSA, secured WSMs and secured IP messages respectively.
l WSA
WSA flow is presented in figure 6 on page 14 of 1609.3 D1.1. See the figure below.
l WSM
According to the feedback from John Moring, John pointed out the signing and encryption process of WSM is done at application layer. Therefore, WSMP is unaware of the existence of security services. In other words, a WSM is signed and encrypted first and then send through WSMP.
l IP messages
IP messages are signed and encrypted first before sending through UDP. (VDTLS is put in this category)
In the logic above, we propose the following figure.
0