[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Summary RE: Last Call: Qualified Certificates
I try to summarize the issues and their resolution to see if we all can
live with this. I exclude the typo remarks.
Issue 1: use of term "Private extensions"
Resolution: We will change and just talk about extensions
Issue 2: Exclude ASN.1 other than ASN.1 in 1988 syntax.
Resolution: We will keep the 1997 syntax as informative, as approved by
Russ.
Issue 3: New section stating changes from RFC 3039
Resolution: Section will be added
Issue 4: Defining granularity of Date of birth
Resolution: We conclude that the best solution would have been if we
just defined a raw text format from the beginning, independent of
GenerelizedTime. That is to late now though, since this attribute
already in use. The problem is that display of a date specified in this
format may be changed to another date due to adjustments for timezones.
The only time that will cause the same date display regardless of
timezone is 12.00.00 GMT. We will therefore recommend the time to be set
to 12.00.00 including second. We also recommend that clients parsing
this attribute should ignore any time data and display just the date
without any adjustment for local time zone.
Issue 5: countryOfResidence and countryOfCitizenship. Multi valued
attributes or Multipple occurance of single valued attributes or
requirement to include just 1 value in a certificate.
Resolution: We don't want to restrict to 1 country value for any of
these attributes. Neither do we want to forbid any variant to include
multiple countries. We do however want to RECOMMEND attribute values to
be repeated as multiple occurrences of single valued attributes, if more
than one value is to be included.
Issue 6: What is hashed in a graphic picture of biometric info?
Resolution: The whole file should be hashed. We will use the same
wording as the new logotype RFC but we will not enhance or change the
ASN.1 structure since this extension is being deployed.
Issue 7: Updating the qcStatement-1 for the new RFC
Resolution: Yes we should define a new OID for compliance with V2 of
this standard, which then also will help indicate the updated/clarified
semantics of the subject Directory attributes.
Issue 8: Optional absence of statementInfo of qcStatament for the
predefined statement
Resolution: We think this is syntactically defined in 3.2.5 but we are
willing to add a clarifying sentence in 3.2.5.1 as well.
Issue 9: Changing the pretty name of the ASN.1 module.
Resolution: We want to follow the praxis of other RFC:s in this area and
keep the name with a new OID. Why wouldn't that work for this standard
when it works for RFC 3280?
I hope this is OK for everyone
If so we will issue a new draft with these changes ASAP.
/Stefan
>
> 3. New section 1.1 is required to be added stating the differences
> between this document and 3039
>
> 4. Section 2, para 2:
> The text "where the certificate meet some qualification
> requirements" should be imported to either "certificates meet" or
> "certificate meets"
>
> 5. Section 2, bullet item 3: Suggest new text of
> "- Definition of usage for the key usage extension in Qualified
> Certificates.."
>
> 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?
>
> 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.)
>
> 8. Section 3.2.4 - This is something that I have no experence with.
If
> you look at a jpeg, bitmap or other type if image, who defines what is
> considred to be a label and what is considered to be the image data?
> What is done in this case about different sized images?
>
> 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?
>
> 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.
>
> 11. Sectin A.1 - I suggest changing the pretty name to
> PKIXqualified88-03 to distinquish from rfc3039.
>
>
>
> jim
>