How does one read Digital Certificate attributes/values?

Question

The plan:
Distribute a document secured by "Certificate Security".  For those who have been granted the rights to print the document, need to be able to print the "User's Name" on the document - for traceability reasons.
In before Acrobat XI (using Pro version), I was able do this with in a javascript  assigning "identity.name" and "identity.loginName" to arbitrary variable; then use addwatermarkfromtext function to display this data on each page.
However with Acrobat XI, I see that identity.name and identity.loginName are Privileged and cannot be called from a page or document level script.  Furthermore addwatermarkfromtext is not supported in Reader (which the recipients are using). So my old tricks no longer work.
I've over come the addwatermarkfromtext restriction inelegantly by using textboxes.
The self-signed certificate I'm using allows for signing and execution of script; but not been successful in using the identity attributes - even with trying "app.trustedfunction... app.beginPriv() etc...
In checking the API reference, see a possible work-around using the certificate properties - specially: certificate.subjectCN. The API reference shows this as a read-only, non-Privileged value!  Am at a loss on how to call/retrieve.  What I am hoping to do is: as the document is secured by Certificate, I want to read the Certificate's "common name" value of the person who opened the document and use this as my traceability token on printed documents.
Would appreciate examples of JavaScript code to retrieve and use the Certificate.subjectCN of the user who has the document open.
(or if I'm still barking up the wrong tree - direction to the right path).
Many Thanks !

Answer 1

If you just want to read the current state of the lines when one changes, you could configure non-buffered change detection (call DAQmxCfgInputBuffer with 0 samples per channel after you configure change detection timing but before you start your task).
Use the change detection event and read just a single sample per callback.
If the software can't keep up though, you wouldn't have a buffer of all of the previous transitions.  If this is something you need, you'll need to keep using the buffered change detection.  Either event could work, but not without caveats:
1.  The Every N Samples event is generated when the requested number of samples are transferred off of the device to the host PC buffer.  It is difficult to control exactly when this transfer happens (though there are channel properties you can try setting--I can't experiment since I don't have the same hardware handy).  You're not getting the events currently because it is likely that the data is sitting in the device FIFO until the transfer is initiated.
2.  The change detection event is generated from the hardware signal.  You have to read the data to get the data transfer to happen though, but until you read the data you don't know how many samples there will be (if the line is changing rapidly you might get several samples per event for example).
For the record I find the buffering pretty awkward on USB devices when dealing with callbacks (e.g. if you are using EveryNSamples callback shouldn't the data transfer be initiated every time N samples are acquired?).  I haven't played with it in a while and it's possible the Data Transfer and Memory Channel Properties can be used to deal with the buffering issues.
Best Regards,
John Passiak