EncryptedKey uniqueness in encryption.xml

4 posts / 0 new
Last post

Hi, all

This is my second posting, and the first one was about the metadata which kindly answered by matt garrish.
That was really helpful for our dev team :)
I hope I can thank this time, too.

here's my question.

When I look up the OCF encryption.xml schema,
<enc:EncryptedKey> element has Id, and this Id use URI to define where resource located, that being said, I assume, <enc:EncryptedKey> Id does not have to be unique in encryption.xml

Therefore, it's possible to have multiple EnryptedKey that have same Id(ek1) in a single encryption.xml file like below.

-----------------------------------------------------------------------------------------
<enc:EncryptedKey Id="ek1">
<enc:EncryptionMethod Algorithm="..."/>
<ds:KeyInfo>
key information 1
</ds:KeyInfo>
<enc:CipherData>
<enc:CipherValue>context 1</enc:CipherValue>
</enc:CipherData>
</enc:EncryptedKey>

<enc:EncryptedKey Id="ek1">
<enc:EncryptionMethod Algorithm="..."/>
<ds:KeyInfo>
key information 2
</ds:KeyInfo>
<enc:CipherData>
<enc:CipherValue>context 2</enc:CipherValue>
</enc:CipherData>
</enc:EncryptedKey>
---------------------------------------------------------------------------------------

Well, that is my guess. Please correct me if I understand something wrong.
Do you think EPUB 3.0 specification ALLOW multiple EncryptedKeys that share same Id in one encryption.xml file? Do you think implement like that invalid for EPUB 3.0?

Thank you, all

As the ecryption document must conform to XML rules, it is not valid to duplicate IDs.

That said, the EPUB 3 schemas don't test for uniqueness that I can find, so if you do duplicate your Id attributes they could improperly pass an epubcheck test. Looks like a bug to me. The schema for the encryption document contains this clarifying note for why this happens:

 

# (1) ds_IdType
#
# This is defined as xsd:NCName.  One might want to use xsd:ID 
# instead, but jing is likely to report an error.  This is because 
# of the compatibility requirement for the ID/IDREF/IDREFS feature, 
# which is specified in the OASIS committee specification 
# "RELAX NG DTD Compatibility" (December 2001).
 
It appears that an additional schematron test for uniqueness should be included.

Why they need to be unique is because every EncryptedKey needs a identifier that can be reliably referenced from the EncryptedData. If you were allowed duplicate IDs, the reading system might very well try to decrypt using the wrong method.

I've reported this as a potential bug...

http://code.google.com/p/epub-revision/issues/detail?id=244

Thank you, Matt. This is really helpful for us as always. We will use unique ID for the encryption document.

Secondary menu