Re: [COSE] draft-ietf-cose-cbor-encoded-cert-09

Dear Robert Moskowitz,

Thank you for your test certificates! The test.210627.1.swimsiging
certificate can be CBOR C509 encoded, the annotated diagnostic format is
given further below. Two comments:

- Specific Certificate Policies, such as the
"icaoIdentityAssuranceMediumDeviceHardware" with OID 1.3.27.16.1.2.0.1.8,
are not present in "9.6. C509 Policies Qualifiers Registry", but are
instead stored as raw bytes.
- The extended key usage "icaoSWIMSigning" with OID 1.3.27.16.1.4.1.1 is
not present in "9.8. C509 Extended Key Usages Registry" and is, like the
policy oid, stored as raw bytes.

The FAATestpNPEIssuingCA certificate, on the other hand, contains a
BMPString in its certificatePolicies extension, violating the draft
restrictions where only UTF8Strings can be handled, since the proposed cbor
encoding does not include any string type information, for compactness.
("If noticeRef is not used and any explicitText are encoded as UTF8String,
the extension value can be CBOR encoded", from 3.3.) If we get feedback
that not handling BMPStrings in this situation is a major drawback we are
open to discussing the potential to accommodate this as well!

Best Regards

Joel Höglund

test.210627.1.swimsiging in CBOR diagnostic format:

1,  / version and certificate type /
h'1ED75CA0FADE19F98B003B8691B8FBFDCA002088',  / serial number /
[ / issuer /
  -4, "US", 8, "FAA", 9, "0124.ANGUTMPKI", 1, "FAA Testp NPE Issuing CA"
],
1624815253, 1687887252, / notBefore, notAfter /
[ / subject /
  -4, "US", 8, "FAA", 9, "0124.ANGUTMPKI", 1, "test.210627.1swimsiging"
],
1, / subjectPublicKeyAlgorithm /
h'FE9C6FDC2F32C476815EF8FA0C60A2FC06E146C965FC18C8AA8004973ED09E1F2A',
[ / extensions /
  7, h'D9B4E381E1E0EC11AB7555B89191C5434F9C3708', / authorityKeyIdentifier /
  9, / authorityInfoAccess /
  [
    2, "http://test1carepository.faa.gov/testca/faa-testp-npe-issuing-ca.p7c",
1, "http://test1carepository.faa.gov/ocsp"
  ],
  6, [h'2B1B100102000108'], / certificatePolicies /
  8, [h'2B1B1001040101'], / extended key usage /
  5, / cRLDistributionPoints /
  [
    "http://test1carepository.faa.gov/testcrl/faa-testp-npe-issuing-ca.crl"
  ],
  1, h'2383FD0B117DFF487E6F3771427D0ADEC8C9E8F8', / subjectKeyIdentifier /
  -2, 3 / key usage /
],
0, / signatureAlgorithm /
h'49857D185646F02D3FF9ABB34ABEDA4A896E3EAD9A2188ED906C491A980E3AC1D671CF5DB23820F49B1B62918BF43136717CD678CECB3988775BBB900A0CCECC'

On Tue, 19 Mar 2024 at 16:08, Robert Moskowitz <rgm-sec@htt-consult.com>
wrote:

> I am attaching test FAA SWIM certs (
> https://www.icao.int/APAC/Pages/swim.aspx).
>
> Both a regular dump and an ASN.1 dump.  You will see:  Signature
> Algorithm: ecdsa-with-SHA512
>
> at bytes 35 and 1021 in the issuing cert and 35 and 718 in the client
> cert.  10 bytes in each case, so only having it once saves 10 bytes, and I
> will take that to the bank.
>
> Please run this cert through your converter code and make sure it works,
> as this is a working cert used in SWIM testing.  Lots I disapprove of in
> this cert, and I have sent my critique of it back in August.  Still a
> struggle with conflicting directions on ICAO certs content.  Problems (IMO)
> in the CP.
>
> On 3/19/24 03:37, Orie Steele wrote:
>
> From Mike O.:
>
> I asked Russ about the history of the duplicate signatureAlgorithm in
> X.509.
> The answer is that in like 1984 -- before PKCS#1 was invented, before
> hash-then-sign was invented -- there was concern that some future
> algorithms might sign by encrypting the TBSCertificate, and so you would
> need to know the signatureAlgorithm in order to decrypt the TBSCertificate.
> So the unprotected copy was put there literally as a hint for how to parse
> the signature value in cases where the contents of the
> TBSCertificate.signatureAlg is opaque.
>
> So, yeah, it's 100% an artifact of evolution. Please get rid of it in C509.
>
> --
>
>
> ORIE STEELE Chief Technology Officer www.transmute.industries
>
> <https://transmute.industries>
>
> _______________________________________________
> COSE mailing listCOSE@ietf.orghttps://www.ietf.org/mailman/listinfo/cose
>
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>