1 / 24

1609.2 status

1609.2 status. William Whyte, Security Innovation 11-1-11 + 1. Summary. Done! Except for Examples Feedback from WG Sponsor ballot pool status? Propose 30-day review period followed by WG comment resolution telecon

dahlia
Télécharger la présentation

1609.2 status

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 status William Whyte, Security Innovation 11-1-11 + 1

  2. Summary • Done! • Except for • Examples • Feedback from WG • Sponsor ballot pool status? • Propose 30-day review period followed by WG comment resolution telecon • Following comment resolution, decide if we need another round of comments. • One outstanding comment already, on compressed points – see end of presentation

  3. MAJOR Changes

  4. Major changes • Extensibility • Start Validity Time in Certificate • CRL staleness handling • Store unverified certificates • Change flags encoding

  5. Extensibility • The contents of several 1609 structures depend on “type” or “flags” fields • These could conceivably have additional values defined in the future • If this were to happen, based on D6, we would have to rev the version number in the message • This causes problems with legacy devices • Solution: define what the message will look like with as yet undefined values of the type variable struct { uint8 protocol_version; ContentType type; select (type) { case unsecured : opaque message<2^32-1>; case signed, signed_partial_payload, signed_external_payload:` SignedMessagesigned_message; case signed_wsa: SignedWsasigned_wsa; case encrypted : EncryptedMessageencrypted_message; case crl_request : CrlRequestcrl_request; case crl : Crlcrl; } 1609Dot2Message;

  6. Extensibility – general approach D6: struct { uint8 protocol_version; ContentType type; select (type) { case unsecured : opaque message<2^32-1>; case signed, signed_partial_payload, signed_external_payload:` SignedMessagesigned_message; case signed_wsa: SignedWsasigned_wsa; case encrypted : EncryptedMessageencrypted_message; case crl_request : CrlRequestcrl_request; case crl : Crlcrl; } 1609Dot2Message; D7: struct { uint8 protocol_version; ContentType type; select (type) { case unsecured : opaque message<2^32-1>; case signed, signed_partial_payload, signed_external_payload:` SignedMessagesigned_message; case signed_wsa: SignedWsasigned_wsa; case encrypted : EncryptedMessageencrypted_message; case crl_request : CrlRequestcrl_request; case crl : Crlcrl; default : opaque message<2^32-1>; } } 1609Dot2Message;

  7. Structures affected • Clause 5.2.1: Handled unknown ContentType in 1609Dot2Message. • Clause 5.2.4: Handled unknown SignerIdentifierType in SignerIdentifier. • Clause 5.2.7, 5.2.13, 5.2.14: added extensions to the ToBeSignedMessage. This is to support including, for example, CRL version advertisement as discussed at the last meeting. • Clause 5.2.15: handled unknown PKAlgorithm value in Signature. • Clause 5.2.19: handled unknown SymmAlgorithm value in EncryptedMessage • Clause 5.2.21: handled unknown PKAlgorithm value in RecipientInfo • Clause 5.2.24: handled unknown ContentType value in ToBeEncrypted (not the only change in this clause, see below). • Clause 5.3.6: handled unknown SubjectType value in CertSpecificData. • Clause 5.3.7: handled unknown SubjectTypeFlags value in RootCaScope. • Clause 5.3.9, 5.3.11, 5.3.23, 5.3.27: handled unknown ArrayType value in PsidArray, PsidPriorityArray, PsidPrioritySspArray • Clause 5.3.13: handled unknown RegionType value in GeographicRegion • Clause 5.3.30: handled unknown PKAlgorithm value in PublicKey • Clause 5.3.35: handled unknown SubjectType value in CertRequestSpecificData • Clause 5.3.41: handled unknown CrlType in ToBeSignedCrl.

  8. ToBeSignedMessage: Extensions • May want to use Signed Message to distribute security management information • Current CRL version • Third party cert • Use extensions to do this • TbsMessageExtension is TLV encoded • No type values currently defined. struct { externContentTypetype ; 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) { ThreeDLocationAndConfidencegeneration_location; } if_flag_set (mf, extensions) { TbsMessageExtension extensions<2^16-1>; } } ToBeSignedMessage;

  9. Anonymous Certificate Scope • Anonymous certificate scope is not yet defined • This placeholder allows v2-compatible anonymous certificates • At the cost of burning a byte • struct { • extern SubjectTypesubject_type; • select(subject_type){ • case root_ca: • RootCaScoperoot_cascope; • case message_ca, message_csr: • MessageCaScopemessage_ca_scope; • case wsa_ca, wsa_csr: • WsaCaScopewsa_ca_scope; • case crl_signer: • CrlSeriesresponsible_series<2^8-1>; • case message_identified_not_localized: • IdentifiedNotLocalizedScopeidnonloc_scope; • case message_identified_localized, • IdentifiedScopeid_scope; • case wsa: • WsaScopewsa_scope; • case message_anonymous: • opaque<2^8-1> anonymous_scope; • default: • opaque<2^16-1> other_scope; • } • } CertSpecificData;

  10. Extensbility concluded • Possible TODO: extend profile to cover what units should do when they receive a message with a field they don’t recognise – accept or reject?

  11. Certificate Start Validity Time struct { SubjectTypesubject_type; CertificateContentFlagscf; … if_set(cf, use_start_validity) { Time32 start_validity; CertificateDuration lifetime; } if_not_set(cf, use_start_validity) { Time32 expiration; } … } ToBeSignedCertificate; • Start validity time in certificates allows pre-issuance of short-lived certs • Useful for anonymity • D7 adds support for start time • To keep size down, encodes start_validity and lifetime • Lifetime = 16 bits: top 3 are units, bottom 13 are value

  12. Certificate Request Acknowledgment • Added messages and process flow to allow a Certificate Management Entity to acknowledge receipt of a certificate response. • This affects the following clauses: • Clause 4.3.2, 4.3.3: diagrams • Clause 5.2.2: Added certificate_-response_acknowledgmentContentType value. • Clause 5.2.24: Added support for certificate response acknowledgment in ToBeEncrypted (not the only change in this clause, see above). • Clause 5.3.39, added ToBeEncryptedCertificateResponseAcknowledgment • Clause 9.2, added option of generating an acknowledgement • The ACK is the hash of the decrypted Certificate Response, so is information that is known only to the valid receiver and the CA • Added as a result of ETSI work

  13. Crl Staleness • Certificate compromise process: compromise  detection  revocation  distribution • CRL is “distribution” phase – contains all revoked certs • But not all compromised certs • A CRL contains issue_date and next_crl fields • At issue_date, the ratio of revoked certs : compromised certs is at its maximum • Receiver has maximum trust in message • Between CRLs the number of revoked certs doesn’t change, the number of compromised certs increases • Receiver’s trust in message should go down • Period between CRLs should be chosen so that number of compromised certs in that period is expected to be relatively small • Next CRL should be issued at next_crl time • If receiver does not receive CRL, they know they’re missing some info • Also, all certs on a chain may have been compromised, so trust in all should decay over time. • How to capture this in .2?

  14. Crl Staleness in .2 • D6: • SignedMessageValidation.rq: Overdue CRL Tolerance= time that has elapsed since the appropriate next_crl time • Security services can reject message if CRL is overdue by “too much” • SignedMessageValidation.cfm does not return any information • D7: • SignedMessageValidation.rq: Overdue CRL Tolerance as in D6 • SignedMessageValidation.cfm returns • Last received CRL (for message signing cert) • Most overdue CRL (for cert in chain with most overdue CRL) • Could potentially return all last-received and overdue info • Possible TODO: guidance in Annex C about how to use this.

  15. Store Unverified Certificate: Background (1) Sender Global SDS Rcv Security Services Extract Data Message with digest Message with cert Cert Verify Extract Data Look up digest Verify Cert

  16. Store Unverified Certificate Background (2) – D6 behavior Sender Global SDS Rcv Security Services Extract Data Message with digest Message with cert Cert Don’t Verify Extract Data Look up digest Verify No cert found

  17. Store Unverified Certificate – D7 behavior Sender Global SDS Rcv Security Services Unverified Cert Extract Data Message with digest Message with cert Don’t Verify Extract Data Look up digest Verify  Found unverified cert Possible TODO: update clause 4 diagrams for receiving messages, WSAs

  18. Change flags encoding • Flags: bitmap of arbitrary length • D6: encoded as length-value where length is encoded in one byte, minimum necessary • No flags: 00 • Flag 0 set: 01 01 • Flag 7 set: 01 80 • Flag 8 set: 01 01 00 • D7: encode length as with PSID length • leading bit 0 = 1 byte; leading bits 10 = 2 bytes; leading bits 110 = 3 bytes; leading bits 1110 = 4 bytes • No flags: 00 • Flag 0 set: 01 • Flag 6 set: c0 • Flag 7 set: 80 80 • Flag 8 set: 81 00 • Saves a byte in almost all cases

  19. Minor changes

  20. Technical • Message formats • Bug fix • Clause 5.2.4: As noted by JurajWeisz, the certificate chain needs to be ordered from highest CA to end entity in order to allow processing. • Clarified the encoding of the ext_data field. This affects clause 6.4.2.1.4 • Format change • Clause 5.3.2 and 5.3.34, changed how we indicate whether a certificate contains just a verification key or a verification and a signing key. • Clause 5.3.38, added csr_cert_unknown to CertificateRequestErrorCode • Changes to processing (all bug fixes) • Clause 6.4.5.1.4.1, added check that the message was generated before the certificate expired and after the start_validity time (if appropriate). • Clause 6.4.5.1.4.1, added check that message was not generated in the future. • Clause 6.4.2.1.4, handled requests to sign a message with Signer Identifier Certificate Chain Length set to a value inconsistent with the actual cert chain length (this is again picking up on a comment from JurajWeisz). • TODO: handle unavailable positioning services (based on this week’s comment from ITRI)

  21. Editorial • Renamed "3dLocationAndConfidence" to "ThreeDLocationAndConfidence" and "2dLocation" to "TwoDLocation" to make them valid C/C++ identifier names • Annex B2 gives an example of how the permission_indices field is used to map the ServiceInfo fields in a WSA to the permissions field in the corresponding certificate. This also causes changes in clause 6.5.3. • Certificate Management Primitives • D6: had StoredCertificateSearch and CertificateRevocationStatus • StoredCertificateSearch: • Used to build cert chains for incoming messages • given a cert digest, see if the cert exists locally and if it’s been revoked or expired • given a certificate, see if it’s been revoked or expired • CertificateRevocationStatus • Also used when building cert chains for incoming messages • Given a cert digest, see if the cert’s been expired • D7: Merge these into CertificateInfo primitive.

  22. Rationale • Let’s review

  23. Compressed / uncompressed EC points • Compressed points are 28 or 32 bytes shorter than uncompressed but may be subject to Certicom patent • Are there other advantages to uncompressed? Slightly shorter processing times. • 1609.2 mandates compressed points • ITRI comment: Should support both, mandate uncompressed • Proposed response: • Mandating uncompressed means that in practice everyone will send uncompressed, unless we mandate support for receiving compressed points everywhere • If we mandate support for receiving uncompressed points we don’t avoid the patent • If we don’t mandate support for receiving uncompressed points, all certs will be 28-32 bytes bigger than necessary • Support for compressed points could potentially be in security profile • But in this case implementers would still need to support them just in case • Discussion

  24. Conclusion • 30-day comment period?

More Related