Subject: Re: [pkix] 2560bis draft 12 posted

From: Johannes Merkle <[email-masked]>
Date: Mon, 04 Feb 2013 18:07:22 +0100

> The French legislation you quoted earlier is clearly not a problem here, as I pointed out before (Nov 8 & 9). What other
> regulations do you have in mind? To be able to asses this we need to look at the letter of the law. In my recollection,
> the German law is not worded in such a way to prevent this either (indeed, I believe that text we are writing makes a
> good foundation for solving some of the requirements the German law does have).
>  

You can safely disregard the German electronic signature legislation in your discussion on how  to deal with requests
for non-issued certificates. In the context of qualified certificates, German regulation (de-facto) requires to return
status "unknown" in this case and the implemented basis (in the niche market for qualified certificates) is so strongly
established that any new approach (e.g. revoked" with reason code "onhold") is unlikely to be supported.

-- 
Johannes

---

From: [email-masked] (Martin Rex)
Date: Tue, 5 Feb 2013 02:20:43 +0100 (CET)

Johannes Merkle wrote:
> 
> > The French legislation you quoted earlier is clearly not a
> > problem here, as I pointed out before (Nov 8 & 9). What other
> > regulations do you have in mind? To be able to asses this we
> > need to look at the letter of the law. In my recollection,
> > the German law is not worded in such a way to prevent this
> > either (indeed, I believe that text we are writing makes a
> You can safely disregard the German electronic signature legislation
> in your discussion on how  to deal with requests for non-issued
> certificates. In the context of qualified certificates, German
> regulation (de-facto) requires to return status "unknown" in this
> case and the implemented basis (in the niche market for qualified
> certificates) is so strongly established that any new approach
> (e.g. revoked" with reason code "onhold") is unlikely to be supported.

What the installed base does, what implementations understand,
and what other responses will not have the detrimental effect
of certs getting inappropriately accepted, are all seperate things.

Could you please point me to the particular German regulation documents
that you believe would be incompatible with the 2560bis change in that
things would no longer work?

-Martin

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 05 Feb 2013 13:21:57 +0100

> of certs getting inappropriately accepted, are all seperate things.

This is actually a closed world governed by its own rules: According to the electronic signature act §17 (4), for all
OCSP responders and client software used to verify qualified certificates, compliance with the requirements of the act
must either be confirmed by an authorized body or be formally declared by the manufacturer. The supervising authority
maintains a list of products (incl. OCSP responders and client software) for which such a confirmation or declaration
has been filed:
http://www.bundesnetzagentur.de/cln_1931/EN/Areas/ElectronicSignature/Publications/Products/Products_node.html

By virtue of the requirement to use only software conforming to the electronic signature act, OCSP clients and
responders exhibit a specific behavior that ensures that they can inter-operate with each other although this behavior
may go beyond (but does not violate) RFC 2560.

> things would no longer work?

I didn't mean to claim any incompatibility of German regulation with RFC 2560bis. I only wanted to convey that German
regulation has developed other means to deal with non-issued certificates, precisely, to return status "unknown", and
this makes adoption of the RFC 2560bis approach unlikely. However, as far as I have understood RFC 2560bis the German
solution (status unknown) is not prohibited by RFC 2560bis, and vice-versa, the RFC 2560bis approach does not contradict
German regulation nor does it result in undesired results with German OCSP clients.

Now for the specific requirements: First of all, I wrote "de-facto", which means that there is no clear written
requirement. But in practice, bodies confirming conformance of OCSP responders to the electronic signature act as well
as the supervising authority will not accept an OCSP responder software returning "good" for non-issued certificates.
The reason is that §15 (3) of the electronic signature ordinance requires certificate validation services to assert not
only the revocation status of the certificate but also its existence in the CA database. As a consequence, compliant
OCSP responders must base their assertions not on a CRL but on the (replicated) CA database, hence, the the status
"unknown" can be safely used to assert non-issuance of a certificate. I say "safely" because OCSP clients to be used
with qualified certificates in Germany originate from the same closed world and have, thus, been developed based on the
same requirements and assumptions.

BTW: Another special feature of OCSP responders for which compliance with the signature act has been declared or
confirmed is that they will actually attest the existence of "good" certificates by an extension CertHash specified in
the Common PKI standard (http://www.t7ev.org/en/common-pki.html). This standard specifically targets compliance with the
German electronic signature act (part 9 defines a specific profile for this) and has been widely adopted by applications
(also clients) claiming conformance with the regulation.

It is important to note, that in the "German world", the OCSP-responders obtain their certificates not from the
corresponding CA but from the CA super-ordinated to that - with the only exception being the root CA. Thus, compromise
of a 2nd level CA does not compromise its OCSP responder and, hence, clients can still trust the assertions of the OCSP
responder. This was designed to circumvent the trust model problems pointed out by Piyush of authorized responders also
asserting issuance or non-issuance of certificates.

-- 
Johannes

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 07 Feb 2013 15:54:39 +0100

Thanks for the explanations Johannes.

As far as I can tell there is not contradiction between RFC2560bis and the
german law, not even implementation of the "renoked" option and the new
extension, even though it may not happen i practice for reason you
explained.

/Stefan

On 2/5/13 1:21 PM, "Johannes Merkle" <[email-masked]> wrote:

>This is actually a closed world governed by its own rules: According to
>the electronic signature act §17 (4), for all
>OCSP responders and client software used to verify qualified
>certificates, compliance with the requirements of the act
>must either be confirmed by an authorized body or be formally declared by
>the manufacturer. The supervising authority
>maintains a list of products (incl. OCSP responders and client software)
>for which such a confirmation or declaration
>has been filed:
>By virtue of the requirement to use only software conforming to the
>electronic signature act, OCSP clients and
>responders exhibit a specific behavior that ensures that they can
>inter-operate with each other although this behavior
>I didn't mean to claim any incompatibility of German regulation with RFC
>2560bis. I only wanted to convey that German
>regulation has developed other means to deal with non-issued
>certificates, precisely, to return status "unknown", and
>this makes adoption of the RFC 2560bis approach unlikely. However, as far
>as I have understood RFC 2560bis the German
>solution (status unknown) is not prohibited by RFC 2560bis, and
>vice-versa, the RFC 2560bis approach does not contradict
>Now for the specific requirements: First of all, I wrote "de-facto",
>which means that there is no clear written
>requirement. But in practice, bodies confirming conformance of OCSP
>responders to the electronic signature act as well
>as the supervising authority will not accept an OCSP responder software
>returning "good" for non-issued certificates.
>The reason is that §15 (3) of the electronic signature ordinance requires
>certificate validation services to assert not
>only the revocation status of the certificate but also its existence in
>the CA database. As a consequence, compliant
>OCSP responders must base their assertions not on a CRL but on the
>(replicated) CA database, hence, the the status
>"unknown" can be safely used to assert non-issuance of a certificate. I
>say "safely" because OCSP clients to be used
>with qualified certificates in Germany originate from the same closed
>world and have, thus, been developed based on the
>confirmed is that they will actually attest the existence of "good"
>certificates by an extension CertHash specified in
>the Common PKI standard (http://www.t7ev.org/en/common-pki.html). This
>standard specifically targets compliance with the
>German electronic signature act (part 9 defines a specific profile for
>this) and has been widely adopted by applications
>corresponding CA but from the CA super-ordinated to that - with the only
>exception being the root CA. Thus, compromise
>of a 2nd level CA does not compromise its OCSP responder and, hence,
>clients can still trust the assertions of the OCSP
>responder. This was designed to circumvent the trust model problems
>pointed out by Piyush of authorized responders also
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 12 Feb 2013 13:15:14 +0100

I hav submitted a new draft as an individual submission:

http://www.ietf.org/id/draft-santesson-auth-context-extension-00.txt

Abstract

   This document defines an extension to certificates according to
   [RFC5280]. The extension defined in this document holds data about
   how the certificate subject was authenticated by the Certification
   Authority who issued the certificate where this extension appears.

   This document also defines one data structure for inclusion in this
   extension that designed to hold information when the subject is
   authenticated using a SAML assertion [SAML].

This draft documents an extension that we have defined in the Swedish
national electronic identification infrastructure in order to be able to
match SAML credentials with associated electronic signatures.
All signature certificates are issued by a central signature generation
service which authenticates the user using SAML credentials and then adds
this extension to the certificate.

This makes it possible for service providers to compare the signer of a
document with the entity currently logged into the service using SAML.

I would have loved for this to be part of the PKIX process, but as we are
not allowed to take on any further work, I let this do as an individual
submission.

Currently the draft is based on the Swedish defined OIDs.

There is still a short window before we need to lock this specification in
the Swedish project, but I'm very interested in review from members of
this group.
The intention is currently to go Informational, in order to just provide a
stable reference to this extension definition.
Should there be an interest in moving this to standards track, then I
would not object to doing so.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 13 Feb 2013 09:02:06 +0100

I was made aware that the document link no longer works:

Here is a link to the latest current draft:
http://tools.ietf.org/html/draft-santesson-auth-context-extension

Thanks to Jim for checking nits and the ASN.1 modules!

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 21 Feb 2013 22:48:05 +0100

I have updated this draft with a full certificate example. And fixed some
nits.
If time permits I will make a short presentation of this in Orlando.

I have received some private reviews. I'm really grateful for that.
More thoughts and reviews would be much appreciated.

Thanks

/Stefan

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 25 Feb 2013 13:40:31 +1100

Stefan,

I shouldn't comment on draft-santesson-auth-context-extension as I have no background as to what it is all about, but I am interested in encoding certificates.

The AuthenticationContexts certificate extension has a strange mix of DER, JSON, XML, and text. It seems to combine all the worst examples of how to embed stuff in ASN.1 into one field.

The contextInfo field is defined an as OCTET STRING. When the optional mimeType field is absent the OCTET STRING holds a DER-encoding. This looks like extnValue OCTET STRING in an Extension. Presumably the contextType value is supposed to identify the ASN.1 type of the embedded value (like extnId). However this isn't explicitly stated; there is no corresponding object class (equivalent to EXTENSION); there is no "(CONTAINING ... ENCODED BY der)" constraint in the ASN.1.

When the mimeType field is present, it defines the format of the contextInfo value. If the format is UTF-8-encoded text, the UTF-8 appears directly in the contextInfo OCTET STRING, not inside, say, a UTF8String.

So contextInfo sometimes holds a DER-encoding, and at other times hold raw bytes of some other format. Perhaps a close analogy is the subjectPublicKey BIT STRING that sometimes holds DER (eg SEQUENCE of modulus and public exponent for an RSA key) and sometime raw bytes (eg for an elliptic curve public key). subjectPublicKey is not a good example to repeat.

To include XML values (SAML) in an ASN.1 value (Certificate) a third syntax is introduced: JSON. Does an app using the JSON really not need to also process the ASN.1 certificate fields so it can get away with only understanding "easy JSON"?

certRef is supposed to reference a value in the cert. When a value is in the subject field an attribute type is provided (eg "2.5.4.5" for serialNumber). However, there can be multiple serialNumber attributes in a DN (eg serialNumber holding an org number, then a serialNumber in a lower RDN holding a staff id).

The example for authenticationInstant is "Feb 12, 2013 12:34:47 AM". Surely we should use a better date format for new specs. For instance, "2013-02-12T00:34:47Z".

mimeType is a PrintableString. Can't we just use UTF8String for everything new?

Object identifier are encoded in 3 different ways is this one extension: DER-encoding (eg 06 03 550405); dotted-decimal notation (eg "2.5.4.5"); and as a URI (eg "urn:oid:2.5.4.5"). Perhaps that is "necessary", but it is unfortunate.

The spec says applications MUST ignore any authentication context types they do not understand. What if the extension is marked critical? Surely you MUST understand at least 1 AuthenticationContext in that case? 

Wouldn't you be better off specifying:
  samlAuthContextinJSON EXTENSION ::= {
    SYNTAX UTF8String
    IDENTIFIED BY {iso(1) member-body(2) se(752) e-legnamnden(201) 5 1} }

--
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stefan Santesson
> Sent: Friday, 22 February 2013 8:48 AM
> To: Stefan Santesson; [email-masked]
> Subject: Re: [pkix] AuthContext Certificate extension
> 
> I have updated this draft with a full certificate example. And fixed
> some nits.
> >>national electronic identification infrastructure in order to be able
> >>to match SAML credentials with associated electronic signatures.
> >>All signature certificates are issued by a central signature
> >>generation service which authenticates the user using SAML
> credentials
> >>and then adds this extension to the certificate.
> >>
> >>This makes it possible for service providers to compare the signer of
> >>a document with the entity currently logged into the service using
> SAML.
> >>
> >>I would have loved for this to be part of the PKIX process, but as we
> >>are not allowed to take on any further work, I let this do as an
> >>individual submission.
> >>
> >>There is still a short window before we need to lock this
> >>specification in the Swedish project, but I'm very interested in
> >>review from members of this group.
> >>The intention is currently to go Informational, in order to just
> >>provide a stable reference to this extension definition.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 25 Feb 2013 23:58:27 +0100

Hi James,

Thanks for the review.
Some comments below.

On 2/25/13 3:40 AM, "Manger, James H" <[email-masked]>
wrote:

>Stefan,
>
>I shouldn't comment on draft-santesson-auth-context-extension as I have
>no background as to what it is all about, but I am interested in encoding
>certificates.
>
>The AuthenticationContexts certificate extension has a strange mix of
>DER, JSON, XML, and text. It seems to combine all the worst examples of
>how to embed stuff in ASN.1 into one field.

Worst in what sense? It works perfectly.

>
>The contextInfo field is defined an as OCTET STRING. When the optional
>mimeType field is absent the OCTET STRING holds a DER-encoding. This
>looks like extnValue OCTET STRING in an Extension. Presumably the
>contextType value is supposed to identify the ASN.1 type of the embedded
>value (like extnId). However this isn't explicitly stated; there is no
>corresponding object class (equivalent to EXTENSION); there is no
>"(CONTAINING ... ENCODED BY der)" constraint in the ASN.1.

The definition is perfectly clear. The mime type specifies the data format
and the OID defines what the actual content is.
>From the context of an ASN.1 parser, this is just bytes to be handed to an
upper application layer.

>
>When the mimeType field is present, it defines the format of the
>contextInfo value. If the format is UTF-8-encoded text, the UTF-8 appears
>directly in the contextInfo OCTET STRING, not inside, say, a UTF8String.

Bytes is the most generic format. Conversion from byte to other formats is
straightforward given that you know the data format given  by the MimeType.

>
>So contextInfo sometimes holds a DER-encoding, and at other times hold
>raw bytes of some other format. Perhaps a close analogy is the
>subjectPublicKey BIT STRING that sometimes holds DER (eg SEQUENCE of
>modulus and public exponent for an RSA key) and sometime raw bytes (eg
>for an elliptic curve public key). subjectPublicKey is not a good example
>to repeat.

Why not?
Its perfectly predictable and well defined, and provide exactly the degree
of flexibility that is desired.

>
>
>To include XML values (SAML) in an ASN.1 value (Certificate) a third
>syntax is introduced: JSON. Does an app using the JSON really not need to
>also process the ASN.1 certificate fields so it can get away with only
>understanding "easy JSON"?

Exactly. The application receiving the bytes does not need to understand
any ASN.1 at all.
Since the context of that application in the defined context info is
dealing with SAML assertions, ASN.1 is not a good data format.
You want to transform the data to data objects through a schema, something
that is hugely more supported through an XML schema or a defined JSON
structure.

>
>
>certRef is supposed to reference a value in the cert. When a value is in
>the subject field an attribute type is provided (eg "2.5.4.5" for
>serialNumber). However, there can be multiple serialNumber attributes in
>a DN (eg serialNumber holding an org number, then a serialNumber in a
>lower RDN holding a staff id).

It is assumed that you would not have multiple serial number attributes
holding exactly the same value.
But even if that would happen, the mapping still works. You get definitive
information about the source of the identity information.

>
>
>The example for authenticationInstant is "Feb 12, 2013 12:34:47 AM".
>Surely we should use a better date format for new specs. For instance,
>"2013-02-12T00:34:47Z".

This format is not defined by me. This is the JSON representation of a
date-time value.

>mimeType is a PrintableString. Can't we just use UTF8String for

Sure. But to my knowledge, mime type can always be expressed as printable
string. But I can change to IA5String.

>
>Object identifier are encoded in 3 different ways is this one extension:
>DER-encoding (eg 06 03 550405); dotted-decimal notation (eg "2.5.4.5");
>and as a URI (eg "urn:oid:2.5.4.5"). Perhaps that is "necessary", but it
>is unfortunate.

OK, Will look into that.

>
>
>The spec says applications MUST ignore any authentication context types
>they do not understand. What if the extension is marked critical? Surely
>you MUST understand at least 1 AuthenticationContext in that case?

If it is critical, you have to reject the cert. But I guess that could be
spelled out better.

>    IDENTIFIED BY {iso(1) member-body(2) se(752) e-legnamnden(201) 5 1} }

Do you mean in the ASN.1 section or the body. I have no strong opinion as
long as it works.

/Stefan

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 26 Feb 2013 13:52:50 +1100

> >no background as to what it is all about, but I am interested in
> >encoding certificates.
> >

ASN.1 has a well-defined and extensively used mechanism for "holes" in types that can hold arbitrary values defined later. Originally it used the "ANY" or "ANY DEFINED BY xxx" notation, though now we use Information Object classes to better indicate which field identifies the type of the value in the hole (and other details).

Embedding stuff in an OCTET STRING might work, but it is an abuse of ASN.1.

> >contextType value is supposed to identify the ASN.1 type of the
> >embedded value (like extnId). However this isn't explicitly stated;
> >there is no corresponding object class (equivalent to EXTENSION);
> there
> >is no "(CONTAINING ... ENCODED BY der)" constraint in the ASN.1.
> 
> The definition is perfectly clear. The mime type specifies the data
> format and the OID defines what the actual content is.

Is there a clear distinction between "data format" and "actual content"? I don't think so.

> From the context of an ASN.1 parser, this is just bytes to be handed to
> an upper application layer.

So the ASN.1 parser still has to just hand the bytes to an upper app layer, even when the bytes are an encoded ASN.1 value that the upper app layer has to immediately hand back to the ASN.1 parser.

> >contextInfo value. If the format is UTF-8-encoded text, the UTF-8
> >appears directly in the contextInfo OCTET STRING, not inside, say, a
> UTF8String.
> 
> Bytes is the most generic format. Conversion from byte to other formats
> is straightforward given that you know the data format given  by the
> MimeType.

Bytes is too generic. When you know you want to insert UTF-8-encoded text (as you do in this draft) it is better to use UTF8String.

> >for an elliptic curve public key). subjectPublicKey is not a good
> >example to repeat.
> 
> Why not?
> Its perfectly predictable and well defined, and provide exactly the
> degree of flexibility that is desired.

I don't know how much flexibility is suitable in this use case. The fact that the draft defines one specialised value (UTF-8 JSON with a specific SAML-related schema) suggests to me that a contextInfo OCTET STRING is the wrong place for flexibility.

> >certRef is supposed to reference a value in the cert. When a value is
> >in the subject field an attribute type is provided (eg "2.5.4.5" for
> >serialNumber). However, there can be multiple serialNumber attributes
> >in a DN (eg serialNumber holding an org number, then a serialNumber in
> >a lower RDN holding a staff id).
> 
> 
> But even if that would happen, the mapping still works. You get
> definitive information about the source of the identity information.

Since the JSON duplicates the values (eg "Valfrid Lindeman" appears in the cert subject name and in the auth.context extension) perhaps it isn't strictly necessary for certNameType & certRef to indicate a unique value in the cert.

The fact that values such as "Valfrid Lindeman" are duplicated in the cert looks like a flaw with this extension.

> This format is not defined by me. This is the JSON representation of a

I don't think so.
The closest I have found is ECMAScript Language Spec (5.1 edition, June 2011):
15.9.1.15 Date Time String Format
ECMAScript defines a string interchange format for date-times based upon a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ

> Sure. But to my knowledge, mime type can always be expressed as
> printable string. But I can change to IA5String.

Please don't swap a 74-character restriction (PrintableString) for a 128-character restriction (IA5String). Support Unicode; just use UTF8String.

> >    IDENTIFIED BY {iso(1) member-body(2) se(752) e-legnamnden(201) 5
> 1}
> >}
> 
> 
> Do you mean in the ASN.1 section or the body. I have no strong opinion
> as long as it works.

I meant replacing the AuthenticationContexts ASN.1 type with UTF8String -- dropping the flexibility to have multiple authentication contexts with multiple mime types and contextTypes. If another type comes along it can go in its own extension.

--
James Manger

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Feb 2013 09:58:18 +0100

James,

On 2/26/13 3:52 AM, "Manger, James H" <[email-masked]>
wrote:

>ASN.1 has a well-defined and extensively used mechanism for "holes" in
>types that can hold arbitrary values defined later. Originally it used
>the "ANY" or "ANY DEFINED BY xxx" notation, though now we use Information
>Object classes to better indicate which field identifies the type of the
>value in the hole (and other details).
>

No it is not!

An OCTET STRING is a perfectly valid placeholder for byte data that is
just byte data in the context of the ASN.1 parser.
This byte data will in most cases have some structure that makes sense to
an application.

This is exactly what is being done here.

>Is there a clear distinction between "data format" and "actual content"?

Of course there are.
Parsing the ASN.1 gives you three data objects.

1) data bytes from the OCTET SCTRING
2) a mime type (String) that lets you know whether the data bytes contains
JSON, XML or DER encoded ASN.1
3) An OID that defines the structure of the data content. If the mime type
is XML it will identify an XML Schema through which you can parse the
data. If the mime type is JSON it will identify a JSON Schema, if it is
ASN.1 it will identify an ASN.1 structure.

