Re: [Spasm] certspec work (draft-seantek-certspec-06.txt)

[Sean Leonard <[e-mail]>]

On 6/15/2016 2:21 PM, Wei Chuang wrote:
>
>
>
>>     4. Another naming method I'm aware of is CRLSets used in
>>     Chromium: https://dev.chromium.org/Home/chromium-security/crlsets
>>     <https://dev.chromium.org/Home/chromium-security/crlsets>
>>     This might be something to consider and possibly mention in
>>     section 6 "Other Certificate Specifications".
>
>     Wei, can you provide more specifics on what you mean when you say
>     "another naming method": do you want a way to identify CRLSets, or
>     are you asking for documentation on how CRLSets identify certificates?
>
>
> This is another technique for identifying a certificate.  I point it 
> out for completeness in case its useful.  I believe its advantage is 
> that its supposed to be compact, and general.
>
>
>     I am only somewhat familiar with CRLSets, but I was under the
>     impression that an entry in a (the) CRLSet identifies a
>     certificate by one of: SHA-256 fingerprint, SHA-256 hash of the
>     public key (SPKI), or SHA-256 hashes of one of the former two
>     split up into a Merkle tree.
>
>
> I believe its simpler than that.  Its the SHA-256 hash of the issuer 
> SPKI and the certificate serial number.  I don't recall it being tied 
> to Json (but I could be wrong).

Hello Wei, I wanted to follow up on this. I am willing to write in a 
spec that includes the hash of the issuer's SPKI.

It will look like:

ISSUERSN:SPKI/SHA-256:3434ABAB..00DA;04FDBDA0

namely, the issuer part will be of the form "SPKI", a slash, and the 
hash name. This preserves algorithm agility, and is syntactically 
distinguishable from the LDAP string encoding.

Compare with:

ISSUERSN:O=DigiCert,ST=UT,C=US;04FDBDA0


The question I would like to pose is: does Chromium or some other 
implementation actually index certificates based on the issuer's SPKI 
hash, followed by the serial number?

The other certspecs (well, most of them anyway) are intended to be 
indexes or keys in a database or other lookup system. There are known 
systems that index by SHA-1 hash, by issuer + SN, etc. (as has been 
previously discussed). File paths are obviously indexes. Notably, pretty 
much all of the certspecs in draft-06 are based on data in the subject 
certificate, or operatively associated directly with the subject 
certificate (e.g., file path). The issuer DN is present in the subject 
certificate, so it is "direct" (no certificate path building required). 
In contrast, an arbitrary verifier has to perform several steps:
1. hunt for the issuer certificate based on the SPKI (hash)
2. extract the issuer DN(s) (there could be multiple issuer 
certificates, e.g., certificate rollover. Clearly not key rollover)
3. then run the algorithm as if ISSUERSN: is specified with the issuer 
DN(s) rather than the SPKIs.

This seems sub-optimal to me, unless the implementation is truly 
indexing based on the hash of the issuer's SPKI, and has some live or 
precomputed table that keeps the issuer's SPKI and certificate(s) together.

I would appreciate some citation to the Chromium source code or writeup, 
regarding how Chromium keeps track of certificates.

Sean

PS An implementation could index certificates purely based on 
serialNumber, and then sift through all matching certificates by 
comparing issuer DN(s) and/or issuer SPKIs. Assuming that serialNumbers 
are supposed to be relatively large and random, this will be pretty 
efficient.

PPS If I enable this, I will also enable SPKI specification in 
SUBJECTEXP:. However specifying the hash of the subjectPublicKeyInfo is 
"direct" because the SPKI is contained in the subject's own certificate.