Re: [COSE] cose-cbor-encoded-cert nameConstraints encoding

[Göran Selander <[e-mail]>]

Hi Ilari, and all,

Many thanks for the detailed comments with issues and proposed resolution!

Unfortunately we are now in a slow phase with vactions and parental leave but the  plan to get back with an update before the next IETF meeting.

Noting the increased interest and the announced [1] ongoing C-implementation by Fraunhofer AISEC, maybe someone else will pick up on these comments earlier?
[1] https://github.com/cose-wg/CBOR-certificates/issues/93

Just two minor comments in-line below.

From: COSE <[e-mail]> on behalf of Ilari Liusvaara <[e-mail]>
Date: Tuesday, 26 July 2022 at 17:02
To: [e-mail] <[e-mail]>
Subject: Re: [COSE] cose-cbor-encoded-cert nameConstraints encoding
On Tue, Jul 26, 2022 at 12:07:53PM +0000, Corey Bonnell wrote:
>
> In reviewing the latest draft of cose-cbor-encoded-cert, I noticed that
> section 3.3 [1] defines GeneralSubtree as the following:
>
> GeneralSubtree = [ GeneralName, minimum: uint, ? maximum: uint ]
>
>
>
> However, RFC 5280 section 4.2.1.10 [2] says:
>
>
>
> "Within this profile, the minimum and maximum fields are not used with
>    any name forms, thus, the minimum MUST be zero, and maximum MUST be
>    absent.  However, if an application encounters a critical name
>    constraints extension that specifies other values for minimum or
>    maximum for a name form that appears in a subsequent certificate, the
>    application MUST either process these fields or reject the
>    certificate."
>
>
> Given this, I don't think it is necessary to provide "minimum" and "maximum"
> fields as they are static ("minimum" is always 0 and "maximum" is always
> absent) in an RFC 5280-compliant certificate; a list of GeneralName for the
> GeneralSubtree is sufficient.

I have written a test CBOR X509 codec.

[GS] The term ”C509” as abbreviation for CBOR encoded X509 certificates is not rooted yet. What does the WG think, is “CBOR X509” a better term?

>From its issue notes, I found a
related issue note:

 "GeneralName can start with uint, so it is pretty nasty to determine
 if any uint in maximum position is in fact a maximum or start of
 next name. This probably will not work at all if GeneralName ever
 gains a type that can take uint as argument. And since minimum has
 a default, it is in fact optional, so the only required field is
 the GeneralName one."

However, the issue resolution note is busted (broken CDDL), and looking
at the code, the minimum/maximum handling is FUBAR.

In light of Corey's above mail, I just ripped out the minimum/maximum
handling, making those generate extension unencodeable if present.

Now each X.509 GeneralSubtree is encoded as CBOR GeneralName.

[GS] This sounds like the right approach.

Göran



        Some other notes I found:




 Certificate policies extension:

  The qualifier value field is of type dependent of qualifier id.
  Different qualfiers seem to put different things there. CPS seems
  to be IA5String, and unotice seems to be sequence{text}. If some cert
  has something else, who knows what the value is. The value field in
  CBOR is text, so sticking raw ASN.1 blobs is not possible.

  => Only qualifiers id-qt-cps and id-qt-unotice are supported.

* Key Usage extension:

  The present encoding seems to be ambiguous. For example, both 06 C0
  (committing signature certificate) and 01 06 (CA certificate) seem
  to encode as integer 3. With 1 prepended, those encode as integer 7
  and integer 131 respecively.

  => Prepend 1 bit to key usage before encoding.

* Name Constraints extension:

  Both permitted and excluded fields are optional, but the spec is not
  clear how missing field is encoded. The cbor-cert spec allows for
  empty array, while PKIX does not allow empty field. However, for
  implementations, it would be easier to encode absent field as
  null.

  => Encode missing permitted/excluded as null.

* Subject Directory Attributes extension:

  The ASN.1 is effectively list of tuples of OID and set.
  The CBOR is tuple of OID and set. There is no obvious way to map
  between the two. Furthermore, the present construction produces
  two values, which is not legal for extension, which can only
  produce one.

  => Use SubjectDirectoryAttributes = [+Attributes]

* Attribute table:

  Presently jurisdictionOfIncorporationCountryName and domainComponent
  both have id 21.

  => Encode domainComponent as 22.

* AS numbers extension:

  Is there a reason the numbers can not backjump?

  => Encode backjumps by overflowing 32-bit ASN.

* "AS Resources v2 (id-pe-ipAddrBlocks-v2)":

  I presume the OID should be id-pe-autonomousSysIds-v2.

* Section about "IP Resources" talks about "previous ASid".

  This looks odd...

* IPv6 address encoding can overflow:

  In encoding IPv6 addresses, the address differences can overflow
  uint. However, I do not expect this happening outside pathological
  cases, especially as CBOR ints go to full size of IPv6 subnetwork
  identifier.

* The encodings of Brainpool curves:

  The payload seems to be 20 octets, but the topmost TLV has length of
  19.

  => Fix topmost TLV length to 20 (0x14).

 * The encodings of ANSSI curve:

  The payload seems to be 21 octets, but the topmost TLV has length of
  19.

  => Fix topmost TLV length to 21 (0x15).

* Authority Key Identifier Extension:

  In pile of CA certs I have laying around, about 1/10 lack keyid in
  AKI.

  => Encode absent keyid as null.


Throwing the pile of CA certs I have at the implementation:

* 24 certificates have fatal errors that prevent compression:
  - 15 have bad notBefore
  - 3 have EKU explicitly not critical
  - 2 are X509v1 certificates
  - 2 have disagreeing signature algorithms
  - 1 has negative serial number
  - 1 has bad notAfter
* 15 certs hit error encoding CRL Distribution Point:
  ("Entry is not a pure DISTRIBUTION_POINT")
* 405 certs hit error encoding Certificate Policies:
  - 326 "Unsupported VisibleString notice"
  - 42 "Unsupported BMPString notice"
  - 29 "Unsupported notice reference"
  - 8 "FFCS VisibleString"
- 5 certs hit error encoding Authority Key Identifier:
  ("Invalid serial in AKI").
- 236 certs have Authority Key Identifier without keyid.




-Ilari

_______________________________________________
COSE mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cose