Oppose raw enrypted digests? Oh yes, don't even think about it. If you do I'll have the folk from the other end of your corridor have a go at you. There is a specific known attack - and not a particularly computationaly intensive one. What goes on INSIDE the signature is not something you want to get involved with here. That is for the cryptographers. What we are debating is the structure of the wrapper. While Merlin's suggestion of raw ASN.1 blobs that are tagged and bagged via XML may sound as if it avoids ASN.1ery I think it actually does the opposite. It means that the XML world has to actually CARE about the ASN.1 blobs and manage them - AND CODE FOR THEM! Thinking ahead, I would much rather that we don't link the ASN.1 and XML namespaces as suggested. Having one namespace recapitulate information in another is rarely a good idea. Not only can it lead to inconsistencies it leads to admin nightmares. The situation I want to avoid is working on a layered standard where I have to go off to IANA to get an OID cut for some PKIX related infrastructure and then go to W3C to get a URI cut. Particularly if IANA might require me to have the W3C URI before they will hand out my OID. There is potentially a multi-step synchronisation here that I am anxious to avoid. Phill > And we control what [1] means, consequently does anyone > oppose Merlin's > first option [2]? > > [1] http://www.w3.org/2000/07/xmldsig#rsa-sha1 > [2] > http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSe p/0375.html 1) The signature may be either an encrypted ASN.1 blob (PKCS#1) or an encrypted raw digest (like W?TLS) _________________________________________________________ Joseph Reagle Jr. W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/People/Reagle/
Received on Tuesday, 29 August 2000 13:38:54 UTC