[Bug 25659] AES-CBC mode does not describe concretely how padding is added

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25659

--- Comment #2 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Mark Watson from comment #1)
> First, the "behave as if ..." applies to all our algorithm descriptions.
> Implementors are free to do whatever they want as long as the externally
> visible behavior is the same as that which would result from following the
> algorithm description to the letter. I think we say this somewhere
> explicitly. Anyway, we should be able to take it as read for all algorithm
> descriptions.
> 
> Second, I thought that by the time we get to the algorithm descriptions we
> are dealing with abstract types. 'plaintext' and 'padded plaintext' are just
> strings of octets, not a language-specific concrete type that contains such
> a string. HOw they are stored / manipulated in memory is
> implementation-specific.

This is not actually what the spec says, which is why I filed the bug. They are
language-specific, concrete types - and that needs to be resolved.

> 
> At least, this was my intention when drafting this text. The method
> descriptions which call into the operation descriptions should say '...
> passing the contents of X as *plaintext*' where X is the ArrayBufferView and
> so plaintext is just the octet string.

Except it doesn't work like that.

This issue came up when working trough Bug 23728. It's actually quite clear
from the spec that, at the time the phrase occurs, "ciphertext" still refers to
a concrete ArrayBuffer type.

As such, from the perspective of an external user, "adding padding octets to
ciphertext" has a defined meaning - an illegal one. It's also underspecified
what it means by "Let X be the result of adding padding octets" - that implies
a concrete, mutative step, but the intent is certainly not.

I agree that the 'intent' is understood, but as it's written, it's
underspecified, which is why I filed this bug - as I'm having to change the
language of these algorithms to make it clear what their external effects are,
so that we *could* include such a conformance requirement.

Conformance requirements and the language related to them should be tracked as
a separate bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 12 May 2014 17:05:04 UTC