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

From: Sean Leonard <[email-masked]>
Date: Wed, 8 Jun 2016 09:28:44 -0700

Hello SPASM:

I would like to propose "certspec" as a work item for this WG, and that 
it be considered in-scope as we debate the WG's scope.

certspec is a string specification for certificates. It allows protocols 
and systems to identify a certificate in a textual form, and is designed 
with human usability in mind (specifically, copy-and-paste operations).

Previous versions of this draft tried to define certspec as a URN, and 
then as a series of URI schemes. Those approaches were not successful. 
This draft just calls it a string. You can look at the diffs 
(particularly the diff between 04 and 05) to see the differences.

Thanks to Russ Housley for feedback on the most recent versions of this 
draft.

Regards,

Sean

-------- Forwarded Message --------
Subject: 	New Version Notification for draft-seantek-certspec-06.txt
Date: 	Wed, 08 Jun 2016 09:16:29 -0700
From: 	[email-masked]

A new version of I-D, draft-seantek-certspec-06.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-certspec
Revision:	06
Title:		String Specification for Certificates
Document date:	2016-06-08
Group:		Individual Submission
Pages:		27
URL:            https://www.ietf.org/internet-drafts/draft-seantek-certspec-06.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-certspec/
Htmlized:       https://tools.ietf.org/html/draft-seantek-certspec-06
Diff:           https://www.ietf.org/rfcdiff?url2=draft-seantek-certspec-06

Abstract:
    Digital certificates are used in many systems and protocols to
    identify and authenticate parties.  This document describes a string
    format that identifies certificates, along with optional attributes.
    This string format has been engineered to work without re-encoding in
    a variety of protocol slots.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 9 Jun 2016 14:44:42 +0100

Sean,

> Thanks to Russ Housley for feedback on the most recent versions of this

If there's a bunch of folks saying they'd implement and deploy
that'd be good. Absent that, see earlier charter discussion.

Cheers,
S.

> URL:           
> https://www.ietf.org/internet-drafts/draft-seantek-certspec-06.txt
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Wei Chuang <[email-masked]>
Date: Thu, 9 Jun 2016 10:49:02 -0700

Just some thoughts about this draft:

1. The title is a little bit confusing, as much of the document is about
naming certificates.  Perhaps "Naming and Metadata Specification for..."?
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.
3. Modify the ABNF to clearly identify the certspec type vs data
4. Another naming method I'm aware of is CRLSets used in Chromium:
https://dev.chromium.org/Home/chromium-security/crlsets
This might be something to consider and possibly mention in section 6 "Other
Certificate Specifications".
5. Can more motivation be provided for attribute section 8?

thanks,
-Wei

On Wed, Jun 8, 2016 at 9:28 AM, Sean Leonard <[email-masked]> wrote:

> Hello SPASM:
>
> I would like to propose "certspec" as a work item for this WG, and that it
> be considered in-scope as we debate the WG's scope.
>
> then as a series of URI schemes. Those approaches were not successful. This
> draft just calls it a string. You can look at the diffs (particularly the
> diff between 04 and 05) to see the differences.
>

---

From: Sean Leonard <[email-masked]>
Date: Tue, 14 Jun 2016 02:03:50 -0700

Thank you for the feedback. Based on time, I will respond in multiple 
e-mails, and out of order...

> 5. Can more motivation be provided for attribute section 8?

Okay. Well I am not sure if more motivation needs to be provided than 
the first paragraph:

    A certificate can have additional attributes (i.e., metadata)
    operatively associated with--but not intrinsic to--it.  For example,
    the additional attributes may represent preferences.  The syntax is
    intended primarily to convey certificate metadata such as attributes
    found in PKCS #9 [RFC2985], PKCS #11 [PKCS11], PKCS #12 [RFC7292],
    and particular implementations of cryptographic libraries.

However, I suppose that I can provide some backstory.

Many certificate owners (taken broadly, I mean users and systems that 
actually use certificates on a semi-regular basis, and that hold the 
corresponding private keys) have preferences attached to those 
certificates, much like SSH key owners attach metadata to their keys. 
"friendlyName" is the obvious example. I'm pretty sure all of us around 
here name our SSH keys certain things, like "use this with foo server" 
or "generated on my Mac Mini in June". An SSH key's filename also 
constitutes metadata; ditto for certificates, although certificates with 
private keys tend to get serialized as PKCS #12. I needed a way to store 
the friendly name of a certificate, which is a piece of information that 
people care about but can change more-or-less at will. It has security 
implications to the extent that it's shown to users, or used as a basis 
for certificate selection. Some Mozilla NSS-based workflows identify 
certificates based on the friendly name (NSS calls it "nickname", but 
uses the same construct).

For S/MIME purposes, there's also smimeCapabilities. Smart clients are 
supposed to cache smimeCapabilities and track them over time: see RFC 
5751 for discussion. Of course, not many actually do this. But for 
tracking purposes, associating smimeCapabilities with the corresponding 
signing and encryption certificates of messages makes sense.

Manipulating X.690 (BER, CER, DER) is not practical, so we need a 
textual format for these attributes that does not reinvent the wheel. 
friendlyName is straightforward: it's just a string, suitably escaped. 
LDAP string encoding provides some escapes so why not use that. 
smimeCapabilities is more complicated, so in order not to reinvent the 
wheel, one can just use ASN.1 value notation directly to get the job 
done. I threw in the other two from PKCS #9 (localKeyId and 
signingDescription) for completeness and because they have trivial LDAP 
string representations. Other attributes are in use, particularly in 
PKCS #12 blobs, but those attributes tend to be vendor-specific.

What draft-06 calls "certattrs" could easily just be "pkixattrs" or 
"cmsattrs", since they all are drawing from the same attribute space. I 
suppose one could go even further and specify an LDAP string format that 
applies to any SET SIZE (1..MAX) OF Attribute. I thought about doing it 
but didn't go that far in certspec-06.

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

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 also was 
under the impression that CRLSets are encoded in JSON and do not have a 
canonical encoding form: because of this, it's difficult to say that a 
CRLSet can be identified by a cryptographic fingerprint in any reliable way.

Best regards,

Sean

---

From: Sean Leonard <[email-masked]>
Date: Wed, 15 Jun 2016 12:15:00 -0700

Returning to the rest of the response:

> 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

---

From: Wei Chuang <[email-masked]>
Date: Wed, 15 Jun 2016 14:21:29 -0700

On Tue, Jun 14, 2016 at 2:03 AM, Sean Leonard <[email-masked]> wrote:

> Okay. Well I am not sure if more motivation needs to be provided than the
> first paragraph:
>
> here name our SSH keys certain things, like "use this with foo server" or
> "generated on my Mac Mini in June". An SSH key's filename also constitutes
> metadata; ditto for certificates, although certificates with private keys
> tend to get serialized as PKCS #12. I needed a way to store the friendly
> name of a certificate, which is a piece of information that people care
> about but can change more-or-less at will. It has security implications to
> the extent that it's shown to users, or used as a basis for certificate
> selection. Some Mozilla NSS-based workflows identify certificates based on
> the friendly name (NSS calls it "nickname", but uses the same construct).
>
> supposed to cache smimeCapabilities and track them over time: see RFC 5751
> for discussion. Of course, not many actually do this. But for tracking
> purposes, associating smimeCapabilities with the corresponding signing and
> encryption certificates of messages makes sense.
>
> Manipulating X.690 (BER, CER, DER) is not practical, so we need a textual
> format for these attributes that does not reinvent the wheel. friendlyName
> is straightforward: it's just a string, suitably escaped. LDAP string
> encoding provides some escapes so why not use that. smimeCapabilities is
> more complicated, so in order not to reinvent the wheel, one can just use
> ASN.1 value notation directly to get the job done. I threw in the other two
> from PKCS #9 (localKeyId and signingDescription) for completeness and
> because they have trivial LDAP string representations. Other attributes are
> in use, particularly in PKCS #12 blobs, but those attributes tend to be
> vendor-specific.
>
> applies to any SET SIZE (1..MAX) OF Attribute. I thought about doing it but
> didn't go that far in certspec-06.
>

Thanks.

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

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

-Wei

> I also was under the impression that CRLSets are encoded in JSON and do
> not have a canonical encoding form: because of this, it's difficult to say
> that a CRLSet can be identified by a cryptographic fingerprint in any
> reliable way.
>
> Best regards,
>
> Sean
>

---

From: Wei Chuang <[email-masked]>
Date: Wed, 15 Jun 2016 14:26:35 -0700

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

> nodes on an internal network, using various configuration formats (config
> files, YANG, XML, JSON, etc.).
>
> reference schemes." It does not attempt, for example, to provide a syntax
> for matching "any certificate for an e-mail address", as
> This is important because it is likely that such a query (it *is* a
> 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
> 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.
>
> 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?

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

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

-Wei

> 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
> "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.
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\CA\Certificates\
> 109F1CAED645BB78B3EA2B94C0697C740733031C\Blob
>

---

From: Sean Leonard <[email-masked]>
Date: Thu, 16 Jun 2016 06:11:52 -0700

On 6/15/2016 2:26 PM, Wei Chuang wrote:
>
>
> On Wed, Jun 15, 2016 at 12:15 PM, Sean Leonard <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     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.
>
>     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>
>     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&>
>     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
>     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:[email-masked], 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
>     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
>     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
>

---

From: Sean Leonard <[email-masked]>
Date: Wed, 22 Jun 2016 17:40:37 -0700

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

---

From: Wei Chuang <[email-masked]>
Date: Fri, 24 Jun 2016 13:32:47 -0700

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

>> <https://dev.chromium.org/Home/chromium-security/crlsets>https://dev
>> .chromium.org/Home/chromium-security/crlsets
>> "another naming method": do you want a way to identify CRLSets, or are you
>> asking for documentation on how CRLSets identify certificates?
>>
>
> 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:
>
> namely, the issuer part will be of the form "SPKI", a slash, and the hash
> name. This preserves algorithm agility, and is syntactically
> 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:
> 2. extract the issuer DN(s) (there could be multiple issuer certificates,
> e.g., certificate rollover. Clearly not key rollover)
> 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.
>

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

-Wei

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