headers
Peter Gutmann | 8 Jun 2002 04:30
Picon
Picon
Picon
Favicon

Updated version of dumpasn1 available


This is the aperiodic announcement of a newer version of dumpasn1, my ASN.1
printing and diagnostic tool.  Recent updates include automated handling of
encapsulated data (if you're still using a version that uses -b and -o then you
really need to get this update), indication of bit positions in bitflags when
there's a single bitflag set, proper formatting of dates rather than just
dumping the ISO 8601 strings, and some other odds and ends.  It's available
from the usual location, http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c.

Peter.
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 1 Jun 2002 08:11
Picon
Picon
Picon
Favicon

Re: ASN.1 syntax for OCSP nonce value?


Geoff Elgey <gelgey <at> wedgetail.com> writes:

>This leads to the following: treating the V part of the nonce TLV as having
>some specific syntax is clearly implementation specific. Any OCSPRequest /
>OCSPResponse value inspected by third-party tools (such as Peter's "dumpasn1"
>tool) therefore MUST treat the nonce as an untyped blob.

The problem with this is that it's then in violation of all other definitions
of EXTENSION in any other standard (X.509, RFC 2459/3280, etc etc).  It's an
error in the OCSP spec which needs to be fixed.  Bride-of-2560 should include a
warning to implementors to say that older implementations may get it wrong (in
terms of what X.509/2459/3280 define) and that implementations should therefore
be able to handle either alternative, but what's actually used should be
consistent with the accepted definition.  Otherwise there's little point in
going through draft standards and whatnot if errors aren't corrected.

Peter.
Permalink | Reply | 0 comments |
headers
Tom Gindin | 3 Jun 2002 07:09
Picon
Favicon

Re: WG Last Call: Permanent Identifier


      Russ:

      I am not really convinced by point 3 of your technical comments.  The
point of the draft is that DN's are not sufficiently unique for
individuals.  This argument can be extended to organizations in general,
but organizations operating CA's are not all or even most organizations.
In any event, so many general PKI features break if CA's have duplicate
DN's, including CRL location and CMS signatures (the serial number/issuer
combination), that getting this particular feature to work in an
environment where CA's have such DN's is little help.

            Tom Gindin

"Housley, Russ" <rhousley <at> rsasecurity.com> <at> mail.imc.org on 05/24/2002
05:31:03 PM

Sent by:    owner-ietf-pkix <at> mail.imc.org

To:    ietf-pkix <at> imc.org
cc:
Subject:    Re: WG Last Call: Permanent Identifier

I have several comments on the Permanent Identifier Draft.  I have divided
them between technical and editorial.

TECHNICAL

1.  The OID value { id-on 2 } has already been assigned for another
purpose.  Please get fresh one.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Haaino Beljaars | 3 Jun 2002 10:13
Picon
Favicon

Validation


Hi,

What should I do, as an end-user, to 'validate' an (end-entity) certificate?
Is it enough to check the certificate path on (delta-)CRL,OCSP? Or should I do more: for example check to
repository and look whether or not the certificate was ever issued? Should I check the fingerprint of the
root CA against a published fingerprint?

Thanks,
Haaino
Permalink | Reply | 1 comment |
headers
Denis Pinkas | 3 Jun 2002 11:28
Picon

Re: draft-ietf-pkix-warranty-extn-01


Alice,

Thank you for inquiring. The new draft is still not adequate.

COMMENT 1

It is very questionable whether the implicit insurance model is appropriate.
The text says: " Usually, the subscriber pays for the extended warranty
coverage". The major issue is whether a subscriber pays a flat price that is
included in the price of the certificate or a price that is per insured
transaction which would be paid by the relying party. Implicitly the first
choice is being made but this choice is questionable.

COMMENT 2

It seems difficult to be able to take benefit of a warranty without proving
that there is a real damage. However, this would imply to disclose the
details of the transaction or the details of the damage. This is conflicting 
with privacy considerations.

End-users may be willing to disclose the amount of transaction that has been
guaranteed, but without providing the details. This does not seem possible
with that approach.

Another approach would be to obtain a warranty from a server to which only
the amount that is wished to be guaranteed would be disclosed. A signed
warranty would then be given.

COMMENT 3
(Continue reading)

Permalink | Reply | 3 comments |
headers
Denis Pinkas | 3 Jun 2002 11:37
Picon

Re: Validation


> Hi,

> What should I do, as an end-user, to 'validate' an (end-entity) certificate?
> Is it enough to check the certificate path on (delta-)CRL,OCSP? Or should I do more: for example check to
repository and look whether or not the certificate was ever issued? Should I check the fingerprint of the
root CA against a published fingerprint?

