Subject: 3280bis-04.txt: Empty ASN.1 Sequences

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 20 Jul 2006 09:27:39 -0400

The text in 4.2.1.11 about CAs not issuing certificates where policy
constraints is an empty sequence got me thinking about where else we should
say something about empty sequences not being allowed. Instead though could
we add something to the ASN.1 Appendix that says where the empty sequences
are allowed: subject, revoked certificates, and basic constraints?

spt

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 25 Jul 2006 14:45:59 -0400

>are allowed: subject, revoked certificates, and basic constraints?
Sean,

I don't think that there needs a statement about this added to Appendix 
B.  I looked through 3280bis and could only find a couple of places 
where the ASN.1 allows for an empty sequence and no requirements are 
specified.

The first was already pointed out by Wen-Cheng Wang, the 
issuingDistributionPoint extension.  If the extension is included, but 
the two OPTIONAL fields are absent and all of the booleans are set to 
their DEFAULT values, then the result is the same as if the extension 
were absent.

The same applies to the nameConstraints extension.  It is syntactically 
possible to include a nameConstraints extension in which both 
permittedSubtrees and excludedSubtrees are absent.  Such an extension 
would impose no constraints, just as if the extension were absent.

In the case of the policyConstraints extension, it is syntactically 
possible to include the extension with both requireExplicitPolicy and 
inhibitPolicyMapping absent, and the result would be the same as if the 
extension were absent.  Of course, in the case of the policyConstraints 
extension, RFC 3280 states that conforming CAs must not issue 
certificates where both fields are absent from the extension.  RFC 3280 
even states that "[t]he behavior of clients that encounter an empty 
policy constraints field is not addressed in this profile."

I would have no objection to including guidance or requirements with 
respect to the inclusion of nameConstraints or issuingDistributionPoint 
extensions where the encoding is an empty sequence, but of course, it 
would have to be based on group consensus.

Do others believe that 3280bis should include a statement about the 
nameConstraints and issuingDistributionPoint extensions that is similar 
to the one currently included for the policyConstraints extension?

Dave

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 25 Jul 2006 12:39:45 -0800

I agree with Sharon.

Mike

-----Original Message-----
From: David A. Cooper
Sent: Tuesday, July 25, 2006 10:46 AM
> . . .

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 26 Jul 2006 17:49:04 -0400

I'd be happy if you made the changes to nameConstraints and
issuingDistributionPoint extensions. 

spt 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Tuesday, July 25, 2006 2:46 PM
To: Turner, Sean P.
Cc: pkix
Subject: Re: 3280bis-04.txt: Empty ASN.1 Sequences

Turner, Sean P. wrote:

>constraints is an empty sequence got me thinking about where else we 
>should say something about empty sequences not being allowed. Instead 
>though could we add something to the ASN.1 Appendix that says where the 
>empty sequences are allowed: subject, revoked certificates, and basic
constraints?
Sean,

I don't think that there needs a statement about this added to Appendix B.
I looked through 3280bis and could only find a couple of places where the
ASN.1 allows for an empty sequence and no requirements are specified.

The first was already pointed out by Wen-Cheng Wang, the
issuingDistributionPoint extension.  If the extension is included, but the
two OPTIONAL fields are absent and all of the booleans are set to their
DEFAULT values, then the result is the same as if the extension were absent.

The same applies to the nameConstraints extension.  It is syntactically
possible to include a nameConstraints extension in which both
permittedSubtrees and excludedSubtrees are absent.  Such an extension would
impose no constraints, just as if the extension were absent.

In the case of the policyConstraints extension, it is syntactically possible
to include the extension with both requireExplicitPolicy and
inhibitPolicyMapping absent, and the result would be the same as if the
extension were absent.  Of course, in the case of the policyConstraints
extension, RFC 3280 states that conforming CAs must not issue certificates
where both fields are absent from the extension.  RFC 3280 even states that
"[t]he behavior of clients that encounter an empty policy constraints field
is not addressed in this profile."

I would have no objection to including guidance or requirements with respect
to the inclusion of nameConstraints or issuingDistributionPoint extensions
where the encoding is an empty sequence, but of course, it would have to be
based on group consensus.

Do others believe that 3280bis should include a statement about the
nameConstraints and issuingDistributionPoint extensions that is similar to
the one currently included for the policyConstraints extension?

Dave

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 26 Jul 2006 23:32:07 +0100

> to the one currently included for the policyConstraints extension?

Yes I believe that such a statement should be included. I've seen
examples of CRLs issued by some CAs containing empty IDP extensions.

The causes interop issues because the effect is to cause implementations
to reject the CRL which don't support IDP while they could have
processed the CRL otherwise.

Steve.