Add PPAPI interface for secure sockets in flash

Add the PPAPI interface for secure sockets in flash. This is a  rough first draft. Some notes:
-After discussing with rsleevi, determined that writing the general purpose interface would require a lot more work/discussion so I've chosen to go the flash-specific interface here as it's the path of least resistance.
-I've used PP_Var for returning binary blob data. The PP_ARRAY_BUFFER type will be used. 

BUG=114626
TEST=none

[wtc, 2012-02-16 20:01:59]

rsleevi: could you also review this?  Thanks.

[Ryan Sleevi, 2012-02-16 21:29:23]

Hey raymes,

I'm taking a first stab at this to sort of highlight the 'hear be dragons'
details. Please don't take it as a negative comment on the code - I think this
is just a difficult thing to get right.

I'd be happy to discuss (in person if easier) what the API goals/needs are for
this, both in the general sense of Pepper and for the specific needs of Flash.
In particular, I'd like to try to gauge whether we're going for minimum
functionality necessary or if we need some general purpose ability.

Crypto APIs are some of the trickiest things to get right, because unfortunately
the history of crypto and APIs is pretty much summed up in http://xkcd.com/927/.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
File ppapi/api/private/ppb_flash_tcp_socket.idl (right):

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_tcp_socket.idl:84: PP_Resource
GetX509Certificate([in] PP_Resource tcp_socket);
Why only return a single certificate?

A (typical) SSL handshake is made up of 1 or more certificates, with the first
certificate asserting the servers identity, and the remaining certificates used
to assist in establishing that identity.

