Subject: CRMF/CMP question

From: Ari Kermaier <[email-masked]>
Date: Tue, 02 Jan 2001 18:59:43 -0500

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 }

In such a field, is it permissible for more than one AttributeTypeAndValue 
having the same type OID to be present?

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?

Ari Kermaier
Phaos Technology

---

From: "Kwon, YongChul" <[email-masked]>
Date: Wed, 3 Jan 2001 09:02:07 +0900

Hi.

> having the same type OID to be present?

	I think SEQUENCE OF implicitly requires no duplicated
	occurrence of same oid.

	If it permits, then I think that it should be SET OF.

	Same concept applied to the X.509 Extension and X.500 Name
	structure.

---

From: Ari Kermaier <[email-masked]>
Date: Tue, 02 Jan 2001 19:17:43 -0500

>         Same concept applied to the X.509 Extension and X.500 Name

I'm pretty sure the ASN.1 notation "SEQUENCE OF" implies no requirements 
concerning duplicate elements. Also, for purposes of CMP, using "SET OF" 
would be problematic because the order of elements must be determinable in 
order to verify signatures and MACs.

---

From: "Kwon, YongChul" <[email-masked]>
Date: Wed, 3 Jan 2001 09:43:51 +0900

> I'm pretty sure the ASN.1 notation "SEQUENCE OF" implies no 

	yes. you're right. I mean that I think the concept of X.509 Extension
	structure would be applied. sorry for ambiguous expression. :-)

> order to verify signatures and MACs.

	it's true.

	but in this case, RFC-2511 and it's son defines 2 possiblities
	- one is utf8Pairs and CertReq.

	in case of utf8Pairs, I think the informations should not be 
	spread to 2 or more regInfo-utf8Pairs(because utf8Pairs already
	express all informations in one reginfo) - same as IssureAltNames. 
	so I think it can't be a problem.

	then let's think about the CertRequest conveyed in regInfo.
	yes... I agree with you. I think It could be a problem.

	RFC-2511bis said

   Information directly related to certificate content SHOULD be
   included in the certReq content.  However, inclusion of additional
   certReq content by RAs may invalidate the pop field.  Data therefore
   intended for certificate content MAY be provided in regInfo.

	Hmm... it sounds the case when RAVerified POP used, right?
	at that time, RFC-2510(Appendix B4) requires 1-2 CertReqMessages 
	in CertReqMessages. and if 2 requests exists, the second one
	have no proof of possession so in this case, the CertRequest
	in regInfo implies the first one - POP invalidated by RA.
	
	Hmm.. so I think it's not a problem neither.

	I can't be quite sure. but What do you think about my opinion?
	If there are any missing points, please let me know them.

---

From: Ari Kermaier <[email-masked]>
Date: Tue, 02 Jan 2001 21:07:43 -0500

>         - one is utf8Pairs and CertReq.

Does this mean that other AttributeTypeAndValue pairs (i.e., ones not 
specified in rfc2511 as registration controls) are prohibited? I assumed 
not, though I could be wrong.

>         so I think it can't be a problem.

UTF8Pairs is different, because a method is specified for concatenating 
multiple UTF8String values for the one OID. The same cannot be said for 
AttributeTypeAndValue in general.

As far as IssuerAltName goes, the syntax is a SEQUENCE of GeneralName, 
where one of the choices is otherName which is defined as a sequence of OID 
and value (similar to AttributeTypeAndValue). The description for 
SubjectAltName (draft-ietf-pkix-new-part1-03) explicitly allows multiple 
GeneralName entries of the same name form; presumably this includes 
multiple otherName instances with the same OIDs. These semantics make sense 
in the context of a sequence of GeneralName, but not necessarily for 
AttributeTypeAndValue in general. Witness son-of-rfc2459's explicit 
instruction that "Only one instance of a particular extension may appear in 
a particular certificate"; but no similar language appears in rfc2510bis or 
rfc2511bis.)

>         yes... I agree with you. I think It could be a problem.

There's a lot more to this question than regInfo. For example, registration 
Controls (in CRMF CertRequest) includes such defined types as 
id-regCtrl-oldCertID and id-regCtrl-pkiPublicationInfo. For oldCertID, 
clearly it makes no sense to have more than one such control in a singe 
CertRequest, but nothing in the spec prohibits it or says what to do if you 
encounter such a situation (e.g, take the first one, or the last one, or 
ignore both, or reject the whole thing). For pkiPublicationInfo, there is 
no logical contradiction in having more than one such control, but the 
syntax for the control explicitly provides a mechanism to include multiple 
pubInfos in a single control. This would seem to imply that multiple 
controls with the same OID are discouraged. But are they illegal?

Other places where this question arises incude, in CMP (rfc2510bis): 
PKIHeader.generalInfo (section 3.1.1), the GenMsgContent PKIBody type 
(3.3.19) and GenRepContent (3.3.20).

---

From: "Kwon, YongChul" <[email-masked]>
Date: Wed, 3 Jan 2001 11:23:54 +0900

> a particular certificate"; but no similar language appears in 
> rfc2510bis or rfc2511bis.)

	you're right. :-)
 
> (3.3.19) and GenRepContent (3.3.20).

	I agree. yeah, they're not illegal. but, I think
	if a control(or extension) structure can include all related 
	informations, then that informations should exist in one 
	control(extension).

	It makes things more clearer and better, doesn't it? :-)
	and it is a kind of canonicalization.

	What I exampled - IssureAltName was not good example. :-(
	What I said was that it could be ... not about the clearity of
	RFC and draft. at this point I missed the track.

	I agree with you. RFC-2511 and bis and RFC-2510 will be better
	if they have verbose comments(that's what I always want!)