The ability to identify ASN.1 data is just for completeness, but that
should really be seen as an exception. In the implementations I have in
mind, you either want XML or JSON.
The reason why ASN.1 is default is because I haven't found any mime type
for DER encoded data, thus I solved that by having that as default.

>So the ASN.1 parser still has to just hand the bytes to an upper app
>layer, even when the bytes are an encoded ASN.1 value that the upper app
>layer has to immediately hand back to the ASN.1 parser.

Exactly. If it causes too much confusion, I'd rather take away the option
to provide DER encoded data. I don't need that option personally.
Embedding ASN.1 is the exception. Embedding JSON or XML is the typical
scenario.

>Bytes is too generic. When you know you want to insert UTF-8-encoded text
>(as you do in this draft) it is better to use UTF8String.

Former versions of this spec did that, but then it is not possible to
allow DER encoded data.
Having a byte blob allows all types of data. The mime type and the OID
makes sure that you know how to parse that data.

>I don't know how much flexibility is suitable in this use case. The fact
>that the draft defines one specialised value (UTF-8 JSON with a specific
>SAML-related schema) suggests to me that a contextInfo OCTET STRING is
>the wrong place for flexibility.

The fact that I too don't know how much flexibility is needed is the
reason why it is this open.
To me this is not a problem.

It is actually really easy to parse this extension, extract the data, oid
and mime type and hand it to the upper layer.
If the mime type is recognised, an application can do certain things with
it without understanding the OID, such as displaying the JSON or XML in a
viewer. If the OID is understood, the data can be parsed with a schema and
used to map against the original authentication context, such as a SAML
login context.

>Since the JSON duplicates the values (eg "Valfrid Lindeman" appears in
>the cert subject name and in the auth.context extension) perhaps it isn't
>strictly necessary for certNameType & certRef to indicate a unique value
>in the cert.
>
>The fact that values such as "Valfrid Lindeman" are duplicated in the
>cert looks like a flaw with this extension.

It is not a flaw. This is how it is supposed to work.
You may, as you pointed out have multiple occurrences of the same RDN
attributes.
One of them may be from one SAML attribute source and the other from
another SAML attribute source.

But I would not object to make the attribute value optional in the JSON
schema. That would actually make sense.

>ECMAScript defines a string interchange format for date-times based upon
>a simplification of the ISO 8601 Extended Format. The format is as
>follows: YYYY-MM-DDTHH:mm:ss.sssZ

You are absolutely correct. Thanks for putting me straight.
The date-time in the example happens to be the default serialization
format used by Gson (com.google.gson) that I use.
However Gson have an open interface for choosing date format for
serialization.

