At Sun, 1 Nov 2009 17:56:37 -0800, Terry Manderson wrote: > > > to allow for audit: if one is paranoid, one can archive a copy of > > every CMS message and use it (along with archived PKI material) to > > prove at some later date that the action was properly authorized. So > > I view CMS as the main security mechanism here, and the one that's > > most closely aligned with the underlying semantics. > > Right, I also have a similar PoV. Although, and it may be an academic > distinction - my reading is that if the XML operations are not truly > idempotent then the 'CMS Signing Time' would have been a more pragmatic > implementation.
Don't think I follow. CMS profile for this draft specifies use of signing time (and, optionally, binary time). You need a signature that covers both the timestamp and the dated material to be audited, which this profile provides. Am I missing something? > So if you do authentication and authorisation in the CMS, why do you need 2 > way identification at the HTTPS layer if it's just for privacy? TLS without checking signatures gives you a secure channel to an unknown entity. Professor Moriarty speaks TLS too. > > The protocol nesting is tedious but straightforward: > > > > IP(TCP(TLS(HTTP(CMS(XML(up-down)))))) > > So, given that ASN.1 is fully capable of describing the data going back and > forth (up/down). Why add the extra XML blob? Primarily because there is running code using XML, secondarily because XML is somewhat easier to code and debug. > thinking from a different point of view - noting that the draft is > using HTTPS with identification of server and client, for replay and > privacy - why not consider the W3Cs XML Signature Syntax? Considered and rejected, because it's broken. The XML world doesn't really have the concept of a single canonical format, and the attempt to reconcile that world view with the requirements of digital signatures resulted in a protocol in which otherwise valid signatures can fail to validate because of disagreements about the canonical form of the signed data. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