The full details are provided in RFC 3280:

   6.1  Basic Path Validation . . . . . . . . . . . . . . . . .  63
   6.2  Extending Path Validation . . . . . . . . . . . . . . .  80

There is no "more" to do.

How the root keys are determined is local matter. Using a fingerprint is 
one possibility.

Denis

 
> Thanks,
> Haaino
Permalink | Reply | 0 comments |
headers
Juergen Brauckmann | 3 Jun 2002 12:22
Picon
Favicon

Re: draft-ietf-pkix-warranty-extn-01


Hi Denis.

Denis Pinkas wrote:
 > COMMENT 2
> 
> It seems difficult to be able to take benefit of a warranty without proving
> that there is a real damage. However, this would imply to disclose the
> details of the transaction or the details of the damage. This is conflicting
> with privacy considerations.

Why should it be a privacy problem? In paper-world you are already
forced to disclose details on your damage if you want to get a refund
from an insurance. If you want money, you have to tell why.

Why is it necessary to object against this procedure when it is about
electronic transactions?

> Another approach would be to obtain a warranty from a server to which only
> the amount that is wished to be guaranteed would be disclosed. A signed
> warranty would then be given.

How can a warranty server solve the problem that someone is forced to
tell details about transactions if he wants to take benefit of a
warranty?

Regards,
   Juergen
(Continue reading)

Permalink | Reply | 2 comments |
headers
Phil Griffin | 3 Jun 2002 12:58

Re: WG Last Call: Permanent Identifier


<snip> 
> 4.  The Security Considerations section is pretty weak.  It mostly 
> restated the purpose of the extension.  I think that it should 
> contain advice for implementors that will make use of the identifier
> as well as advice for the
> 
> Assigner Authority.  For example, the Social Security Administration
> would be such an authority in the US, and they assign nine digit
> indentifiers.  Are 123-45-6789 and 123456789 the same?
> (snip)

One way to represent a series of integers efficiently is to
use the RELATIVE-OID type:

   SocialSecurity  ::=  RELATIVE-OID

   number  SocialSecurity  ::=  { 233  21  1022 }

   number ::= <SocialSecurity> 233.21.1022 </SocialSecurity>

This requires only one tag octet, and the code to implement
this type is nearly identical to that for OBJECT IDENTIFIER -
the same minus the restriction on the sets of values and the
merging of the first two nodes. 

This example value BER encodes for transfer in only five octets,
and XER encodes in 44 octets. The main drawback is that it requires
use of ASN.1 notation from this century ;-)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Denis Pinkas | 3 Jun 2002 14:41
Picon

Re: draft-ietf-pkix-warranty-extn-01


Juergen,

> Hi Denis.

> Denis Pinkas wrote:

>  > COMMENT 2
> >
> > It seems difficult to be able to take benefit of a warranty without proving
> > that there is a real damage. However, this would imply to disclose the
> > details of the transaction or the details of the damage. This is conflicting
> > with privacy considerations.
> 
> Why should it be a privacy problem? In paper-world you are already
> forced to disclose details on your damage if you want to get a refund
> from an insurance. If you want money, you have to tell why.

Not necessarilly. I have to tell how much. A good example is a payment
guaranted by a smartcard. An inquiry is made for a certain amount of money
and the warranty is granted for that amount. You do not have to tell which
goods have been purchased.

> Why is it necessary to object against this procedure when it is about
> electronic transactions?

See above.

> > Another approach would be to obtain a warranty from a server to which only
> > the amount that is wished to be guaranteed would be disclosed. A signed
(Continue reading)

Permalink | Reply | 1 comment |
headers
Denis Pinkas | 3 Jun 2002 14:39
Picon

Re: WG Last Call: Permanent Identifier


Phil,

> <snip>
> > 4.  The Security Considerations section is pretty weak.  It mostly
> > restated the purpose of the extension.  I think that it should
> > contain advice for implementors that will make use of the identifier
> > as well as advice for the
> >
> > Assigner Authority.  For example, the Social Security Administration
> > would be such an authority in the US, and they assign nine digit
> > indentifiers.  Are 123-45-6789 and 123456789 the same?
> > (snip)

> One way to represent a series of integers efficiently is to
> use the RELATIVE-OID type:
> 
>    SocialSecurity  ::=  RELATIVE-OID
> 
>    number  SocialSecurity  ::=  { 233  21  1022 }
> 
>    number ::= <SocialSecurity> 233.21.1022 </SocialSecurity>

This is not the direction we are planning to take. We need to be able to
accept spaces between the digits, we do not want to impose punctuation
marks. So we need loose matching rules where all control characters, spaces,
and punctuation marks can be removed; and then where the values are
compared using CaseIgnoreMatch.

This is this sort of wording that Tom and myself are planning to add to the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane