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

[Sean Leonard <[e-mail]>]

On 6/15/2016 2:26 PM, Wei Chuang wrote:
>
>
> On Wed, Jun 15, 2016 at 12:15 PM, Sean Leonard <[e-mail] 
> <mailto:[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
>     <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
>     <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 <http://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&
>     <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?
Hmm... Textual Format for Identifying Certificates Identifying 
Certficates in Text Conveying Certificates in Textual Formats and 
Protocols, with Attributes
>
>     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.
Yes, there is definitely value. Actually when it comes to actual names, 
it makes sense to have a string format that can be used to look up 
certificates by the names that the certificate certifies. SUBJECTEXP: 
comes close in the current draft, but appending the notAfter date is 
supposed to narrow it down to just one certificate (in theory, anyway). 
Perhaps there is demand for a textual format (namely, the "LDAP string 
syntax") for GeneralName. If so, I would not mind including it in this 
draft or in a companion document. In keeping with using OpenSSL as 
inspiration, basically GeneralName would look like the syntax of Subject 
Alternative Name in 
<https://www.openssl.org/docs/manmaster/apps/x509v3_config.html>. While 
such a syntax is not a "certspec" in the sense that it doesn't aim to 
identify a single certificate, but rather, a family of certificates, it 
could be used in a lookup using an appropriate, adjacent protocol slot, 
and is syntactically compatible. I am also willing to include a textual 
format that specifies the subject DN, for analogous reasons to 
specifying the GeneralName. A "search" or "lookup" operation has "has" 
semantics: if a certificate /has/ a name component, then it matches. In 
contrast, an "identify" operation has "is" semantics: if a certificate's 
name /is/ all of the components specified (for subject DN and for SAN, 
this also means, /in order/), then it matches. (I do not feel that 
providing a GeneralName spec with "is" semantics adds value, but can be 
convinced otherwise.) There is a relationship between GeneralName and 
draft-ietf-pkix-eai-addresses-01 that needs to be addressed: if a 
textual encoding specifies email:fóo@bár.com, an implementation ought to 
be smart about encoding (and searching) for the pkix-eai-addresses 
method instead of the rfc822Name method. This should be discussed in any 
context that searches for certificates based on e-mail addresses. Sean
> -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
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm