Subject: RE: Part1 last call comments

From: David Kemp <[email-masked]>
Date: Thu, 1 Mar 2001 10:44:05 -0500 (EST)

Hi Jim,

Thanks for pointing out that I misread your proposal, focusing on
the "expires" instead of the "all CRLs".

As long as there is a statement in 2459bis that CRL expiration is a
matter of local policy, and applications MUST make provision for the
fact that the next CRL will not be available precisely at nextUpdate,
then I don't have a problem with your original proposal "until all
existing CRLs expire."  A more precise wording might be "until the
application considers all existing CRLs to have expired", but that
would be redundant if 2459bis contains an unambiguous statement that
different applications *will* have different caching policies (different
definitions of "CRL expiration").

Section 3.3 says: "If a revocation is reported now, that revocation
will not be reliably notified to certificate-using systems until the
next periodic CRL is issued".  In the case where more than one CRL is
in scope for a particular certificate (for example a deltaCRL series
and a less-frequently-issued full CRL series, or overlapping partitions
with different dates), it is again a local application policy whether
to consider its local cache valid until the most fresh source has an
update, until the least fresh source has an update, or even beyond the
point where all sources have had an update (treat a CRL as valid for 24
hours even though a new one was issued after 12 hours).

So "until the next periodic CRL is issued" is correct for applications
which start trying to update their cache at nextUpdate of the freshest
in-scope CLR series.  "...until all currently issued CRLs pass their
next update" is correct for applications which start trying to update
their cache only when the last (least fresh) in-scope CRL passes
nextUpdate.  Note that neither of these statements is correct if CAs
populate nextUpdate with an inaccurate value.

If all applications were configured to require the absolute latest info
(i.e. no application used a CRL cache), then revocation will be
reliably notified even before the next periodic CRL (i.e. if you cache
CRLs exactly as you cache OCSP responses and the CA issues unscheduled
CRLs on revocation events, you will get revocation info from CRLs as
fresh as you would get it from OCSP).

And if some applications are configured to cache CRLs for 24 hours
and the CA issues them every 12 hours, then revocation won't be
reliably notified even after the next periodic CRL is issued.

So the statement in 3.3 doesn't mean much: certificate-using systems
will be reliably notified sooner than, exactly when, or later than
the next periodic in-scope CRL depending on the specific certificate-using
system's caching policy.  PKIX can't require all applications to use
the same caching policy; the freshness/bandwidth/response-time/availability
tradeoffs are different for different certificate-using applications.

In summary, I no longer disagree with what you originally proposed, but
I don't agree with it either, since neither the current wording nor the
proposed change is generally true but each is sometimes true.  Any
statement regarding "reliably notified" must be made within the context
of a specific CRL caching policy.  My goal is to nail down one piece of
jello in this revocation picture:  PKIX CAs MUST populate nextUpdate
with the true time of the next scheduled CRL, and applications have to
handle the propogation/caching/reliance issues.

Regards,
Dave

> > > 4. Section 3.3 - Minor point,  in paragraph 4 - This should be "until
> > > all existing CRLs expires" rather than "until the next periodic CRL
> > > update".  A CRL may be valid for more than one issue period (i.e. issue
> > > every 12 hours, expire after 24 hours).
> >
> > Jim,
> >
> > I disagree with this proposed change.  CRLs do not expire, they only
> > have a next scheduled update date.  As section 3.3 paragraph 3 says,
> > "the meaning of 'suitably-recent' may vary with local policy", and
> > if one local policy says that CRLs which are issued every 12 hours
> > don't expire until 24 hours after issue, fine.  A different local
> > policy, however, might say that the identical CRL expires 13 hours
> > after issue.
> >
> 
> Dave,
> 
> Would the text "until all currently issued CRLs pass their nextUpdate." be
> acceptable to you?  I merely want to reflect that there may be multiple
> valid CRLs in existence, and until all of them have passed their nextUpdate
> time a cached CRL can validly be expected to be used.
> 
> jim

---

From: Frank Balluffi <[email-masked]>
Date: Fri, 02 Mar 2001 08:04:58 -0800

Russ Housley said:

> The same compiler would like "EXPLICIT" or "IMPLICIT" to be 
> inserted before 
> uses of ORAddress, Name, DirectoryString, and 
> RelativeDistinguishedName.

Having been bitten by this in the past, I would recommend that PKIX at least
insert a comment into the ASN.1 source with the appropriate tag type.

Frank

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, March 01, 2001 5:51 PM
> To: [email-masked]
> Subject: Re: Part1 last call comments
> 
> 
> All of these comments deal with the ASN.1 modules in 
> draft-ietf-pkix-new-part1-04.txt and 
> draft-ietf-pkix-ipki-pkalgs-01.txt.  Jim Schaad posted some comments 
> earlier, but I do not completely agree with his resolutions.  I will 
> address those second.  First, I want to raise a two things 
> that were not 
> raised in Jim's message.
> 
>   1.  AuthorityKeyIdentifier is defined as:
> 
>     AuthorityKeyIdentifier ::= SEQUENCE {
>        keyIdentifier             [0] KeyIdentifier           OPTIONAL,
>        authorityCertIssuer       [1] GeneralNames            OPTIONAL,
>        authorityCertSerialNumber [2] CertificateSerialNumber 
> OPTIONAL  }
> 
>     KeyIdentifier ::= OCTET STRING
> 
> There is nothing wrong with this ASN.1; however, at least one 
> compiler 
> wants either "EXPLICIT" or "IMPLICIT" to be inserted before 
> CertificateSerialNumber.  Obviously, only one of these is 
> correct.  The 
> problem in the compiler seems to come from the fact that 
> CertificateSerialNumber is imported from the explicit module.
> 
> The same compiler would like "EXPLICIT" or "IMPLICIT" to be 
> inserted before 
> uses of ORAddress, Name, DirectoryString, and 
> RelativeDistinguishedName.
> 
> A programmer must know a fair amount about ASN.1 to know the 
> correct type 
> of tagging in each case.  To avoid implementation errors from 
> anyone that 
> might use that tool, should we make the insertion?  My 
> initial reaction is 
> that anyone who uses a tool with such shortcomings must edit 
> the module to 
> overcome them.  I think that preserving alignment with X.509 is 
> important.  However, I think we should make sure that the example 
> certificate includes these cases to help implementors catch 
> mistakes early 
> in the development process.
> 
> 2.  The implicit module (section A.2) contains the following:
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     
> DistributionPointName OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
>     IssuingDistributionPoint ::= SEQUENCE {
>       distributionPoint       [0] DistributionPointName OPTIONAL,
>       onlyContainsUserCerts   [1] BOOLEAN DEFAULT FALSE,
>       onlyContainsCACerts     [2] BOOLEAN DEFAULT FALSE,
>       onlySomeReasons         [3] ReasonFlags OPTIONAL,
>       indirectCRL             [4] BOOLEAN DEFAULT FALSE }
> 
>     DistributionPointName ::= CHOICE {
>          fullName                [0]     GeneralNames,
>          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> 
> This matches the definitions from X.509 (4th Edition), but it 
> is still a 
> very strange use of CHOICE.  It relies on a little-known ASN.1 rule:
> 
>          The tagging construct specifies explicit tagging if 
> the "Tag Type"
>          alternative is used and the value of "TagDefault" 
> for the module is
>          "IMPLICIT TAGS", but the type defined by "Type" is a 
> choice type
>          or an any type.
> 
> The same compiler as discussed above, does not internally 
> implement this 
> rule.  The programmer must insert the "EXPLICIT."  Again, my 
> reaction is 
> that anyone who uses a tool with such shortcomings must edit 
> the module to 
> overcome them.  I think we should make sure that the example 
> certificate 
> includes these cases to help implementors catch mistakes early in the 
> development process.
> 
> I think that implementors would be well served if the specification 
> included the binary certificates were made available.  I do 
> not think that 
> we should make the document any bigger.  Perhaps we can 
> develop a companion 
> document that contains several sample certification paths 
> with CRLs to aid 
> developers.  Of course, we need to carefully consider the 
> validity periods 
> for the sample certificates to be useful to future 
> developers, but that is 
> a topic for another thread.
> 
> Now to Jim Schaad's message.
> 
> >3.  Section 4.2.2.2 - Recommend moving the defintion of 
> id-ad-caRepository
> >to implicit ASN.1 module since that is where accessLocation 
> is located.
> 
> Good idea.  I do not think that moving the OID definition will impact 
> anyone that already did an implementation.
> 
> >5.  ASN Module A.1:  Do not have a new module OID for this.
> 
> A new OID for the modules was assigned quite some time ago.  
> It should have 
> been included in this draft.
> 
>          id-mod-pkix1-explicit        OBJECT IDENTIFIER ::= { 
> id-mod 18 }
> 
> >6.  A.1:
> >                    X520SerialNumber        PrintableString (SIZE 
> > (1..ub-serial-number))
> >       replace with
> >                    X520SerialNumber        ::= 
> PrintableString (SIZE 
> > (1..ub-serial-number))
> 
> Agree; the assignment operator (::=) is missing.
> 
> >7. Section A.1
> >                    id-domainComponent      AttributeType ::= 
> > id-domainComponent
> >      replace with
> >                    id-domainComponent      AttributeType ::= 
> > id-domainComponent }
> 
> I do not think that this is the correct change.  The document says:
> 
>          id-domainComponent     OBJECT IDENTIFIER  ::=
>                                              { 0 9 2342 
> 19200300 100 1 25 }
> 
>          id-domainComponent      AttributeType ::= id-domainComponent
>          domainComponent ::=     IA5String
> 
> I think the middle statement should be deleted altogether.  
> Also, the last 
> line must begin with a capital letter ("domainComponent" becomes 
> "DomainComponent").
> 
> >8.  ASN Module A.2:  Do not have a new module OID for this.
> 
> A new OID for the modules was assigned quite some time ago.  
> It should have 
> been included in this draft.
> 
>          id-mod-pkix1-implicit        OBJECT IDENTIFIER ::= { 
> id-mod 19 }
> 
> >9.  Section A.2
> >                 anyPolicy OBJECT IDENTIFIER ::= 
> > {id-ce-certificate-policies 0}
> >       replace with
> >                 anyPolicy OBJECT IDENTIFIER ::= 
> {id-ce-certificatePolicies 0}
> >       (or fix the previous line)
> 
> Agree.  X.509 (the 4th Edition) uses 
> id-ce-certificatePolicies, and we 
> should too.
> 
> >----------------   Algorithm Draft
> >
> >ASN Module:
> >Fix:
> >    PKIX1Algorithms88 { tbd }
> 
> I assigned id-mod-pkix1-algorithms a long time ago.  It 
> should have been 
> put into this draft.
> 
>          id-mod-pkix1-algorithms      OBJECT IDENTIFIER ::= { 
> id-mod 17 }
> 
> >Replace
> >             cofactor  INTEGER  OPTIONAL,         -- The 
> integer h = #E(Fq)/n
> >With
> >             cofactor  INTEGER  OPTIONAL          -- The 
> integer h = #E(Fq)/n
> 
> My preference would be to replace the comma with "}" and 
> delete the next 
> line.  This is just taste.  The comma needs to go.
> 
> >------------------ Random
> >
> >part1-algs.asn(3) : warning XXXXX: Module PKIX1Algorithms88 
> does not have an
> >OID assigned to it
> >
> >  --- single name would be nice but not necessary.  In the 
> case of pkcs-9
> >however there should be a harmonization plan.
> >
> >rfc2630.asn(254) : warning XXXXX: Arc naming collision 
> between x9algorithm
> >and x9cm
> >         Conflicts with what's in Algorithms draft
> >rfc2630.asn(262) : warning XXXXX: Oid value assigned to 
> multiple symbols:
> >'dh-public-number' and 'dhpublicnumber'
> >         Conflicts with what's in Algorithms draft
> >rfc2634.asn(204) : warning XXXXX: Arc naming collision 
> between pkcs-9 and
> >pkcs9
> >         Conflicts with what's in Part1 A.1
> 
> I do not see a problem with adopting the names from RFC 2630 
> and RFC 2634.
> 
> Russ
> 
>

---

From: "Pawling, John" <[email-masked]>
Date: Fri, 2 Mar 2001 11:27:12 -0500

All,

We compiled the PKIX1Explicit88 module in the
draft-ietf-pkix-new-part1-04.txt using the Enhanced SNACC ASN.1 compiler.
We found some of the same problems that Jim reported (X520SerialNumber
definition missing "::="; id-domainComponent defined twice).  We also found:

1) OLD: ub-serialNumber INTEGER ::= 64
   NEW: ub-serial-number INTEGER ::= 64

2) OLD: domainComponent ::= IA5String
   NEW: DomainComponent ::= IA5String

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 3 Mar 2001 07:40:48 (NZDT)

Russ Housley <[email-masked]> writes:

>A programmer must know a fair amount about ASN.1 to know the correct type of
>tagging in each case.  To avoid implementation errors from anyone that might
>use that tool, should we make the insertion?

I would say, yes.  The ASN.1 rule you quote is a booby-trap which has caught a
number of implementors (I added it to the X.509 style guide a while back for
this reason, and you still occasionally see questions about it on various
lists, and I've had a few "Your dumpasn1 shows ... but RFC 2459 says ..." too),
it'd be worth making this explicit in the ASN.1.

Peter.