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]> 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
> <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
