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

[Wei Chuang <[e-mail]>]

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

> Thank you for the feedback. Based on time, I will respond in multiple
> e-mails, and out of order...
>
> On 6/9/2016 10:49 AM, Wei Chuang wrote:
>
> Just some thoughts about this draft:
>
>
> 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.
>

Thanks.


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

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