Ietf-types

Download

ietf-types@alvestrand.no

March 2002

2 participants
2 discussions

RE: WAP Mime types
by Pieter Kasselman 04 Mar '02

04 Mar '02

Hi, apologies for any inconvenience caused. I include the three mime type definitions as text in the main body of the mail. Pieter -------------------------application/vnd.wap.cert-response------------------ ---------- From: pkasselman(a)baltimore.com To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.wap.cert-response MIME media type name: application MIME subtype name: vnd.wap.cert-response Required parameters: None Optional parameters: None Encoding considerations: The encoding follows the WTLS encoding rules as specified in [WTLS]. The content takes the form of a CertResponse structure. This structure is defined in [WPKI]. Security considerations: This MIME type is used to install new client certificates on a WAP client device. The structure allows for a X509 certificate, certificate URL or a referral URL to be returned. Interpreting the MIME type requires the certificate storage medium to be accessed and modified. If this medium is accessed or updated incorrectly existing certificate information may be corrupted. If an incorrect certificate URL is returned, this may be used as part of a denial of service attack on a server at a later stage. Likewise the referral URL may be used to launch a co-ordinated denial of service attack on a server. Interoperability considerations: The WAP Forum Ltd. Interoperability Working Group (WIG) assesses interoperability for all WAP Forum Ltd. specifications. See [WAP]. Published specification: This media type is specified in the WPKI specification that can be found at http://www.wapforum.org/what/technical.htm The encoding rules and signature generation are defined in the WTLS specification that can be found at http://www.wapforum.org/what/technical.htm Applications which use this media type: Any application that conforms with the [WPKI] specification. Additional information: Magic number(s): None File extension(s): None Macintosh File Type Code(s): None Person & email address to contact for further information: Pieter Kasselman Baltimore Technologies pkasselman(a)baltimore.com Intended usage: COMMON Author/Change controller: The WAP Forum Ltd. References [WPKI] Wireless Public Key Infrastructure Definition - WAP- 217-WPKI [WTLS] Wireless Transport Layer Security Specification - WAP- 261-WTLS -------------------------application/vnd.wap.hashed-certificate------------- --------------- From: sjosefsson(a)rsasecurity.com To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.wap.hashed-certificate MIME media type name: application MIME subtype name: vnd.wap.hashed-certificate Required parameters: None Optional parameters: None Encoding considerations: The encoding follows the WTLS encoding rules as specified in [WTLS]. The content takes the form of a TBHTrustedCAInfo structure. This structure is defined in [WPKI], reproduced below for informational purposes. The structure is binary data, and must be encoded for non-binary transport; in 7-bit environments the Base64 encoding is suitable. struct { CharacterSet character_set; opaque displayName <1..2^8-1>; } CertDisplayName; enum { sha1 (0), 255 } HashAlgorithm ; struct { uint8 version; CertDisplayName displayName; Certificate trustedCACert; opaque cainfo_url <0..2^8-1>; HashAlgorithm hash_alg; } TBHTrustedCAInfo; Users must enter exactly 80 "effective" bits of hash, which extracted from the display form and are the leftmost 80 bits of the SHA-1 hash of the CA information. Let "hash" be the SHA-1 hash of the encoding of (the encoding of) a TBHTrustedCAInfo structure. This consists of 160 bits (h0,..h159), in network byte order, h0 being the leftmost bit). The display form of the hash consists of 30 decimal digits, constructed of 5 blocks of 6 digits. The leftmost 5 digits of each block represent 16 bits of the effective hash, (i.e. can take the value '00000' to '65535' decimal), the sixth digit of each block is a check digit for the block. Block zero consists of h0 to h15 (with h0 being the most significant bit), followed by the associated check digit; block one consists of h16 to h31; followed by the associated check digit etc. That is if h0 is '1'B and h1 to h15 are all '0'B, then the sixteen bits have the value '8000'H or '32678' decimal, and the check digit is '5' decimal (see below for the check digit calculation method). The check digit is calculated using the same mechanism as used for credit card numbers, that is, the LUHN formula (mod 10) as described below. The following steps are required to validate a 6 digit group: Step 1: Double the value of alternate digits of the number beginning with the second digit from the right (the first right--hand digit is the check digit.) Step 2: Add the individual digits comprising the products obtained in Step 1 to each of the unaffected digits in the original number. Step 3: The total obtained in Step 2 must be a number ending in zero (30, 40, 50, etc.) for the number to be validated. Example 1: to validate the group 398719, corresponding to '9BBF'H as the sixteen bits of hash: Step 1: 3 9 8 7 1 9 x2 x2 x2 ------------ 6 16 2 Step 2: (6) + 9 +(1+6) + 7 + (2) + 9 Step 3: Sum is 40 = 0 (mod 10): group is validated Example 2: to validate the group 326785, corresponding to '8000'H as the sixteen bits of hash: Step 1: 3 2 6 7 8 5 x2 x2 x2 ------------ 6 12 16 Step 2: (6) + 2 +(1+2) + 7 + (1+6) + 5 Step 3: Sum is 30 = 0 (mod 10): group is validated Security considerations: This MIME type is used to install new CA certificates on a WAP client device. The TBHTrustedCAInfo structure contains the new CA certificate, without protection. Due to the sensitive nature of CA certificates the client uses a checksum value entered by the user, received "out of band" of the CA certificate delivery response (e.g. via paper mail), to guarantee the integrity of the CA certificate. The client must calculate the checksum of the received TBHTrustedCAInfo structure and verify it against the manually entered checksum value. Interoperability considerations: The WAP Forum Ltd. Interoperability Working Group (WIG) assesses interoperability for all WAP Forum Ltd. specifications. See [WAP]. Published specification: This media type is specified in the WPKI specification that can be found at http://www.wapforum.org/what/technical.htm The encoding rules and signature generation are defined in the WTLS specification that can be found at http://www.wapforum.org/what/technical.htm Applications which use this media type: Any application that conforms with the [WPKI] specification. Additional information: Magic number(s): None File extension(s): None Macintosh File Type Code(s): None Person & email address to contact for further information: Simon Josefsson RSA Security sjosefsson(a)rsasecurity.com Intended usage: COMMON Author/Change controller: The WAP Forum Ltd. References: [WPKI] Wireless Public Key Infrastructure Definition - WAP-217-WPKI [WTLS] Wireless Transport Layer Security Specification - WAP-261-WTLS [WAP] WAP Forum Certification Program and Policy - http://www.wapforum.org/cert/go-cert.html -------------------------vnd.wap.signed-certificate------------------------- --- From: pkasselman(a)baltimore.com To: ietf-types(a)iana.org Subject: Registration of MIME media type application/vnd.wap.signed-certificate MIME media type name: application MIME subtype name: vnd.wap.signed-certificate Required parameters: None Optional parameters: None Encoding considerations: The encoding follows the WTLS encoding rules as specified in [WTLS]. The content takes the form of a SignedTrustedCAInfo structure. This structure is defined in [WPKI]. Security considerations: This MIME type is used to install new CA certificates on a WAP client device. The SignedTrustedCAInfo structure contains both the new CA certificate and the certificate of the signer that introduces the new CA certificate. The structure is signed as specified in [WPKI] and [WTLS]. Due to the sensitive nature of CA certificates the client device must be able to trust the signer of this structure before the contained certificate is used. The client must verify the signature contained in the SignedTrustedCAInfo structure, verify the certificate of the signer as well as the signature on the new self-signed CA certificate. If the signer CA is independent of the newly introduced CA there may be implications for the certification policies of the two CAs. Interoperability considerations: The WAP Forum Ltd. Interoperability Working Group (WIG) assesses interoperability for all WAP Forum Ltd. specifications. See [WAP]. Published specification: This media type is specified in the WPKI specification that can be found at http://www.wapforum.org/what/technical.htm The encoding rules and signature generation are defined in the WTLS specification that can be found at http://www.wapforum.org/what/technical.htm Applications which use this media type: Additional information: Magic number(s): None File extension(s): None Macintosh File Type Code(s): None Person & email address to contact for further information: Pieter Kasselman Baltimore Technologies pkasselman(a)baltimore.com Intended usage: COMMON Author/Change controller: The WAP Forum Ltd. References: [WPKI] Wireless Public Key Infrastructure Definition - WAP- 217-WPKI [WTLS] Wireless Transport Layer Security Specification - WAP- 261-WTLS > -----Original Message----- > From: Keith Moore [SMTP:moore@cs.utk.edu] > Sent: 04 March 2002 14:43 > To: Pieter Kasselman > Cc: 'ietf-types(a)iana.org' > Subject: Re: WAP Mime types > > I can't read the proposed type registrations because they are mislabeled > as application/octet-stream. Perhaps you could repost them with proper > labelling? > > Keith ----------------------------------------------------------------------------- Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. http://www.baltimore.com

1 0

WAP Mime types
by Pieter Kasselman 04 Mar '02

04 Mar '02

Hi, the WAP Forum Security Group would like to submit the following MIME-types for registration in the vendor tree. In accordance with recommendations in RFC 2048 the mime types are submitted for a two week community review before submission to IANA. The mime types are: vnd.wap.hashed-certificate - Used for installing a new CA certificate on a mobile device. vnd.wap.signed-certificate - An alternative for installing a new CA certificate on a mobile device. vnd.wap.cert-response - Installing user certificates on a mobile device. <<vnd.wap.hashed-certificate>> <<vnd.wap.signed-certificate>> <<vnd.wap.cert-response>> Pieter ----------------------------------------------------------------------------- Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. http://www.baltimore.com

2 1