1 / 15

1609.2 D10

1609.2 D10. William Whyte November 30, 2011. Approach. Clause 5: Process Flows and definitions of validity Valid keypair Valid signed communications Clause 6: Message Definitions Clause 7: Primitives Request/confirm pairs Request describes processing, confirm returns the values

marius
Download Presentation

1609.2 D10

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 1609.2 D10 William Whyte November 30, 2011

  2. Approach • Clause 5: Process Flows and definitions of validity • Valid keypair • Valid signed communications • Clause 6: Message Definitions • Clause 7: Primitives • Request/confirm pairs • Request describes processing, confirm returns the values • “The following processing ensures correct output from the corresponding confirm primitive” – i.e. the processing is not normative itself, but if followed produces normatively correct output

  3. Major Changes from D9 • Finished removing SDS • Cryptomaterial handle • Functions • Rewrote all cert request & mgmt processing • Updated PICS proforma • Updated Annex F

  4. SDS • Previously: • Message / WME SDS held private key and cert • Global SDS held CRLs, trust anchors • CME SDS held private keys while cert request was in process • Specification and mechanisms for updating info were incomplete and SDS did not correspond to concepts in other standards • Replaced by: • Cryptomaterial Handles for Message / WME SDS • CME for Global SDS • Combination of Cryptomaterial Handles and CME for CME SDS • Advantage: fully specified interface • CME in 5.7, CMH in 5.6

  5. Cryptomaterial handle (5.6) • Stores a single private key and the corresponding cert or public key • Mechanism to allow the document to: • Pass key to processing without key in the clear • Enforce that key and certificate are a valid pair • Not an interop issue – enforces the shalls from the process flows in clause 5 but has no testable shalls itself • Please review and ensure presentation is appropriate

  6. Functions • Many primitives need to construct cert chain, validate cert chain, decrypt message • Defined “functions” within clause 7.8 so that primitives can invoke them • Not normative but can be used to produce normatively correct results • As with primitives, “The following processing ensures correct output ” • Is this approach acceptable?

  7. Cert Request & Mgmt Processing • D8 (the balloted draft) had a lot of process flow within primitives for cert mgmt • Waiting for response from CA • Applying for both CSR cert and communications cert as a result of a single primitive invocation • D10 moves that process out of the primitive to clause 5.6. • Figure 31 • Also uses the functions to ensure that cert chains are constructed and validated in a way consistent with other processing.

  8. PICS proforma • Fully updated to ensure all shalls have a corresponding entry and all entries in the proforma have a traceable requirement. • Some non-testable shalls in 5.6.3.2 • There are a lot of entries in the PICSproforma • There are a lot of sets of options in .2 • Want to allow implementers to produce an implementation that supports a single one of each option and still be conformant • Extreme granularity of PICS allows implementer to specify exactly what they do • Is this the right approach or is something more high-level appropriate? • WSA options – do we need to support all types of geographic region?

  9. Security profiles • Updates to security profiles to cover new options to primitives • SAE please review!

  10. Annex F • Please review – are there other questions that should be answered?

  11. Open Questions • Where do normative crypto statements go? • Use of internal calls within diagrams • Time and location • Replay protection bug

  12. Normative crypto statements • “This is how you do ECDSA” etc • Currently mainly in clause 6, message definitions • Pro: • crypto processing depends on the encoding • given this, it’s hard to introduce crypto processing in clause 5 before encoding is defined • Cons: • would prefer to keep processing and message definitions separate • processing might be missed in message definitions section • Keep in clause 6 / move to clause 5 or 7 / move to a new clause between 6 and 7?

  13. Use of internal calls within diagrams • Example: when signing data, need to check that the cert hasn’t been revoked • In clause 7 processing we use CME-CertificateInfo to do this • Process flow diagram in clause 5 shows CME-CI; text mentions CME-CI • Probably better to express this in clause 5 as requirements on the output rather than by showing internal processing

  14. Time and location • Currently just get time and location within primitives • Should probably pass them as parameters to primitives • Note assumption that these are securely obtained

  15. Replay protection bug • Signed message may have internal payload, external payload, or both. • The byte that says whether payload is internal or external is not signed • Allows a one-shot replay attack: attacker can see message as signed, then replay as signed external payload • See F.5.5 • We should fix this, probably by including type byte in the data that’s verified.

More Related