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

[Wei Chuang <[e-mail]>]

On Wed, Jun 15, 2016 at 12:15 PM, Sean Leonard <[e-mail]> wrote:

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

Regarding the title, then perhaps something describing how this document is
to be used?


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

And yet there's value in identifying certificates for lookup and such.
Just pointing what I thought was a use for the specification.

-Wei


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