Subject: [COSE] FW: draft-ietf-cose-x509 typos and technical points

From: Jim Schaad <[email-masked]>
Date: Fri, 16 Aug 2019 15:11:31 -0700

Forgot to add the mailing list like I was going to.

From: Jim Schaad <[email-masked]> 
Sent: Friday, August 16, 2019 2:55 PM
To: 'Sean Leonard' <[email-masked]>; [email-masked]
Subject: RE: draft-ietf-cose-x509 typos and technical points

From: Sean Leonard <[email-masked] <mailto:[email-masked]> > 
Sent: Saturday, August 10, 2019 12:28 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: draft-ietf-cose-x509 typos and technical points

Hello:

I found the following typos in draft-ietf-cose-x509:

      *  If multiple certificates are conveyed, a CBOR array of bstrs is
         used.  Each certificate being in it's own slot.

Should be:

* If multiple certificates are conveyed, a CBOR array of bstrs is used, with each certificate being in its own bstr.

[JLS] FIxed

The x5u header attribute description discusses “URL” but the IETF parlance is “URI”. Please sub “URI” instead of URL as appropriate.

[JLS] I am still a bit old fashion on this.  In part because the use of IRI is so fraught.  Done.

application/pem-certificate-chain is not an appropriate media type to use for PKIX certificates. If it is in PKIX textual format (RFC 7468), text/plain needs to be acceptable. You are asking a parser to parse through plain text.

[JLS] I was never really sold on doing this, the question is how often would it ever be done in real life today.  For now I am just going to delete this unless people say that this is frequently used.

I would like to see identification by IssuerAndSerialNumber. The reason is because many certificate databases index certificates by Issuer + Serial Number, so this lookup will be fast. The serial number is just a bstr. The issuer is just the DER blob of the issuer field (therefore, a bstr). It could be a tstr as well with the textual representation of the issuer field, but I do not know if we want to go there and introduce LDAP string parsing.

[JLS]  I am very loathe to include issuer/serial number as an option.  While I understand that many databases are indexed by this pair of values, I think that just as many of them are also indexed by one or more instances of a hash function.  My problem with using this is that it is known not to be a unique identifier of a certificate for any number of reasons.  The same problem exists if one uses the SKI extension to identify a certificate, there may be multiple certificates with the same value.  (Indeed I routinely make this value a fixed constant for a number of certificates just to make people angry.)  When this was realized for S/MIME, it was a high priority to add the hash of the certificate to the signed attributes so that this would be fixed.  I am less worried at the moment about dealing with cross certificates as I don’t believe that this will be an IoT problem, so I did not do an attribute with a chain of hashes corresponding to the certification chain.

Jim

Thanks,

Sean