Re: [emergency] CAP v1.2 implementation Difficulties

[Jacob Westfall <jake@jpw.biz>]

> in fact look at a solution that does work as a 1.2 change.  We have tested this with out a problem and know that it
> works.   The basic concept is to encapsulate the <any> tags within optional identified tags to isolate them from
> multi-namespace issues.  (For backward compatibility we could also leave the current 1.1 <any> tag in place, but we
> would not make any use of it.)

In order to provide for enveloping signatures and encryption there are two methods that are in common practice for other specifications, there may be others and if so please pass them along.  The use of isolating tags is not standard practice and should not be necessary.  The <any> method is portable, and validates using a wide variety of tools and libraries.  The equivalent <import> method that I sent to the list requires the additional schemas to be present thereby being less portable, but also validates using a wide variety of tools and libraries.  If neither of these methods is working for you, then its a clear implementation issue that should probably be taken up with the tools vendor as something is broken.

Its important to remember that encrypting and/or signing CAP messages is in 1.1 and is not a "new" addition in 1.2.  The key issue raised by Dave from my viewpoint is whether to allow for encryption at all inside the CAP message.  Some of the other issues he raises I belive to be out of scope for this TC to address.  Encrypting a standalone CAP message is unlikely to be a practice that anyone employs.  So should the TC remove this capability from the CAP specification?

If this capability were to be removed, there would no longer be two subsequent <any> elements in the schema and presumably Gary's tools problem would go away.  Dave's concerns about encryption and distribution would be addressed.  During the past public reviews and comment calls, no commentor raised this issue, previous comments on encryption were actually calling for stronger practices.

If encryption was stripped from the specification, it would require this vote to fail and the TC to make the changes and conduct another public review period.  I assume that would only be 15 days as a continuation of the current cycle but would need confirmation of that since this was a specification ballot.  If the ballot passes and we decided to make this change to the approved specification, probably a 60 day public review as it would be a new review cycle??

Another option could be to pass the specification as is, leaving encryption in, then do an errata that says best practices indicate encryption should not be employed without a wrapper, etc.

There has been a lot of last minute work on 1.2 which creates difficult decisions like this, we really need to encourage earlier work with and comments for 2.0.

-- 
jake@jpw.biz
--