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