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