Subject: RE: Last Call: Qualified Certificates

From: "Nystrom, Magnus" <[email-masked]>
Date: Wed, 17 Dec 2003 10:19:24 +0100 (W. Europe Standard Time)

Jim,

Thanks for your review. I'll respond to a few of your comments here.
Stefan will address the others.

On November 12, Jim Schaad wrote:

> Comments on this draft are as follows:
>
> 1.  Section 1 para 3;  I object to the phrase "private extensions".
> This document does not defined private extensions even if they exist in
> the id-pe arc.  These are now public extensions. -- Remove the word
> private.

No, we are using the branch id-pe which specifically is named "arc for
private certificate extensions" in RFC 3280. As I see it, private/public
refers to presence in X.509 or not. C.f. section 4.2.2 of RFC 3280,
whose title even is "Private Internet Extensions" (although the TOC in
RFC 3280 lists another name).

> 2.  Section 1 para 3: Remove all references to 1993 ASN.1

Russ has approved to keeping it (but, as we already do, keep the 1988
syntax normative). It will be 1997 ASN.1 syntax, BTW.

> 6.  Section 3.2.1 - DateOfBirth SHOULD state the proper encoding to be
> used.  I.E. are we looking for seconds, minutes or hours or just DATE in
> the GeneralTime field?

I don't see a need to do this for interoperability reasons. The
GeneralizedTime ASN.1 type will always contain a date, and optionally
a time down to a precision as specified in ISO 8601. Relying parties
will need to parse the type anyway. Some registration authorities may
decide to use a more precise measurement than others and I would not
want to preclude them from doing so.

> 7.  Section 3.2.1 - countryOfResidence and countryOfCitizenship - If you
> have multiple countrys to be listed, should this be a multi-value item
> or should there be two distinct attributes? (Alternatively should this
> be restricted back to a single attribute with a single value - i.e you
> can only list one of your countries of citizenship.)

The attributes (seen as ASN.1 objects) themselves are
multi-valued. This follows from PKCS #9 v2.0 where they are fully
defined and we have a reference to PKCS #9 in the document about
this. But this still allows several distinct attributes each with a
single (or multiple) value (values). As the extension itself only is
intended to carry information from a directory about the subject of
the certificate and does not disallow multiple instances of the same
attribute type it is really up to the issuer and the way it stores
information about the subject to populate it. A conformant relying
party that relies on information provided in this extension will need
to parse the complete extension value anyway, so again I am not sure
anything needs to be done.

> 9.  Section 3.2.5.1 - I would like to know the reason that qcstatement-1
> has not been updated to a new OID.  This is a new draft document with
> some different semantics than 3039.  Are these changes all suffiently
> small that a new policy is not needed?

Thanks, we have discussed this and intend to assign a new OID.

> 10. Sectin 3.2.5.1 - I have decided to put the predefined statement into
> my QC.  After reading this document I understand that what I want
> stearts as follows:
>
> 	EXTENSION { id-pe-qcStatements,
> 			{ id-qcs-pkixQCSyntax-v1, {ABSENT, ? }}
> In this case I don't have asemanticsIdentifier created by the document,
> so I must be incoluding the NameRegistrationAuthorities otion.  However
> I don't know if what goes here is the pkix working group name or some
> other value.

I am not sure I understand your question Jim, but values for the
nameRegistrationAuthorities component has nothing to do with PKIX. It is
the OID for the authority responsible for the subject's name (or
attributes of the subject's name) as it appears in the certificate. I
thought this was clear from 3.2.5.1?  Likewise for the semanticsIdentifier
option - it is to be specified by/for that authority.

> 11.  Sectin A.1 - I suggest changing the pretty name to
> PKIXqualified88-03 to distinquish from rfc3039.

I don't quite see why? Normally you keep the module name but update
the number (OID), and there are some reasons for this
too. C.f. X.509's "AuthenticationFramework" module whose name has
remained the same even though the module OID has changed over the
years. I believe the same is true for "PKIX1Explicit88" too, for
example.

-- Magnus

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 17 Dec 2003 11:58:15 -0800

> -----Original Message-----
> 
> Thanks for your review. I'll respond to a few of your 
> comments here. Stefan will address the others.
> 
> > This document does not defined private extensions even if 
> they exist 
> > in the id-pe arc.  These are now public extensions. -- 
> Remove the word 
> > private.
> 
> No, we are using the branch id-pe which specifically is named 
> "arc for private certificate extensions" in RFC 3280. As I 
> see it, private/public refers to presence in X.509 or not. 
> C.f. section 4.2.2 of RFC 3280, whose title even is "Private 
> Internet Extensions" (although the TOC in RFC 3280 lists 
> another name).

