Subject: RE: questions about rfc2510bis and rfc2511bis

From: Carlisle Adams <[email-masked]>
Date: Fri, 19 Jan 2001 17:47:27 -0500

Hi Ari,

As I wrote in my response to Magnus, I apologize for such a long delay in
replying to your comments/questions.  See embedded answers below.

> ----------
> From: 	Ari Kermaier[SMTP:[email-masked]]
> Sent: 	Tuesday, January 09, 2001 12:38 PM
> To: 	Carlisle Adams
> Subject: 	questions about rfc2510bis and rfc2511bis
> 
> I posted the comments and questions listed below over the last few weeks, 
> but they didn't seem to generate any interest. Since the documents in 
> question have been submitted for last call, I thought I'd better send them
> 
> to you directly. I apologize if that's inappropriate.
> 
> Ari Kermaier
> Phaos Technology
> 
> AltCertTemplate Control:
> ------------------------
> 
> CMP (draft-ietf-pkix-rfc2510bis-02) Appendix D defines the following new 
> control:
> 
> 	id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
> 	AltCertTemplate ::= AttributeTypeAndValue
> 
> 1) Is the complete (expanded) syntax of the control supposed to be
> 
>      SEQUENCE {id-regCtrl-altCertTemplate OBJECT IDENTIFIER,
>          SEQUENCE {type OBJECT IDENTIFIER,
>                  value ANY DEFINED BY type} }
 
Yes.

> and if so what OIDs are envisioned for use here?
 
I did do an independent "cmp-altCert" draft 6 months ago that has just
expired.  I will probably get around to updating and resubmitting it some
day soon...  Anyway, the sorts of things I had in mind were templates for
X.509 attribute certificates and WAP WTLS certificates (id-acTemplate ::=
{id-regCtrl-altCertTemplate xx} and id-wtlsTemplate ::=
{id-regCtrl-altCertTemplate yy} were the place-holders in the draft).

> 2) If this control is present and contains both the subject and public
> key, 
> is a POPOSigningKey signature supposed to be calculated on the DER
> encoding 
> of the entire control, or just the AttributeTypeAndValue payload of the 
> control?
 
Good point -- this was unclear.  What I intended was the DER-encoded value
of the AttributeTypeAndValue payload.  I will clarify this in the text.

> 3) The first paragraph of draft-ietf-pkix-rfc2510bis-02 Appendix D, where 
> the AltCertTemplate control is defined, states:
> 
> 	The following definitions are from rfc2511bis.  They are included
> here
> 	in order to codify behavioral clarifications to that request
> 	message; otherwise, all syntax and semantics are identical to
> rfc2511bis.
 
[Note:  by "definitions" above, all I meant was CertRequest, POPOSigningKey,
and POPOPrivKey.]

> As far as I can see, the AltCertTemplate control is not mentioned anywhere
> 
> in rfc2511bis, nor is it included in the ASN.1 module for rfc2510bis. Is 
> this a sin of omission (missing from 2511bis and 2510bis Appendix F) or of
> 
> comission (maybe it shouldn't be in 2510bis Appendix D either)?
 
I don't think a sin (omission or commission) is occurring here.  RFC 2511
says that the list of controls may expand over time.  This expansion need
not occur in 2511; it could theoretically happen anywhere (as long as it's
controlled).  All we're doing here is defining a new control and specifying
the behaviour around its processing.  This doesn't have to be in 2511bis,
and doesn't really belong in 2510bis App G either (since App G is the syntax
for everything outside 2511).  I think it is perfectly reasonable for this
control and behaviour specification to happen in appendix D of 2510bis since
this is the specification that also allows alternative certificate formats
through CMPCertificate, whereas this concept is irrelevant to 2511bis.

> CertResponse.rspInfo:
> ---------------------
> 
> draft-ietf-pkix-rfc2510bis-02 section 3.3.4 has the following syntax for a
> 
> certification response:
> 
>    CertResponse ::= SEQUENCE {
>        certReqId           INTEGER,
>        -- to match this response with corresponding request (a value
>        -- of -1 is to be used if certReqId is not specified in the
>        -- corresponding request)
>        status              PKIStatusInfo,
>        certifiedKeyPair    CertifiedKeyPair    OPTIONAL,
>        rspInfo             OCTET STRING        OPTIONAL
>        -- analogous to the id-regInfo-utf8Pairs OCTET STRING defined
>        -- for regInfo in CertReqMsg [rfc2511bis]
>    }
> 
> 4) I don't understand the comment for the rspInfo field -- rfc2511bis has 
> the UTF8Pairs registration info value defined as UTF8String, not OCTET 
> STRING. Can anyone enlighten me as to how rspInfo is supposed to be
> encoded?
 
