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

[Wei Chuang <[e-mail]>]

On Wed, Jun 22, 2016 at 5:40 PM, Sean Leonard <[e-mail]> wrote:

> 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?
>

Yes.  CRLSets are used in Chromium:
https://www.imperialviolet.org/2012/02/05/crlsets.html
https://www.imperialviolet.org/2014/04/29/revocationagain.html


>
> 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.
>

agl's github link:
https://github.com/agl/crlset-tools

-Wei


>
> 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.
>
>