I understand that it is under the private extensions arc.  I belive that
the way this arc was named is not clear.  IMHO by publishing this
extension in a public document for public consumption it no longer is a
private extension.  I see no advantage to having the word private in
this location.

> > used.  I.E. are we looking for seconds, minutes or hours or 
> just DATE 
> > in the GeneralTime field?
> 
> I don't see a need to do this for interoperability reasons. 
> The GeneralizedTime ASN.1 type will always contain a date, 
> and optionally a time down to a precision as specified in ISO 
> 8601. Relying parties will need to parse the type anyway. 
> Some registration authorities may decide to use a more 
> precise measurement than others and I would not want to 
> preclude them from doing so.

In order to do a DER encoding of a GeneralTime field, without other
restraints being placed on this field, I think (but have not verified)
that on ewould be required to specify the msecs thus leading to a date
such as 196012170000000000Z for the DOB.  Even cutting it off at the
same level as dates in RFC3280 is an improvement.

> 
> > 7.  Section 3.2.1 - countryOfResidence and 
> countryOfCitizenship - If 
> > you have multiple countrys to be listed, should this be a 
> multi-value 
> > item or should there be two distinct attributes? 
> (Alternatively should 
> > this be restricted back to a single attribute with a single value - 
> > i.e you can only list one of your countries of citizenship.)
> 
> multi-valued. This follows from PKCS #9 v2.0 where they are 
> fully defined and we have a reference to PKCS #9 in the 
> document about this. But this still allows several distinct 
> attributes each with a single (or multiple) value (values). 
> As the extension itself only is intended to carry information 
> from a directory about the subject of the certificate and 
> does not disallow multiple instances of the same attribute 
> type it is really up to the issuer and the way it stores 
> information about the subject to populate it. A conformant 
> relying party that relies on information provided in this 
> extension will need to parse the complete extension value 
> anyway, so again I am not sure anything needs to be done.

This makes my code harder to implement as a RP.  I now need to look for
both multiple values and multiple fields.  It is much simplier to only
need to look for one (probably from ease of programing it would be
multiple values).

> > 10. Sectin 3.2.5.1 - I have decided to put the predefined statement 
> > into my QC.  After reading this document I understand that 
> what I want 
> > stearts as follows:
> >
> > In this case I don't have asemanticsIdentifier created by the 
> > document, so I must be incoluding the NameRegistrationAuthorities 
> > otion.  However I don't know if what goes here is the pkix working 
> > group name or some other value.
> 
> I am not sure I understand your question Jim, but values for 
> the nameRegistrationAuthorities component has nothing to do 
> with PKIX. It is the OID for the authority responsible for 
> the subject's name (or attributes of the subject's name) as 
> it appears in the certificate. I thought this was clear from 
> 3.2.5.1?  Likewise for the semanticsIdentifier option - it is 
> to be specified by/for that authority.

LET ME QUOTE:

   --  This statement identifies conformance with syntax and
   --  semantics defined in this Qualified Certificate profile
   --  (Version 1). The SemanticsInformation may optionally contain
   --  additional semantics information as specified.

As I read this statement there should be an OID that identifies this
DOCUMENT as a name registration authority.  If I use the fields defined
by this document and use the defined OID in this document, then I need
to be able to correction encode this extension in my certificate without
reference to an external naming authority.  If this is not the case then
there is absolutely no reason to have section 3.1 or 3.2.1, 3.2.2, 3.2.3
or 3.2.4 as they are defining how these fields should be used.

I need a way to refer to this document as either the semanticsIdentifier
or the nameRegistrationAuthority.

> I don't quite see why? Normally you keep the module name but 
> update the number (OID), and there are some reasons for this 
> too. C.f. X.509's "AuthenticationFramework" module whose name 
> has remained the same even though the module OID has changed 
> over the years. I believe the same is true for 
> "PKIX1Explicit88" too, for example.
> 
> -- Magnus
> 

jim

---

From: "Nystrom, Magnus" <[email-masked]>
Date: Wed, 17 Dec 2003 23:06:06 +0100 (W. Europe Standard Time)

Jim,

Thanks for continuing the discussion... Some replies below.

On Wed, 17 Dec 2003, Jim Schaad wrote:

> > > This document does not defined private extensions even if they exist
> > > in the id-pe arc.  These are now public extensions. -- Remove the
> > > word private.
> >
> > private certificate extensions" in RFC 3280. As I see it,
> > private/public refers to presence in X.509 or not.  C.f. section 4.2.2
> > of RFC 3280, whose title even is "Private Internet Extensions"
> > (although the TOC in RFC 3280 lists another name).
>

Well, it is not important for me. I just wanted to follow the example set
by 2459/3280.

> > > 6.  Section 3.2.1 - DateOfBirth SHOULD state the proper encoding to
> > > be used.  I.E. are we looking for seconds, minutes or hours or just
> > > DATE in the GeneralTime field?
> >

No - ISO 8825-1 says that you can have any precision when DER-encoding
GeneralizedTime values, but seconds MUST be present (as must the "Z" for
UTC time). Trailing decimal zeros are always removed. I.e. an authority
which only uses dates will have values like:

19601217000000Z

Whereas an authority which does count seconds may have

19601217000022Z

But this would not be allowed:

19601217000022.0Z

Note that, in all cases, the string will consist of at least 15
characters. Any more than that an the authority uses fractional seconds
down to the precision allowed by ISO 8601. I still don't think this needs
to be specified further.

> > > 7.  Section 3.2.1 - countryOfResidence and countryOfCitizenship - If
> > > multi-value item or should there be two distinct attributes?
> > > (Alternatively should this be restricted back to a single attribute
> > > with a single value - i.e you can only list one of your countries of
> > > citizenship.)
> >
> > The attributes (seen as ASN.1 objects) themselves are multi-valued.
> > This follows from PKCS #9 v2.0 where they are fully defined and we
> > have a reference to PKCS #9 in the document about this. But this still
> > allows several distinct attributes each with a single (or multiple)
> > value (values).  As the extension itself only is intended to carry
> > information from a directory about the subject of the certificate and
> > does not disallow multiple instances of the same attribute type it is
> > really up to the issuer and the way it stores information about the
> > subject to populate it. A conformant relying party that relies on
> > information provided in this extension will need to parse the complete
> > extension value anyway, so again I am not sure anything needs to be
> > done.
>

Right, it is a little harder (but not particularly complex). On this one -
and also to answer Russ comment as to why I would like to allow both
variants - I am concerned about backwards-compatibility. 3039 has been out
for a couple of years now and both patterns may have been used.

> > > into my QC.  After reading this document I understand that what I
> > > want stearts as follows:
> > >
> DOCUMENT as a name registration authority.

No, that was not the intent - this document should not be a name
registration authority.

Note the syntax: A QCStatement is a SEQUENCE of a statementID component
(an OID) and an optional statementInfo. For the object qcStatement-1, the
statementInfo component is a value of type SemanticsInformation. The
semantics of qcStatement-1 is that the certificate has been issued in
conformance with syntax and semantics identified in this document. In the
case of qcStatement-1, the statementInfo component (which is of type
SemanticsInformation) "MAY contain a semantics identifier and MAY identify
one or more name registration authorities." ("MAY" since the components
are optional).

As stated in the document, the semanticsIdentifier component of a
SemanticsInformation value contains an OID which defines semantics for
certain attributes and names in basic certificate fields, and the
nameRegistrationAuthorities component contains the name of one or more
authorities responsible for the registration of attributes or names
associated with the subject and the association between such an authority
and present attributes MAY be defined by a semanticsIdentifier OID.

> If I use the fields defined by this document and use the defined OID in
> this document, then I need to be able to correction encode this
> extension in my certificate without reference to an external naming
> authority.  If this is not the case then there is absolutely no reason
> to have section 3.1 or 3.2.1, 3.2.2, 3.2.3 or 3.2.4 as they are defining
> how these fields should be used.
>

As I see it, you shouldn't. The statementInfo component is optional. If
all you want to say is that you're conformant with syntax and semantics of
this document then you set the statementID to id-qcs-pkixQCSyntax-v1 and
leave out the statementInfo component. If there is some well-known OID
that defines semantics for a set of attributes and/or names used then
include the statementInfo component, and set the semanticsIdentifier
component. If you just want to name a registration authority then include
the statementInfo component and set its nameRegistrationAuthority
component. If you want to associate a name a registration authority with
semantics for certain attributes then set both components of the
SemanticsInformation.

I have tried to capture our thinking above, but I may have missed
something as we wrote this almost four years ago. Stefan, feel free to
correct me if I got something wring.

Did this help at all, Jim?

-- Magnus

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 17 Dec 2003 17:30:58 -0700

> From: Nystrom, Magnus
> Sent: Wednesday, December 17, 2003 3:06 PM
>
> Jim Schaad wrote:
>
> > I understand that it is under the private
> > extensions arc.  I belive that the way this
> > arc was named is not clear.  IMHO by
> > publishing this extension in a public
> > document for public consumption it no longer
> > is a private extension.  I see no advantage
> > to having the word private in this location.
>
> Well, it is not important for me. I just wanted to
> follow the example set by 2459/3280.

Magnus, Jim:

FWIW and in the spirit of Last Call, I agree with Jim.  It seems
a rather innocuous point, but issues are made of such stuff.  As
I see it, this is the PKIX/IETF standard means of expressing
this information in an X.509-based certificate.  The fact that
its OID happens to be rooted off id-pe should not be taken as
invitation to revisit the addressed needs with a view towards a
"public" version.

Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 17 Dec 2003 20:17:28 -0800

Magnus,

Only one issue left....

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nystrom, Magnus
> 
> Jim,
> 
> comments here. 

> > > > 10. Sectin 3.2.5.1 - I have decided to put the predefined 
> > > > statement into my QC.  After reading this document I understand 
> > > > that what I want stearts as follows:
> > > >
> > > nameRegistrationAuthorities component has nothing to do 
> with PKIX. 
> > > It is the OID for the authority responsible for the 
> subject's name 
> > > (or attributes of the subject's name) as it appears in the 
> > > certificate. I thought this was clear from 3.2.5.1?  Likewise for 
> > > the semanticsIdentifier option - it is to be specified 
> by/for that 
> > > authority.
> >
> > LET ME QUOTE:
> >
> No, that was not the intent - this document should not be a 
> name registration authority.
> 
> Note the syntax: A QCStatement is a SEQUENCE of a statementID 
> component (an OID) and an optional statementInfo. For the 
> object qcStatement-1, the statementInfo component is a value 
> of type SemanticsInformation. The semantics of qcStatement-1 
> is that the certificate has been issued in conformance with 
> syntax and semantics identified in this document. In the case 
> of qcStatement-1, the statementInfo component (which is of type
> SemanticsInformation) "MAY contain a semantics identifier and 
> MAY identify one or more name registration authorities." 
> ("MAY" since the components are optional).
> 
> As stated in the document, the semanticsIdentifier component 
> of a SemanticsInformation value contains an OID which defines 
> semantics for certain attributes and names in basic 
> certificate fields, and the nameRegistrationAuthorities 
> component contains the name of one or more authorities 
> responsible for the registration of attributes or names 
> associated with the subject and the association between such 
> an authority and present attributes MAY be defined by a 
> semanticsIdentifier OID.
> 
> > If I use the fields defined by this document and use the 
> defined OID 
> > in this document, then I need to be able to correction encode this 
> > to have section 3.1 or 3.2.1, 3.2.2, 3.2.3 or 3.2.4 as they are 
> > defining how these fields should be used.
> >
> > I need a way to refer to this document as either the 
> > semanticsIdentifier or the nameRegistrationAuthority.
> 
> As I see it, you shouldn't. The statementInfo component is 
> optional. If all you want to say is that you're conformant 
> with syntax and semantics of this document then you set the 
> statementID to id-qcs-pkixQCSyntax-v1 and leave out the 
> statementInfo component. If there is some well-known OID that 
> defines semantics for a set of attributes and/or names used 
> then include the statementInfo component, and set the 
> semanticsIdentifier component. If you just want to name a 
> registration authority then include the statementInfo 
> component and set its nameRegistrationAuthority component. If 
> you want to associate a name a registration authority with 
> semantics for certain attributes then set both components of 
> the SemanticsInformation.
> 
> I have tried to capture our thinking above, but I may have 
> missed something as we wrote this almost four years ago. 
> Stefan, feel free to correct me if I got something wring.
> 

This does and does not help.  I can now understand how you think that I
should be encoding this extension.  However in reviewing the document I
do not see any statements about the fact that the presence of
QCStatements being optional.  This needs to be clarified in the
document.  The document does require that either statementInfo or
statementId be present within the QCStatement object however. Thus if
QCStatements is not OPTIONAL (my reading of your above statement) then a
statement as to how to encode as using the "conformance and semantics
defined in this document" needs to be made.

jim

---

From: "Nystrom, Magnus" <[email-masked]>
Date: Thu, 18 Dec 2003 09:32:37 +0100 (W. Europe Standard Time)

Jim,

Please find my reply below.

On Wed, 17 Dec 2003, Jim Schaad wrote:

> > > > > document, so I must be incoluding the
> > > > > NameRegistrationAuthorities otion.  However I don't know if what
> > > > > goes here is the pkix working group name or some other value.
> > > >
> > > > nameRegistrationAuthorities component has nothing to do with PKIX.
> > > > It is the OID for the authority responsible for the subject's name
> > > > the semanticsIdentifier option - it is to be specified by/for that
> > > > authority.
> > >
> > > LET ME QUOTE:
> > >
> > component (an OID) and an optional statementInfo. For the object
> > qcStatement-1, the statementInfo component is a value of type
> > SemanticsInformation. The semantics of qcStatement-1 is that the
> > certificate has been issued in conformance with syntax and semantics
> > identified in this document. In the case of qcStatement-1, the
> > statementInfo component (which is of type SemanticsInformation) "MAY
> > contain a semantics identifier and MAY identify one or more name
> > registration authorities."  ("MAY" since the components are optional).
> >
> > associated with the subject and the association between such an
> > authority and present attributes MAY be defined by a
> > semanticsIdentifier OID.
> >
> > > If I use the fields defined by this document and use the defined OID
> > > authority.  If this is not the case then there is absolutely no
> > > reason to have section 3.1 or 3.2.1, 3.2.2, 3.2.3 or 3.2.4 as they
> > > are defining how these fields should be used.
> > >
> document.

I think there is some confusion here. QCStatements is not optional. But
each QCStatement has the syntax

   QCStatement ::= SEQUENCE {
       statementId   QC-STATEMENT.&Id({SupportedStatements}),
       statementInfo QC-STATEMENT.&Type
       ({SupportedStatements}{@statementId}) OPTIONAL }

(or in older syntax:

QCStatement ::= SEQUENCE {
    statementId        OBJECT IDENTIFIER,
    statementInfo      ANY DEFINED BY statementId OPTIONAL}
)

I.e. the statementInfo component of each QCStatement value is OPTIONAL.
So, if you use this extension, you can have a QCStatement with the
statementId value set to the statement OID defined in the document, but
you don't need to have a statementInfo component present.

> The document does require that either statementInfo or statementId be
> present within the QCStatement object however.

(QCStatement is a type, not an object)

No, it requires that either the semanticsIdentifier or the
nameRegistrationAuthorities components (or both) be present in a value of
type SemanticsInformation which is the syntax for the qcStatement-1
object. This should not be confused with the QCStatement type. If the
statementId component of a QCStatement value has the value
id-qcs-pkixQCSyntax-v1 then the statementInfo component is still optional,
but if present it must have the syntax SemanticsInformation for which it
holds that at least one of its components must be present.

> Thus if QCStatements is not OPTIONAL (my reading of your above
> statement) then a statement as to how to encode as using the
> "conformance and semantics defined in this document" needs to be made.

QCStatements is not OPTIONAL, but you don't need to populate individual
QCStatement's statementInfo components, as described above.

-- Magnus

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 18 Dec 2003 00:47:59 -0800

Magnus,

This being the case, please add a textual statement that for
qcStatement-1, the parameters SemanticsInformation is optional.

jim

> From: Nystrom, Magnus [mailto:[email-masked]] 
> Sent: Thursday, December 18, 2003 12:33 AM
> To: [email-masked]
> Cc: [email-masked]; 'Stefan Santesson'
> Subject: RE: Last Call: Qualified Certificates
> 
> 
> Jim,
> 
> comments 
> > > > > here.
> > > > > > statement into my QC.  After reading this document I 
> > > > > > understand that what I want stearts as follows:
> > > > > >
> > > > > > NameRegistrationAuthorities otion.  However I don't know if 
> > > > > > what goes here is the pkix working group name or some other 
> > > > > > value.
> > > > >
> > > > > nameRegistrationAuthorities component has nothing to do with 
> > > > > PKIX. It is the OID for the authority responsible for the 
> > > > > subject's name (or attributes of the subject's name) as it 
> > > > > appears in the certificate. I thought this was clear from 
> > > > > 3.2.5.1?  Likewise for the semanticsIdentifier option 
> - it is to 
> > > > > be specified by/for that authority.
> > > >
> > > > LET ME QUOTE:
> > > >
> > > > As I read this statement there should be an OID that identifies 
> > > > this DOCUMENT as a name registration authority.
> > >
> > > SemanticsInformation value contains an OID which defines 
> semantics 
> > > for certain attributes and names in basic certificate fields, and 
> > > the nameRegistrationAuthorities component contains the 
> name of one 
> > > or more authorities responsible for the registration of 
> attributes 
> > > or names associated with the subject and the association between 
> > > such an authority and present attributes MAY be defined by a 
> > > semanticsIdentifier OID.
> > >
> > > > If I use the fields defined by this document and use 
> the defined 
> > > > OID in this document, then I need to be able to 
> correction encode 
> > > > this extension in my certificate without reference to 
> an external 
> > > > naming authority.  If this is not the case then there is 
> > > > absolutely no reason to have section 3.1 or 3.2.1, 
> 3.2.2, 3.2.3 or 
> > > > 3.2.4 as they are defining how these fields should be used.
> > > >
> > > As I see it, you shouldn't. The statementInfo component 
> is optional. 
> > > If all you want to say is that you're conformant with syntax and 
> > > semantics of this document then you set the statementID to 
> > > id-qcs-pkixQCSyntax-v1 and leave out the statementInfo 
> component. If 
> > > there is some well-known OID that defines semantics for a set of 
> > > attributes and/or names used then include the statementInfo 
> > > component, and set the semanticsIdentifier component. If you just 
> > > want to name a registration authority then include the 
> statementInfo
> > > something as we wrote this almost four years ago. Stefan, 
> feel free 
> > > to correct me if I got something wring.
> > >
> > This does and does not help.  I can now understand how you 
> think that 
> > I should be encoding this extension.  However in reviewing the 
> > document I do not see any statements about the fact that 
> the presence 
> > of QCStatements being optional.  This needs to be clarified in the 
> > document.
> 
> I think there is some confusion here. QCStatements is not 
> optional. But each QCStatement has the syntax
> 
> I.e. the statementInfo component of each QCStatement value is 
> OPTIONAL. So, if you use this extension, you can have a 
> QCStatement with the statementId value set to the statement 
> OID defined in the document, but you don't need to have a 
> statementInfo component present.
> 
> nameRegistrationAuthorities components (or both) be present 
> in a value of type SemanticsInformation which is the syntax 
> for the qcStatement-1 object. This should not be confused 
> with the QCStatement type. If the statementId component of a 
> QCStatement value has the value id-qcs-pkixQCSyntax-v1 then 
> the statementInfo component is still optional, but if present 
> it must have the syntax SemanticsInformation for which it 
> QCStatements is not OPTIONAL, but you don't need to populate 
> individual QCStatement's statementInfo components, as described above.
> 
> -- Magnus
>

---

From: "Nystrom, Magnus" <[email-masked]>
Date: Thu, 18 Dec 2003 09:51:10 +0100 (W. Europe Standard Time)

Jim,

The QCStatement.statementInfo component is optional for any and all
statements. It is not specific for qcStatement-1, it is governed by the
Type definition for QCStatement. Quoting from the text describing the
QCStatement type: "Each statement SHALL include an object identifier for
the statement and MAY also include optional qualifying data contained in
the statementInfo parameter." Adding a special statement for qcStatement-1
would be confusing, IMO.

-- Magnus

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 18 Dec 2003 13:19:10 -0800

Magnus,

My default assumption is that if you define a statementId and an
assoicated statementInfo, the statementInfo must be present for that
statementId unless otherwise documented in the definition of the
statementId.  The text you cite below allows me to create a statementId
and either define the statementInfo as absent or optional.

jim

> Sent: Thursday, December 18, 2003 12:51 AM
> To: [email-masked]
> The QCStatement.statementInfo component is optional for any 
> and all statements. It is not specific for qcStatement-1, it 
> is governed by the Type definition for QCStatement. Quoting 
> from the text describing the QCStatement type: "Each 
> statement SHALL include an object identifier for the 
> statement and MAY also include optional qualifying data 
> contained in the statementInfo parameter." Adding a special 
> statement for qcStatement-1 would be confusing, IMO.
> 
> -- Magnus
> 
> > > > > > > > NameRegistrationAuthorities otion.  However I 
> don't know 
> > > > > > > > if what goes here is the pkix working group 
> name or some 
> > > > > > > > other value.
> > > > > > >
> > > > > > As I read this statement there should be an OID that 
> > > > > > identifies this DOCUMENT as a name registration authority.
> > > > >
> > > > > As stated in the document, the semanticsIdentifier 
> component of 
> > > > > a SemanticsInformation value contains an OID which defines
> > > semantics
> > > > > for certain attributes and names in basic certificate fields, 
> > > > > and the nameRegistrationAuthorities component contains the
> > > name of one
> > > > > component, and set the semanticsIdentifier component. If you 
> > > > > just want to name a registration authority then include the
> > > statementInfo
> > > > > missed something as we wrote this almost four years 
> ago. Stefan,
> > > feel free
> QCStatement 
> > > with the statementId value set to the statement OID 
> defined in the 
> > > document, but you don't need to have a statementInfo component 
> > > present.
> > >
> > > nameRegistrationAuthorities components (or both) be present in a 
> > > value of type SemanticsInformation which is the syntax for the 
> > > qcStatement-1 object. This should not be confused with the 
> > > QCStatement type. If the statementId component of a QCStatement 
> > > value has the value id-qcs-pkixQCSyntax-v1 then the statementInfo 
> > > component is still optional, but if present it must have 
> the syntax 
> > > SemanticsInformation for which it holds that at least one of its 
> > > components must be present.
> > >