"OCTET STRING" was a poor choice of description in this comment.  You're
right; this is confusing.  I should have used "octet string", or preferably
"string", since I didn't mean the ASN.1 type; all I meant was "bunch of
octets".  I will fix this.

> AttributeTypeAndValue Sequences:
> --------------------------------
> 
> There are several places in CMP/CRMF where a definition such as the 
> following appears:
> 
> CertReqMsg ::= SEQUENCE {
>      (...)
>      regInfo   SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }
> 
> 5) In such a field, is it permissible for more than one 
> AttributeTypeAndValue having the same type OID to be present?
 
I don't think anything prohibits this, but this is an ASN.1 question, not a
CMP/CRMF question.

> 6) If yes, how should the multiple entries be processed? If no, shouldn't 
> there be a comment to that effect, or perhaps a new production defined 
> (such as AttrTypeAndValueSequence ::= SEQUENCE SIZE(1..MAX) of 
> AttributeTypeAndValue)) with a comment included?
 
No, I don't think a comment is warranted here.  (As I said, this is an ASN.1
question, and there's no reason to do anything here that violates how ASN.1
is supposed to work...)

> CertStatus.certReqId:
> ---------------------
> 
> 7) An apparent inconsistency between the text and the ASN.1 module in 
> rfc2510bis:
> 
> 3.3.18 Certificate Confirmation content
> 
>        CertStatus ::= SEQUENCE {
>           certHash    OCTET STRING,
>           -- the hash of the certificate, using the same hash algorithm
>           -- as is used to create and verify the certificate signature
>           certReqId   INTEGER,
>           -- to match this confirmation with the corresponding req/rep
>           statusInfo  PKIStatusInfo OPTIONAL
>        }
> 
> Appendix F: "Compilable" ASN.1 Module using 1988 Syntax
> 
>    CertStatus ::= SEQUENCE {
>       certHash    OCTET STRING,
>       -- the hash of the certificate, using the same hash algorithm
>       -- as is used to create and verify the certificate signature
>       statusInfo  PKIStatusInfo OPTIONAL
>    }
 
Someone else pointed this out to me as well (to my great embarrassment,
after all the ca-talk discussion over this structure!).  I can't believe I
missed this in the appendix!  Section 3.3.18 is correct, and the appendix
will be fixed.

Thank you for your comments, and I hope the above explanations are helpful.

Carlisle.

---

From: Ari Kermaier <[email-masked]>
Date: Mon, 22 Jan 2001 13:35:58 -0500

Carlisle,

Thank you for your answers, they're very helpful. However, I have a 
follow-up to the AttributeTypeAndValue SEQUENCES comments:
>AttributeTypeAndValue Sequences:  --------------------------------
>
>There are several places in CMP/CRMF where a definition such as 
>the  following appears:
>
>CertReqMsg ::= SEQUENCE {       (...)       regInfo   SEQUENCE 
>SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }
>
>5) In such a field, is it permissible for more than 
>one  AttributeTypeAndValue having the same type OID to be present?
>
>I don't think anything prohibits this, but this is an ASN.1 question, not 
>a CMP/CRMF question.
>6) If yes, how should the multiple entries be processed? If no, 
>shouldn't  there be a comment to that effect, or perhaps a new production 
>defined  (such as AttrTypeAndValueSequence ::= SEQUENCE SIZE(1..MAX) 
>of  AttributeTypeAndValue)) with a comment included?
>
>No, I don't think a comment is warranted here.  (As I said, this is an 
>ASN.1 question, and there's no reason to do anything here that violates 
>how ASN.1 is supposed to work...)

I wasn't thinking about a comment that violates ASN.1 per se, but rather 
something along the lines of the treatment of extensions in rfc2459:

4.1  Basic Certificate Fields

(...)
         extensions      [3]  EXPLICIT Extensions OPTIONAL
                              -- If present, version shall be v3
(...)

    Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

    Extension  ::=  SEQUENCE  {
         extnID      OBJECT IDENTIFIER,
         critical    BOOLEAN DEFAULT FALSE,
         extnValue   OCTET STRING  }

(...)

4.2  Standard Certificate Extensions

(...)
    Each extension includes an OID and an ASN.1 structure (...) Only
    one instance of a particular extension may appear in a particular
    certificate. For example, a certificate may contain only one authority
    key identifier extension (...)

I was thinking that a similar restriction might make sense for most (maybe 
all?) of the registration info and controls.

::Ari