I am still trying to get my head on the things that people do and do not think are going to be needed for this work. Specifically I am trying to figure out what are the set of features that people want to see.
I think that it would be useful if someone were to write a throw away draft that did the following. Taking the current CMS structures that we thing should be mapped - AuthenticatedEnvelopedData, SignedData and AuthenicatedData. Walk through each of the fields in these structures and write a one line summary of the function of the field. Make a statement that this is or is not a feature that should be followed in the WOES work. Examples: SignedData.digestAlgorithms - provides a list of content digest algorithms to allow for one pass processing. WOES does not need one pass processing SignedData.signerInfos - provides a list of different signers for the data. WOES does not need to support multiple signers SignedData.encapContentInfo.eContent - optional field allowing the signed content to either be embedded in the structure or detached from the structure. WOES will not support detached content. We can then determine which of the features are to be supported and are not to be supported. There may be other fields from different structures that also needed to be looked at. However I believe that it is universally stated that we don't want to do the transforms of XMLDigsig, although it might be that canonicalization may need to be looked at. Note - arguments that could be added to the above would be: The digestAlgorithms field provides for the ability for one pass processing for both senders and recipients. Given that senders only do things once and recipients do things multiple times it might be useful to enable one pass processing for recipients and state that it does not exist for senders. Doing this does not mean that we need to have this field, it could instead be supported by placing the data contained in the signerInfo field before the encapsulated content. Options would be No One Pass Processing, One Pass Processing for both, One Pass Processing for Sender, One Pass Processing for Recipient. Jim _______________________________________________ woes mailing list woes@ietf.org https://www.ietf.org/mailman/listinfo/woes
