Domain Security Services Using S/MIME draft-ietf-smime-domsec-04.txt William Ottaway DERA Malvern,UK IETF 47 Adelaide, Australia.

Minor changes zDOMSEC signatures are now added by encapsulation only (Used to allow parallel signatures). –Allows order of third party signature application to be known. –More secure. zSection four re-written to aid understanding.

Issues from last WG zISSUES 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.”

Issue 1 Domain Naming Conventions zWe have decided to keep the original naming rules – E.g. Originator :- Legal domain names are :- zMust always rely on CA to police naming conventions.

Issue 2 eContentType should be id-data zAdded text to the case when no originator signature is present to state that the eContentType will be id-data as specified in CMS. zHowever, 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 doesn’t have an originator signature.

What’s Next zObtain OID for id-signatureType. zSubmit for last call.