Domain Security Services Using S/MIME draft-ietf-smime-domsec-04.txt

1
Domain Security Services Using S/MIMEdraft-ietf-s
mime-domsec-04.txt

• William Ottaway
• DERA Malvern,UK
• w.ottaway_at_eris.dera.gov.uk
• IETF 47
• Adelaide, Australia.

2
Minor changes

• DOMSEC signatures are now added by encapsulation
  only (Used to allow parallel signatures).
• Allows order of third party signature application
  to be known.
• More secure.
• Section four re-written to aid understanding.

3
Issues from last WG

• ISSUES
• From minutes -
• Jim Schaad recommended that the domain name
  should be exactly matched.
• Jim also pointed out that RFC 2630 states that
  the content type should be id-data when there are
  no signers of a signedData object.

4
Issue 1Domain Naming Conventions

• We have decided to keep the original naming rules
• E.g. Originator - William.Ottaway_at_eris.dera.gov.
  uk
• Legal domain names are -
• domain-signing-authority_at_eris.dera.gov.uk
• domain-signing-authority_at_dera.gov.uk
• domain-signing-authority_at_gov.uk
• domain-signing-authority_at_uk
• Must always rely on CA to police naming
  conventions.

5
Issue 2eContentType should be id-data

• Added text to the case when no originator
  signature is present to state that the
  eContentType will be id-data as specified in CMS.
• However, the eContent will contain the unsigned
  message instead of being left empty as suggested
  in CMS (section 2).
• Allows the DOMSEC signature to cover the message
  which doesnt have an originator signature.

6
Whats Next

• Obtain OID for id-signatureType.
• Submit for last call.