I have changed it to the format you suggest.
This needs to go into the spec.

>Please don't swap a 74-character restriction (PrintableString) for a
>128-character restriction (IA5String). Support Unicode; just use
>UTF8String.

Sorry, mistyped. No problem, I can use UTF8String.

>I meant replacing the AuthenticationContexts ASN.1 type with UTF8String
>-- dropping the flexibility to have multiple authentication contexts with
>multiple mime types and contextTypes. If another type comes along it can
>go in its own extension.

I really want to avoid defining a new extension if I find a reason to
provide other data.

The current model makes extension parsing generic. The extension parser
just extracts data, oid and mime type and makes it available to the upper
applications.
I can change data format without ever changing the cert extension
implementation. That is worth a lot to me.

I don't really see the problem you are trying to avoid.

The added flexibility really releaves the provided context info structure
from being perfect for all types of valid contexts and all possible needs.
If this one don't meet your need, you can define your own without having
to define a new extension or even touch your cert parsing code.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Feb 2013 15:29:43 +0100

I've been looking into this date-time thing today and it is a mess uglier
than was aware of.

Nothing seems 100% consistent.

ECMA is based on ISO 8601, but not exactly.
Further the ECMA spec uses a ":" sign in the timezone expression (+01:00)
instead of what common tools uses and expects, which is more aligned with
RFC 822 (+0100).

The Java SimpleDateFormat class that is used to stringify date and time is
using RFC 822 time zone, which seems to be almost compatible with the
successor of RFC 822 (RFC 5322), except that RFC 5322 seems to require a
leading whitespace.

I'm actually thinking that it would be better to simply use an XML schema
for this to get rid of this problem, since XML has a defined way of
expressing date.
That would also remove dependency on the JSON Schema draft.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 27 Feb 2013 00:20:42 +0100

James,

After going through the date thing, I concluded that the document would be
better defined and distinct using an XML Schema instead of JSON.
I therefore decided to agree with you and to simplify the extension.

I actually think the ability to define what XML Schema that is used is
enough and I really don't need the option of going JSON or ASN.1 for this.

I have updated the draft but missed the cut-off by 40 minutes.

The new draft is available here in the mean while:
http://aaa-sec.com/_temp/draft-santesson-auth-context-extension-04.txt

/Stefan