Further, is this the list the server sends? Or is this the list that was
actually validated - which may be completely different than what the server sent
(with the exception of the first certificate, the server's identity, which
remains constant)

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
File ppapi/api/private/ppb_flash_x509_certificate.idl (right):

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:19: struct
PP_Flash_X509Certificate_Principal {
An actual principal name is:

an ordered array of
  unordered arrays of
    tuples of
      identifier, opaque type

For a certain list of pre-specified |identifiers|, |opaque type| is defined as a
string type, is stored as

  encoded type, length, value


The behaviour of Chrome's X509Certificate only including a very limited subset
(of which this list seems to reflect) was done to fit certain display needs, but
in no way reflects what an application developer would expect/use, and can
easily present the wrong information or lead to spoofing the user.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:29: enum
PPB_Flash_X509Certificate_Version {
Is there a reason you need to expose version?

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:47: [in] int32_t length);
Create takes (in) int32_t, but other APIs (GetSerialNumber,
GetAlgorithmParameters) give (out) uint32_t.

Suggest this be a uint32_t.

What happens if there is more than one X509Certificate?
What happens if there is extra data after the end of a valid X509Certificate?

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:63: mem_t GetSerialNumber([in]
PP_Resource certificate,
There's some unfortunate subtlety here re: X.509

Is the SerialNumber an actual numeric value?
Is it a byte string with the leading zero (an encoding artifact) or without (the
'logical' value)

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:69: PP_Var GetAlgorithmID([in]
PP_Resource certificate);
This is the signature algorithm, not the SPKI algorithm.

What is the form? A string ("rsaWithSha1")? An OID string?

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:74: mem_t
GetAlgorithmParamaters([in] PP_Resource certificate,
As... DER?

And why not expose the algorithm itself, why only expose the parameters?

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:86: 
Typo: Vaild -> Valid

This will definitely cause issues because dates in certificates are stored as
strings, and can therefore represent values up to the year 9999.

I know of a number of certificates that already assert dates larger than a
32-bit time_t / seconds since epoch (I think the comment "timestamp" is woefully
underspecified here), primarily because they take now+30, which yields
expirations in 2042 (> 2038 time_t max)

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:90: PP_Var
GetSubjectPublicKeyAlgorithmID([in] PP_Resource certificate);
It's unclear what this stores.

Is it a string such as "rsa" ? Is it a specific OID?

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:107: PP_Var
GetSubjectPublicKey([in] PP_Resource certificate,
Duplicate declaration to line 95-96

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:117: * Get the subjects unique
ID as a byte array.
What is "unique ID" ?

Do you mean authorityKeyId / subjectKeyId (which are extensions?) Is this some
sort of internal tracking? Is this a normalized form of the distinguished names
(of which there may be multiple certificates with that same subject /
issuer-as-subject)

[raymes, 2012-02-16 22:31:29]

Hi Ryan, thanks for the comments this is exactly the guidance I was looking for.
I haven't had any prior experience with these API's so this help is appreciated.


Right now the aim is purely to support flash, but it would be nice to write this
in a way that is extendable for use cases in the future. I've tried to answer
your questions as best I can, but I'll also set up a time where we can sit down
and discuss it. 
Thanks.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
File ppapi/api/private/ppb_flash_tcp_socket.idl (right):

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_tcp_socket.idl:84: PP_Resource
GetX509Certificate([in] PP_Resource tcp_socket);
I guess the intention is only to return the server's certificate here, which is
the data that flash requires. I can update the name/comment.

On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> Why only return a single certificate?
> 
> A (typical) SSL handshake is made up of 1 or more certificates, with the first
> certificate asserting the servers identity, and the remaining certificates
used
> to assist in establishing that identity.
> 
> Further, is this the list the server sends? Or is this the list that was
> actually validated - which may be completely different than what the server
sent
> (with the exception of the first certificate, the server's identity, which
> remains constant)

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
File ppapi/api/private/ppb_flash_x509_certificate.idl (right):

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:19: struct
PP_Flash_X509Certificate_Principal {
These are the only fields required by flash.

On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> An actual principal name is:
> 
> an ordered array of
>   unordered arrays of
>     tuples of
>       identifier, opaque type
> 
> For a certain list of pre-specified |identifiers|, |opaque type| is defined as
a
> string type, is stored as
> 
>   encoded type, length, value
> 
> 
> The behaviour of Chrome's X509Certificate only including a very limited subset
> (of which this list seems to reflect) was done to fit certain display needs,
but
> in no way reflects what an application developer would expect/use, and can
> easily present the wrong information or lead to spoofing the user.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:29: enum
PPB_Flash_X509Certificate_Version {
On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> Is there a reason you need to expose version?

AFAICT it's exposed in actionscript (although not documented) through the class:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/secu...

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:47: [in] int32_t length);
On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> Create takes (in) int32_t, but other APIs (GetSerialNumber,
> GetAlgorithmParameters) give (out) uint32_t.
> 
> Suggest this be a uint32_t.

Done. Thanks for the catch.
> 
> What happens if there is more than one X509Certificate?
> What happens if there is extra data after the end of a valid X509Certificate?
 
I'm not sure what behavior makes sense here. I would assume that it should take
only 1 certificate and nothing else. Suggestions?

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:63: mem_t GetSerialNumber([in]
PP_Resource certificate,
On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> There's some unfortunate subtlety here re: X.509
> 
> Is the SerialNumber an actual numeric value?
> Is it a byte string with the leading zero (an encoding artifact) or without
(the
> 'logical' value)

A byte string I guess, with the leading 0 removed as per
SerialNumber->http://msdn.microsoft.com/en-us/library/windows/desktop/aa377200(v=vs.85).aspx

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:69: PP_Var GetAlgorithmID([in]
PP_Resource certificate);
On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> This is the signature algorithm, not the SPKI algorithm.
> 
> What is the form? A string ("rsaWithSha1")? An OID string?

Yes, the signature OID string. I will update the name/documentation.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:74: mem_t
GetAlgorithmParamaters([in] PP_Resource certificate,
On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> As... DER?
> 
> And why not expose the algorithm itself, why only expose the parameters?

This is just what flash required. The format is the same as the Paramaters field
in
http://msdn.microsoft.com/en-us/library/windows/desktop/aa381133(v=vs.85).aspx,
which I guess is DER in our case.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:86: 
On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> Typo: Vaild -> Valid
> 
> This will definitely cause issues because dates in certificates are stored as
> strings, and can therefore represent values up to the year 9999.
> 
> I know of a number of certificates that already assert dates larger than a
> 32-bit time_t / seconds since epoch (I think the comment "timestamp" is
woefully
> underspecified here), primarily because they take now+30, which yields
> expirations in 2042 (> 2038 time_t max)

Right, I should have used a larger int. Would changing it to a 64bit integer
suffice? Can update the comment to refer to the epoch.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:90: PP_Var
GetSubjectPublicKeyAlgorithmID([in] PP_Resource certificate);
On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> It's unclear what this stores.
> 
> Is it a string such as "rsa" ? Is it a specific OID?

It's again the OID of the algorithm, I can update the name/comment.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:107: PP_Var
GetSubjectPublicKey([in] PP_Resource certificate,
On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> Duplicate declaration to line 95-96

Done.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:117: * Get the subjects unique
ID as a byte array.
It's
SubjectUniqueId->http://msdn.microsoft.com/en-us/library/windows/desktop/aa377200(v=vs.85).aspx

Again exposed through AS.

On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> What is "unique ID" ?
> 
> Do you mean authorityKeyId / subjectKeyId (which are extensions?) Is this some
> sort of internal tracking? Is this a normalized form of the distinguished
names
> (of which there may be multiple certificates with that same subject /
> issuer-as-subject)

[Ryan Sleevi, 2012-02-16 23:06:32]

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
File ppapi/api/private/ppb_flash_tcp_socket.idl (right):

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_tcp_socket.idl:84: PP_Resource
GetX509Certificate([in] PP_Resource tcp_socket);
On 2012/02/16 22:31:29, raymes wrote:
> I guess the intention is only to return the server's certificate here, which
is
> the data that flash requires. I can update the name/comment.

If going the Flash-specific interface route: GetServerCertificate
If going the general purpose route: I would return an array (of server supplied)
certificates.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_tcp_socket.idl:92: PP_Bool AddRootCertificates([in]
PP_Resource certificate,
Looking at the Flash API, I would suggest dropping the term root here.

This is a chain building certificate, which may be trusted or not. This is a
separate dimension than root certificates (root certificates can be trusted or
untrusted, intermediate certificates can be trusted or untrusted, if an
intermediate is trusted you don't need a root)

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
File ppapi/api/private/ppb_flash_x509_certificate.idl (right):

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:19: struct
PP_Flash_X509Certificate_Principal {
On 2012/02/16 22:31:29, raymes wrote:
> These are the only fields required by flash.
> 
> On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> > An actual principal name is:
> > 
> > an ordered array of
> >   unordered arrays of
> >     tuples of
> >       identifier, opaque type
> > 
> > For a certain list of pre-specified |identifiers|, |opaque type| is defined
as
> a
> > string type, is stored as
> > 
> >   encoded type, length, value
> > 
> > 
> > The behaviour of Chrome's X509Certificate only including a very limited
subset
> > (of which this list seems to reflect) was done to fit certain display needs,
> but
> > in no way reflects what an application developer would expect/use, and can
> > easily present the wrong information or lead to spoofing the user.
> 

For a Flash-specific API: This is OK. It's Adobe's fault for writing a crappy
API.
For a general purpose API: something equivalent to vector<vector<tuple>> would
make more sense, and then let the Pepper Flash code grab the values it needs.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:29: enum
PPB_Flash_X509Certificate_Version {
On 2012/02/16 22:31:29, raymes wrote:
> On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> > Is there a reason you need to expose version?
> 
> AFAICT it's exposed in actionscript (although not documented) through the
class:
>
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/secu...

Adobe's API sucks.

That said, use either X509_CERTIFICATE or X509CERTIFICATE - don't mix both.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:63: mem_t GetSerialNumber([in]
PP_Resource certificate,
On 2012/02/16 22:31:29, raymes wrote:
> On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> > There's some unfortunate subtlety here re: X.509
> > 
> > Is the SerialNumber an actual numeric value?
> > Is it a byte string with the leading zero (an encoding artifact) or without
> (the
> > 'logical' value)
> 
> A byte string I guess, with the leading 0 removed as per
>
SerialNumber->http://msdn.microsoft.com/en-us/library/windows/desktop/aa377200(v=vs.85).aspx

(Adobe rant).

This unfortunately can create ambiguities for certificates - it's generally
better to /not/ strip the data.

General purpose: Return the full bytes, make the Flash code strip it.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:74: mem_t
GetAlgorithmParamaters([in] PP_Resource certificate,
On 2012/02/16 22:31:29, raymes wrote:
> On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> > As... DER?
> > 
> > And why not expose the algorithm itself, why only expose the parameters?
> 
> This is just what flash required. The format is the same as the Paramaters
field
> in
>
http://msdn.microsoft.com/en-us/library/windows/desktop/aa381133%28v=vs.85%29...,
> which I guess is DER in our case.
> 

Thanks. Yeah, this is DER.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:86: 
On 2012/02/16 22:31:29, raymes wrote:
> On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> > Typo: Vaild -> Valid
> > 
> > This will definitely cause issues because dates in certificates are stored
as
> > strings, and can therefore represent values up to the year 9999.
> > 
> > I know of a number of certificates that already assert dates larger than a
> > 32-bit time_t / seconds since epoch (I think the comment "timestamp" is
> woefully
> > underspecified here), primarily because they take now+30, which yields
> > expirations in 2042 (> 2038 time_t max)
> 
> Right, I should have used a larger int. Would changing it to a 64bit integer
> suffice? Can update the comment to refer to the epoch.

"It would be nice" to expose a PPAPI date type here, these dates are always UTC.

Short of that, a normalized string type (YYYYMMDDHHMMSS) would be better.

Alternatively, PP_Time might be appropriate here.

http://codereview.chromium.org/9405038/diff/1008/ppapi/api/private/ppb_flash_...
ppapi/api/private/ppb_flash_x509_certificate.idl:117: * Get the subjects unique
ID as a byte array.
On 2012/02/16 22:31:29, raymes wrote:
> It's
>
SubjectUniqueId->http://msdn.microsoft.com/en-us/library/windows/desktop/aa377200(v=vs.85).aspx
> 
> Again exposed through AS.
> 
> On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> > What is "unique ID" ?
> > 
> > Do you mean authorityKeyId / subjectKeyId (which are extensions?) Is this
some
> > sort of internal tracking? Is this a normalized form of the distinguished
> names
> > (of which there may be multiple certificates with that same subject /
> > issuer-as-subject)
> 

Flash sucks.

I don't think I've ever seen a issuerUniqueId / subjectUniqueId in a certificate
in the wild. We don't currently expose these from X509Certificate, but we should
be able to expose it.

FTR, it's Section 4.1.2.8 in RFC 3280, which was added in X.509 v2, but only
works in the concept of "The Global Directory" from X500, which never existed,
and whose utility was replaced by extensions in X.509 v3 and skid/akid.

[raymes, 2012-02-21 19:07:39]

Updated the CL, PTAL.
Thanks.

https://chromiumcodereview.appspot.com/9405038/diff/1008/ppapi/api/private/pp...
File ppapi/api/private/ppb_flash_tcp_socket.idl (right):

https://chromiumcodereview.appspot.com/9405038/diff/1008/ppapi/api/private/pp...
ppapi/api/private/ppb_flash_tcp_socket.idl:84: PP_Resource
GetX509Certificate([in] PP_Resource tcp_socket);
On 2012/02/16 23:06:33, Ryan Sleevi wrote:
> On 2012/02/16 22:31:29, raymes wrote:
> > I guess the intention is only to return the server's certificate here, which
> is
> > the data that flash requires. I can update the name/comment.
> 
> If going the Flash-specific interface route: GetServerCertificate
> If going the general purpose route: I would return an array (of server
supplied)
> certificates.
> 

Done.

https://chromiumcodereview.appspot.com/9405038/diff/1008/ppapi/api/private/pp...
ppapi/api/private/ppb_flash_tcp_socket.idl:92: PP_Bool AddRootCertificates([in]
PP_Resource certificate,
On 2012/02/16 23:06:33, Ryan Sleevi wrote:
> Looking at the Flash API, I would suggest dropping the term root here.
> 
> This is a chain building certificate, which may be trusted or not. This is a
> separate dimension than root certificates (root certificates can be trusted or
> untrusted, intermediate certificates can be trusted or untrusted, if an
> intermediate is trusted you don't need a root)

Done.

https://chromiumcodereview.appspot.com/9405038/diff/1008/ppapi/api/private/pp...
File ppapi/api/private/ppb_flash_x509_certificate.idl (right):

https://chromiumcodereview.appspot.com/9405038/diff/1008/ppapi/api/private/pp...
ppapi/api/private/ppb_flash_x509_certificate.idl:29: enum
PPB_Flash_X509Certificate_Version {
On 2012/02/16 23:06:33, Ryan Sleevi wrote:
> On 2012/02/16 22:31:29, raymes wrote:
> > On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> > > Is there a reason you need to expose version?
> > 
> > AFAICT it's exposed in actionscript (although not documented) through the
> class:
> >
>
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/secu...
> 
> Adobe's API sucks.
> 
> That said, use either X509_CERTIFICATE or X509CERTIFICATE - don't mix both.

Done.

https://chromiumcodereview.appspot.com/9405038/diff/1008/ppapi/api/private/pp...
ppapi/api/private/ppb_flash_x509_certificate.idl:63: mem_t GetSerialNumber([in]
PP_Resource certificate,
On 2012/02/16 23:06:33, Ryan Sleevi wrote:
> On 2012/02/16 22:31:29, raymes wrote:
> > On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> > > There's some unfortunate subtlety here re: X.509
> > > 
> > > Is the SerialNumber an actual numeric value?
> > > Is it a byte string with the leading zero (an encoding artifact) or
without
> > (the
> > > 'logical' value)
> > 
> > A byte string I guess, with the leading 0 removed as per
> >
>
SerialNumber->http://msdn.microsoft.com/en-us/library/windows/desktop/aa377200(v=vs.85).aspx
> 
> (Adobe rant).
> 
> This unfortunately can create ambiguities for certificates - it's generally
> better to /not/ strip the data.
> 
> General purpose: Return the full bytes, make the Flash code strip it.

Done.

https://chromiumcodereview.appspot.com/9405038/diff/1008/ppapi/api/private/pp...
ppapi/api/private/ppb_flash_x509_certificate.idl:69: PP_Var GetAlgorithmID([in]
PP_Resource certificate);
On 2012/02/16 22:31:29, raymes wrote:
> On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> > This is the signature algorithm, not the SPKI algorithm.
> > 
> > What is the form? A string ("rsaWithSha1")? An OID string?
> 
> Yes, the signature OID string. I will update the name/documentation.

Done.

https://chromiumcodereview.appspot.com/9405038/diff/1008/ppapi/api/private/pp...
ppapi/api/private/ppb_flash_x509_certificate.idl:74: mem_t
GetAlgorithmParamaters([in] PP_Resource certificate,
On 2012/02/16 23:06:33, Ryan Sleevi wrote:
> On 2012/02/16 22:31:29, raymes wrote:
> > On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> > > As... DER?
> > > 
> > > And why not expose the algorithm itself, why only expose the parameters?
> > 
> > This is just what flash required. The format is the same as the Paramaters
> field
> > in
> >
>
http://msdn.microsoft.com/en-us/library/windows/desktop/aa381133%2528v=vs.85%...,
> > which I guess is DER in our case.
> > 
> 
> Thanks. Yeah, this is DER.

Done.

https://chromiumcodereview.appspot.com/9405038/diff/1008/ppapi/api/private/pp...
ppapi/api/private/ppb_flash_x509_certificate.idl:86: 
On 2012/02/16 23:06:33, Ryan Sleevi wrote:
> On 2012/02/16 22:31:29, raymes wrote:
> > On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> > > Typo: Vaild -> Valid
> > > 
> > > This will definitely cause issues because dates in certificates are stored
> as
> > > strings, and can therefore represent values up to the year 9999.
> > > 
> > > I know of a number of certificates that already assert dates larger than a
> > > 32-bit time_t / seconds since epoch (I think the comment "timestamp" is
> > woefully
> > > underspecified here), primarily because they take now+30, which yields
> > > expirations in 2042 (> 2038 time_t max)
> > 
> > Right, I should have used a larger int. Would changing it to a 64bit integer
> > suffice? Can update the comment to refer to the epoch.
> 
> "It would be nice" to expose a PPAPI date type here, these dates are always
UTC.
> 
> Short of that, a normalized string type (YYYYMMDDHHMMSS) would be better.
> 
> Alternatively, PP_Time might be appropriate here.

Done.

https://chromiumcodereview.appspot.com/9405038/diff/1008/ppapi/api/private/pp...
ppapi/api/private/ppb_flash_x509_certificate.idl:90: PP_Var
GetSubjectPublicKeyAlgorithmID([in] PP_Resource certificate);
On 2012/02/16 22:31:29, raymes wrote:
> On 2012/02/16 21:29:23, Ryan Sleevi wrote:
> > It's unclear what this stores.
> > 
> > Is it a string such as "rsa" ? Is it a specific OID?
> 
> It's again the OID of the algorithm, I can update the name/comment.

Done.

[Ryan Sleevi, 2012-02-21 19:22:42]

As a 1:1 match of the public Flash API, LGTM. We can revisit this when/if
exposing to NACL or other apps.

https://chromiumcodereview.appspot.com/9405038/diff/8001/ppapi/api/private/pp...
File ppapi/api/private/ppb_flash_x509_certificate.idl (right):

https://chromiumcodereview.appspot.com/9405038/diff/8001/ppapi/api/private/pp...
ppapi/api/private/ppb_flash_x509_certificate.idl:79: * Get the valid start date
of the certificate.
s/valid/validity/ ?

https://chromiumcodereview.appspot.com/9405038/diff/8001/ppapi/api/private/pp...
ppapi/api/private/ppb_flash_x509_certificate.idl:114: * <code>PP_Var</code>
array buffer.
PP_Var can contain NULLs, correct?

I'm just anticipating that for most/all certificates, this will be a
non-existent field, ergo NULL seems the correct response.