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. 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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/cose
