So in an attempt to provide as "complete"
an example as possible, I kinda went for the overkill approach. Namely,
you can user either:
a)
the KeyName in the EncryptedData to point to the EncryptedKey, or
b)
the ReferenceList in the EncryptedKey to point to the EncryptedData.
In general, I prefer "b" since
I can scan through various encrypted stuff and only start processing only
when I find an EncryptedKey encrypted with my key, then I can decrypt whatever
was encrypted with it.
Alternative "a" implies reaching
the EncryptedData then scanning the document for all EncryptedKey elements
with the same name and then figuring out which one is encrypted with my
key.
As either approach is correct, I don't
want to rule out either. If it makes it simpler, we can show the example
as illustrating "a" and then just point out that "b"
is also possible.
So, if you can figure out how to word
smith this so that it is not so confusing, please do. Thanks!
Regards
Heather Hinton, PhD, PEng
Senior Security Architect, TFIM Product Architect
tel: + 1 512 838 0455
T/L 678-0455
"Scott Cantor"
<>
02/05/2006 08:53 PM
To
Heather Hinton/Austin/IBM@IBMUS
cc
<>
Subject
[security-services] RE: Encryption guidance
> Seeings as I can't find Scott's email as a stand-alone,
here
> is the info below, put into a word document (for editing).
I wish the spammers had your address book.
> Also, just FYI, I did include an example at the end with
> multiple keys within the Encrypted Data - this should cover
> the "broadcast" scenario that was discussed on this morning's
> call. I checked with our local WS-I/BSP folks and they
> believe that this is compatible with BSP guidelines, even
> though it is within the scope of SAML.
This seems understandable, if convoluted, but one question...what's the
purpose of the <ReferenceList> in the <EncryptedKey> elements?
Or, I should
say, what's different about the broadcast example vs. the other two
examples?
It seems like you could use <ReferenceList> (or not) uniformly in
all the
examples, but it doesn't appear to specifically pertain to the broadcast
use
case. The <CarriedKeyName> aliasing seems independent of it.
Is it a requirement of these libraries that the Data reference the Key
and
vice versa, or is one direction (Data->Key) sufficient?
I'm just wordsmithing mostly, but this seemed more substantive. Pending
the
answer, I'll supply revised text.
-- Scott
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
