It is not worth making policy qualifiers more general, and if I never had to think about either of the existing ones ever again it would make me very happy. Neither of them is particularly well specified or useful.
-Tim From: COSE <[email protected]> On Behalf Of Russ Housley Sent: Wednesday, April 12, 2023 11:55 AM To: Joel Höglund <[email protected]> Cc: cose <[email protected]> Subject: Re: [COSE] Opinions on C509 / cbor-encoded-cert open issues Joel: I have argued against the use of policy qualifiers since the original work that lead to RFC 2459. However, there are always a few people that want to keep them. So, they never get deprecated. I support anything that makes the use of policy qualifiers more painful. Russ On Apr 12, 2023, at 7:59 AM, 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
