1609.2 Status

1. 1609.2 Status William Whyte, Security Innovation October 2010 Troy, MI

2. Overview • Changes to D6 • Extensibility • Schedule

3. Changes to D6 Clause 5 (Messages) • 5.2.4, changed order of certs in certificate change • 5.2.12, renamed 3DLocationAndConfidence to ThreeDLocationAndConfidence • 5.2.16, Signed WSA • Clarified how WSA signatures are generated • permission_indices field is to be included in signed data • Gave example of permission_indices field (in Annex B) • Diagram on next slide • 5.3.16, 2DLocation renamed to TwoDLocation • 5.3.34, changed maximum length of CRL path in CRL to 264 from 232.

4. Permission_indices

5. Changes to D6 Clause 6 (Processing) • 6.4.2.1.2, added “Expiry Time” to arguments to WSS-SignedMessage.request (correcting accidental omission) • 6.4.2.1.4, clarified how signed messages with external data are handled. • 6.4.3.1.5, changed tag length in ECIES encryption from 16 bytes to 20 for compatibility with existing implementations • 6.4.4.2.2, added ability to get certificate type and identifier from cert if present • 6.4.5.1.4.1, removed references to “Perform Cryptographic Verification” (which had already been removed from the interface) and removed references to “successful but unverified” in 6.4.5.2. • 6.5.2.1.4 and 6.5.3.1.4, specified how a WSA is hashed for signature generation or verification

6. Changes to D6 Annexes • A: Relabeled PICS entries from “Nx.x” to “Sx.x” • B: Updated examples • C: Merged all informative sections into this annex, reduced considerably in size, completed • D: Updated bibliography

7. Extensibility • A number of enumerated types in 1609.2 are used to tell a recipient how the rest of the secured message is structured • enum { unsecured (0), signed(1), encrypted (2), certificate_request(3), certificate_response(4), anonymous_certificate_response(5), certificate_request_error(6), crl_request(7), crl(8), signed_partial_payload(9), signed_external_payload(10), signed_wsa(11), reserved (240...255), (2^8-1)} ContentType; • flags {fragment(0), use_generation_time(1), expires(2), use_location(3)} MessageFlags; • enum { ecdsa_nistp224_with_sha224 (0), ecdsa_nistp256_with_sha_256 (1), ecies_nistp256 (2), reserved (240..255), (2^8-1) } PKAlgorithm; • These types are in principle extensible • But if they are extended a recipient will not know how to parse the message • Should it be possible to extend 1609.2 without changing the version number?

8. Example: PublicKey struct { PKAlgorithm algorithm; select(algorithm){ case ecdsa_nistp224_with_sha224: case ecdsa_nistp256_with_sha256: EccPublicKeypublic_key; case ecies_nistp256: SymmAlgorithmsupported_symm_alg; EccPublicKeypublic_key; } } PublicKey; struct { … PublicKeypublic_keys<2^8-1>; } ToBeSignedCertificate; • Possible extension: add new public key types • Motivation: • Jurisdictions may restrict the maximum length of encryption keys • Cryptanalytic breakthroughs against ECDSA / ECIES • Should not break legacy implementations: • because if a recipient isn’t using the encryption key they don’t need to know the algorithm • Other considerations: • Length field in ToBeSignedCertificate restricts the additional algorithms that implementers may try out • It must be possible to fit two public keys into 255 bytes – rules out RSA-1024 • Variable-length encoding for public_keys field is clunky way of saying whether the cert has one or two keys • Mechanism: • Reserve top bit of certificate subject type field to say whether there are one or two public keys • Require that new public keys have their length encoded • Optional: require that some PKAlgorithm values encode length in 1 byte and others in 2?

9. Example: ToBeSignedMessage struct { externContentType type ; MessageFlagsmf; select(type) { case signed : Psidpsid; opaque data<2^32­1>; case signed_partial_payload : Psidpsid; extern opaque ext_data<2^32­1>; opaque data<2^32­1>; case signed_external_payload : Psidpsid; extern opaque ext_data<2^32­1>; case signed_wsa : opaque data<2^32-1>; } if_flag_set (mf, use_generation_time) { Time64WithConfidence generation_time; } if_flag_set (mf, expires) { Time64 expiry_time; } if_flag_set (mf, use_location) { ThreeDLocationAndConfidence generation_location; } } ToBeSignedMessage; • Possible extension: “epidemic” CRL distribution • Should not break legacy implementations: because it is not used by the application, but by the security services • Mechanism: Add a new MessageFlags value and include an extension with the CRL status information

10. Example: Geographic Region • Possible extension: additional region types such as an identifying string • Should not break legacy implementations: ??? • Mechanism: opaque string struct { RegionTyperegion_type; select(region_type){ case from_issuer: ; case circle: CircularRegioncircular_region; case rectangle: RectangularRegionrectangular_region<2^16­1>; case polygon: PolygonalRegionpolygonal_region; case none: ; } }GeographicRegion;

11. Possibilities • Least flexible: require version number rev for changes • Most flexible: For each extensible enumerated type, define within 1609.2 how it may be extended • Identify fields that depend on the type • Require new fields bases on new types to be TLV encoded • Possibly with terminating field or “number of fields” field

12. Schedule • Complete examples • Resolve extensibility questions • Today? • Circulate