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

[Sean Leonard <[e-mail]>]

Returning to the rest of the response:

On 6/9/2016 10:49 AM, Wei Chuang wrote:
> Just some thoughts about this draft:

> 2. This document would do best when coupled with work on methods to 
> access certificates such as draft-bhjl-x509-srv-00 that would use it.

Yes, I think that would be fine and a useful coupling.

However, the motivator for certspec is to identify a single certificate 
unambiguously, not a family of certificates. Use cases include in 
configuration data for Internet-connected devices, such as for 
administrators administering certificate settings on clients, server, or 
nodes on an internal network, using various configuration formats 
(config files, YANG, XML, JSON, etc.).

Section 2 says "Certificate specifications, or "certspecs", are not 
designed or intended to provide a search tool or query language to match 
multiple certificates. The goal is to replace data elements that would 
otherwise have to include whole certificates, or that employ proprietary 
reference schemes." It does not attempt, for example, to provide a 
syntax for matching "any certificate for an e-mail address", as 
draft-bhjl-x509-srv-00 suggests:

https://certs.example.com/certificates/search.cgi?uri=someuser%40example.com


This is important because it is likely that such a query (it /is/ a 
query) could return multiple certificates. It would be fine to use 
draft-bhjl-x509-srv-00 to construct a different query:

https://certs.example.com/certificates/search.cgi?certspec=SHA-256:64DF
42FF3410B579958ADDCC5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E


That would be okay; the result would have to be strictly limited to a 
single application/pkix-cert, not multiple certificates (compare with 
Section 5 of draft-bhjl-x509-srv-00). However, I question the utility of 
such a thing. If you know the SHA-256 hash but not anything else about 
the certificate, are you sure you want to be asking "example.com"? Maybe 
you should be asking elsewhere? (Compare with the ni: URI scheme.) If 
you know the SHA-256 hash and you know that you are hunting for a 
certificate that matches an e-mail address, it makes more sense to use 
draft-bhjl-x509-srv-00 or something else to return all the known 
certificates, and then have the client verify that one of the 
certificates matches the SHA-256 hash. The client has to do this anyway 
for security reasons.

Certspecs are meant to be "simple" enough that they can be included as 
components of broader formats, including certificate queries. For example:

https://certs.example.com/certificates/search.cgi?uri=someuser%40example.com&
certspec=SHA-256:64DF42FF3410B579958ADDC
C5C35E6BAEAFCCB4EB2B3FCDD29CE4EE06857F68E&certspec=SHA-1:FEA3
64082CEACA2AC80E8AECFA2224BCC3210D2A


Would be a better example (assuming that the client really did forget 
about the original certificate, perhaps because it is very 
resource-constrained): the premise being that bandwidth can be saved by 
doing server-side filtering.

> 1. The title is a little bit confusing, as much of the document is 
> about naming certificates.  Perhaps "Naming and Metadata Specification 
> for..."?
Actually...none of the document is about naming certificates, because 
they aren't names.

Certificates don't have globally unique "names". The closest thing to a 
name is Issuer + Serial Number, as issuer is theoretically unique and 
serial number is supposed to be unique for every cert issued by a 
particular CA. But we know this is not true because CA issuers are not 
bound to follow some global Directory, which never materialized.

The family of element-based specs is included for compatibility (e.g., 
with CMS, which identifies certificates based on issuerAndSerialNumber 
or SubjectKeyIdentifier; also compatibility with the MS CryptoAPI and 
Mozilla NSS major implementations ) and efficiency (e.g., database 
lookups), rather than absolute unambiguity. They are only unambiguous 
given certain assumptions, namely assumptions about the store(s) where 
the certificates are being looked up.

Several drafts ago, I tried to call these things names by stuffing them 
into the URN protocol slot. That ultimately failed, mainly because a lot 
of these things aren't names. Hashes (fingerprints) of certificates are 
also not truly unambiguous names--they are only unambiguous given 
certain engineering assumptions for certain periods of time. If you 
doubt this, consider whether MD5:01332f309262d789097cdda53be5174d is 
really the kind of "name" that we are looking for. All cryptographic 
hash algorithms are susceptible to cryptanalysis; it's just a matter of 
time and ingenuity. The data-based specs are also not really names; it 
would be like "naming" a human being by his or her entire genome sequence.

So they aren't names; they are just ways of getting at a (single) 
certificate in text.

> 3. Modify the ABNF to clearly identify the certspec type vs data

The current ABNF is intentional. Prior drafts had "certspec-type", but 
the most recent drafts remove that because it gets in the way of human 
usability (copy-and-paste-ability).

I thought about "path:" or "file:" for the filesystem-based path specs, 
but "file:" looks too much like a file: URI (it's not a file URI), and 
"path:" is both a bit superfluous, and a bit ambiguous (i.e., what kind 
of path?). Overall, a conforming implementation can recognize additional 
specs in its own special way, if it wants to. This specification only 
requires implementations to recognize a few important string patterns.

This reminds me...I was going to include Registry keys, such as
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\CA\Certificates\109F1CAED645BB78B3EA2B94C0697C740733031C\Blob

In that example, it's totally obvious that "HKEY_LOCAL_MACHINE\" is the 
prefix to a Registry key or value (and, notably, not a filesystem path). 
That would be an example of a class of certspecs that is not so great to 
exchange on the open Internet, but is very useful for a managed intranet.

Best regards,

Sean