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

[Sean Leonard <[e-mail]>]

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.

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

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