Russ Housley [email protected]<mailto:[email protected]> wrote: >I would expect these to be null all the time.
Yes, thanks for the explanation and reference. Then we go for GeneralSubtree = [ GeneralName ] NameConstraints = [ permittedSubtrees: GeneralSubtree / null, excludedSubtrees: GeneralSubtree / null, ] >I support anything that makes the use of policy qualifiers more painful. This made me laugh đ Cheers, John From: COSE <[email protected]> on behalf of Russ Housley <[email protected]> Date: Wednesday, 26 April 2023 at 16:05 To: Joel Höglund <[email protected]> Cc: cose <[email protected]> Subject: Re: [COSE] Opinions on C509 / cbor-encoded-cert open issues Joel: > GeneralSubtree = [ GeneralName, minimum: uint / null, maximum: uint / null ] The above is trying to represent the following ASN.1 structure: GeneralSubtree ::= SEQUENCE { base GeneralName, minimum [0] BaseDistance DEFAULT 0, maximum [1] BaseDistance OPTIONAL } When minimum == null, the value is zero, right? When maximum == null, the value is the same as being absent in the ASN.1 structure, right? RFC 5280 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. I would expect these to be null all the time. Russ On Apr 26, 2023, at 5:08 AM, Joel Höglund <[email protected]<mailto:[email protected]>> wrote: Hi all! Thank you for the input regarding PolicyQualifier-support! Based on the replies, we conclude there isn't a strong interest in handling non-text PolicyQualifierIds, which means we can keep the current status. Regarding the handling of GeneralSubtree, a field used in the NameConstraint policy extension, we have concretised it down to the following choice, to update the current GeneralSubtree encoding from the current: GeneralSubtree = [ GeneralName, minimum: uint, ? maximum: uint ] To either GeneralSubtree = [ GeneralName, minimum: uint / null, maximum: uint / null ] which supports min and max, or just GeneralSubtree = [ GeneralName ] dropping the min-max support. So we push once more to see if there are opinions: Is the usage of min-max considered an important aspect which needs to be supported, or is a removed support an acceptable restriction to impose? Best Regards Joel Höglund On Wed, 12 Apr 2023 at 13:59, Joel Höglund <[email protected]<mailto:[email protected]>> wrote: Hi all! We are working on the remaining open issues regarding draft-ietf-cose-cbor-encoded-cert. Below are two areas in which we are interested in hearing the opinions of the community before making decisions on which updates to make: 1. The encoding of the NameConstraints extension, applicable only for CA certificates (originally defined in https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10) NameConstraint contains GeneralSubtree, which in turn, in the current version of the draft is defined as: GeneralSubtree = [ GeneralName, minimum: uint, ? maximum: uint ] Due to current limitations of how GeneralName is encoded, we need to either update the GeneralName encoding (making it slightly longer). Alternatively, limit the scope of the draft to certificates that donât contain explicit min-max specifications. - Is the usage of min-max considered an important aspect which needs to be supported, or an acceptable restriction to impose? 2. Limitations regarding the certificate policies extension; the current version of the draft states the following restrictions: âIf noticeRef is not used and any explicitText are encoded as UTF8String, the extension value can be CBOR encoded.â With the following CDDL: PolicyIdentifier = int / ~oid PolicyQualifierInfo = ( policyQualifierId: int / ~oid, qualifier: text, ) CertificatePolicies = [ + ( PolicyIdentifier, ? [ + PolicyQualifierInfo ] ) ] The RFC5280 defines the two PolicyQualifierIds CPS Pointer and User Notice (https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.4). The question to the community becomes: - Are you aware of other PolicyQualifierInfo used, which include their own non-text qualifiers? That is, is it worth the effort to make the qualifier encoding more general, dependent on the policyQualifierId type. A related issue is that there exist certificates using text types other than the recommended UTF8String encoding for explicitText. This we suggest accepting as a limitation, but are interested in hearing if there are other opinions. The current latest version 05 can be found here: https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-05.html Looking forward to your input! Joel Höglund _______________________________________________ COSE mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
