UUIDv5 (deterministic hash based) IDs seems good on the surface. It is when you dive deep in to the guts of the workflow that you find that they make a mess of everything.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Mar 14, 2016, at 17:37, John-Mark Gurney <> wrote:
Mates, Jeffrey CIV DC3/DCCI wrote this message on Mon, Mar 14, 2016 at 16:43 +0000:I certainly understand concerns about deterministic IDs breaking workflows and not working in a number of potential use cases. It might make sense to simply allow IDs to follow the UUID v4 and UUID v5 specs. That way organizations that want to use deterministic IDs can, while those that don't have no need to. Ultimately because of how the UUID spec works out both will have the same length, and an outside observer will only notice a single character change between the two.From a parsing standpoint handling something like xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx instead of xxxxxxxx-xxxx-5xxx-xxxx-xxxxxxxxxxxx is pretty trivial as both will accomplish the same thing.I don't necessarily see an issue w/ this, BUT if they do this, thenauthor of the object MUST NOT revision their object, and they can'teven revoke the object either, since the hash of the revoked objectwill not match the original object.-- John-Mark
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
